New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFLY-15035][WFLY-15036] Use source code transformation to produce a native jakarta namespace variant of the mail subsystem artifact #14485
Conversation
WF Preview tests: https://ci.wildfly.org/viewLog.html?buildId=264432&buildTypeId=WF_Ee9BootableJarLinuxJdk8 First one passes; second has two failures we are seeing in many places so not likely relevant, discussed at https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/ClusteredMessagingTestCase.20failures |
<!-- TODO implement WFGP-206 or use maven-resource-plugin filtering to drive this | ||
value with an expression so we can use one source file for both javax and jakarta variants | ||
of this module --> | ||
<artifact name="${org.wildfly:wildfly-mail-jakarta}"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be a possibility to use the same artifact instead of renaming it? I mean, instead of having a wildfly-mail-jakarta version, use just wildfly-mail.
That would avoid the need to overwriting the artifact in the module.xml and deal with the license stuff.
After all the transformed artifact is built when the server is built. The problem is the artifact is installed in the local repository, so, if you are moving from Jakarta EE to Java EE locally, you need to build the server and you could have no certainty about which artifact are you using. Not sure if there could be other bad sides. So, just asking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requirement is to produce both javax.* and jakarta.* artifacts in the same build and deploy them to nexus. People using a jakarta.* namespace variant of WF should be able to provision a server solely with artifacts pulled from remote maven, with no provisioning-time transformation.
See https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/LE6CBNDI3GNXWVX4DOZLU5QNPZQWFJ7K/ for a discussion of how to avoid duplicating the module.xml. But the license stuff I think is unavoidable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, right, I understand. I raised an invalid approach here, although the wildfly-mail is built by the server, we still need to make a distinction, (version, classifier) so feature packs are able to retrieve the expected one.
mail/src/test/java/org/jboss/as/mail/extension/MailTransformersTestCase.java
Outdated
Show resolved
Hide resolved
…ta namespace variant of the mail subsystem artifact
https://issues.redhat.com/browse/WFLY-15035
Also https://issues.redhat.com/browse/WFLY-15036