Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] Jakarta Platform TCK branching...

I would expect GlassFish testing to occur on the GlassFish Jenkins instance. 
+1, my understanding is that jobs like https://ci.eclipse.org/jakartaee-tck/job/build-glassfish/ will be moved to Glassfish Jenkins instance right?

 One potential issue is that the (many) GlassFish specific deployment descriptors are the closest thing that we have of representing the per test configuration deployment settings in a way that could be mapped to work with other compatible implementations.

Interesting, so this means the platform TCK depends on Glassfish descriptors. 
Are these [1] the kind of descriptors you are referring to in your reply? 
If yes, I don't understand why the Glassfish testing occurring in the Glassfish Jenkins instance will be an issue since we already have the descriptors in the https://github.com/eclipse-ee4j/jakartaee-tck repository.
If no, can you please expand a bit more on how this dependency exists currently in TCK Jenkins jobs?

[1] 
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jms/commonee/xml/descriptors/genericra/mdb_sndQ_ejb.jar.sun-ejb-jar.xml


 


On Tue, Jul 27, 2021 at 1:02 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On 7/27/21 12:37 PM, Cesar Hernandez wrote:
Regarding #1, the 9.0.x branch is archived. 

Thank you. For those that in the future want's to have a reference to the 9.0 branch at that point in time, I think the 9.0.0 TAG is the way to go https://github.com/eclipse-ee4j/jakartaee-tck/releases/tag/9.0.0

+1 as the `9.0.0` tag is the way to go!



Is anyone against renaming the `master` branch [3] to something else like `main`?  Any other name suggestions?
I'm +1 in changing from master to main. The collateral change this will trigger is an update on the Jenkis Jobs in ttps://ci.eclipse.org/jakartaee-tck/ right?

Platform TCK Developers also will need to rename their local master branch, something like:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a




Is anyone against moving (Jakarta EE Platform 10) TCK testing to somewhere else other than our Platform TCK CI [5] system? 
Do we have any proposal on where to move the Platform TCK?

As per the https://www.eclipse.org/lists/glassfish-dev/msg00728.html discussion, I would expect GlassFish testing to occur on the GlassFish Jenkins instance.  Other compatible implementations would keep testing wherever they have been testing previously. 

One potential issue is that the (many) GlassFish specific deployment descriptors are the closest thing that we have of representing the per test configuration deployment settings in a way that could be mapped to work with other compatible implementations. 



On Tue, Jul 27, 2021 at 9:08 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On 6/29/21 5:52 PM, Scott Marlow wrote:

We currently have the following Platform TCK branches:

  • 9.0.x [1] - was last used for handling Jakarta EE 9 TCK challenges.  I expect to use the 9.1.x [2] branch for any further EE 9 TCK challenges. 
  • 9.1.x [2] - should be used for handling Jakarta EE 9.1 TCK challenges.  Could also be used for any future 9.x minor releases (e.g. to create a 9.2.x branch if that is ever needed). 
  • master [3] - should be used for developing our changes for the next Platform release (e.g. Jakarta EE Platform 10). 

Questions:

  1. Do we need the 9.0.x branch [1] for anything at this point?  If not, I suggest that we archive [4] the 9.0.x branch.
  2. Is anyone against renaming the `master` branch [3] to something else like `main`?  Any other name suggestions?
  3. Is anyone against moving (Jakarta EE Platform 10) TCK testing to somewhere else other than our Platform TCK CI [5] system?  This would simplify the EE development process for the Platform TCK team and also ensure that no EE implementation is treated as a reference implementation in the future (as much as possible).  (Future) TCK challenge processing would likely need some changes for how we validate TCK challenges but that is likely easy enough to deal with.

Regarding #1, the 9.0.x branch is archived. 

Moving forward to EE 10, we can consider two separate development branches:

- Refactoring branch (e.g. perhaps `refactor`) that can initially test with Jakarta EE 9.1 for testing Junit, TestNG, Arquillian changes.  By keeping this branch on EE 9.1 we will be assured that tests should pass 100%.
- Master (or whatever we call it as per #2) branch that can sync up EE 10 Spec API changes later in fall (and `refactor` branch when complete).  By keeping this branch on the legacy TCK test facilities, we can initially test EE 10 Spec implementations before we merge in `refactor` branch changes.  If we don't finish the refactoring changes for the EE 10 release, we wouldn't merge the changes.  We do plan to complete the TCK refactoring changes but the main advantage of the branching is to keep the ability to run TCK tests throughout the EE 10 release.

Scott

Scott

[1] https://github.com/eclipse-ee4j/jakartaee-tck/tree/9.0.x
[2] https://github.com/eclipse-ee4j/jakartaee-tck/tree/9.1.x
[3] https://github.com/eclipse-ee4j/jakartaee-tck (master)
[4] https://github.blog/2017-11-08-archiving-repositories
[5] https://ci.eclipse.org/jakartaee-tck

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top