> MP is a much younger technology. I would say that compatability in MP is comprable to
> what it was in Java EE at the same stage of development.
At least the 2.1 release looked like only one updated feature even made it into the release train, so it seems almost too often for the majority of features.
>I think assuming that MP does not have decent quality is assuming too much without any >evidence to back it up. I'm not saying the technology or the process is perfect, but you could >hardly say that about Java EE either.
The evidence is primarily seen on GitHub or other places where some MP projects just stopped contribution in early 2018 or before, so they can no longer be considered “Agile” or up-to date with a stack that releases new features and a release train at least once per quarter. They are outdated and no longer compatible with e.g. MP 2.0 or even 1.4 in many cases, which is very hard to track.
With Java EE this compatibility is monitored and guaranteed by the TCK/Oracle:
https://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html
You can see, the list got shorter with every Java EE version down to only the few vendors who care for compatibility (while Glassfish 5 is Java EE 8 compatible, even Oracle’s own Weblogic products are not yet ;-)
If a proper matrix like that was maintained for MicroProfile, I’m sure, the list of MicroProfile 2.1 compatible runtimes would be even shorter than that for Java EE 8, but nobody cares or dares to create that list.
And even without a “Jakarta EE Certified” or “MicroProfile compatible” tag, I am pretty sure, Eclipse Foundation would at least like to have such matrix for the sake of users, so they don’t need trial and error to find out what works for them.
> It's really, really important to understand that MP can be very complementary to Jakarta EE, > but it should not be limited to that platform.
Interestingly Pivotal/Spring seems to have more synergies with Jakarta EE or at least parts, while the strong focus on competing DI framework CDI makes it rather unattractive to combine with a Spring stack.
Werner
I think you are forgetting that Jakarta EE requires a substanital effort to move from Oracle over to EF, thus the number of commits can be expected to be high. In addition, Java EE and its consituant specifications have been around far longer with many more touch points so a lot more work is required to keep it going. In comparison, MP is fairly lightweight and although you may not see as many commits, it has had a large number of releaases in its short life.
The percentage of individual contributors is roughly the same, in Jakarta EE Oracle still does a large share, but it’s less than individuals already. And even Pivotal which is often seen as a major competitor has contributed to Jakarta EE (more than Red Hat over the past 3 months ;-)
The list of projects/products on the MicroProfile project page says nothing about the compatibility. Some are pet-projects by just a single person and say nothing about which version(s) of MicroProfile they are even compatible with. Others look pretty outdated and abandoned or stopped at 1.0 compatibility.
MP is a much younger technology. I would say that compatability in MP is comprable to what it was in Java EE at the same stage of development.
If you want Enterprise grade quality and compatibility, not all of them seem suitable.
Not all Java EE solutions are suitable either. It's a market; there are choices.
Mike has not fully elaborated on details, guess we’ll have to hear and discuss that after the holidays, but some of the issues I mentioned here are probably worrisome to Eclipse Foundation as well, especially that almost every project or product can put a “I do MicroProfile” sticker on their page and some don’t always have the resources to keep them up to date and provide a decent quality, which puts a bad light on the whole project and Eclipse ecosystem.
I think assuming that MP does not have decent quality is assuming too much without any evidence to back it up. I'm not saying the technology or the process is perfect, but you could hardly say that about Java EE either.
It's really, really important to understand that MP can be very complementary to Jakarta EE, but it should not be limited to that platform.
Werner
Sent from Mail for Windows 10
Why do you not want Jakarta EE to be independent and agile?
Richard Monson-Haefel wrote on 12/20/18 2:24 PM:
Mike,
You have alluded to this problem before - that MP will have to adopt the EFSP - but I don't recall you providing an explanation. That would probably go a long way in helping folks like me understand why other projects suddenly have to adopt the EFSP. I'm all for it with Jakarta, but MP has been doing fine without a formal process and I would like to see it remain independent and agile. Sorry if this gets people's knickers in a kerfuffle but its a valid point of view considering how little we know about your position on the subject.
On 2018-12-20 11:54 a.m., Richard Monson-Haefel wrote:
Given that the MP has not planned to adopt the EFSP, I wonder if Microprofile should move to a new host? It might be the best solution for all.
I don't find that to be a very constructive comment given that you haven't even heard what our concerns are. And the issues that we are seeing are not going to go away if it's hosted somewhere else. Success comes with greater responsibilities.
Plus, as Steve pointed out we already have an example of a MicroProfile spec entering the JCP process. So there is already an entirely community-led precedent to follow.
Perhaps we should down tools on the email and discuss this in real time in January.
On 2018-12-19 12:36 p.m., Scott Stark wrote:
We should be looking at elements of the MicroProfile process that seems to work and attempt to accommodate the possibility of MicroProfile using a future EFSP, but I'm not convinced that it is a requirement, and potentially not even possible.
Scott, et al,
I guess I was being too subtle in my previous email on this thread. In our opinion, simply maintaining the status quo is not an option. Adoption of the EFSP by MicroProfile is a question of when, not if.
The existing specification process and licensing regime for MicroProfile is causing the Eclipse Foundation serious concerns. We do not feel that the status quo is an acceptable long term scenario. This is the result of both the success in the industry that the specifications are achieving, and what we have learned as an institution as we created the EFSP.
Happy to explain more details on a call.
![Avast logo]()
| This email has been checked for viruses by Avast antivirus software.
www.avast.com |
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
https://www.tomitribe.com/
