|
I am refocusing my part of the
conversation to where I believe the productive context best
resides and BCCig the rest. If anyone feels otherwise, they can
feel free to re-adapt the recipients.
I wholly agree with Werner. Given the
current situation we can all pretty much see, it is best to add
MicroProfile Configuration as an implementation level integration
with Jakarta NoSQL rather than anything in the specification
itself. Since we only have one implementation in the foreseeable
future this should go a long way to meeting user needs. At the
same token, it avoids devaluing Jakarta EE as a credible open
standard roughly on par with Java EE. This also gives the powers
to be some more time to sort things out properly if that is ever
going to happen.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
P.S. #1: Otavio, I did not realize
you had approached the MicroProfile folks about this. Given what
I thought you had said about MicroProfile and Jakarta EE
alignment, the initial email on this thread confused me a bit. I
figured you had changed your mind for some reason. Now I think I
am getting the intermediate context of what might have
transpired that I did not know about. Obviously, I commend your
effort. I don't think it is completely in vain, in the least it
demonstrates a good faith initiative.
P.S. #2: Werner, I noticed Mark was
the co-lead for the original Configuration JSR. Do you know what
his views are with regards to standardization via Jakarta EE?
Just curious more than anything else.
On 9/22/2019 5:54 PM, Werner Keil
wrote:
Amelia,
The thing with the "small hat" is something that
would be nice to also respect when sharing such a giant piece
of multiple threads with multiple mailing lists. The hat(s)
are just too many and it feels like the Mad Hatter from Alice
in Wonderland instead of a decent "hat" someone can actually
wear or get something out of.
I can only repeat what I already stated in the Jakarta
NoSQL/JNoSQL mailing list, that it seems perfectly fine for an
IMPLEMENTATION like JNoSQL to use MP Config in its current
form, but the Spec/API (Jakarta NoSQL) will not be able to use
it until MP Config was ready to graduate into a Jakarta
Specification as well. Or rather the remains of https://jcp.org/en/jsr/detail?id=382 which
clearly stated "The
Specification Leads and Expert Group agreed to withdraw the
JSR and move it to the Jakarta EE spec process."
As long as that does not happen or it's delayed
because the Spec Leads are The Servant of two Masters, there
is no way Jakarta NoSQL or other Jakarta EE specifications can
use a standardized configuration effort.
While MP Config is one of the few MP features
that are reused by a couple of others, it is far from a true
standard.
The de facto standards would be Apache Commons Config.
Other very promising efforts by Netflix like Archaius (also
based on Commons Config) were archived now and no longer get
maintained, but there are other very versatile efforts that
scratch a similar itch like Apache Tamaya or Helidon Config by
Dmitry who also provided input to this thread. Helidon Config
and Helidon as a whole have no dependency on MicroProfile
except a small dedicated "microprofile bridge" that also uses
MP config, but just in this module.
For implementation projects like JNoSQL there is more than
one option for configuration and MP Config is just one iof
them, it is far from certain that it must be used. For the
Spec until a Jakarta configuration effort is approved by the
Spec Committee or even proposed there, Jakarta NoSQL will have
to substitute any configuration elements on that level. Until
that could be replaced with a standard, just like MicroProfile
would if the config modules were superseded by a Jakarta
Config standard.
Hola from home OSS Community,
Otavio— as the author who started this thread, how
can we help you be the VERY example of proper OSS
outreach via the formal mediums utilized by the
MicroProfile Community?
You chose to send this msg to the Jakarta EE spec
leads forum, do you actually think they get to decide
the MicroProfile future?
This thread started as a fail
of an outreach from your part. I get it, OC1 travels
and exhausting, it happens. NOW— you are a MP
Committer, you are a Jakarta EE Committer— both
communities have their formal outlets to discuss stuff.
Therefore, let our future actions show that you/me/us,
in both communities, are not only paying attention to
how we communicate but most importantly that we are
capable of growing with the feedback provided thus far
and that our actions show care.
To everyone else— who nicely participated in this
thread created during the hectic OC1 Sept 15th, please add
your questions & follow-ups to the working document
titled: EF IP Flow Q&A [2] that the MicroProfile
Community started on June 1st via the Community Hangout
with forum thread [1] along side with the thread in the
correct forum.
+1 to Mark follow up.
Reza— it is ok to if you feel frustrated & may
choose to checkout out of any project as stated when you
write “...has been pretty
futile. Hence, I fear I must decline your kind
invitation because I do not see it as worthwhile at
the current time personally.” Kudos on
stating it via open forums- after all, it is your chosen
voice and voices are welcomed.
I have stated multiple times via diverse mediums and
happy do so again, anyone reading this thread can
hopefully smile:
“if you want to keep everyone happy, you should
be selling ice-cream instead of working as a
Contributor in OSS”— I
stand by this msg. :)
After spending 10 days sharing much with many of the traveling and locals who form our amazing ecosystem, I want to remind each one of us one of my favorite OSS blogs by Rich Bowen written in 11/18 yet valid today b/c its core is our individual voices in OSS communities.
QUOTE:
"By wearing the
smallest hat possible –i.e., speaking with the voice
with the least authority– you allow other people to
be free to express their own dissenting opinions
without feeling that they have already been
overruled. This is in line with our culture of
providing a level playing field, where all voices
are equal, and all opinions are weighed the same."
Lastly, the MicroProfile project has a flat structure where everyone who actively participates, gets the merit and gets to directly influence the project.
Titles and vendors are meaningless - b/c we have chosen to protect its flat structure from day zero to now.
What matters is each Contributors’ actions. Her/his merit is owned and acknowledgments become true by other individuals, who prioritize showing up, those whose actions lead by example on getting shit done and moving way from potential “drama”.
Therefore, in MP any individual “entitlement" is crushed at each turn. We grow as a stronger community each day b/c we choose to ask more questions and avoid throwing assumptions.
The respect to protect our time and that of others is everything. After all, investment in OSS demands each individual owning and being responsible for debt-thrown. You, me, us affirm via projective-mode, our stands that are hopefully fluid and adjusted as we fail and stand up to make not only ourselves but others just a tiny bit better.
THAT is what makes MicroProfile welcome anyone who wants to try helping out do so without barriers or glamouring BS.
My take: MicroProfile continues to state that it is not ready to be part of the Jakarta EE project.
the MP community and its amazing fluid progress won’t be halt nor forced to join any project.
This has nothing to do with the current reality of the Jakarta EE. MP is a complement to Jakarta EE, therefore it is up to the Jakarta EE contributors to utilize the MP APIs as she/he see it fit.
Lets first and foremost focus on the independent growth of both communities. Reminder that the management of both communities is not the same.
MP is fully run by its Community without layers. —
This is my voice as a Microprofile Contributor.
Coffee at hand, wishing everyone a beautiful rest of
a Sunday/Monday!
From what I have observed time and
again, trying to initiate any discussion around
any of this in the MicroProfile alias has been
pretty futile. Hence, I fear I must decline your
kind invitation because I do not see it as
worthwhile at the current time personally. If
others deem differently, I am sure they will try
to initiate discussion once again and hope it
will go somewhere this time around.
As I said, at the current time, my
outlook is mostly to wait and see what happens.
I am afraid there comes a point when that is all
one is motivated to utilize their personal
bandwidth towards and simply hope things will
sort themselves out (or not).
That all said, if a discussion
does start and appears to progress towards some
kind of sensible path forward different from
past patterns, it might find the motivation to
chime in. I do fairly closely watch the goings
on there.
Reza Rahman
Principal Program Manager
Java on Azure
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 --------
Date: 9/22/19 6:40 AM (GMT-05:00)
Subject: Re: [jakartaee-spec-project-leads]
Jakarta NoSQL and Eclipse MicroProfile
Configuration
Reza, as has been pointed out to you several times
already, whilst it’s fine to have discussions and
opinions about other efforts happening elsewhere
here, the final decisions for those efforts (e.g.,
Config) need to be driven by those communities
(e.g., MP) and not by Jakarta EE. Just as I
wouldn’t expect the MP community, say, to try to
determine the future of a Jakarta EE specification
or an open source effort happening in ASF, for
example. So please take those thoughts and
opinions to the right communities and let’s
continue to respect them accordingly.
The notion that Oracle cannot contribute to
MP due to issues around IP flow is not news to a
number of individuals/groups within MP but it is
good that it is now out in the open. I know that
those discussions had already started within MP
lists months ago anyway but had stalled due to
the concerted effort by everyone to get Jakarta
EE 8 out. Now I believe they will restart, so
once again a great time for people (yourself
included) to get involved in the right lists and
with the correct community. However, I strongly
suggest that statements like "if MicroProfile
even can be said to have much of a defined
process” be left behind because they can be too
easily misinterpreted in the negative and lead
to conflicts and defensive behaviours that won’t
result in any easy resolution. Let’s all stick
to the facts and behave accordingly.
Thanks,
Mark.
As Oracle leadership
correctly mentioned during Oracle Code
One, there are even bigger issues
besides the fact that these are
fundamentally different processes (if
MicroProfile even can be said to have
much of a defined process) and that
this will introduce complexity,
inconsistency and confusion basically
forever for everyone involved -
especially people that will need to
advocate for this technology as
independents. The IP flow for
MicroProfile is murky. As a result, I
don't think Oracle can even legally
accept just incorporating MicroProfile
into Jakarta EE without further proper
standardization. This is indeed why
Oracle employees are not allowed to
contribute to MicroProfile today.
The fact that
MicroProfile Configuration is stable
is the very reason it makes sense to
properly assimilate and harmonize it
into Jakarta EE as opposed to keep it
in MicroProfile any more. In my view,
that cannot be said of many other if
any other MicroProfile specifications.
Reza Rahman
Principal Program
Manager
Java on Azure
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
--------
Date: 9/21/19 7:16 AM (GMT-05:00)
Subject: Re:
[jakartaee-spec-project-leads]
Jakarta NoSQL and Eclipse
MicroProfile Configuration
One problem I see with
Jakarta EE depending on MP specs is
the different backward compatibility
policies. MP only allows breaking
compatibility on major versions while
I expect Jakarta EE to stay even more
conservative (similar to Java EE).
In that sense, moving
the Config spec to Jakarta EE
(keeping the package) would
basically stabilize its processes to
the same level as Jakarta EE. The
Config spec is pretty mature so this
move wouldn't hurt it.
But for the time
being, and given that we all agree
we don't want to change packages,
I think it's reasonable for
Jakarta NoSQL to depend on MP
Config while we decide how to
handle this situation. In the end,
the API will be the same.
Scott,
Jakarta
JNoSQL needs to rely on MP
Config. The discussion is to
make MP Config adopted by
Jakarta Specs without any
package name changes. Jakarta
specs are available to MP specs
already. Personally, I would
like to see MP specs to be
adopted by Jakarta specs.
Thanks
Emily
As I'm
reading this I'm
trying to understand
why there'd need to be
a Jakarta Config spec
in order for
individual Jakarta
specs like NoSQL, etc.
to use MicroProfile
Config.
Is this
fundamentally
different from the
individual Jakarta
specs evolving to use
new Java language
features (a process
not controlled by
Jakarta).
If it
gets to the point that
there are a set of
special cases for
Jakarta applications
then maybe that would
be a good time to
launch a Jakarta
Config spec, but for
now couldn't
individual specs just
start using MP Config
and see where it goes?
That
said.. I think it's
smart to discuss first
and get a consensus
this isn't a
completely wrong
direction to head
down..
------------------------------------------------------
Scott Kurz
WebSphere Batch and
Compute Grid
Development and Level
3 Team Lead
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102544
skurz@xxxxxxxxxx
--------------------------------------------------------
![Inactive hide
details for Mark
Little ---09/19/2019
10:16:21 AM---+1 >
On 18 Sep 2019, at
20:35, Josh Juneau
<juneau001@gmail.c]() Mark
Little ---09/19/2019
10:16:21 AM---+1 >
On 18 Sep 2019, at
20:35, Josh Juneau
<juneau001@xxxxxxxxx>
wrote:
From:
Mark
Little <markclittle@xxxxxxxxx>
To: JakartaEE
Spec Project
Leadership discussions
<jakartaee-spec-project-leads@xxxxxxxxxxx>
Date:
09/19/2019
10:16 AM
Subject:
[EXTERNAL]
Re:
[jakartaee-spec-project-leads]
Jakarta NoSQL and
Eclipse MicroProfile
Configuration
Sent
by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
+1
On 18 Sep 2019, at
20:35, Josh Juneau
<juneau001@xxxxxxxxx>
wrote:
I agree that the
Jakarta EE Platform
should adopt
MicroProfile Config as
a standard spec.
However, I do not feel
that there should be
any need for renaming
or changing the
MicroProfile Config
project. MicroProfile
should still be able
to continue evolving
separately.
Is it possible for
Jakarta EE to adopt
MicroProfile Config as
the reference
implementation for a
"Jakarta EE Config"
spec? In my mind, this
would be much like
Weld is the reference
implementation for
CDI, although
namespaces are
different between the
two.
Thanks
Josh Juneau
juneau001@xxxxxxxxx
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau
On Sep 18, 2019,
at 7:35 PM, Emily
Jiang <emijiang6@xxxxxxxxxxxxxx>
wrote:
My preference is
to go through a
lightweight
boarding process.
I am against the
idea of renaming
packages.
Thanks
Emily
On Sep 18, 2019
at 2:50 pm, <Kevin Sutter> wrote:
Correct.
Do not assume
that just
because we
have to change
javax to
"jakarta" that
it applies to
all projects
that might
someday be
associated
with Jakarta
EE. The javax
rename is a
special case
due to Oracle
requirements.
As Dmitry
points out
this whole
area needs
further
discussion.
---------------------------------------------------
Kevin Sutter
STSM,
MicroProfile
and Jakarta EE
architect
e-mail:
sutter@xxxxxxxxxx Twitter: @kwsutter
phone:
tl-553-3620
(office),
507-253-3620
(office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: "dmitry.kornilov"
<dmitry.kornilov@xxxxxxxxxx>
To: JakartaEE
Spec Project
Leadership
discussions
<jakartaee-spec-project-leads@xxxxxxxxxxx>
Date: 09/18/2019
12:31 PM
Subject: [EXTERNAL]
Re:
[jakartaee-spec-project-leads]
Jakarta NoSQL
and Eclipse
MicroProfile
Configuration
Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
It doesn't mean
it. Where is an
option to keep microprofile.io namespace. We need to
discuss it.
- Dmitry
-------- Исходное
сообщение --------
От: Otavio Santana
<otaviopolianasantana@xxxxxxxxx>
Дата: 18.09.2019
10:56 (GMT-08:00)
Кому: JakartaEE
Spec Project
Leadership
discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Тема: Re:
[jakartaee-spec-project-leads]
Jakarta NoSQL and
Eclipse
MicroProfile
Configuration
If move Eclipse
MicroProfile into
Jakarta EE process
means a new
package name such
as jakarta.config.
I don't think that
is a good idea,
because several
people use Eclipse
MicroProfile in
production. So, we
are going to have
two projects to
the same thing
(one as
MicroProfile and a
second one as
Jakarta), and
sometimes it might
mean copy/paste
from/to projects.
Therefore, smell
code on both
projects.
On Wed, Sep 18,
2019 at 10:36 AM
Dmitry Kornilov
<dmitry.kornilov@xxxxxxxxxx>
wrote:
Emily,
I have a better
idea. Let's make
MP Config the
first spec which
follows Jakarta EE
spec process. It
will make it a
full Jakarta EE
citizen and open
doors to other
specs to use it.
:)
Thanks,
Dmitry
On 18 Sep 2019, at
05:38, Emily Jiang
<emijiang6@xxxxxxxxxxxxxx>
wrote:
Hi Otavio,
As promised via
our chat, I would
share my view
here.
I totally agree
that Configuration
is very important
for developing
cloud-native
microservices. It
is a best practice
in 12-Factor App
to make
microservice
configurable.
MicroProfile
Config exists for
exactly that
reason. I strongly
recommend to use
it.
As for your
question of
whether it is ok
for Jakarta EE to
depend on Eclipse
MicroProfile
Config, I think it
is a good idea.
Since many people
including Adam
Bien, myself, etc,
seriously think
Jakarta EE +
MicroProfile are
very powerful
together and most
of time they are
needed at the same
time, I strongly
think it makes
sense for Jakarta
EE specs also
utlising
MicroProfile specs
such as
MicroProfile
Config, etc.
MicroProfile specs
already pull in
Jakarta EE specs,
such as CDI,
JAX-RS, JSON-B and
JSON-P.
Technically
Jakarta EE should
be able to pull in
MicroProfile
specs.
If a lightweight
onboarding process
is needed to
enable
MicroProfile specs
to be used in
Jakarta Specs, I
am ok with that.
It is very
important that
MicroProfile and
Jakarta continue
complementing with
each other not
competing with
each other.
My 2cents.
Emily
On Sun, Sep 15,
2019 at 9:07 PM
Otavio Santana
<otaviopolianasantana@xxxxxxxxx>
wrote:
Hello everyone, I
have one question
about the
integration
between Jakarta
and Eclipse
MicroProfile.
As you know,
Jakarta EE has the
goal of the
cloud-native
application, so we
tend to use good
practices on that.
There is the
twelve-factor
of an Appthat
has the good
practices of
delivery your
application in the
cloud, and the third item there is the configuration.
My whole point
here is that need
to have one API to
all Jakarta EE
project to use
related to
configuration. We
might use this API
on several
projects such as
JPA, JMS, and so
on. Right now, we're facing this
discussion on
Jakarta NoSQL.
My question is: Do
we have plans to
integrate Jakarta
EE with Eclipse MicroProfile
Configuration?
I'm not happy with
a copy/paste
approach from a
feature that
already exists,
because that means
two points to
maintain;
furthermore, that
is not good code
practices.
In the cloud, the
perspective
configuration will
be like CDI,
because several
specifications are
going to use it.
Right now, my best
shot to Jakarta
NoSQL is to use
only in the
Reference
implementation and
put it as
optional.
--
Otávio Santana
twitter: http://twitter.com/otaviojava
site: http://about.me/otaviojava
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
--
Thanks
Emily
=================
Emily Jiang
ejiang@xxxxxxxxxx
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
--
Otávio Santana
twitter: http://twitter.com/otaviojava
site: http://about.me/otaviojava
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery
options,
retrieve your
password, or
unsubscribe
from this
list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads
mailing list jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from
this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from this
list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your
delivery options,
retrieve your
password, or
unsubscribe from this
list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery
options, retrieve your
password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing
list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member and do not represent the views of my employer.
|
