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
adjustme=
