[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse.org-architecture-council] JEP 336: deprecate pack200
|
Hey!
+1 for dropping pack200 support (plan 2).
Cheers,
-Martin
> Am 26.06.2018 um 09:31 schrieb Mickael Istria <mistria@xxxxxxxxxx>:
>
> Hi all,
>
> On the p2-dev mailing-list, a user/contributor has mentioned this JEP: http://openjdk.java.net/jeps/336 . It's about removing pack200 from JRE.
> The user message and a following discussion are available at https://dev.eclipse.org/mhonarc/lists/p2-dev/msg05770.html
>
> pack200 is heavily used by p2 to reduce download size/time.
> The big question is, if it's not standard any more, what are the possible choices and their pros/cons:
> * Plan1: p2 contributors switch p2 to an alternative implentation of pack200
> ** Pros
> *** No functional change
> *** Still smaller download size/time
> ** Cons
> *** Need to find a good pack200 un/compression engine (seems like a hard task), or to help one if getting good enough to be a substitute (slightly harder), or to author a good one (extremely harder); and help maintaining them on the long run (hard)
> *** Adapt p2 to use a newer compression engine
> *** overall, the 2 ones fail in the category "it's a lot of work".
> * Plan2: drop pack200 from p2 on future Java
> ** Pros
> *** relatively simple, p2 most likely has the switches to ignore pack200 already, so we can just configure those according to whether JRE ships pack200
> *** sustainable and easier maintenance on the long run
> ** Cons
> *** Bigger downloads when updating, more load on download.eclipse.org
>
> Plan 2 has the big advantage of requiring less effort. The big question is would download.eclipse.org scale enough to serve non-packed artifacts?
> And maybe other questions to discuss?
>
> Note that for the architecture council, I think the right grain of discussion is mostly to evaluate whether dropping pack200 support would be a major issue or not.
> For technical implementation details (p2 dynamically chosing pack200 or not according to JRE, considering other compression formats...), then the p2 bugtracker and mailing-lists are more appropriate.
>
> Cheers,
>
> --
> Mickael Istria
> Eclipse IDE developer, for Red Hat Developers
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.