Skip to main content
[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

This is not true. The big bang allows to extend the existing packages once they are renamed. This means, once an application is migrated, now *new* packages are needed to be imported at a later time.

-Markus

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of Emily Jiang
Sent: Sonntag, 19. Mai 2019 16:39
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

 

Not really. My point is no different from Big Bang or incremental approach when it comes to consume new updates. All of the approaches require importing new packages. 

Emily 

 




On May 18, 2019 at 5:27 pm, <Markus KARG> wrote:

Your idea would cut off all existing apps from easily adopting minor enhancements of existing APIs and would enforce to migrate to completely new APIs, which is more work and higher risk than simply once change the imported package names. Typically existing apps are not maintained just to get free of bugs but also to adopt these small enhancements, and nobody wants to rewrite his app from Jakarta API to Microprofile API just to have one new parameter in a method.

-Markus

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of Emily Jiang
Sent: Samstag, 18. Mai 2019 18:05
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

 

We discussed Big Bang and incremental approach so far. Both of them have pros and cons. How about we do something in between:

Directly lock javax JSRs. For any new update related to a particular JSR, just start the new changes under Jakarta EE namespace without changing the existing APIs. For an example, MicroProfile Rest Client is an update to Rest client. MicroProfile context propagation is an update on Concurrence JSR. In MicroProfile, we create new APIs without changing any Java EE specs. We can use this approach for Jakarta EE spec updates. The only difference is to use jakata.ee namespace. In this way, we can directly create any APIs.

I think changing the current javax either Big Bang or incrementally will impact existing users. As you may know, some old libs may not have the source available any more. I think what I recommend does not impact any existing apps.

My 2cents

Thanks 

Emily 





On May 18, 2019 at 3:10 pm, <Peter P. Lupo> wrote:

All the points made in favor of the big bang so far are pretty relevant and good points. I also agree with the big bang. I like the idea of providing an alternative to the existing API so we can provide a tool to migrate the existing applications but I would only go this far in terms of keeping existing functionality.

Truth being told, Java EE needs pruning. The more features we add, greater is the effort to keep backward compatibility, making enhancements costly.

We could provide a Jakarta.legacy package for equivalence and start fresh under Jakarta.*, keeping what is useful, adding new stuff and removing stuff like ejb older than 3.1, etc...

 

On Sat, May 18, 2019, 09:49 Josh Juneau <juneau001@xxxxxxxxx> wrote:

An area that I don't think has been mentioned yet is documentation.  Sorry if it has and I've missed it.  If we take a step back and look through the eyes of the everyday user, I believe it would be very cumbersome and confusing to have books, tutorials, and articles that contained different namespaces due to an incremental approach.  The users would really have to be on top of the versions they are using while reading and trying to learn.  

 

The big bang approach, in my opinion, would make learning a bit easier from a users perspective.  If they were to pick up a book written on Jakarta EE 9, then all package renames would be documented...and the book would still be relevant down the road when Jakarta EE 10 or 11 are released.  It would be almost as if Jakarta EE 9+ is a completely new platform...a fresh start, as others have said.

 

If we were to choose an incremental approach, it seems that books and tutorials would almost be obsolete each time a new release comes out.  

 

Thanks for reading.

 

On Fri, May 17, 2019 at 10:58 AM Rieon Ke <rieon@xxxxxxxx> wrote:


Hello,

I have opened a PR to add transitive dependencies list,

Am I heading in the right direction?  is this what we want?

 

Rieon

_______________________________________________
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

_______________________________________________ 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

Back to the top