eclipse-ee4j/cargotracker

Move to Jakarta EE 10

Closed this issue · 21 comments

Essentially update namespaces. There may be some Java SE 11 features that may be applied.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

So for Jakarta 8 we are introducing the new features form Java 8 and the Jakarta 9 version will require Java 11+, right?

Yes, that's the idea. Jakarta EE 9 targets Java SE 11, so it is fine to begin applying those features at that point (though I imagine these changes would be very small). Jakarta EE 8 targets Java SE 8, so it is best to stick to that version for the Jakarta EE 8 release (and there are many places where Java SE 8 features will apply).

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

ggam commented

Does it really make sense to maintain two versions, one for Jakarta EE 8 and other for EE 9? Isn't it better to just move towards 9 with Java 11?

One of the most frequent requests for the original Cargo Tracker project was supporting various versions of the specifications as people are most often not using the latest. It is a bit too much work to try to support Java EE 6 now, but Java EE 7, Jakarta EE 8 and Jakarta EE 9 should be easy. That said, the older versions will be separate branches from which we will do releases (and possibly back-ports) but the master branch will try to reflect the latest version of the technologies that we have bandwidth to support. Either way, we will need to do gradual adjustments to a fairly non-trivial code base, so the effort is mostly the same to support older versions of the technologies.

I will document some of this in a road map shortly. The Eclipse Foundation had asked for one from the start, but I just could not prioritize it so far.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

ggam commented

Makes sense. I'm keeping an eye on this repository and will try to contribute where possible.

To be honest, we first need to stabilize the project and have a solid Java EE 7 initial release including resurrecting the website and documentation. The code base is now old so we need to make sure it's dependencies still work. Also, there are many bugs that were never properly resolved. Theo has been doing a pretty good job taking care of the code and maybe Nishant can help us with the website and GitBook.

I think once the initial stabilization is done, it may be easier to divide up the work cleanly. I will do a call to action when we reach that point (probably in a few weeks).

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Is anyone starting this task? if nobody did this, I will start a branch for this.

I have assigned the issue to you and will look at the PR ASAP. I am sure it’s fine.

We need to defer this until Payara (and other implementations) bring Jakarta EE 9 support to production.

Hi @hantsy, are you still working on this? Since Payara 6 is released now, we can get it done? Can you issue a PR against master? Also, can we just move to Jakarta EE 10 instead?

I have tried to update my personal example projects to Jakarta EE 10, both are working well.

The left problem here is the Arquillian issue(it is really not active as before), there is a big issue when using Arquillian Drone/Graphene and JUnit 5 to test page object.

Is Arquillian generally working with JUnit 5, Payara 6 and Jakarta EE 10? As you know, we don't use Drone/Graphene. If not Jakarta EE 10, could we try a move to Jakarta EE 9? Either way, do you think you can do a PR against master?

This project does not test the pages(so we have not use Drone/Graphene yet).

I think moving to Jakarta EE 10 is more valuable, Jakarta EE 9 just updated the jakarta namespace and did not introduce new features.

I will try to send a new PR for Jakarta EE 10 in this week.

Awesome! I will look for it! I’ll assign the JUnit 5 issue to you as well. Will be great to take care of that too!

Going forward, @ojuschugh1 will be handling this.

hi @hantsy
I am facing a problem when i am trying to run GitHub branch omnifish-jee10 of cargtracker in eclipse ide .Even though i have followed the same steps told in the readme.md.
I am using eclipse ide latest version,jdk 17,payara 6 .Could you please tell me how to resolve this issue as i am working on this project as you have worked with jakarta ee 10 .
Can Jakarta EE 10 even work in eclipse ide with Payara for the omnifish branch ?

Thanks and Regards
omnifish

He means the Eclipse IDE Java EE bundle. It has tools for Java EE and web development.

Fixed by #272.