Re: [jakartaee-platform-dev] Transitioning from Java EE to Jakarta EE an

[Edwin Derks <ederks85@xxxxxxxxx>]

Hi Mahmoud,

I have been reading your post a few times now, trying to provide you with a helpful answer in regards to the transitive dependencies as I understand your question.

In the vision of Java EE/Jakarta EE, it is recommended to solely adhere to, and compile against the API's of the specific Java EE/Jakarta EE version you have defined in your project. This way, you get application server portability and provides you with optimal developer experience since you shouldn't have to think about which version of what API you are using. Unless of course, you want to know what features they contain.

The Java EE 8 and Jakarta EE 8 platform dependencies as shown in the blog define their own transitive versions of the specification api's. These are different in regards to versions, yes, but by switching from the Java EE to Jakarta EE dependency, you shouldn't experience any issues in your code because the contents of the API's is byte-level compatible.

However, If I understand the meaning of the blog post correctly, it means that IF you have a specific (transitive) API version in your pom.xml from anything OTHER than the Jakarta EE dependency, this can become a mismatch in version. As a result, you end up with both API versions on your classpth which can become an issue when running the application. As you describe in your example, where a big project can contain multiple API versions, the answer imho is to cleanup/refactor/improve the application until everything adheres to the specific Jakarta EE version of the project, NOT try to cope with multiple API versions.

This kind of dependency issues are far more common in e.g. Spring Framework. Here you define some components you want to use in your project, which pull in LOTS of transitive dependencies. Since these might not be related and you aren't really able to control them other than exclude, they are in that case probably not aligned on version and transitive dependencies as it is done in a properly built application server. As a result, you can end up with all sorts of mismatching dependency versions on your classpath. Trust me, I've been there making these mistakes...

Easily able to prevent this is the strength of using Jakarta EE, as long as you adhere to the specifications and platform version.

Please let me know if this has helped you further.

Kind regards,

Edwin

On Mon, 22 Jun 2020 at 17:55, Mahmoud Anouti <manouti.dev@xxxxxxxxx> wrote:

Hello,

Sorry if this is not the best mailing list to send to. While reading the following article on transitioning from Java EE to Jakarta EE, I came across the following note on Maven dependency management when replacing a Java EE API with its Jakarta EE equivalent:

"For Maven, there are two totally different dependencies, and Maven will happily include both of them. This can happen, for instance, when a top-level dependency transitively brings in a Java EE dependency. Prior to the update to Jakarta, a transitively introduced javax.faces:javax.faces-api:2.2 would be overridden by, for example, a top-level javax.faces:javax.faces-api:2.3.

When that top-level dependency is changed to jakarta.faces:jakarta.faces-api:2.3.2, the 2.2 dependency will no longer be overridden and Maven will use them both, leading to all sorts of problems. If the transitive inclusion can’t be updated, this issue can typically be fixed by using exclusions..."

If I'm understanding correctly, this means if I'm migrating from e.g. javax.servlet-api:3.1.0 to jakarta.servlet-api:4.0.3, I would have to exclude javax.servlet-api from all transitive inclusions, otherwise two versions of the same API will be on the classpath. In a big project, there may be a lot of third parties that pull javax.servlet-api.

I've picked the above example on purpose: in my case I wanted to upgrade from Servlet 3 to 4 while migrating to Jakarta EE at the same time. But the need to add exclusions in other dependencies is holding me back from also moving to the jakarta groupId.

Ideally I would hope for a mechanism that tells Maven to treat jakarta.servlet-api:4.0.3 as a newer version of javax.servlet-api:3.1.0, as opposed to a completely different artifact. The closest thing I could find to theoretically achieve that was the Maven relocation mechanism. I wonder if anyone came across this issue and what they think about it.

Thanks,

Mahmoud

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