| Yes, but you make it sound that the issues you raise are totally unfixable. Maybe they are, I would just want to know why people feel that way?
But I doubt that this is the way to go in reality. MP Config most probably cann't meet the standards of Jakarta EE.
Which standards can’t MP meet?
Another problem is that MP and EE have different release cycles
You are also a committer on the MP Config, so you could help align releases. We shouldn’t confuse platform releases with single project releases.
I doubt that the MP would accept that.
This is just an assumption from your end. I can tell you it would have my support and I’m sure many other folks in the MP community would support it as well, but we can’t just assume things without even asking.
Well, unfortunately, we had to return to these discussions. But let me continue that discussion in another thread. On 21 Feb 2025, at 17:29, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
I wrote my arguments against Jakarta EE depending on MP Config earlier today, quoting:
> Jakarta EE can depend on MP Config, or a core part of it (without CDI). But I doubt that this is the way to go in reality. MP Config most probably cann't meet the standards of Jakarta EE. Another problem is that MP and EE have different release cycles, and, even if EE depended only on a core MP Config part, releases of MP, MP Config Core, and EE would need to be synchronized. I doubt that the MP would accept that.
End of quote.
We discussed this multiple times and always came to a conclusion that Jakarta EE shouldn’t depend on MP specs. If we’re going to question this again, we’re going nowhere.
I stated proposals that I think are the only viable options. I hope we’ll have an agreement or that somebody comes with a betrer option.
And I don’t question your past effort or contributions. I was talking about these endless discussions with no conclusions.
Ondro I’m sorry Ondro, you are being completely unfair with your observations.
We had this exact same discussion 5 years ago. In the now inactive CN4J group, there were two proposals, one to move and the other to keep, which were voted and the one to move won:
The MP community never disrupted or hindered any efforts on a Jakarta Config after that decision. In fact, me and Emily were (with some other folks) the most active members in that group, either in calls, commits, issues, and so on. And we were there in good faith and pushed to move things forward, so threatening actions are not a good way to collaborate. You need to realize that based on previous experience, many of us are way more skeptical about the end results, so you also need to be more patient and educate us to convince us that your proposal is the best one.
I have to apologize again, because I read the entire thread, and I couldn’t understand why Jakarta cannot accept anything in MicroProfile repositories. Do you mind explaining it again? You can reply privately if you want.
Cheers, Roberto
Jakarta Core Profile cannot accept anything in MicroProfile repositories, as I argumented, it wouldn’t work. Disputing about things like this is exactly what I mean by hindering. We shouldn’t talk about options that just wouldn’t work, that’s a waste of time and going in circles.
Ondro I might have misunderstood what you meant on Option 1. I will just say Jakarta Core Profile just includes MP Config core. The repo will stay in MP.
My comments are inline. Exactly as Reza wrote. Just the latest Jakarta EE 10 is implemented by 9 distinct solutions, out of those at least 4 have full or partial support for MicroProfile. Only 2 solutions plus Quarkus primarily support MicroProfile and have no or only partial support for EE. I think this is in line of the adoption trends Reza wrote about.
And now, it seems to me like Jakarta EE wants to evolve and bring Config, but MicroProfile has effectively hindered this initiative for a very long time, instead of helping and supporting Jakarta EE, which is at the core of MicroProfile. I don't see why Jakarta EE should take any consideration about MicroProfile at this stage, after MicroProfile choosing the pull model, and after being slowed down with all these discussion how to align with MicroProfile while MicroProfile doesn't even want to collaborate and align with Jakarta EE.
I am not sure what you meant by saying MicroProfile has hindered this initiative. There was suggestions and I said multiple times at some calls. MicroProfile Config is willing to split up into 2 parts: core; cdi parts.
I see only 2 options now: - MicroProfile will cooperate and agree to move MP Config or at least its non-CDI part to Jakarta Core Profile, and then we can keep the packages without breaking the API
This is the option I offered to help and contribute. This is so far the best approach.
- Jakarta Config will be created in Jakarta Core Profile, with jakarta packages, and MicroProfile will need to cope with it. The new API can map the MP Config API or create a variant inspired by it
If this discussion continues for too long without a resolution, I will strongly support creating Jakarta Config spec without any regard to MicroProfile, either as a copy of MP Config APIs in jakarta packages, or a completely new API. And I will start contributing to Jakarta Config as a committer, together with some other committers who want to do some work instead of wasting time in discussions. There's no reason why these discussions should slow down Jakarta EE. I don't see these kind of discussions in Microprofile, why should we have them in EE?
Ondro
This is indeed a very important branding, marketing, and
strategic consideration. What we observe is that while Jakarta EE
adoption and usage is not stellar, MicroProfile adoption and usage
fares even worse:
https://trends.google.com/trends/explore?date=2016-01-21%202025-02-21&q=Jakarta%20EE,MicroProfile&hl=en.
These have been the trends for some time now. It's not surprising
when customer express the preferences on this matter to us.
On 2/21/2025 9:54 AM, Werner Keil
wrote:
As
Steve mentioned, the adoption and true certification of MP is
merely a fraction of Jakarta EE.
The
most recent MP versions only got certified by one or two
products, before that MP 6 had 4 compatible products according
to Steve. Jakarta EE lists around 20 product by almost the same
number of vendors. Not all may have certified against Jakarta EE
10, but in general the number of compatible implementations is
higher. And let's not forget, MP as well as Spring also
implements some of Jakarta EE, so that multiplies the usage
drastically.
Regards,
Werner
Hi,
Can you please clarify which standards MicroProfile
Config cannot meet?
Also, why is there an assumption that MP Config
wouldn’t accept some sort of release alignment? MP
projects are free to release anytime they want.
Cheers,
Hi,
Yes, MP decided on the pull model. That means
that the decision is solely on Jakarta EE, with
the pull model, MicroProfile has decided they
don't care about EE.
Copying/forking MP Config is not the only
option, even with the pull model. Even with this
model, Jakarta EE can depend on MP Config, or a
core part of it (without CDI). But I doubt that
this is the way to go in reality. MP Config most
probably cann't meet the standards of Jakarta
EE. Another problem is that MP and EE have
different release cycles, and, even if EE
depended only on a core MP Config part, releases
of MP, MP Config Core, and EE would need to be
synchronized. I doubt that the MP would accept
that.
For the arguments above, the only
reasonable options I see, are:
- MP Config participates in this process
and splits to core part and CDI part, so
that the core part can be moved to Jakarta
EE Core Profile without package changes
- Jakarta EE copies the core part of MP
config under the jakarta package prefix
and adds it to the Core Profile. Jakarta
EE can introduce a new CDI Config
integration spec, or the existing CDI spec
can specify integration in the non-lite
part, which is not part of EE Core
Profile. This could still cause conflicts
for implementations that provide both MP
and EE, but we can hardly do anything
about it
- Jakarta EE will not care about MP Config
and will introduce its own API. This
option makes sense only if all other
options fail. We tried that already and
haven't delivered in more than 2 years.
This basically boils down to extracting
core parts of MP Config, and the question is
whether to keep the package names or
introduce jakarta package names, and whether
MP helps and splits the MP Config spec or
not. The third option is probably the least
desired right now.
Are any other options on the table?
Ondro
On Fri, Feb 21,
2025 at 1:15 PM Steve Millidge (Payara) via
config-dev < confi...@xxxxxxxxxxx>
wrote:
To be honest the whole thing
is a mess that should have been sorted out
years ago. As one of the 4 vendors that
actually has a compatible implementation of
Microprofile 6 and above the two WG should
have merged years ago with innovation
occurring in Jakarta ee as standalone specs
then maturity being signalled by adoption
into a platform spec.
"Downstream
consumers will probably require a fork (with
changing package names) to meet the
downstream projects requirements."
This should not be
controversial as it is rehashed continually.
While we have the
same debates the market does not care and
moves on.
Steve
I strongly disagree with forking MP
Config to Jakarta with namespace
changes. This introduces unnecessary
headaches and namespace clashes in the
IDEs. Why cannot Jakarta EE adopt
MicroProfile Config as it is and job
done? No more hassle.
The namespace update is purely
artificial and causes too many headaches
and version matching. In order to
continue the forking and namespace
changes, can anyone show me the rule of
Jakarta not allowing the use of
MicroProfile specs first?
Emily
Kito/all,
Thanks for forwarding this,
although the quote of quotes of
quotes makes it very hard to read.
I fully agree with Otavio's
message that both are developed
under the Eclipse Foundation, and
users of a product don't really
care, if it was developed in
repository A or B.
However, what Roberto outlined
earlier about continuous copying
between MP Config and Jakarta
Config makes absolutely no sense.
RC> After the initial
copy/paste, how would things
evolve?
My intention is that technical
evolution would take place in the
MicroProfile Config project. In
the event of Jakarta specific
accommodations, we would
1. Cross that bridge when we come
to it.
2. Try to come up with solutions
that are palatable to both
communities, Jakarta
EE and MicroProfile.
3. If absolutely necessary, we
would define content in MP Config
that
would have the proviso such as
"this only takes effect in Jakarta
EE environments". There is
ample precedent for such
approaches. See
what we did with Faces when
Validation was present (in EE) vs.
not
present (such as in Tomcat).
RC> Would Jakarta keep the APIs
in-sync?
Yes. Every time Jakarta needed a
new version, they would pick up a
chosen release of MP config to
give the copy/paste treatment to.
MicroProfile consumes Jakarta EE,
so there is no MP application or
platform without a Jakarta EE
platform, at the very least the
Core Profile. So Jakarta Config is
expected to be available in every
profile. If the MP Config API was
to co-exist with Jakarta Config
forever, then applications would
have to exclude one of them from
their build system, otherwise they
risk confusion or even mixing them
in the same project with unforseen
and unpredictable consequences.
Especially if a Jakarta EE
application using Jakarta Config
API also wanted to use certain MP
features like OpenTelemetry,
Health, etc. internally configured
via MP Config, but potentially
even a different version of the
API, if e.g. MP 8.1 used a new
version of MP Config while Jakarta
EE was still on 12 or 13 based on
an older MP Config API.
If the API is a
drop-in-replacement then nothing
keeps the MP projects from using
the Jakarta one after the next
release. And it does not really
matter, if it was maintained in
https://github.com/jakartaee/config or
Otherwise everyone, most
importantly developers and users
of both MP and Jakarta EE would
face a "config hell".
Regards,
Werner
I think that, in the
case of config, other
specifications can just
specify the accepted
config properties,
regardless of how these
properties are provided.
The TCK could use system
properties as a common
config source.
Then Microprofile
umbrella can state that
these properties are
supplied by MP Config,
Jakarta EE Platform
would state they are
supplied by Jakarta
Config. Jakarta Core
profile wouldn't need to
include Jakarta Config.
Or it could, but then
MicroProfile would state
that Jakarta Config is
not required. I'm sure
there's a way to define
all this in a simple way
so that everybody is
happy.
I think that makes a
lot of sense. Each spec
just says what it needs
from a "Configuration
Provider" and that
provider would be either
MP Config or Jakarta
Config.
With all that, I
share the same sentiment
with Reza. I always
hoped that MP would tend
to donate APIs to
Jakarta after they
become stable, and then
completely rely on the
Jakarta version of the
API.
I agree with this
sentiment as well...
We need to also keep in
mind the perspective of
the end users... they want
a "normal" configuration
setup that "just works"
with all of the different
parts of the app. And it
would be confusing to have
two different namespaces
with the same classes.
It's also confusing for
the end user to have two
different Config
specifications, even if
they're roughly the same.
I think that, in
the case of config,
other specifications
can just specify the
accepted config
properties, regardless
of how these
properties are
provided. The TCK
could use system
properties as a common
config source.
Then Microprofile
umbrella can state
that these properties
are supplied by MP
Config, Jakarta EE
Platform would state
they are supplied by
Jakarta Config.
Jakarta Core profile
wouldn't need to
include Jakarta
Config. Or it could,
but then MicroProfile
would state that
Jakarta Config is not
required. I'm sure
there's a way to
define all this in a
simple way so that
everybody is happy.
With all that, I
share the same
sentiment with Reza. I
always hoped that MP
would tend to donate
APIs to Jakarta after
they become stable,
and then completely
rely on the Jakarta
version of the API.
But that's not
necessary, and I think
anything is better
than the current
state, when many
implementations rely
on MP config even for
their Jakarta EE
functionality, or even
worse, MP parts
support MP Config
while Jakarta EE parts
don't.
All the best,
Ondro
I am sure Ed
and/or Jared will
respond with their
own thoughts - in
the meantime let
me share my two
cents, including
on some of the
broader technical
intricacies.
First a purely
personal opinion
independent of
Microsoft. These
are some of the
intricacies of
managing two
platforms run by
two separate
working groups
that in practice
need to co-exist
closely. It's the
reason some of us
espoused the hope
that common
dependencies and
possible sources
of colliding
resources to
manage would only
be in one
direction with the
Jakarta EE Core
Profile being
keenly mindful of
the needs of both
MicroProfile as
well as the other
Jakarta EE
Profiles (and
hopefully in some
distant future
other non-Eclipse
Foundation
platforms that
also depend on a
stable/high-quality/minimal
Core Profile). The
hope would have
been that
platforms such as
MicroProfile would
deprecate APIs
that are
effectively
standardized onto
the shared space
of the Core
Profile.
Setting aside
the above purely
personal opinion,
if MicroProfile is
very averse to
supporting both
Jakarta Config and
MicroProfile
Config, I don't
think it's too
hard to just keep
Config out of the
Core Profile
including the
small handful of
Jakarta EE APIs
there (via spec
profiles if
needed). The major
customer pain
point is needing
to configure the
data/external
infrastructure
related Jakarta EE
technologies using
old style embedded
XML or Java, which
are mostly not in
the Core Profile
anyway.
On 2/17/2025
11:17 AM, Roberto
Cortez via
config-dev wrote:
If we have
separate
namespaces and
APIs are synced
manually /
selectively (and
evolve
independently),
I’m guessing
that any Jakarta
specification
would use its
own Jakarta
Config, and
MicroProfile
specifications
would use MP
Config?
In
practice, even
if Jakarta
Config is not
part of the
Core, if any
Core
specification
adopts it, it
would force
Jakarta Config
with its own
API to the MP
platform. Is
this correct?
Cheers,
I plan to
bring this up
in the Jakarta
EE Steering
Committee. The
technical
debate aside,
I think there
are also
process and
branding/IP
considerations
here. For one,
it's important
to track down
what the
existing
consensus had
been in
Jakarta EE
WG/Jakarta
Config with
regards to
namespace. A
sanity check
from the
perspective
of branding/IP
is also in
order as these
are in reality
two different
working
groups.
I agree
that the most
prudent
approach is
avoiding
needlessly
introducing
mutual
inter-dependencies.
Both
MicroProfile
and Jakarta EE
should be able
to
independently
evolve their
configuration
approaches
when needed.
Separate
namespaces
with APIs
synced
manually/selectively
when needed
does that
well.
On
2/11/2025
11:00 AM, Ed
Burns via
config-dev
wrote:
Even
with
approaches
that allow for
mitigating the
circular
dependencies,
I am strongly
predisposed to
prefer the
repackaging
approach that
allows the
content of
MicroProfile
config to be
accessed by
Jakarta
specifications
using an
entirely
Jakarta
namespace.
Ed
My responses
are inline. We
will discuss
this issue in
more detail at
this Tuesday's
MP Technical
call. Please
join if you
are
interested.
The joining
details can be
found here.
Hi Ed,
Thank you
for the
response.
1.
A technical
problem
regarding
introducing
circular
dependencies.
Yes, the
issue is that
MP Config is
dependent on
CDI. This has
been discussed
many times,
and I believe
MP is open to
make the
necessary
adjustments
and removing
that
restriction.
In the
previous
Jakarta Config
initiative,
that was
already a
goal. One of
the things
I’ve been
advocating is
for MP Config
(or any other
Config
specification),
to work
standalone
without any
other
dependency.
This would
allow any Java
project to
consume it
without
requiring the
use of the
platform. As
for the CDI,
that can be an
addendum to
the
specification
or even be
integrated
into CDI
itself.
+1. We
can rework MP
Config to use
the CDI
approach by
dividing MP
Config to MP
Config Core
and MP Config
full, where MP
Config Core
will just have
the spi part
while the
other part
will include
CDI. In this
way, Jakarta
can simply
include MP
Config Core in
the Jakarta
Core profile.
With this, I
think Jakarta
can simply
include MP
Config Core
with the need
of having
Jakarta
Config. With
this approach,
renaming
microprofile-config.properties
to
application.properties
is not
mandatory as
the package
namespace
would contain
microprofile.
2.
A
non-technical
problem where
Jakarta specs
may not make
dependencies
on
MicroProfile
artifacts.
Can we
clarify what
the problem is
exactly? Is
this something
that can be
worked out?
What I’m
trying to
understand is
if we could
work on the
technical and
non-technical
issues that
prevent
Jakarta from
adopting MP as
is (without
copying and
renaming
packages), and
assuming we
can have those
fixed, would
Jakarta be
able to use it
as a regular
dependency?
To my
best
knowledge,
there was no
restriction
for Jakarta to
use MP as long
as the MP spec
do not depend
on Jakarta. If
MP Config Core
is consumed by
Jakarta, there
would be no
circular
dependency.
Cheers,
Roberto
Date:
RR>
Just using
application.properties
is a good idea
indeed.
RR>
I am sure Ed
and Jared will
respond, but I
believe the
idea here
RR>
is to allow
both Jakarta
EE and
MicroProfile
to evolve
RR>
independently
in accordance
with their own
needs and also
RR>
collaborate
when best seen
fit.
Indeed,
doing that
now.
RC>
|
