Hello All,
We had the same idea about adding a classifier or altering the maven
coordinates. What we found is that adding "-jakarata" to the artifact
names worked extremely well and required very minimal changes to the
Tapestry 5 gradle build. One benefit of this approach is that we were
able to use the same version number for both javax and jakarta artifacts
since they effectively have separate namespaces.
We also investigated the classifiers approach, but abandoned that idea
quickly since it required much more extensive project changes. We also
ran into major problems with IntelliJ's handling of source and javadoc
archives with another library that went down that path (Apache Shiro
IIRC). In that case, they used a transform to generate the jakarta
artifacts from the javax artifacts. The net effect was that the IDE was
confused by the classifiers and selected the wrong sources and javadoc
archives.
FYI - On a related note, we have been tracking changes to the master
branch for our jakarata build, and encountered a runtime breakage in
some of the recent changes (~ 3 weeks ago). The errors we encountered
were of the of form "Exception assembling embedded component...". We
were very pressed for time when this happened, and have not had time to
track down the root cause. I read somewhere that this was a known issue
to be fixed in 5.8.7.
Regards,
David
On 8/7/2024 2:40 PM, Dmitry Gusev wrote:
Hi Thiago,
Just a thought, but did you consider to have a `jakarta` word somewhere in
the artifact coordinates?
Either in the artifact names or as a classifier in the versions. This way
we could still have release numbers continue naturally and let the users
pick the flavor. We can eventually stop producing non-jakarta flavors when
time comes, if ever, or do javax/jakarta-only fixes if necessary skipping
the flavors where it would make sense.
Having holes (regardless how big or small they are) in version numbers will
break semver and tooling that rely on its conventions potentially.
Regards,
Dmitry
On Wednesday, July 31, 2024, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
Hello, Tapestry community!
As already discussed, the Jakarta EE an javax.servlet versions of the
Servlet API have some differences that go beyond the package rename, but,
at the same time, the Tapestry team won't leave the javax.servlet users
behind. We'll have 2 different branches, master on Jakarta EE) and javax,
and we'll keep them in feature parity as much as possible (of course,
Jakarta EE is the living API, while javax.servlet is dead, so any future
Tapestry feature that depends on something Jakarta EE has but javax.servlet
doesn't won't be backported to the javax branch).
With the approach decided, we arrive at a problem similar to what same say
is the most difficult one in software development: naming things. Current
Tapestry is at version 5.8.6. What should be the version number for the
upcoming Jakarta EE-supporting version? I'd like to remind everyone that
the project itself is Tapestry 5, given it's a complete rewrite that shares
no code with Tapestry 4 and other previous versions, so, for example,
version 5.8.6 should actually be considered version 8.6 of Tapestry 5.
The Tapestry team has come up with some suggestions:
* 5.50: Pros: 50 is a round number, half of 100, a lot larger than 8, so we
have a lot of room for new Tapestry major releases of the javax branch to
be 5.9.x, 5.10.x, etc. Con: no easy association between javax and Jakarta
version.
* 5.19: Pros: 9 is the Jakarta EE version containing the Servlet API
version with the jakarta.servlet package used by Tapestry in the branch
that supports it. While it doesn't leave as much room for new major
releases of the javax branch, it does leave a good number. Con: no easy
association between javax and Jakarta version.
* 5.18: Pro: easy association between versions of javax and Jakarta
branches, which would be kept in a constant version difference. We could
even have the first Jakarta release to be 5.18.7 while the javax release
would be 5.8.7 (we're planning to release it in the upcoming weeks). Con:
less room for major releases.
* 5.28: Mostly same as above, but with larger room for major releases.
* 5.9: Pro: matches the Jakarta EE version. Cons: no room for major
releases at all. (Me, Thiago, really dislike this idea, but another
committer suggested it and really loves it, so here it is, hehehe).
* Something else you suggest (with rationale, please).
There's no perfect solution. All of them come with a bit of confusion. I
personally would go with either 5.18 or 5.28 and have the first release
being 5.18.7 or 5.28.7 to align with the upcoming 5.8.7 release.
I'm looking forward to your feedback.
Cheers!
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
