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 know if JNoSQL will have to wait for the use of MP Conf till it applies the EFSP, because it is an implementation.
The API part certainly cannot now. 

Sorry if the Spring example was hard to get, but the point was that even on the API and Jakarta spec level there is a need to allow things like Remote configuration of the data source and similar app server and enterprise application properties. 

Giving @PersistenceUnit and all the similar annotations in other Jakarta EE specs a chance to configure the application A on environment X remotely in a more unified way is what the Jakarta platform needs in similar ways e.g. Spring Boot already has.

I work with major clients every day and one of the biggest problems for them is that in legacy systems based on Java EE 5 (if you are lucky ;-) to 7 they often end up with a different behavior of a service in DEV, UAT or PROD and sometimes waste days or weeks try to find out which service uses which properties file, XML or table in a database.

Werner 

Emily Jiang <emijiang6@xxxxxxxxxxxxxx> schrieb am Sa., 4. Apr. 2020, 12:28:
I have 2 comments to make:
1. It is orthogonal to debate here how good MP Config is. For different people, you might get a different answer. However, majority feedback is very positive. Sure, there is still room for improvement and more features need to be added to make it more powerful, more effective and performant. It is not perfect but it is  very useful already.

2. Let's just look at what Otavio needs and provide an answer in this thread. Otavio and I had a brief chat and went through his use case in terms of JNoSQL. It turned out JNoSQL does not require a full Jakarta Config spec but wants some JNoSQL properties to be visible to applications. In more details, there is no Config API dependencies required from the JNoSQL API jar. All JNoSQL needs  is to state some properties must be available to the applications as config properties. With the support of MP Config, the JNoSQL spec can state "refer to MicroProfile Config for how to look up the properties, e.g."
@Inject
@ConfigProperty(name = "suffix")
private ColumnFamilyManager manager;
In this case, even though MicroProfile Config has made any subsequent changes, JNoSQL is not massively affected as it has no direct dependency on its jars. Only TCKs have direct dependencies on MP Config and they can just pick a version of MicroProfile Config and stick to it. For end users, they can choose the version of MP Config they want to inject JNoSQL properties.

Therefore, I think once MicroProfile has sorted the WG (hopefully in a few weeks), it should be feasible for JNoSQL to adopt MicroProfile Config and make progress. It will be much easier for JNoSQL to move forward to declare 1.0 release instead of waiting for a spec to be created and then releaased first, which could take a long time.

My 2cents.

Emily





On Fri, Apr 3, 2020 at 11:43 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
The decision cannot be made here and while MP could state whether it wishes to donate some stable specs and features voluntarily from its side or not, that does not dictate anything for Jakarta  EE.

The bodies to make such a decision e.g. the Spec or Steering Committee will have to initiate a vote there or a number of questions like that of the namespace. 
Unless a WG (one for MP alone or one for both) gets the MP specs (all or if they would have a choice those that want to qualify for spec usage) to adopt the EFSP none of this is relevant, not even a direct fork of the code, because the toxic IP situation.
The old Inject Spec like CDI or Bean Validation had a few exceptions at JCP.org already, e.g. using another license for the spec, but they were governed by the JCP like all the other specs, therefore a fork or migration of the Inject JSR to Jakarta Inject was possible, but from the current MP Config it would be much more risky. Thats not the case for  https://github.com/eclipse/ConfigJSR  btw, the JSR could probably be forked much more easily from an IP and process point of view ;-)
 

Werner 





On Sat, Apr 4, 2020 at 12:18 AM Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
I think we should pause for a while and thnk why this thread started. The profound reason is that it's not clear whether JakartaEE can adopt MP specs such as Config. It seems that people not affiliated with MP mostly think that it can't because MP with its pull model can't provide enough stability guarantees for JEE. People behind MP mostly think that it can or will be able to do so in the near future, at least for some specs.

We should resolve this question first before going into disputes whether to fork MP config or not. 

So, is it possible that some JakartaEE specs (Otavio named JPA, JNoSQL and JMS) will be able to consume MP Config after by the time JEE is released? That should be in about 18 months I guess. Or is it not possible and forking MP specs is the only option? 

Last time we talked about it I remember the answer was clear No because of IP reasons. Would it be possible when MP has a WG? Or something else is required? Maybe some guarantees from MP on top of the pull model? 

Ondro

Dňa pi 3. 4. 2020, 20:53 Werner Keil <werner.keil@xxxxxxxxx> napísal(a):
 Regarding stability it looks like not every container based on Jakarta EE also works that well with MP Config:

Of course Mike knows better than anyone else,  that Eclipse Foundation often saw more than one project accepted with exactly the same goal:
https://www.eclipse.org/m2e/  is still around although it can also be seen as "mature" and "stable". There was another one roughly around the same time, IAM, see https://www.eclipse.org/projects/archives.php (there was even an Eclipse project called "Corona" once ;-) which did not make it that long.

So there would be nothing wrong if enough people (either from the old JSR or different projects dealind with configuration) gathered around a Jakarta spec that could be a "fork" of mp-config or something "inspired" by it and others. Of course using a working piece of code can't hurt, but claiming "MP is the only place where innovation happens" while no significant commit is seen on Github over the past 6 months denies reality compared to several others like Helidon: https://github.com/oracle/helidon/graphs/contributors 
I won't even mention Spring and Spring Boot because their adoption and ecosystem around them is undeniable.

Speaking of Dropwizard, while it was already stable and mature before the idea of MicroProfile even came up, a kind of subset from Dropwizard Config https://github.com/joschi/JadConfig is also a notable example for an annotation based approach.

Werner





On Fri, Apr 3, 2020 at 8:11 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
You are simply factually wrong in this regard.  You're defining
"caring about compatibility" as being synonymous with "forcing strict
compatibility rules", when this is not true in any respect.

I voted "Pull" because the chief goal of MP ought to be to meet user
needs effectively and quickly, even if that means (in the worst case)
bumpy compatibility at first.  As I said, compatibility is a quality
measure (just one of many) and it arises from a good specification.
Making a specification be compatible doesn't make it good or useful.
It's far better to add compatibility restrictions *after* the
specification is already stable, rather than to add such restrictions
to a specification that is still rapidly developing (thereby greatly
diminishing its usefulness in the name of stamping a logo on it in the
short term).  This is (IMO) a good indicator of when it makes sense to
"graduate" a spec into Jakarta.  The consumers of Jakarta are looking
for long term stability, and that comes from quality, not from a
compatibility contract.

Voting "Push" would have done nothing to improve the quality of
specifications and would have obstructed the process of cross-vendor
standardization - an already inherently politically and socially
obstructive process.  It was a very cynical option IMO.

On Fri, Apr 3, 2020 at 12:55 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Everyone who voted for this "Pull" option voted against compatibility and supporting it, not sure how many votes Red Hat got there and who was eligible but the majority voted for the "I don't care about compatibility" option, did you vote for "Push"?
>
>
>
> On Fri, Apr 3, 2020 at 7:33 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>
>> AFAICT the only people claiming that MP doesn't care about
>> compatibility are MP detractors.  MP doesn't *prioritize*
>> compatibility, but I for one *care* about it quite a lot.  When your
>> first priority is meeting use cases, then compatibility becomes a
>> quality measure: the easier it is to retain compatibility in the face
>> of new use cases, the more likely it is that the specification is
>> already useful for use cases beyond those originally imagined.  The
>> more useful a specification is, the wider its adoption.
>>
>> On Fri, Apr 3, 2020 at 12:18 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>> >
>> > And especially one claiming it doesn't care about compatibility or the consumers of its frameworks or APIs while the other by definition has to.
>> >
>> > Werner
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Apr 3, 2020 at 7:11 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>> >>
>> >> Hi David,
>> >>
>> >> I agree nobody wants to duplicate effort. Which is why it is non-sensical to have two separate specification bodies defining specifications which are intertwined as these discussions on both sides demonstrate.
>> >>
>> >> Steve
>> >>
>> >> -----Original Message-----
>> >> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of David Lloyd
>> >> Sent: 03 April 2020 16:49
>> >> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>> >> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>> >>
>> >> On Fri, Apr 3, 2020 at 9:56 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>> >> >
>> >> > All of these are defined by standard bodies with strong compatibility requirements like W3C or the JCP.
>> >> >
>> >> > The namespace is not so much a problem as the "Not My Problem" attitude the MP stakeholders expressed in their vote for the option called "Pull". That is even a stronger argument against using a feature like MP Config as is instead of a "fork" or writing something heavily inspired by it from scratch in Jakarta EE.
>> >>
>> >> Who would do the work?  We're rapidly innovating in MP Config right now, learning a lot about the problem space and processing real user feedback, and applying that knowledge in a way that can be consumed today.  If you fork, you're going to end up with probably a separate body of people (where will these people come from?), developing a separate piece of software from scratch which, instead of being based on working and useful implementations, is top-down designed and has no initial implementations - discarding that learning process just to spite MP out of impatience AFAICT.  It seems silly to me.
>> >>
>> >> If the bar for Jakarta EE is stability, you can't clear that bar by crapping out some code and calling it "stable", no matter how brilliant you are.  It has to be proven in the laboratory of the real world - an iterative process.  MP Config is going through that process right now, in fact, and rapid innovation is the direct result of that.
>> >> We're not breaking things for fun, and in fact we put forth some effort to not break things anyway (despite being allowed to).  Perhaps there will be a time where most people are mostly happy with it and few new use cases arise, rendering the specification mostly quiescent, but until that time, anything you do to call the field of standardized configuration in Java "stable" will effectively be a lie, just to check a box.  Such lies do little to enhance the reputation of specification bodies which perpetuate them.
>> >>
>> >> > Not giving a damn about compatibility requirements means, Jakarta EE probably would have to fork the TCK for such MP feature anyway because if the project suddenly decides to run the TCK with Spock or JUnit 5 instead of TestNG while the Jakarta EE platform has other foundations of its TCKs, then Jakarta EE might as well just fork the whole of it instead of bothering with a TCK fork or trying to integrate it somehow without support by the authors.
>> >>
>> >> I guess it depends on how much you enjoy doing busy work.  I for one really dislike doing it; any time spent working on a (possibly
>> >> inferior) parallel specification to one that is in wide use is time wasted, to me; I can only imagine that my co-collaborators on MP Config feel similarly.  Who would be left to work on the specification when all of the experienced engineers don't want to do it?  What kind of specification would that be?
>> >>
>> >> It's far more rational to let MP Config continue to do the "dirty work" of figuring out what works and what doesn't work, and then revisit the question at a more appropriate time.  Consuming MP Config could be a far more attractive option in, say, 12-18 months time.
>> >> Moving it wholesale to Jakarta might similarly be a more reasonable option at that time.  It's better than spending 12-18 months arguing over a new specification anyway - how tiresome that would be.
>> >> --
>> >> - 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
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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

_______________________________________________
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


--
Thanks
Emily

_______________________________________________
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