|
It is the least I can try to do now
after almost two decades of being an unapologetic Java EE
enthusiast. Frankly I am mostly in wait-and-see mode and hoping
sanity still does somehow prevail. If not, I think the time will
come to have a broader discussion in the community outside vendors
to chart paths forward (I am going to guess different paths for
different individuals based on their own personal values). There
is some concrete data that I would share at that point with
regards to overall resourcing levels compared to what had been put
into Java EE even in the Oracle era let alone the Sun era. This is
data that has been bothering me for a while now but I do not think
it is the right time yet to discuss such issues very broadly.
Hopefully things will still self correct.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual
community member and do not represent the views of my employer.
On 9/21/2019 2:39 PM, Guillermo
González de Agüero wrote:
Thanks for your sincere opinion, Reza.
I think I have already summarized all the
principal issues I see thus far - pretty much everywhere
that my personal bandwidth allows. None of this should be
news to key decision makers.
To summarize it in one sentence: I don't
think MicroProfile was ever designed to be an open
standard and we should be careful conflating it with
Jakarta EE willy nilly. Sometimes good boundaries really
do make for better neighbors.
Jakarta EE clearly was designed to be an
open standard in the same vein Java EE was. Open standards
are the real reason many of us bothered supporting Java EE
in the first place. If the commitment to what that stands
for in every sense is no longer valued, I personally can
say I don't see compelling enough value in Jakarta EE
going forward either. Sans open standards, we have a very
strong and compelling long time de-facto standard in
server side Java. Might as well just get behind that and
finally consolidate the ecosystem.
I suspect most of the community sees that
already and perhaps have already tuned out of all this for
these very reasons. We should be a bit more aware of these
very real possibilities instead of only seeing things from
the perspective of what seems convenient and comfortable
at the moment. I certainly don't want to see all this end
in failure after all these years. Indeed it greatly pains
me to have to say any of this frankly. I really wished I
did not need to...
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own
as an individual community member and do not represent the
views of my employer.
Sent
via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 9/21/19 1:15 PM (GMT-05:00)
Subject: Re: [jakartaee-spec-project-leads] Jakarta
NoSQL and Eclipse MicroProfile Configuration
I wasn't aware of that and I didn't know
Oracle employees were unable to contribute to MP due to IP
flow issues.
But if that's the case, it should be
discussed as an MP issue that is potentially preventing
contributions.
Do you see other problems besides that?
It's definitely worth looking at it now that Jakarta EE
is ready to go.
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
_______________________________________________
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
--
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.
|
