I really thought long and hard whether I should respond but against my best judgement I will - hopefully for the last time on this thread.
I really wish it were that easy to just focus on the technical details. The real struggle for me is whether I should contribute to something that ultimately will end up undermining the very things I sincerely believe truly matter. I know this will inevitably take time now but that is why I would personally feel a lot more comfortable if I knew what the long term intentions are with regards to Jakarta EE and MicroProfile alignment.
The main point I want to make though is that I hope there are others that don't have the fundamental concerns I do and will heed the invitation to engage in MicroProfile Configuration with a view towards usage with Jakarta EE APIs.
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: Roberto Cortez <radcortez@xxxxxxxxx>
Date: 4/7/20 4:03 PM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
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.
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).
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.
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.
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.
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.
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.
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.
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
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
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
