Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Detach JavaMail #6165
Detach JavaMail #6165
Changes from 2 commits
32f1fac
15b1fdd
1348ffb
72bc903
21e2f37
b87684e
64aeabb
5103131
e6cb360
aa974a6
faf50aa
8f99ae4
ed7b370
770dd8f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
We used to bundle 1.6.5 and now we are detaching 1.6.2? https://github.com/jenkinsci/javax-mail-api-plugin/blob/javax-mail-api-1.6.2-1/pom.xml#L47 vs.
jenkins/bom/pom.xml
Line 325 in c31d930
BTW you may consider https://www.jenkins.io/doc/developer/publishing/releasing-cd/#pom-file-modifications having plugin version automatically track library version. Otherwise it is all too easy for Dependabot to let https://github.com/jenkinsci/javax-mail-api-plugin/blob/e8b4d80f40e47e76aad413366953d333b0975f97/pom.xml#L36-L47 get out of synch.
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.
Correct. Really the root cause of this problem is that the Jakarta organization published a few releases under the original package names before switching to the Jakarta package names. I suppose we could release a 1.6.5 version of
javax-mail-api
that switches to the last Jakarta organization release prior to the Jakarta package rename. But then plugins wouldn't be able to depend onjavax-mail-api
andjakarta-mail-api
concurrently without awkward Enforcer conflicts. Seemed simpler to avoid the issue by sticking to the last pre-Jakarta-organization release. I have not been able to find any meaningful differences between the last "pre-Jakarta-organization" release and the last "post-Jakarta-organization-change-pre-package-rename" release that would affect end users, much less any binary incompatibilities.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.
Sorry, I did not follow much of this. My understanding was that 2.x uses the new package name while 1.6.x uses the old. What is the delta between 1.6.2 and 1.6.5?
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.
It's a bit tough to explain, but 1.6.2 was the last release under the original
groupId
andartifactId
(and used thejavax.
package namespace). 1.6.3, 1.6.4, and 1.6.5 were released under a new JakartagroupId
andartifactId
(but still used thejavax.
package namespace). 2.0.0 was released under the same JakartagroupId
andartifactId
(but used thejakarta.
package namespace). So this makes things a bit awkward if you want to put both the oldjavax.
classes and the newjakarta.
packages on the same classpath. You can't easily do that with 1.6.3, 1.6.4, and 1.6.5 because they share the samegroupId
andartifactId
as 2.0.0 (despite having different packages).This doesn't matter much for production, but it does matter for plugin/BOM tests that might pull in e.g. both
javax-mail-api
andjakarta-mail-api
as test-scoped dependencies. If I had used 1.6.5 injavax-mail-api
that would have forced me to use the JakartagroupId
andartifactId
, which would then conflict with the 2.0 version fromjakarta-mail-api
. If you want to have both sets of packages on the classpath at the same time, you basically need to stick to the original pre-Jakarta group ID and artifact ID, which also means being behind a few very small minor releases.Just how small? See https://eclipse-ee4j.github.io/mail/docs/CHANGES.txt
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.
OK, makes sense now, thanks for explanation!