[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [microprofile-wg] DISCUSSION: MicroProfile->Jakarta EE Proposal - namespace
|
From iJUGs perspective, the namespace decision is not a show stopper or
red line at all regarding the merge of the MPWG into the JEEWG, which we
support.
After collecting community feedback from the JavaLand 2025, this is our
preference in order:
2) Change the namespace to jakarta.*
1) Keep org.eclipse.microprofile
3) Change the namespace to jakarta.microprofile.*
Why:
I would be a bad outcome of the WG merge, when everything will be kept
as it is...
Users, especially new ones, do not care about the history, why things
are not intuitive and more complicated than necessary - it's just some
sort of technical debt that should be removed...
So, with the experience of the last namespace change in Jakarta (from
javax.* -> jakarta.*), tooling and a process to clean this up is
available. The namespace should become the jakarta.*, as the rest of the
Jakarta Component and Umbrella Specs.
As discussed in the MicroProfile Technical call yesterday, there are
some exceptions to that:
Jakarta made a decision in the past to move the Component Spec TCK to a
different namespace - this is a discussion that need to be held in
Jakarta, but I think, it was made for the wrong reasons as MicroProfile
gives the the proof that the API and the TCK can safely have the same
namespace, so it's technical debt that should be prevented to be
introduced to former MP specs and cleaned up or updated instead in
Jakarta. Of course, this could be a longer discussion there... ;-)
Scott brought up an aspect of maintenance: What to do with necessary
Service Releases to existing MP specs. Reason for this could be i.e. a
security issue, that need to be fixed, because a vendor would like to
continue to offer support on that version in their product. I think, in
this case, it's important to keep the existing namespace
org.eclipse.microprofile.*, as changing it introduces a breaking change
(which would require a Major Release instead). Deviating from the
situation in javax.* -> jakarta.* we will be allowed to even do MP spec
Major and Minor Releases on the old MP namespace too, but we need to
decide, which support for existing (and future) versions is required in
general.
Ed brought up, that the future Spec Teams at Jakarta might do the right
decision to change the namespace - I think that could be a way, but
might confuse users, when this is done step-by-step over multiple
releases, as they then need to be Major Releases all the time in the
Umbrella Spec, when introduced in a single Component Spec (Major
Release) as breaking change over the time. Doing this in a coordinated
way like it was done in Jakarta before makes sense to me (a new Major
Release with the new namespace only, then start further development
based on that).
Another exception would be MP Telemetry, as we decided to re-use the
existing OpenTelemtry APIs for good reasons in MP. Reinventing the API
in a jakarta.* namespace does not make sense to me. As there is no API
artifact currently with the spec, this might be a minor issue at the
moment, but introducing a Component Spec API (empty mostly, to manage
the dependencies only) was discussed in the past.
Option 3 is a compromise, that would not solve anything because it
deviates from the schema and breaks the API with historical information,
where it was created. On top it extends the namespace in length. When
thinking about moving Component Specs later within Jakarta Umbrella
Specs, this will create an additional breaking change or technical debt
then - we should prevent that, so this is my last order decision
regarding namespace. Also, as Scott said, there might be more potential
future namespaces to be discussed, they would probably fall into this
category from my point of view.
Best,
Jan
Am 06.05.25 um 18:50 schrieb Scott Stark via microprofile-wg:
Keep the namespace. Branding can happen at the spec project level and
above. Forcing another pointless namespace change is the last thing
Jakarta needs. If another project like Springboot wanted to come under
the Jakarta umbrella would they also be forced to change package
namespace? That would be ridiculously hostile.
If for some reason the namespace changes, the Jakarta MP project
should create separate releases of the spec API jars under the
original package namespace in addition to whatever new namespace
exists.
On Fri, May 2, 2025 at 3:39 PM John Clingan via microprofile-wg
<microprofile-wg@xxxxxxxxxxx> wrote:
At this week's Live Hangout, we continued to discuss the MicroProfile->Jakarta EE Proposal. To keep the eventual resolution "simple", the idea is to come to agreement "out of band" and "ahead of time", where possible. That way, we have a better idea of what the resolution encapsulates. We are going to discuss these items on the microprofile-wg email alias, followed by non-binding straw polls. These are areas where we currently do not have agreement. Many of the MicroProfile Working Group members are also Jakarta EE Working Group members. Not all Jakarta EE Working Group members are MicroProfile Working Group Members, but I'd like to encourage them to participate in this discussion.
The first topic is the MicroProfile namespace for existing MicroProfile specifications, which is currently org.eclipse.microprofile. This is arguably the most impactful discussion because it could result in a breaking change for developers and our customers. The question is whether or not this namespace remains if the MicroProfile->Jakarta EE resolution passes. I have seen a few options discussed so far:
1) Keep org.eclipse.microprofile
2) Change the namespace to jakarta.*
3) Change the namespace to jakarta.microprofile.*
I'd like to give a couple days of open discussion before opening up a separate straw poll email thread. Please respond to this thread discussing benefits and concerns.
Thanks!
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
