Re: [jakartaee-platform-dev] Oracle's position on Jakarta EE 9

["Markus KARG" <markus@xxxxxxxxxxxxxxx>]

Tobias,

nice to read you. :-)

I agree with your arguments, but yes, there actually is a downside: The big bang actually is much, much more work than simply running a refactoring in the IDE. It implies a real lot of manual work. Clearly the less modules to migrate, the less work the vendors do have.

-Markus

-----Ursprüngliche Nachricht-----
Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Tobias Frech
Gesendet: Montag, 7. Oktober 2019 11:06
An: jakartaee-platform-dev@xxxxxxxxxxx
Betreff: Re: [jakartaee-platform-dev] Oracle's position on Jakarta EE 9

Hi!

Is there any big downside of splitting big-bang renaming and pruning into separate steps?

Doing renaming in Jakarta EE 9 and pruning in Jakarta EE 10 would have one big up-side: Jakarta EE 9 would be available for general availability to everyone sooner. As a project manager I then have the option to migrate to Jakarta EE  9 (or try it in a PoC) but I am not forced to do it right away. I might want to do a PoC with EE 9 and then leap frog to EE 10.

Of course all the candidates for pruning can be marked as "deprecated"
in EE 9 then. If a candidate is removed in EE 10 can then still can be decided on the feedback from projects still relying on these parts.


I haven't read through all the discussions and documents that have been established up to now. If any of this above contradicts something that has already been decided I just didn't know :-)


Best regards

Tobias


Am 03.10.19 um 10:53 schrieb Martijn Dashorst:
> On Thu, Oct 3, 2019 at 10:20 AM Mark Thomas <markt@xxxxxxxxxx> wrote:
>> Pruning - No view as it doesn't impact the specs Tomcat implements.
>> API Compatibility - I'd like to see the API elements that have been 
>> deprecated for many years finally removed. I wonder if it is worth 
>> having a more defined process for removal such as "deprecated in n 
>> releases and removed in the n+1th release"
> On both these I'd suggest doing that in the release *after* the package rename.
>
> As a consumer of the APIs in my multi-million lines of code projects I 
> don't want to conflate API changes due to the rename with API changes 
> because of grinding an axe.
>
> Removing old cruft, while it has it merits, means more discussions:
> TCK's need to be altered beyond the package rename, interoperability 
> between specs need to be discussed. It opens up the process for much 
> more delay.
>
> I'd urge the Jakarta community to do focused releases:
> - Java EE 8 -> Jakarta EE 8: transition 'as is' from Oracle to 
> Jakarta, including all the paperwork, documentation and TCKs.
> - Jakarta EE 8 -> Jakarta EE 9: rename all the things: make the world 
> live in the jakarta package
> - Jakarta EE 9.x/10.x -> evolve the specs to your liking
>
> I understand the allure of removing cruft from the APIs, but the thing 
> is that folks have workarounds in place that can/will fall over when 
> you remove the cruft. This will break if you conflate the package 
> rename with cleanup, and you won't know exactly if it is broken due to 
> the package rename or cleanup.
>
> Martijn Dashorst
> _______________________________________________
> 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

--
Frech IT GmbH / Am Brünnele 7 / 71642 Ludwigsburg phone : +49-(0)7141-9113037 / HR B 744851 / AG Stuttgart
--------------------------------------------------------
Geschäftsführer: Tobias Frech
mobile: +49-(0)172-7112352  / email: tobias@xxxxxxxxxx