[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
|
Bingo.
> On Jun 5, 2019, at 2:20 PM, Lilian BENOIT <lilian.benoit@xxxxxxxxxx> wrote:
>
> On the contrary, would be is it premature to want rename package without direction of Jakarta Platform.
>
> we could make a new version only new specifications and javaee specifications.
> During this period, we could work to define specifications which will must evolved ?
> We will have more informations for choosing big bang or incremental approach ?
>
> With new version, we will send a good signal for user community. Jakarta EE is LIVE.
>
> Best regards,
> Lilian BENOIT.
>
>
> Le 05/06/2019 22:58, Bill Shannon a écrit :
>> There's already some optional specs in Java EE 8, we could remove
>> them in Jakarta EE 9 and then not have to worry about moving them to
>> jakarta.*.
>> We could also consider pruning some other specs by making them
>> proposed optional in Jakarta EE 9 and making them optional and
>> possibly removing them in Jakarta EE 10. Such specs might not need to
>> be moved to jakarta.*.
>> I think this is why the Big Bang proposal says "some or all" will be
>> moved to jakarta.*; it allows us to leave behind specs that we plan to
>> abandon.
>> But we haven't decided what our pruning or removal policy will be for
>> Jakarta EE releases so this may be premature.
>> Kevin Sutter wrote on 6/5/19 1:37 PM:
>>> Steve,
>>> _> __Are you really suggesting that after all this time that we
>>> actually don’t want to change the apis that we’ve just spent two
>>> years moving to the Eclipse Foundation?_
>>> Not at all. I'm just being pragmatic. It's very easy to talk about
>>> all of the desired changes. It's another to get the community fired
>>> up to actually architect, develop, test, and document all of the
>>> changes. An incremental approach would allow the more gradual (I'd
>>> say natural) migration from javax to jakarta. It also allows us to
>>> better determine which Specs are not active and maybe candidates for
>>> stabilization or deprecation or even removal.
>>> ---------------------------------------------------
>>> 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 [1]
>>> From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
>>> To: jakartaee-platform developer discussions
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> Date: 06/05/2019 03:23 PM
>>> Subject: [EXTERNAL] Re: [jakartaee-platform-dev]
>>> Transitioning Jakarta EE to the jakarta namespace
>>> Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>>> -------------------------
>>> I’m not aware of any list. The linked document is Arjan’s view
>>> of what he wants to see. I’m sure others would have other ideas. I
>>> for one would want to see evolution of CDI, JBatch, JPA and JMS and
>>> maybe even EJB which weren’t on the list.
>>> Now that APIs have been moved to the Eclipse Foundation whether an
>>> api evolves or not is up to the open source project and the
>>> corresponding community. However I firmly believe that for all the
>>> mainstream heavily used Java EE 8 apis there is a desire out there
>>> to see them evolve.
>>> Are you really suggesting that after all this time that we actually
>>> don’t want to change the apis that we’ve just spent two years
>>> moving to the Eclipse Foundation?
>>> Steve
>>> FROM:jakartaee-platform-dev-bounces@xxxxxxxxxxx
>>> <jakartaee-platform-dev-bounces@xxxxxxxxxxx> ON BEHALF OF John
>>> Clingan
>>> Sent: 05 June 2019 20:54
>>> To: jakartaee-platform developer discussions
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to
>>> the jakarta namespace
>>> BTW, I should mention that my comment was general in nature and not
>>> targeted specifically at Bill’s comment. I just wanted to insert
>>> my thought somewhere and that seemed as good a place as any :-)
>>> @Steve, you mentioned "we believe a majority of APIs need to
>>> evolve”. Does a list exist of which APIs plan to evolve and in
>>> what timeframe? I think the only list I’ve seen is here:
>> https://www.eclipse.org/community/eclipse_newsletter/2019/february/Jakarta_EE_9.php
>>> [2]
>>> On Jun 5, 2019, at 11:47 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
>>> +1, John. We can start incrementally and move to big bang later.
>>> We can't do the reverse.
>>> ---------------------------------------------------
>>> 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 [1]
>>> From: John Clingan <jclingan@xxxxxxxxxx>
>>> To: jakartaee-platform developer discussions
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> Date: 06/05/2019 12:55 PM
>>> Subject: [EXTERNAL] Re: [jakartaee-platform-dev]
>>> Transitioning Jakarta EE to the jakarta namespace
>>> Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>>> -------------------------
>>> I’ve been pretty quiet up to this point, following the discussion.
>>> Early on was I was for “big bang” for various reasons already
>>> outlined in other comments. What I find increasingly concerning, the
>>> more I think about it, we are guessing/making assumptions as to the
>>> impact of a decision.
>>> “We don’t know what we don’t know”, IMHO. Making a big-bang
>>> change is a big step that could have unforeseen consequences to the
>>> ecosystem and the user base. We are a small group discussing the
>>> namespace issue that is trying to represent a developer base of
>>> probably 1M managing potentially millions deployed apps based on
>>> these specs. A more conservative approach would be to do an
>>> incremental update, measure the impact and learn some things along
>>> the way, and then decide if further incremental steps are required
>>> or if we can simply move the remainder.
>>> On Jun 5, 2019, at 9:20 AM, Bill Shannon <bill.shannon@xxxxxxxxxx>
>>> wrote:
>>> Oracle agrees that Big Bang is best.
>>> Steve Millidge (Payara) wrote on 6/5/19 9:12 AM:
>>> Just to add Payara favours a big bang approach as described in
>> https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/proposal-01-bigbang.adoc
>>> [3]we believe a majority of APIs need to evolve and therefore a
>>> majority of apis will eventually move to the Jakarta namespace so
>>> may as well do it now.
>>> From:
>> jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>ON
>>> BEHALF OF Scott Stark
>>> Sent: 05 June 2019 16:59
>>> To: jakartaee-platform developer discussions
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to
>>> the jakarta namespace
>>> There has been no decision and there continues to be uncertainty as
>>> to the best approach. Vendors seem to favor an incremental approach
>>> as there is a belief that it eases backward compatibility stories.
>>> Developers seem to favor getting the move over with. I think the
>>> current plan is to talk about a plan toward a decision on the
>>> upcoming June 12 community call.
>>> On Jun 5, 2019, at 4:19 AM, reza_rahman <reza_rahman@xxxxxxxxx>
>>> wrote:
>>> Has a definitive decision on this been reached already? If not, when
>>> will it be reached? If a decision has been reached, can the
>>> community have visibility into how each of the stakeholders voted on
>>> this issue and why?
>>> I looked at the recent meeting minutes and it is very unclear to me
>>> if a vote was held and what the rationale from each decision maker
>>> was. In particular I would personally like to understand how
>>> community input was weighted.
>>> I am still hoping we can all celebrate together soon with the right
>>> forward looking and community focused decision being made by
>>> stakeholders.
>>> 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.
>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>> -------- Original message --------
>>> From: David Blevins <dblevins@xxxxxxxxxxxxx>
>>> Date: 5/6/19 7:23 PM (GMT-05:00)
>>> To: jakartaee-platform-dev@xxxxxxxxxxx
>>> Subject: [jakartaee-platform-dev] Transitioning Jakarta EE to the
>>> jakarta namespace
>>> [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
>>> javaxnamespace 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 javaxwould 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
>>> javaxto jakartachange of that entire specification. Examples
>>> include:
>>> o Adding a value to an enum
>>> o Overriding/adding a method signature
>>> o Adding default methods in interfaces
>>> o Compensating for Java language changes
>>> · Binary compatibility for existing applications in the
>>> javaxnamespace 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 jakartanamespace from entering the ecosystem by
>>> requiring they also implement an equivalent javaxlegacy API.
>>> · There is no intention to change Jakarta EE 8 goals or
>>> timeline.
>>> · Community discussion on how to transition to the
>>> jakartanamespace 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 javaxnamespace to the jakartanamespace 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 javaxwould move
>>> immediately into jakartaas-is.
>>> · Any packages not moved from javaxto jakartacould be
>>> included in Jakarta EE, but would be foreverfrozen and never move to
>>> the jakartanamespace.
>>> · Jakarta EE 9 would be refocused as quick, stepping-stone
>>> release, identical to Jakarta EE 8 with the exception of the javaxto
>>> jakartanamespace 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 javaxto jakartaMaven 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 javaxto the jakartanamespace 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 javaxto jakartanamespace
>>> transition.
>>> · The most active APIs would immediately move from javaxto
>>> 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 javaxand jakartapackaged
>>> APIs
>>> · If a change was needed to a javaxAPI post Jakarta EE 9 for
>>> any reason, that API would transition fromjavaxto jakarta.
>>> · Jakarta EE 10 would be a mix of javaxand jakartapackaged
>>> 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 javaxto jakartais “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 javaxnamespace 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 javaxorjakartain Jakarta EE 11?”
>>> · Difficulty in keeping the industry in sync.
>>> · New implementations may find themselves having to deal with
>>> the javaxto jakartatransition, 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/
>>> [4]
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins [5]
>>> http://www.tomitribe.com [6]
>>> 310-633-3852
>>> _______________________________________________
>>> 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 [7]
>>> _______________________________________________
>>> 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 [7]
>>> _______________________________________________
>>> 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 [7]
>>> _______________________________________________
>>> 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 [7]
>>> _______________________________________________
>>> 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 [7]
>>> _______________________________________________
>>> 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 [7]
>>> _______________________________________________
>>> 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
>> Links:
>> ------
>> [1] https://www.linkedin.com/in/kevinwsutter
>> [2]
>> https://www.eclipse.org/community/eclipse_newsletter/2019/february/Jakarta_EE_9.php
>> [3]
>> https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/proposal-01-bigbang.adoc
>> [4] https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
>> [5] http://twitter.com/dblevins
>> [6] http://www.tomitribe.com/
>> [7] 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
> _______________________________________________
> 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
