| Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration. |
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)