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...


On 7/27/21 4:49 PM, Cesar Hernandez wrote:

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?

https://ci.eclipse.org/jakartaee-tck/job/build-glassfish/ is a bad example as that job is not needed anywhere.  We added that to the Platform TCK CI so that we could start early testing of GlassFish 6 before there were builds available of it.  The job is pretty close to a one liner that just builds GlassFish.  I think that https://ci.eclipse.org/glassfish/ can already build GlassFish and I believe that TCK jobs were already copied over as well. 



 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.

I meant that the Platform TCK currently contains the GlassFish deployment descriptors for many tests and the GlassFish TCK porting kit implementation. 


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.

[1] is an example of the kind of descriptors that I am referring to. 

What I am asking here is whether others besides GlassFish are using the GlassFish deployment descriptors in their TCK testing?  IMO, this is important to understand since the GlassFish TCK porting kit implementation is likely be moved elsewhere (for EE 10) which would include the test deployment descriptors. 

If no, can you please expand a bit more on how this dependency exists currently in TCK Jenkins jobs?

[1] 


 


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