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.


On Wed 8 Apr 2020 at 19:03, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Rudy also mentioned that on the ambassadors list, but most artifacts would be affected by caching artifacts, therefore one being used there ten or a hundred times more than others is a factor telling how widely used they are.

No it’s not. Not in the case I mentioned. AFAIK SmallRye is the most widely MP RM implementation shared by a few. So if this one does not use the artefact, then you don’t get a multiply factor error, you get an entire population not represented. 


There are a few  other places, e.g. a more static downstream figure for
vs.
or
 
And the dependency graph on GitHub
vs.
or 

These can be misleading because every Github repository counts, even if it was a pet project nobody updated for years, but both show a rank from "high" to "low" where each of the 3 examples here are in the same position compared to each other.

Werner 




On Wed, Apr 8, 2020 at 6:48 PM Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:
Messaging. Clement tells me that SmallRye Reactive Messaging for example does not make use of that artifact (except for TCK runs), it has its own artifact / copy.

On Wed, Apr 8, 2020 at 3:06 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
Which one MP Config or Messaging?

For a relative comparison between different artifacts it certainly works and is undeniable, but if e.g. they only count direct downloads from Bintray, JCenter or everything including MavenCentral, happy to hear more about that, because then Unit-API would certainly have over a Million downloads as well ;-)

One has to ask the people inside JFrog if they are allowed to share them.

Werner






On Wed, Apr 8, 2020 at 3:00 PM Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:


On Wed 8 Apr 2020 at 02:01, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Hi,

Many probably know JFrog recently saw a couple of new joiners including Stephen Chin, and it seems that is paying off because every newer artifact in Bintray JCenter (including mirrors of MavenCentral) now shows the total downloads in the new UI, even if the artifact does not expose the stats explicitly.

For Unit-API since JSR 363 started it is: Wed Jan 01 2014 - Wed Apr 08 2020    
Total downloads for javax.measure:unit-api: 839,718
says 839702 downloads.

So where that shows it is the lifetime downloads for that artifact.

says 150848 downloads.

says only 384 downloads.

This number is for sure wrong. 
I alone have downloaded it more than that :)


says 223498 downloads. 
Only under the new Jakarta groupId.
The old javax artifacts don't seem to be counted, or it would take too long for some that exist for up to 18 years now...?

It's only the downloads via Maven, Gradle or similar, but it gives a good picture how popular those artifacts are to build others.

Maybe if someone asks their old colleagues now at JFrog nicely, there could be some APIs for such queries e.g. on a Jakarta or Microprofile feature page? ;-)

Werner 



On Tue, Apr 7, 2020 at 10:03 PM Roberto Cortez <radcortez@xxxxxxxxx> wrote:
This is the point that me and David have been trying to pass all along.

MP Config as is, is missing core functionality that a standard Config spec should have. Some of that work is being done in MP Config 2.0. So again, my suggestion to focus on the technical aspects and work out the non-technical details in parallel.

We would love to see more contributors in MP Config and this is the perfect chance for anyone to join.

On 7 Apr 2020, at 19:18, Werner Keil <werner.keil@xxxxxxxxx> wrote:

Hi,

Thanks that is a very precious peace of information, in fact other implementations like Helidon also have both MP Config addons and their own configuration subsystem, for example "Hocon" support like in Typesafe Config. 

Some may never be worth standardizing or implementation specific only, but the fact that so many of the popular adopters of MP Config need to create addons or build their own APIs around it show, that simply taking MP Config as the golden standard is probably not enough. 
Either some of these have to be added by the MP team soon enough, or the whole question of a fork or wider standard effort that also takes other approaches into consideration could be what satisfies more users and their needs and who knows even attract Spring to implement it like in other cases (anything from Servlet to JPA, JMS or Batch just to name a few).

Werner




On Tue, Apr 7, 2020 at 8:10 PM Vedran Smid <vedransmid@xxxxxxxxx> wrote:
Hi,

yes, Spring Configuration and its eco system are superior to MP. Well, Spring generally is a superior platform to pretty much any other atm in my humble opinion.
Quarkus has some nice MP Config addons though.

On Tue, 7 Apr 2020 at 19:56, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Hi,

I was curious because you said you use both for a long time and Spring offers a comparable kind of configuration at least since Spring 3 I believe.
I have not checked the latest OpenLiberty versions but they also support one or another version of MP Config, in some cases that can duplicate dependencies, but that would not be different if you use a particular version of Spring on top of Wildfly or OpenLiberty, Tomcat or Jetty.

Jetty in fact has its own configuration system a bit similar to Windows INI files. I have not seen that used with any of the mentioned solutions, even Spring (although I am sure it might work) but I know Apache Commons Config does support INI files very well. Used them in several client projects.
Jetty 10 already updates to Jakarta EE (8 I suppose) but can't say, if it considers using a unified config framework, not before Jakarta EE had one I guess.

Werner 




On Tue, Apr 7, 2020 at 7:41 PM Vedran Smid <vedransmid@xxxxxxxxx> wrote:
Hi,

not sure I understand your question. I never said I mix Spring and JavaEE/JakartaEE. If I use e.g. OpenLiberty I use whatever they say they support. The same would go for any other server. There is also an option of using custom made runtime. For example, it is very easy to get Jetty up and running with SmallRye.

On Tue, 7 Apr 2020 at 19:10, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Hi,

That is an interesting experience.
Do you combine either of them in your actual application code?

Spring for configuration or MP Config, and which version of Jakarta EE?
In some like Wildfly 19 you might get them in sync because it already has Jakarta EE 8 and MP Config 1.4 while the earlier versions like Wildfly 18 were a mix between the pre Jakarta version of MP Config and an otherwise optionally Jakarta EE 8 compatible implementation, so you may end up with two or more separate "Enterprise stacks" if you even added Spring to your application ;-O

So regardless of the namespace question and if it's possible for a future Jakarta EE X (not necessarily 10) version to include a MP Config or other MP Y version, the timing is important. And if you look at the JCache JSR, that also is quite popular and has a few implementations but for the same reason it missed the inclusion into the Java EE (and now Jakarta EE) platform so many times, its Spec Leads don't seem to care about this inclusion any more. 

Because JSR 107 uses the JCP in theory even a Jakarta Spec/API might use it but I am not a patent lawyer to tell all the nasty pitfalls, for your application you sure can use it, but it never made it into the Java/Jakarta EE platform so far.

Werner




On Tue, Apr 7, 2020 at 6:46 PM Vedran Smid <vedransmid@xxxxxxxxx> wrote:
Hi all, 

I am o long time Spring and JavaEE/Jakarta user. I also used MP quite a lot since the early days.
All the projects I worked on in the last 2 years that were JavaEE/Jakarta based were used along with MP and this proved to be a success.

I am now almost used to including MP Config as a second dependency in my projects(after jakarta api). This is just to show how badly a standard way of configuring apps is missed in Jakarta. The same could be said for security even though it looks like it could finally see better days.

MP Config is now used in many major frameworks like Quarkus and Helidon and I feel that diverging from something that many people are now using across multiple frameworks in the same way could prove to be costly when people are already loosing interest in Jakarta.

It would be nice to see MP Config under Jakarta namespace but I also do not mind depending. 
I am concerned that by forking I would not get what I have right now and there is also a question of when and how and of what quality. 





On Tue, 7 Apr 2020 at 17:22, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Reza,

This list is mainly for gathering opinions, therefore the more we get by others whether they use Jakarta EE, MP or both a year or 5 or just a few months, their opinions are welcome.

However, the voting under the EFSP won't happen as MicroProfile in the mailing list defined for themselves. 
Frankly comparing it with say a vote for new committers in any Eclipse project (which MP currently is) that is pretty similar, They took the "veto" out which happens in some cases like the mentioned committer vote, but otherwise the vote there seems legitimate, but it is not a WG yet and it does not follow the EFSP yet, so things will have to "Jakartarize" more if both want to apply the same process, whether on the Jakarta or MP side.

Werner 





On Tue, Apr 7, 2020 at 5:15 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
Werner,

I think you know that I value you and I know you are coming from a really good place. However, maybe us "old hands" have a responsibility to consider if we too are causing all the air to be sucked out of the room? Maybe we by and large shared everything that is productive to share at this point? Just something to consider.

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.

On 4/7/2020 11:00 AM, Werner Keil wrote:
David,

I know and what Reza also wanted to say (not trying to speak for him) is that in some cases the same people from the same company stating the same things here do not make that stronger or weaker.
It is good to occasionally a few individuals (other than myself) provide input based on their situation or how the use the technology in their daily job.

In the end there won't be a vote here, and the kind of voting that happened on the MP mailing list where it seems every committer has one vote (https://wiki.eclipse.org/MicroProfile/VotingProcess ) is unlikely to be the same if a formal WG and committees are established for MP like Jakarta EE. There only one participant member who is elected into each committee has one vote and one committer (myself and others in different committees) 
So Red Hat and IBM each seem to have a vote, but not 3 people working at each company.
 
Werner




On Tue, Apr 7, 2020 at 4:42 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
Werner I think you missed my point utterly so I'll restate it here:
Jakarta may fork Config (or anything else that they can get IP
clearance on) whenever they want!  Once again: Jakarta may fork Config
whenever they want!

Here's another one: Jakarta may design their own Config spec whenever they want!

Hopefully that's really clear and there is no more confusion on it.

Now I will also state these *facts*.

* Jakarta cannot FORCE the MP community (or any other community) to DO anything.
* Jakarta needs PEOPLE to work on a specification, because
specifications do not grow on trees: they have to be written by people
who KNOW the subject matter AND who KNOW how to write specifications.
* The PEOPLE who are CURRENTLY working in the area of middleware
configuration are working on MP Config *at present*.
* The MP Config spec is in the process of being cleaned up as rapidly
as the COMMUNITY can do so (noting that most (perhaps all) of us,
regardless of employer, are VOLUNTEERS).
* The MP Config spec is NOT YET of sufficient quality that we can
PROMISE not to break compatibility - there are still unsolved problems
that we are working on which are likely to have a compatibility
impact.
* The PEOPLE who are working on MP Config will probably continue to do
so (at least for the time being), and would have done so REGARDLESS of
the push/pull vote.  This is because...
* Jakarta cannot FORCE the MP community (or any other community) to DO anything.

Do you understand what I'm saying?  I'm not stating *any* opinions
here, or outlining *any* political objectives.  These are the *facts*
of the matter, like it or not.  So you need to think about what you're
trying to achieve.  If you're trying to achieve a Jakarta EE
Configuration specification, what do you think that entails?  Do you
think it just means forking some OSS project and publishing it as a
specification?  Is it a political "spite MicroProfile" move to you?
Rather than looking at this as a Jakarta vs MicroProfile battle, can
you see that we're working towards the same goal?  The legwork *has*
to be done.  It shouldn't matter to anyone in Jakarta whether that
work is done in MP or here, because either way the goal *should* be to
publish a high quality Jakarta specification.

On Tue, Apr 7, 2020 at 8:20 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Thanks for the input.
> There seems no place to do a formal vote here, but it is nice to see more voices from the community.
>
> The "JSR" does not have to be built and it was heavily inspired by MP config anyway at the time but with the JCP requirements applied (unlike MP Config) In an ideal world we should see the community and contributors behind MP Config join into that, but again there is a lot of pride and prejudice not just from the English folks right now, so can't promise that will work as you hope for.
>
> Werner
>
>
>
>
>
> On Tue, Apr 7, 2020 at 3:15 PM Thomas Andraschko <tandraschko@xxxxxxxxxx> wrote:
>>
>> +1 for a Jakarta Config
>> There are many Config APIs around Jakarta EE: Deltaspike, tamaya, MP
>> Its really a good time for doing it
>>
>> But IMO we should not just fork it.
>> We should review it, check the MP feature requests and issues, and build a new Config JSR, which is heavily inspired by MP
>>
>> Werner Keil <werner.keil@xxxxxxxxx> schrieb am Di., 7. Apr. 2020, 14:59:
>>>
>>> Gilberto,
>>>
>>> Thanks for your input. Nice to hear from another member of the community and user not just vendors.
>>> What you mentioned about Servlet, CDI (which till V2 had mostly beans.xml, but CDI 2 also comes with a brand new "configurator" package) JPA and others is one of the main reasons why not only implementations (the initial driver for Otavio/JNoSQL) should benefit from a unified external configuration, but sooner or later most relevant Specs in Jakarta EE as well.
>>>
>>> Werner
>>>
>>>
>>>
>>> On Tue, Apr 7, 2020 at 2:28 PM Gilberto <gilbertoca@xxxxxxxxx> wrote:
>>>>
>>>> Folks/Friends,
>>>>
>>>> I see(limited view I would say) MicroProfile (taking in account that each provider claims is the best innovator) as a framework like Spring Boot, Dropwizard, etc. All of them uses standardized specifications (Jakarta EE), all!
>>>> I do not see myself using any of them for any time soon. Instead, I have to and will continue to use standardized specifications, Servlet, CDI, JPA, JSF, EJB (in my case using TomEE [1]) for a long time.
>>>>
>>>> For me, MP config is like Tamaya, DeltaSpike, etc. and you know there is more, so now it's time to standardize (that's the Jakarta EE role, doesnt it?). So, let's take advantage of Otavio's initiative, take the JSR[2] as a base and standardize it.
>>>> And them you will see that everyone will use it the same way they are using (Servlet, CDI, JPA to say the minimum).
>>>>
>>>> Regards,
>>>>
>>>> Gilberto
>>>>
>>>> PS.:  I used the google to translate this reply, so if anyone get offended by it I want to apologize.
>>>>
>>>> [1] http://tomee.apache.org/
>>>> [2] https://github.com/eclipse/ConfigJSR
>>>>
>>>> Em ter., 7 de abr. de 2020 às 06:29, Mark Little <mlittle@xxxxxxxxxx> escreveu:
>>>>>
>>>>> Hi Reza.
>>>>>
>>>>> I’m not sure what you’re reading which would suggest the aims behind MP around standardisation have changed so maybe you can let me know? While I wait for that I’ll point out that with Jakarta EE under the Eclipse Foundation, which is NOT a recognised standards body, MP has as much chance of becoming a de facto standard as anything under the EF, including Jakarta EE. If anyone wants to move MP or Jakarta or something else under EF to an official standards body then that’s probably a wonderful idea too.
>>>>>
>>>>> Yes, I do agree that at the start of MP efforts (prior to the donation to EF) we said that if the time for standardisation happened for any MP specs we would consider the appropriate body, such as the JCP. I believe that still stands. But the point that seems to be missing in many minds is that the spec group should make that decision and the spec group (individuals, vendors etc.) should then get involved in that standards body and pull the spec across. If some other individuals who have not been involved in the spec were to do that then I think we are setting everyone up for failure.
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>> On 6 Apr 2020, at 13:19, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>>>>>
>>>>> The reason any of us view MicroProfile as a source of standardization for Jakarta EE is that had been the explicitly stated goal of MicroProfile for some time. I understand whoever is controlling MicroProfile these days has changed their mind at some recent point. It should not be too big of a  surprise if the community outside MicroProfile has not changed its mind about where it would like MicroProfile features to go.
>>>>>
>>>>> Let us also keep in mind that the purpose of any open standard is to incorporate technologies that just make sense and that configuration in enterprise Java has had a lot prior art that MicroProfile configuration itself has incorporated. It is an entirely reasonable thing to further standardize these features without getting too many emotional aspects involved such as "envy" and "drew their plans against us".
>>>>>
>>>>> I really fear such overt emotions has long detracted from legitimate technical discussion and has a chilling effect specifically on end users stating their needs and expectations without fear of being on the receiving end of an emotional outburst. I can say for sure it makes me uncomfortable and I really wonder if that is necessary? Perhaps it also serves to stir negative emotions in others that impede rational consideration? Can we do a bit better and stick to technical matters here?
>>>>>
>>>>> 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: Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>
>>>>> Date: 4/6/20 7: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.
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> I really don't understand your point in this long email. This is a JakartaEE mailing list and nobody from the Jakarta community is suggesting MP to do anything. We're just discussing how to cope with the Pull decision of the MP project and it's MP committers who are trying to dictate what to do or not to do.
>>>>>
>>>>> I would refrain from the criticisng language you used and rather ask you to suggest how the JEE and MP community can better understand each other and find the best way to collaborate.
>>>>>
>>>>> Dňa po 6. 4. 2020, 11:56 Mark Little <mlittle@xxxxxxxxxx> napísal(a):
>>>>>>
>>>>>> Mike, they are closely related. But let me take this time to explain.
>>>>>>
>>>>>> It seems to me that some in the Jakarta EE community and Eclipse Foundation are forgetting one very valuable thing about successful open source efforts, such as MP: they’re not owned by Red Hat, IBM, Tomitribe, EF or others who have contributed so much over the years, or those who have sat outside and watched; they are (or in this case, MP is) a community effort and it’s owned by the community. Any other community, such as Jakarta EEM, has no inalienable right to pass judgement on how another community acts or behaves and somehow decide to swoop in and take it over. I’d be as vehemently against that happening here as I would some other group deciding the try to take control over Jakarta EE or some other project in, say, the ASF. Clearly there are ways to exercise control and influence over a community and they are well defined: get involved, influence from within, gain commit rights and try to direct that way. But trying to do this from the outside it something none of us should be comfortable with doing - that’s not good open source collaboration. Anyone remember Hudson these days?
>>>>>>
>>>>>> Speaking very specifically about Jakarta EE and MicroProfile, there is nothing in either community rules of engagement or statement of intent, or whatever we want to call it, that allows one to have expectations on the other. We should treat these two communities as peers and with respect. Even though there is overlap in the community membership that does not mean any of us should assume they are so closely related that what one wants the other must also want or bend towards. I sit in both communities. I’ve helped create both communities. Yet to paraphrase HG Wells, at times in these conversations it’s as if some in Jakarta EE "regarded [the MP community] with envious eyes, and slowly and surely drew their plans against us.” That’s no way for anyone to behave.
>>>>>>
>>>>>> There should be no default rule for the relationship between Jakarta EE and MicroProfile because each MicroProfile specification is often driven by a mix of different developers, vendors and communities who may not want their efforts forked. To ignore them is tantamount to a hostile take-over. The Jakarta EE communities should work with them and try to persuade them to see their point of view. However, if the MP spec community cannot be persuaded then I caution continuing with a fork. Embed and try to work together because the MP spec should still be usable within Jakarta EE. And working with the original community is a far better path to future success than trying to split efforts.
>>>>>>
>>>>>> If no way to collaborate can be found, including simply embedding that spec into Jakarta EE, then I'd suggest that there is something fundamentally wrong with that specific MP spec community or those in Jakarta EE. I really can't see this ever happening though so it's not worth further consideration: generally everyone is pretty reasonable and friendly in both communities.
>>>>>>
>>>>>> Then there's the notion of changing the namespace of a MP specification if it is "imported". Well I also don't think that should be a hard and fast rule either. It should be something that is worked out between the MP specification in question and the Jakarta EE community. If the MP spec community rejects changing namespace then that should also not be a reason to reject importing and collaborating with them and defaulting to a hostile-like fork. Regardless of the potential conflicts that could arise just think of the PR nightmares.
>>>>>>
>>>>>> And that brings me to the final question: where does work on the MP specification continue, assuming it does need to continue? Well guess what? I think that's up to the MP spec community since they are the founders of their work and their future destiny. If they feel that innovation should shift entirely to Jakarta EE then go for it, with all of my support. But likewise, if they feel innovation should continue in MP and maybe they are a part of the corresponding Jakarta EE community which then works to pull updates across when it makes sense that’s great collaboration too. Everyone wins and we drive forward together.
>>>>>>
>>>>>> Just in case this is lost on anyone who read this far or is skipping to the conclusion, my main point is that whether MP produces specs, TCKs or something else, it is an open source community effort. We should treat it no differently in that regard than we would treat some other open source project with which we want to collaborate and definitely no different to how we would want others to treat us.
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>>
>>>>>> On 3 Apr 2020, at 14:26, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>>
>>>>>> I followed "push vs pull" very closely. What does that vote have to do with this purported governance decision?
>>>>>>
>>>>>> On 2020-04-03 9:20 a.m., Ken Finnigan wrote:
>>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> Mark was referring to https://groups.google.com/forum/#!topic/microprofile/i6E_a5WOPSs
>>>>>>
>>>>>> Which I thought you were aware of
>>>>>>
>>>>>> On Fri, Apr 3, 2020 at 9:05 AM Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>> On 2020-04-03 8:05 a.m., Mark Little wrote:
>>>>>>>
>>>>>>> Yeah we had that conversation in the MP community. Let's respect that decision even if you don't agree with it. You know ... good open source practices and all that, right ;) ?
>>>>>>>
>>>>>>> What decision? Can you point to where that happened?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mark.
>>>>>>>
>>>>>>> On Fri, Apr 3, 2020 at 1:02 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> It’s not orthogonal if the communities were merged.
>>>>>>>>
>>>>>>>> MP could switch all apis to the jakarta namespace when it adopts Jakarta EE 9 at the same time as the base specs switch from javax to the jakarta namespace.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Mark Little
>>>>>>>> Sent: 03 April 2020 12:55
>>>>>>>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>>>>>>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sure but that is totally orthogonal to whether Jakarta EE changes the namespace when it consumes MP components. What isn't orthogonal is the potential splitting of community activities across these forks. I'll be blunt here, I'm less concerned about the continued viability of the original MP specifications as I am about the forks into Jakarta EE.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 3, 2020 at 12:39 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> On the community concerns. The MicroProfile community is adamant that it is independent and will evolve with no concern for consumers of the specifications to maintain velocity and to remain innovative (the Pull model). It’s not a position I argued for at the time within MicroProfile I argued that the communities should merge and therefore there would be no community concerns and these questions would not arise. See https://blog.payara.fish/microprofile-and-jakarta-ee-technical-alignment
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> However we are where we are.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Mark Little
>>>>>>>> Sent: 03 April 2020 12:22
>>>>>>>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>>>>>>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> OK let's take the case of CORBA ... last time I looked Java EE did not change the namespaces when it incorporated CORBA and when it took the OTS and renamed it to the JTS. And OTS wasn't stable at that time, going through several subsequent revisions, as did CORBA.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I also note you didn't address the community concerns I raised.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 3, 2020 at 11:29 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> The log4j example is spurious. Log4J is a library jar not a specification. How many people need to support 2 versions of log4j in their application?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As a counter example I have seen many runtimes shade a popular library jar thereby changing its namespace for stability reasons, exactly because an application may incorporate a different version to the one shipped in the runtime.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Mark Little
>>>>>>>> Sent: 03 April 2020 10:59
>>>>>>>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>>>>>>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Also as pointed out during the MP “push vs pull” debate was the important fact that if any group wants to pull an MP specification then whether or not they change the namespace is really independent of stability. I can’t recall the last time (or first time) I came across a project which forked log4j and changed the namespace “for stability” reasons.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I hope anyone considering forking any specification or project considers the potential implications on communities. Better to collaborate and put up with some different namespaces. Many MP and Java EE users have been doing that for years so far without complaint.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Finally, I assume if a fork goes ahead that there is a developer community behind the forked effort tracking MP or it might go stale quickly, missing critical updates etc.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2 Apr 2020, at 20:11, Andy Guibert <andy.guibert@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> >  During the MP technical discussion there was discussion about those things and it was clear for everyone that the  "move fast and break things" of MP is a valid scenario but with consequences for downstream consumers (they require a fork if they want stability)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If Jakarta wants a stable version of MP Config, they can simply pick a version of MP Config and stay with that version, right?  Say MP Config 1.4, and since MP follows semantic versioning rules, really Jakarta could work with any version of MP Config 1.X.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> > MicroProfile did what it needed to do, now it is time that Jakarta does what it needs to do and move forward. It can't be blocked because the people of MP don't think it is a good idea (and they shouldn't care about it as they would not consider downstream consumers)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> But Jakarta does _not need_ to do this. Furthermore, if Jakarta forked+promoted its own version of Config, they would not be a simple downstream consumer of MP Config. Jakarta would be essentially creating something entirely new (i.e. not binary compatible) that tries to fracture the existing+future userbase of the Config API.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We need to consider who would benefit from such a fork, as opposed to Jakarta simply adopting the MP Config 1.X spec (which again, follows semantic versioning which guarantees no breaking changes).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> - Andy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 2, 2020 at 1:43 PM Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> During the MP technical discussion there was discussion about those things and it was clear for everyone that the  "move fast and break things" of MP is a valid scenario but with consequences for downstream consumers (they require a fork if they want stability)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> MicroProfile did what it needed to do, now it is time that Jakarta does what it needs to do and move forward. It can't be blocked because the people of MP don't think it is a good idea (and they shouldn't care about it as they would not consider downstream consumers)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Rudy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 2 Apr 2020 at 20:35, Andy Guibert <andy.guibert@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> I strongly oppose the idea of forking MP Config in Jakarta.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Politics aside, it is an absolute headache from a technical perspective. It's going to be the javax->jakarta rename all over again, except worse because the "old" spec (MP Config) will still move forward on its own.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Config needs to be a foundation technology that lots of other library implementations can depend on. If we have a Jakarta Config and a MP Config API floating around, how will those libraries support both APIs? If a property is set at the same ordinal in both MP Config and Jakarta config, which one should win?
>>>>>>>>
>>>>>>>> If the solution of forking a Jakarta Config is only feasible if MP agrees to kill of MP Config, I highly doubt that will happen, and frankly it is a rude thing to ask another community to do.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I agree that MP has the freedom to "move fast and break things", but MP does not break things just for fun. In the case of MP Config, it is a pretty stable technology that is feature complete, so I highly doubt any new breaking changes will arise in the future. Even if they did, Jakarta could define which version of MP Config it was capable of inter operating with.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> - Andy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 2, 2020 at 9:19 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> I don’t like the idea of Jakarta consuming “raw” MP specs for a number of reasons
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If I want to support the latest MP and the latest Jakarta EE in the same product then it will be a nightmare, if they run at different pace but are in the same namespace. This will drive us to shipping separate products and therefore Jakarta EE developers will be excluded from the latest innovations in MP.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Jakarta needs to be a consistent platform, it has enough problems with multiple bean models that need unifying. Therefore changes may need to done to specifications to make them consistent with the current state of the overall Jakarta EE platform and to make them work well in the context of Jakarta EE. Given the MP stated goal is to be not concerned with how consumers use the specifications I assume this work will need to be done within the Jakarta efforts.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> MP goal is rapid innovation, “move fast, break things” Jakarta’s goal is a stable evolving platform with backwards compatibility requirements. These things are inconsistent. If a developer is using the MP namespace then they know apis may change. If they are using Jakarta apis then they have backwards compatibility guarantees. Mixing the namespace within the Jakarta EE platform breaks that understanding.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Finally for politics. IMHO many members of the MP project do not really see themselves delivering standardised apis in a multi-vendor collaboration,  it’s all about innovation and speed. They balk at governance, committees, etc. and wish to move forward like an Apache project. MP should forget about specifications, working groups etc. and leave Jakarta EE to standardize the innovative apis where appropriate into a coherent platform in the Jakarta namespace.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The ideal solution is for Jakarta to see MP as a pool of innovation for ideas which we can adopt, standardise and incorporate in a consistent manner into the overall Jakarta EE platform.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Emily Jiang
>>>>>>>> Sent: 02 April 2020 13:28
>>>>>>>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>>>>>>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Personally, I don't like the idea of forking, which might sound like a good idea at a first glance. However, once there is a fork, this will give end uers a lot of headache. When they  do an import, multiple things pop up and they might end up use partial APIs from either spec. The MP Config and Jakarta Config spec will go out of sync very soon. In short, there should not be 2 config specs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Having that said, as mentioned by Kevin, MP is focusing on creating WG. Once it is done, there are no IP concerns. Why can't Jakarta EE consume MP Config freely. Also, I suggested a LTS solution for MP Specs to indicate some releases to be consumed by Jakarta etc.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> My 2cents.
>>>>>>>>
>>>>>>>> Emily
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 2, 2020 at 7:41 AM Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> Yes, forking the MP config is a good idea now that MicroProfile has decided on the pull option.
>>>>>>>> The Working Group discussion (and thus IP handling) doesn't solve the issue with the backward compatibility which explicitly will not be of any concern to MicroProfile. MP Config will perform a breaking change in the next month, so even if it seems stable, it can't be referenced by Jakarta.
>>>>>>>>
>>>>>>>> Besides the integration of MP JWT Auth as Arjan proposes, I also propose to include MP Rest client into Jakarta REST. We need to implement the same features in the respectively Jakarta specifications so it will be a fork.
>>>>>>>>
>>>>>>>> When the main MicroProfile specs are forked into Jakarta, there will be no need anymore to combine the Jakarta and the MicroProfile specifications into the applications servers and we will have Jakarta runtimes and MicroProfile runtimes each consumes their respective specifications.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 2 Apr 2020 at 03:24, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> On Apr 1, 2020, at 8:33 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, there is another option...  Wait a month or so while MicroProfile figures out a Working Group proposal.  The MP community and the EF are both in favor of establishing a separate MP Working Group as a first step.  Once this is established, then the Specifications (and APIs and TCKs) will all be properly covered from an IP standpoint and they could be consumable by Jakarta EE projects.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Right.  And specifically we don't just need the Working Group in place with a specification process, but we need to actually do a release of MicroProfile Config under that process.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We're a few months away from having IP clean enough for any proposal on the Jakarta side to move forward.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In short, our current status: eat your meat so you can have your pudding. :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mike Milinkovich
>>>>>> Executive Director | Eclipse Foundation, Inc.
>>>>>> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
>>>>>> @mmilinkov
>>>>>> +1.613.220.3223 (m)
>>>>>> _______________________________________________
>>>>>> jakarta.ee-community mailing list
>>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Mark Little
>>>>>> mlittle@xxxxxxxxxx
>>>>>>
>>>>>> JBoss, by Red Hat
>>>>>> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
>>>>>> Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
>>>>>> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>> ---
>>>>> Mark Little
>>>>> mlittle@xxxxxxxxxx
>>>>>
>>>>> JBoss, by Red Hat
>>>>> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
>>>>> Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
>>>>> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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

Back to the top