On Tue, May 7, 2019 at 1:15 PM carlos andres de la rosa
<kusanagi12002@xxxxxxxxx <mailto:kusanagi12002@xxxxxxxxx>> wrote:
Yes good catch and also any other resources like properties files
and also documentation resources
Cheers
On Tue, May 7, 2019, 20:06 Mark Struberg <struberg@xxxxxxxxxx
<mailto:struberg@xxxxxxxxxx>> wrote:
one of the points I just came across is for example all the xsd
and dtd we have. They are referenced as javax/..
And expecially in the XML area we have namespaces starting with
javax as well.
I didn't think through, but we have to add them to the list of
things to clarify.
LieGrue,
strub
> Am 07.05.2019 um 19:27 schrieb carlos andres de la rosa
<kusanagi12002@xxxxxxxxx <mailto:kusanagi12002@xxxxxxxxx>>:
>
> That is pretty good mark have a proof of concept can be
pretty helpful to validate the approach and what will be the
challenges that we will face in order to get the change done.
>
>
> Cheers
>
> On Tue, May 7, 2019, 19:18 Mark Struberg <struberg@xxxxxxxxxx
<mailto:struberg@xxxxxxxxxx>> wrote:
> It doesn't matter anyway. We cannot finally decide anything
before say end of July.
> Because FIRST I'd like to play with the options. I'm already
pretty far with moving some libs over to jakarta.*.
> But Tomcat is really depending on WAY more than I would love
to see. JAX-RPC anyone? ;)
>
> If Tomcat is up and running with a few apps, then we might
have a way better understanding about whether a big-bang will
work out or not.
>
> Just my $.02
>
> LieGrue,
> strub
>
> > Am 07.05.2019 um 18:55 schrieb Mark Little
<markclittle@xxxxxxxxx <mailto:markclittle@xxxxxxxxx>>:
> >
> > I think 500-1000 data points is useful but unless I know
the people who cast their votes are actually involved in the
community (which is possible through email), I'll have to weigh
those votes slightly different than, say, a vote I receive from you.
> >
> > Mark.
> >
> > On Tue, May 7, 2019 at 11:27 AM Reza Rahman
<reza_rahman@xxxxxxxxx <mailto:reza_rahman@xxxxxxxxx>> wrote:
> > There is no such thing as a perfect sampling. What matters
is whether a poll is sufficiently representative. I think
500-1000 data points is pretty representative. That's why
results tend to stabilize by that point.
> >
> > Please note these are my personal opinions as a Jakarta EE
community member, and do not necessarily reflect the positions
of my employer.
> >
> > On 5/7/2019 6:57 PM, Mark Little wrote:
> >> Agreed. I caution against polls like this which are
anonymous because it's hard to determine the actual value of the
data.
> >>
> >> Mark.
> >>
> >> On Mon, May 6, 2019 at 9:00 PM Amelia Eiras
<aeiras@xxxxxxxxxxxxx <mailto:aeiras@xxxxxxxxxxxxx>> wrote:
> >> The MicroProfile Project doesn’t operate under polls Reza.
> >> The process is over its community hangout and forum.
> >>
> >>
> >> Amelia Eiras
> >> https://twitter.com/ameliaeiras
> >> Tribe: https://tomitribe.com https://tribestream.io
> >> OSS: https://tomitribe.io https://microprofile.io
> >>
> >>> On May 6, 2019, at 5:58 PM, Reza Rahman
<reza_rahman@xxxxxxxxx <mailto:reza_rahman@xxxxxxxxx>> wrote:
> >>>
> >>> I am with Ryan here. There is a lot of FUD spreading
around about what the commitment levels to MicroProfile is
vis-a-vis Jakarta EE. This really isn't
helping anyone here and in fact is leading the whole community
towards fragmentation, ultimately undermining both MicroProfile
and Jakarta EE. I hope that is a perspective that is understood
well. People are indicating a preference for doing the move all
at once, but it is not necessarily the case that they don't see
the value in moving MicroProfile APIs over to Jakarta EE. Indeed
maybe they prioritize new features from MicroProfile more.
> >>>
> >>> Here is a poll I am running on that topic:
https://twitter.com/reza_rahman/status/1124499308970004480.
There are ~500 input points so far. Here are the results:
> >>>
> >>> * 19% - Stays separate forever
> >>> * 58% - Merges with Jakarta EE
> >>> * 14% - Becomes Jakarta incubator
> >>> * 09% - Forget Jakarta. MP rules
> >>>
> >>> Again, I really do hope the Eclipse Foundation polls
people on this. If not, please at least consider retweeting mine.
> >>>
> >>> On 5/7/2019 8:32 AM, Ryan Cuprak wrote:
> >>>>
> >>>> My thoughts:
> >>>> • Jakarta EE 9 - Fold some parts of the MicroProfile
into the platform and leave the existing specifications alone.
Do this to freshen the platform and keep it relevant. Containers
always lag supporting the latest specification and I’d expect
this to be especially pronounced with a namespace change.
Changing a namespace may sound easy, but I am guessing
maintaining backward support may not be - may cause products to
be EOL or forked etc. Maybe move specifications that are low
risk and/or not used as widely to the new namespace but make
this optional.
> >>>> • Jakarta EE 10 - all specifications on new namespace
> >>>> • Jakarta EE 11 - new features to the existing
specifications
> >>>>
> >>>> While Jakarta EE 9 is being put together, begin
releasing previews of EE 10 with the new namespace so that
organizations can begin accessing its impact.
> >>>>
> >>>> With the big bag conversion, I’d be curious to hear what
the vendors are thinking along with the IDEs. Could the major
container vendors be polled?
> >>>>
> >>>> -Ryan
> >>>>
> >>>>
> >>>>> On May 6, 2019, at 7:39 PM, David Blevins
<dblevins@xxxxxxxxxxxxx <mailto:dblevins@xxxxxxxxxxxxx>> wrote:
> >>>>>
> >>>>> Following up with my individual hat on. If we can get
this wrapped sooner than a month, great. If there's clear
consensus on any particular direction, let's just go for it.
> >>>>>
> >>>>> There are items in the "Decisions" sections. The
thinking is that we should decide what proposal we want (either
of these two or something else) within the timeframe allotted.
Decisions associated with the proposal that need to be cleared
before it can be executed may naturally take longer to make.
> >>>>>
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On May 6, 2019, at 4:23 PM, David Blevins
<dblevins@xxxxxxxxxxxxx <mailto:dblevins@xxxxxxxxxxxxx>> wrote:
> >>>>>>
> >>>>>> [Contents of this email represent discussions of the
Jakarta EE Specification Committee over the last several
meetings. The statements here have been reviewed by and
represent the voice of the Jakarta EE Specification Committee]
> >>>>>>
> >>>>>> As announced in the Update on Jakarta EE Rights to
Java Trademarks[1] post on Friday, future modification of the
javax namespace will not be allowed. While this is not what was
envisioned when Jakarta EE started, in many ways this in our
best interest as the modification of javax would always have
involved long-term legal and trademark restrictions.
> >>>>>>
> >>>>>> To evolve Jakarta EE, we must transition to a new
namespace. The primary decisions we need to make as a community
and industry are how and when. Given all delays and desires on
everyone’s part to move forward as fast as possible, we would
like to have this discussion openly as a community and conclude
in one month. It is the hope that in one month a clear consensus
emerges and can be presented to the Specification Committee for
final approval.
> >>>>>>
> >>>>>> In an effort to bootstrap the conversation, the
Specification Committee has prepared two proposals for how we
might move into the new namespace. These should be considered a
starting point, more proposals are welcome. No final decisions
have been made at this stage.
> >>>>>>
> >>>>>> The guiding principle for Jakarta EE.next will be to
maximize compatibility with Jakarta EE 8 for future versions
without stifling innovation.
> >>>>>>
> >>>>>> Other proposals should incorporate the following
considerations and goals:
> >>>>>>
> >>>>>> • The new namespace will be jakarta.*
> >>>>>> • APIs moved to the jakarta namespace maintain class
names and method signatures compatible with equivalent class
names and method signatures in the javax.* namespace.
> >>>>>> • Even a small maintenance change to an API would
require a javax to jakarta change of that entire specification.
Examples include:
> >>>>>> • Adding a value to an enum
> >>>>>> • Overriding/adding a method signature
> >>>>>> • Adding default methods in interfaces
> >>>>>> • Compensating for Java language changes
> >>>>>> • Binary compatibility for existing applications in
the javax namespace is an agreed goal by the majority of
existing vendors in the Jakarta EE Working Group and would be a
priority in their products. However, there is a strong desire
not to deter new implementers of the jakarta namespace from
entering the ecosystem by requiring they also implement an
equivalent javax legacy API.
> >>>>>> • There is no intention to change Jakarta EE 8 goals
or timeline.
> >>>>>> • Community discussion on how to transition to the
jakarta namespace will conclude Sunday, June 9th, 2019.
> >>>>>>
> >>>>>> It is envisioned binary compatibility can be achieved
and offered by implementations via tooling that performs
bytecode modification at either build-time, deploy-time or
runtime. While there are open questions and considerations in
this area, the primary goal of the discussion that must conclude
is how do we move forward with future modifications to the APIs
themselves.
> >>>>>> Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New
Features
> >>>>>> The heart of this proposal is to do a one-time move of
API source from the javax namespace to the jakarta namespace
with the primary goal of not prolonging industry cost and pain
associated with the transition.
> >>>>>>
> >>>>>> Were we to take this path, a compelling approach would
be to do the namespace rename and immediately release this as
Jakarta EE 9. Additional modifications would be put into a
Jakarta EE 10 which can be developed in parallel, without
further delays.
> >>>>>>
> >>>>>> • Some or all Jakarta EE APIs under javax would move
immediately into jakarta as-is.
> >>>>>> • Any packages not moved from javax to jakarta could
be included in Jakarta EE, but would be forever frozen and never
move to the jakarta namespace.
> >>>>>> • Jakarta EE 9 would be refocused as quick,
stepping-stone release, identical to Jakarta EE 8 with the
exception of the javax to jakarta namespace change and
immediately released.
> >>>>>> • Jakarta EE 10 would become the new release name for
what we imagined as Jakarta EE.next with only minor impact on
timeline.
> >>>>>> • Work on Jakarta EE 10 could start immediately after
rename is completed in the GitHub source and need not wait for
the Jakarta EE 9 release to actually ship.
> >>>>>> Pros:
> >>>>>> • One-time coordination and cost to the industry,
including; conversion tools, users, enterprises, cloud vendors,
IDE creators, platform vendors, trainers and book authors.
> >>>>>> • Easily understood rule: everything Jakarta EE 8 and
before is javax, Jakarta EE 9 and after is jakarta
> >>>>>> • Consistent with the javax to jakarta Maven groupId
change.
> >>>>>> • Highest degree of flexibility and freedom of
action, post-change.
> >>>>>> • Industry would have the opportunity to begin
digesting the namespace change far in advance of any major new
APIs or feature changes.
> >>>>>> Cons:
> >>>>>> • Largest upfront cost for everyone.
> >>>>>> • Specifications that may never be updated would
still likely be moved.
> >>>>>> • Decision to not move a specification is permanent
and therefore requires high confidence.
> >>>>>> Decisions:
> >>>>>> • Which specifications, if any, would we opt not to move?
> >>>>>> • Would we take the opportunity to prune
specifications from Jakarta EE 9?
> >>>>>> • Do we change the language level in Jakarta EE 9 to
Java SE 11 or delay that to Jakarta EE 10?
> >>>>>>
> >>>>>> Proposal 2: Incremental Change in Jakarta EE 9 and beyond
> >>>>>> Evolve API source from javax to the jakarta namespace
over time on an as-needed basis. The most active specifications
would immediately move in Jakarta EE 9. Every Jakarta EE
release, starting with version 10 and beyond may involve some
javax to jakarta namespace transition.
> >>>>>>
> >>>>>> • The most active APIs would immediately move from
javax to jakarta
> >>>>>> • APIs not changed or determined by the community to
be unlikely to change would stay in javax
> >>>>>> • Jakarta EE 9 would be a mix of javax and jakarta
packaged APIs
> >>>>>> • If a change was needed to a javax API post Jakarta
EE 9 for any reason, that API would transition from javax to
jakarta.
> >>>>>> • Jakarta EE 10 would be a mix of javax and jakarta
packaged APIs, but a different mix than Jakarta EE 9.
> >>>>>> • At some point down the road, Jakarta EE xx, it may
be decided that the migration from javax to jakarta is “done”
and the final APIs are moved.
> >>>>>> Pros:
> >>>>>> • Cheaper up front cost and reduced immediate noise.
> >>>>>> • No need to move specifications unless there is an
immediately visible benefit.
> >>>>>> • Potential for less impact from API change overall.
> >>>>>> Cons:
> >>>>>> • Prolonged coordination, cost and complexity to
industry affecting conversion tools, users, enterprises, cloud
vendors, IDE creators, platform vendors, trainers and book authors.
> >>>>>> • Use of restricted javax namespace prolonged.
> >>>>>> • Frustration of “always changing” packages may deter
application developers and become a permanent perception of the
brand.
> >>>>>> • Difficulty in remembering/knowing which Jakarta EE
release an API was moved. “Is Connector javax or jakarta in
Jakarta EE 11?”
> >>>>>> • Difficulty in keeping the industry in sync.
> >>>>>> • New implementations may find themselves having to
deal with the javax to jakarta transition, unable to avoid
legacy costs and therefore decide not to enter the space.
> >>>>>> • Transitive dependencies to other specifications may
make incremental change difficult or impossible.
> >>>>>> • Restrictions on what Java SE implementation can be
used for certification
> >>>>>> Decisions:
> >>>>>> • Do we start small or start large?
> >>>>>> • Which APIs would immediately need to be changed?
> >>>>>> Out of Scope
> >>>>>> The following are very important community
discussions, but do not require a decision in the time-frame
allotted:
> >>>>>>
> >>>>>> • Roadmap or release date for any Jakarta EE.next
that would contain new features
> >>>>>> • List of specifications that may be deprecated,
pruned or removed from Jakarta EE.next, if any
> >>>>>> • Specification text around backwards compatibility
requirements, if any
> >>>>>> • What profiles should be defined
> >>>>>>
> >>>>>> However, depending on the path chosen, some of these
topics may require immediate resolution before the chosen path
can be executed.
> >>>>>>
> >>>>>> [1]
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
> >>>>>>
> >>>>>> --
> >>>>>> David Blevins
> >>>>>> http://twitter.com/dblevins
> >>>>>> http://www.tomitribe.com
> >>>>>> 310-633-3852
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> jakartaee-platform-dev mailing list
> >>>>> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> >>>>> To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
> >>>>>
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> jakartaee-platform-dev mailing list
> >>>>
> >>>> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> >>>>
> >>>> To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
> >>>>
> >>>>
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> >>> _______________________________________________
> >>> jakartaee-platform-dev mailing list
> >>> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> >>> To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
> >>>
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> >>
> >> _______________________________________________
> >> jakartaee-platform-dev mailing list
> >> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> >> To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
> >>
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> >>
> >>
> >> _______________________________________________
> >> jakartaee-platform-dev mailing list
> >>
> >> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> >>
> >> To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
> >>
> >>
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> > _______________________________________________
> > jakartaee-platform-dev mailing list
> > jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> > To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
