[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
|
> On Apr 6, 2020, at 9:05 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>
> From what I can tell, most people are seeing this as a last resort. I certainly do.
>
> For the folks I talk to, standardization is definitely a very important consideration. Indeed the desire to utilize a credible open standard
I don’t see much of a difference here: both are open source Eclipse Foundation projects, both are certainly “credible"
> (with everything that means such as cohesion,
Both define integration of technologies
> vendor neutrality,
Ownership for both is under the EF which is by definition vendor neutral
> governance,
There are slight differences in governance but it still mostly amounts fo Eclipse rules (e.g. contributors vote).
> process,
They also seem to have similar processes as best as I can tell.
> compatibility, stability, backwards compatibility)
Now we hit an actual difference. The goals for the specs under MP are to evolve rapidly, to prioritize innovation over never-ending compatibility. The big problem with using forking to achieve never-ending compatibly is that you can’t ever resync the fork, it is forever different and will forever lag behind the version that is still moving forward. Historically pruning takes years, so you are talking about pushing an outdated technology on users (which many will soon abandon) and then vendors will be stuck shipping it anyway just to pass the TCK.
In any case, the need to evolve and the problems that it introduces won’t go away after you fork everything into EE. In fact I would expect the best way you would solve it would be to create a new platform within Jakarta that prioritizes innovation much in the same way as MP does.
-Jason