Skip to main content

[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.

I don't think IP clearance is really the issue here.  You could fork
the JSR, or MP Config 1.3, or MP Config 1.4, and you'd still have the
same problem which is that you'd have to get bodies working on the
specification to bring it up to a reasonable level of quality, which
is what we (the MP Config team) are already doing.  Why not wait and
get the benefits of that work for free?

On Mon, Apr 6, 2020 at 12:28 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Hi,
>
> Any fork of MP Config before all of these issues had been fully resolved would indeed be affected, but this  https://github.com/eclipse/ConfigJSR  isn't ;-) If the MP WG and individual features like MP config can't get their act together with regarding all 3 points, there is an option 4. which is fork the already IP cleared Config JSR which basically ahead of MP Config 1.3 and only missing a few things that went into 1.4, but the delta can't be so huge, several here already stated the list of open issues is longer than that of new features with 1.4 (still curious about that delta btw, could not find it in the release notes) therefore instead of 2. create from scratch 4. fork the proper JSR would be better than having to write everything over again.
> Just like the Jakarta Inject only with a few more API elements.
>
> Werner
>
>
>
>
> On Mon, Apr 6, 2020 at 6:44 PM 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.
>>
>> 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



-- 
- DML



Back to the top