Flexible transitive dependencies JavaEE or JakartaEE 8 (while binary compatible) "Two poms one jar" #134
Conversation
Signed-off-by: Gordon Hutchison <[email protected]>
Signed-off-by: Gordon Hutchison <[email protected]>
|
Does this mean a user project would need to inherit from this pom? How does the profile become accessible to a user application? |
|
@kenfinnigan my intention was that: Of course that is build time, run time (for example in Open Liberty) may bundle an api-jar and replace its pom. I do not believe the users's project pom.xml would have to inherit from this one. |
|
By the way @kenfinnigan , I originally had all the did not work here as the 'earliest' jakarta CDI release is 2.0.1 whereas the javax |
hutchig
changed the title
|
I actually get a much cleaner If I put the 'dependencyManagement' stanza nested within the javax/jakarta profiles too. So I will drop a commit that does that...as I have defined the javax and jakarta profiles Spot also above how MicroProfile Health is still pulling in javax version of CDI under the Jakarta profile...I will investigate... |
Signed-off-by: Gordon Hutchison <[email protected]>
|
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html |
|
TODO: Gordon to investigate if profiles are active in pom's which are not parent poms when a jar is used as a dependency - i.e. can a profile be used to control a 'transitive' dependency being present or not. |
|
To answer a question from the MP Community hang out I did a Then can show that an application can effect the transitive dependancies with the system Note that |
|
A further test would be for the mpUser project to just refer to a specific |
|
I can confirm that it works @kenfinnigan : 1 - change a microprofile spec pom.xml to a have the parent and delete I chose RM as that is one I had to hand... Have a user project that depends on the api: Test if the -Djakarta flag on the user's project build has an effect on which transitive So yes - the "two poms one jar" idea is implementable as long as the So as this is mostly a demonstration to show how compatible Jakarta and Java EE 8 |
|
If I understand correctly, the BOM needs to be imported in the |
|
@kenfinnigan You can see in this example that the bom or parent project is not referenced directly in the user project at all but only transitively via the child MP api spec jar's pom. The minimal set of information for matching a dependency reference against a dependencyManagement section is actually {groupId, artifactId, type, classifier}. I think the sweet spot is to have a user project just reference a MP api jar Of course some MP platforms rebundle anyway and then user will tend to have something like |
|
I thought it was, as the user app example earlier has: |
|
@kenfinnigan it was initially but then I modified it, see above the text which has: Apologies that this was not clear. |
Signed-off-by: Gordon Hutchison <[email protected]>
This pull request illustrates how a pom can support the
'two poms one jar' idea i.e. Jakarta/Java EE can be easily toggled.
See the Oct 8th Architecture call minutes action item.
This idea is not technically necessary, and should not be merged, if at all,
until MicroProfile is based on Jakarta officially. It serves only to help
demonstrate that Jakarta EE8 is a no-change-required switch by showing
easy switching with absolutely no changes to the jar used.
This idea is that, as a jar built with Java EE 8 or Jakarta EE 8 dependencies
is an identical binary (as all package and class names are identical - the maven
group and artifact ID is purely a build concept and does not leek into the jar file
(at least for Java/Jakarta EE 8), then one can use the same JAR for building
against regardless of if one wishes to get EE8 dependencies (and their transitive
dependencies) from a Java EE 8 or Jakarta EE 8 based project.
We can use dependency management in the top level MicroProfile project
to control this for all MicroProfile projects centrally.
A user can control the transitive dependancies being JakartaEE or JavaEE
by setting or not setting the "jakarta" SystemProperty ("mvn -Djakarta clean package").
try
"rm -rf ~/.m2/repository/jakarta/ ~/.m2/repository/javax && mvn -Djakarta clean package"
or
"rm -rf ~/.m2/repository/jakarta/ ~/.m2/repository/javax && mvn clean package"
to see what it does.
Profiles are multi-dimensional so it is possible to have {release, jakarta} as both
active etc.
Of course, the user is not rebuilding our jar nor the individual spec's jars and to some
extent, that is the point.