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>
A few comments
inline. Thank
you!
JA>
This email is
a follow up to
the discussion
at the
2025-02-04
JA>
Jakarta EE
platform call.
JA>
In that call,
we discussed
an approach
where Jakarta
EE 12 could
JA>
effectively
use
MicroProfile
Config "as is"
with some
important
JA>
non-technical
accommodations.
JA>
1. The APIs
for Jakarta
Config would
be the
MicroProfile
Config APIs,
JA>
but with
jakarta
namespace.
Yes, a
copy/paste.
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