[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [microprofile-wg] MicroProfile and Jakarta EE
|
Hi John,
as discussed before (with a different
wording of the proposal), iJUG will vote with a definitive -1 too,
in MicroProfile and with a community vote in Jakarta EE.
Why:
In general, the option to fork Open
Source Software is a fundamental right of it (defined in it's
licences), for very good reasons!
While it's not the first choice
obviously, but when a project is moving into a direction that does
not fit to it's user(s) any more (i.e. changes of the licence
etc.) or stops developing at all, it ensures users can still
evolve the project in a different context.
This proposal leads to a Working Group
lock-in for a specification (technology)!
Think about a concrete scenario where
Jakarta specifications start directly depending on MicroProfile
(as it's the case the other way around already) and a MP spec does
not fulfil the need in Jakarta EE, i.e. does not support JPMS in
the right way and/or creates circular dependencies.
Should a Jakarta EE release get blocked
by MicroProfile (forever)?
The only solution with this proposal
accepted and if there is no agreement with MP to fix this might be
finding a third separate organisation for a spec that fixes the
issue - this creates again additional overhead.
With the current discussed proposals
supporting ranges of specifications (even with Major Releases) in
MP as a base and not heading for a single directed graph of
(component) spec versions, this scenario is not pure theory! And I
have strong concerns that we get managed multiple system
environments (resulting from the version ranges), when we still
test manually in both WGs...
Regarding the IP argument: I am not a
layer, but as far as I know, there are regions on this planet
where software patents allowed and create severe issues.
Notably, in the EU they are not allowed
by definition, but this is not the full truth in reality...
But issues that might came from this
side the EF tries to cover with the Membership contracts and
patent licences for the projects - that's why we use a foundation:
To take care of this, where we as developers don't want to take
are - or not being able to, because we decided not to became
layers.
Of course, below patents there are
things like trademarks, we need to take care of - i.e. protecting
our namespace or when forking, the namespace might need to change.
Next, why there is a need to have a
special agreement between these two Working Groups, that we would
not accept with other external ones and as we would not within one
of these WGs internally?
I think, it's because there is a
overlap in scope between Jakarta EE and MicroProfile!
iJUG decided to join these both WGs to
help to align them - one of the main driving forces was:
Users do not understand that there are
two separate WGs simply!
The longer story at that time was,
users of my age understood the historical reasons having two, like
MicroProfile's role in the late Java EE times with stalled
development, especially before it got moved to the EF.
But now - or when thinking out of the
perspective of a developer half of my age - how we justify the
overhead of having two Working Groups?
We still need to answer this question,
because MicroProfile lacks of a clear mission statement with a
evolving Jakarta EE!
One answer could be joining both WGs:
Combining component specs to umbrella
specs could be much easier and Committers could join their forces
- a lot of coordinating overhead could be omitted.
On the other hand then there are more
specs that need to be managed in on WG.
Personally I think, before this can
happen a lot of work need to be done on the technical and even
more on the organisational level (by taking the best of both
approaches hopefully).
Because of this it might be a viable
solution in the long run...
Another answer could be finding
separate visions for the future of both WGs:
MicroProfile could benefit from the
organisational differences related to Jakarta EE - with a smaller
set of specs and it's flat organisation it could evolve and
innovate faster.
The original mission statement of
MicroProfile was "Move fast and break things!":
We could go into this direction again
(which we don't do at the moment from my point of view) - then the
question is, what we want to do with widely used technics, that we
should not break for users?
Moving them as a hole or in part to
Jakarta EE could be one answer, if this makes sense. And regarding
the last, this should focus on technical aspects first, like spec
cohesion as Ed Burns mentioned in his last Jakarta EE WG
presentation.
Collaboration is a required here too,
but not enforced.
This proposal just freezes the
technologies to two separate WGs:
Working Group members got forced to
collaborate and there is a risk to block each other, even with
good intentions in mind.
Moving specs is then not allowed any
more, or need an exception from this rule.
In community work we need to convince
the others instead of being able to force them, as it is possible
in businesses or sometimes politics - but even there it's better
to convince instead of to force somebody in the long run.
Red Hat is a well known (good) citizen
in the Open Source ecosystem. Is this proposal really Red Hat's
direction in the future?
What users want to do is combining both specification sets (up to
in one single application) - and I think this overlaps quite well
with the vendors perspective, right?
So why we are not heading for improving
collaboration between the WGs?
May be the last one could be extended
to accept different namespaces for referenced APIs (like in MP
Telemetry has been done with directly using OpenTelemetry APIs,
instead of reinventing them in the MP namespace).
In shot: We should learn from each
other to innovate and evolve, together, by convincing.
A little longer: This includes learning
from ourself too, as a lot of us wearing a different hat in the
opposite WG too - I think we agree on this already.
Can I convince you? ;-)
Best,
Jan
PS: You might not know the fact that I
started my IT community engagement in the JBoss User Group Munich,
therefore I am really wondering about this proposal coming from
Red Hat's side...
Am 01.03.23 um 20:28 schrieb Reza
Rahman:
As discussed, if the substantive concern is around MicroProfile
JWT and Jakarta Security, then the next step is to facilitate a
direct, technically focused conversation between the
leads/committers of MicroProfile JWT (probably including David)
and Jakarta Security (probably including Arjan). Microsoft is
more than willing to facilitate such a conversation and believes
there is much room for productive compromise towards advancing
the best interests of end users, both technology sets, and the
broader ecosystem. It is best to defer other potentially
problematic/contentious actions before this conversation can
properly take place.
As previously stated, Microsoft would be forced to regrettably
vote -1 without further comment to the current resolution as
proposed.
I sincerity hope this helps us move forward in a productive
direction.
On 3/1/2023 2:08 PM, John Clingan
wrote:
Based on relatively recent discussions, Red Hat is concerned that specifications defined in MicroProfile may get forked into Jakarta EE. We have been having discussions on this topic for a month or so, and I took the action item of having the discussion on the microprofile-wg email alias.. The discussion was generated due to Red Hat’s proposed MicroProfile ballot (draft) verbiage:
”Resolved, the MicroProfile Steering Committee agrees to utilize Jakarta EE specifications in whole or part by reference and not by forking a Jakarta EE specification"
However, if we were to vote, then we would desire a reciprocal Jakarta EE Working Group, similar to the following:
”Resolved, the Jakarta EE Steering Committee agrees to utilize MicroProfile specifications in whole or part by reference and not by forking a MicroProfile specification"
To summarize where we are at with the discussion:
There is already some layering and/or referencing in place - MicroProfile layers on Jakarta specs in whole (JAX-RS, CDI, etc) and in part (JWT layers on some Java Security APIs like isCallerInRole() ).
We would like Jakarta EE to take a similar approach, and reference MicroProfile APIs instead of forking
We would like to gain consensus within MicroProfile, and then have the conversation with the Jakarta EE working group (perhaps via CN4J).
Status (feel free to correct):
Red Hat supports this proposal
Tomitribe supports this proposal (in the context of Intellectual Property)
Microsoft feels that if MP/Jakarta can attain technical alignment (ex: API by reference) and maintain vendor neutrality, then it is a step towards supporting this proposal
The remaining question is, is this sufficient context for us to engage Jakarta EE to attain alignment, or are there any outstanding issues to address before engaging Jakarta EE Working Group?
_______________________________________________
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
