Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Options for Jakarta EE and MP alignment



On Fri, Apr 3, 2020 at 8:03 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
On Fri, Apr 3, 2020 at 12:27 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
> Hi,
>
> On Fri, Apr 3, 2020 at 7:10 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>
>> The very fact that you point out how all vendors have non
>> interchangeable features indicates that it's not quite ready yet!
>
>
> I hear you, but by that token, would JPA be ready for inclusion in Jakarta EE today if by some twist in history it was never included and was now in MP instead?
>
> All JPA vendors have proprietary features even today.

This is a good data point, and a hard question that should be asked
is, "can we do better?".  Maybe that was the best that could be done
at the time, maybe not.  A standards body should strive for quality,
and that is not something that just *ends* one day.

>> There's only one road to stabilization, and freezing some
>> random thing *now* is not that road.
>
> I hear you again, but who's talking about *freezing* things?
>
> If a spec moves to Jakarta, it's not frozen. Though we still haven't decided on the exact cadence for Jakarta EE, the proposals uttered ranged from between three months and a year.

To clarify this point a little: moving the spec to Jakarta isn't
possible without buy-in from the people developing the spec, since
without that buy-in, we would simply continue to develop it in MP
Config, making it a "fork" not a "move".


This happened in many cases, on a small scale with Jakarta Inject although I would rather say that's a move, unless Google Guice, Dagger and Spring all decided to never adopt Jakarta Injection, but the 1.0 @Inject has effectively stalled and nobody worked on it for over 10 years now.

Or Hudson vs. Jenkins, we know how that ended.

Or Apache OpenOffice vs. LibreOffice (and NeoOffice, almost forgot there was a 3rd fork) This timeline https://de.libreoffice.org/about-us/chronik/ looks a bit misleading because it's by LibreOffice. They bump the first digit of the version number at least once a year, while OpenOffice has 4.2 planned only this year, but there were also regular releases and Apache claims over 280 Mio. downloads recently, so at least Libre and OpenOffice both look rather healthy and all 3 should be mostly compatible thanks to the OASIS OpenDocument spec.
 
> If you take into account specs can release things in-between Jakarta releases even, then in my book that doesn't quite sound as freezing the spec, does it? Or did you mean something else there?

Several things are possible, but there are a few basic assumptions.
The first assumption is that no matter what, it is very, very unlikely
that anyone will successfully force or convince the MP Config spec
team to stop working on the spec, at least for now.  So given that, if
Jakarta decides to fork the spec, they can either take a snapshot in
time, effectively freezing at the point where it was forked, or it can
continue to develop the spec.  Given that MP Config are also
developing the spec with (ostensibly) the same motivations (that is,
identifying and meeting the majority of significant use cases in a
specification with good quality), then either work will be duplicated
or Jakarta will be trailing behind MP (since MP can always pull things
from Jakarta, but Jakarta (due to compatibility restrictions) may not
be able to pull things from MP).  So given that, it is illogical
(though obviously possible) to fork and *not* freeze (at least from a
compatibility perspective).

This is why it makes far more sense to let MP Config work for a while:
the starting line for Jakarta Config would be in a far better position
as a result.

It depends very much on the resources that are really able to contribute to MP Config compared to the last 6-12 with very little activity and a a new release only this year with almost 2 years between 1.3 and 1.4 (that is almost longer than the time between Java EE 8 and Jakarta EE 8 with every spec at least refactored and also changes to the APIs not to mention the Open TCK) 

The time window to change a namespace while all the others have to change anyway won't last longer than till after Jakarta EE 9 is released. 
If the new WG properly applies the EFSP to MicroProfile and it is made easy enough to use those standalone TCKs in a future combined platform, then I guess it's up to relevant stakeholders in Jakarta EE if a mix of package or artifact names like "jakarta" and "org.eclipse" also on an API level is desired and acceptable. 

Werner
 
--
- DML

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

Back to the top