Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Ja

[Werner Keil <werner.keil@xxxxxxxxx>]

+1

The stability also would have to be guaranteed. 

MP showed some very bad behavior in other features like Health or Metrics where this was even so bad it affected the downstream products by Red Hat or IBM and it had to be reverted. 

That is nothing that must happen in a standards platform. 

Sure there could be "preview" features along the lines of the JDK but the stable ones cannot be broken every other month. 

And especially the biggest poster child and player in the Microframework space Spring has many features that came with Spring Framework and have been stable for almost two decades.

Werner 

On Mon, Apr 6, 2020 at 7:42 PM Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:

On Mon, 6 Apr 2020 at 18:43, Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx> wrote:

Hi,

This is clearly a topic a lot of people feel very passionately about. I’ve just read the discussion and my head is somewhat whirling.

It seems to me that it is premature to talk of a fork. I think the original route of the fork proposal stemmed from the items Reza raised which are:

1. MicroProfile doesn’t adequately capture IP flows.
1. MicroProfile doesn’t have a working group
2. MicroProfile doesn’t follow a specification process.

The difference in stability requirements is the main issue, not the IP flow.

 

Surely any fork of MicroProfile Config is going to be affected by those concerns, just pulling it into Jakarta EE in a different package namespace doesn’t make those IP concerts go away. Since the MicroProfile community are intending to resolve the 3 items, and likely well before Jakarta EE 10 happens it seems that a fork now is not really an option.

I think

1.Wait for MP to have a WG and Spec Process and then reference MP Config
2. Create something new
3. Wait for MP to have a WG and Spec Process and then fork MP Config

I think option 1 would be my preference, I get that for others it wouldn’t. I would hope that the MP Config community and the Jakarta EE spec committee would be able to come to an agreement to enable it.

I think option 2 has the problem that David raises which is I’m skeptical of getting a vibrant community behind both MP Config and Jakarta Config. I think one or the other will end up failing. The advantage of option 2 is of course it can be done now, whereas 1 has to wait for the working group.

I don’t like forking so I’m not keen on option 3 and since I think it is only viable if the MicroProfile IP issue is resolved at which point #1 is an option I consider this the least desirable outcome.

Thanks
Alasdair

> On Apr 6, 2020, at 11:49 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>
> With all due respect, it is clear we value different things. The things you suggest are unimportant are actually the things why some of us choose something like Java EE or Jakarta EE in the first place.
>
> The fact that MicroProfile does not have a vendor neutral working group, does not follow a well defined, structured process, the decisions seem be dominated by a narrow set of vendor commiters, has a weaker sense of compatibility, etc are very big defferences indeed. Indeed MicroProfile does not even aim to be an open standard whereas that is a central goal for Jakarta EE. That all said, these very things are what also makes MicroProfile valuable as a separate effort focused on meeting market demands faster through rapid innovation.
>
> I think it is also important to appreciate how important a sense of cohesion, both from a platform and ecosystem perspective is. Many of us choose the Jakarta EE model because we want to feel the APIs are are using are well integrated and uniform, following a well understood set of sensible norms from a common, trusted source. Again, if those were not preferences it makes little sense to use this technology set in the first place.
>
> With regards to your point with regards to API divergence, I think we can all agree at this point it is a necessary evil. Indeed that is a challenge more or less all standardization attempts or even software in general needs to address. Once the initial fork/standardization is done, there will be some need for further evolution. If the idea being standardized is mature enough, this should not be any more a challenge than it is for any other technology in Jakarta EE that also has non-standard alternatives in the market or even non-standard features in compatible implementations.
>
> With regards to Jakarta embracing innovation, I fully agree but even there I suspect we have very different values. Jakarta should remain a conservative open standard while allowing for the concept of standardization pipeline domains/projects of which MicroProfile could be one.
>
> Hope that provides perspective. We don't have to agree, but I do think it is important to recognize crucial differences in perspective.
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Jason Greene <jason.greene@xxxxxxxxxx>
> Date: 4/6/20 11:00 AM (GMT-05:00)
> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
> Subject: 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
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

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

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