Equinox JarProcessor [1] seems to use pack200 CLI. 1. https://git.eclipse.org/c/equinox/rt.equinox.p2.git/plain/bundles/org.eclipse.equinox.p2.jarprocessor/src/org/eclipse/internal/provisional/equinox/p2/jarprocessor/JarProcessor.java
Gintas On Thu, 11 Oct 2018 at 17:00, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote: > To be complete on this subject, the pack200 algorithm has been implemented > to be able to resolve artifacts in an Eclipse updatesite. I don’t know how > nowadays artifacts are packaged on a « p2 repository », but some > documentation still exists and doesn’t contain any warnings: > > https://wiki.eclipse.org/Equinox_p2_Repository_Optimization#Pack200_Optimization > > Nicolas > > > > > Le 10 oct. 2018 à 14:04, Jaikiran Pai <jaiki...@apache.org> a écrit : > > > > Hi Jan, > > > > For end users (of Ivy), the place where pack200 packaging becomes > > visible is when they reference it in their dependencies as noted in our > > doc[1]. So IMO, I think we should probably add a note/warning within our > > documentation than a runtime log/warn message. But I still think, it's a > > bit too early to do that. Maybe we should wait a few more releases of > > Java and see if any alternatives show up? > > > > [1] > > > https://ant.apache.org/ivy/history/latest-milestone/concept.html#packaging > > > > -Jaikiran > > On 10/10/18 11:09 AM, Jan Matèrne (jhm) wrote: > >> If I understand Dragans point right, the warning comes when analyzing > the code. > >> Not just running Ivy. > >> So the normal user won't see the warning. Maybe we should implement a > warning? > >> > >> Jan > >> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Jaikiran Pai [mailto:jaiki...@apache.org] > >>> Gesendet: Mittwoch, 10. Oktober 2018 07:08 > >>> An: dev@ant.apache.org > >>> Betreff: Re: Java 11 Compatibility Problem > >>> > >>> I agree with Stefan, at the moment I recommend ignoring those warnings. > >>> There isn't anything else we can do (other than removing support for > >>> pack200, which isn't a good option). > >>> > >>> -Jaikiran > >>> > >>> > >>> On 10/10/18 9:56 AM, Stefan Bodewig wrote: > >>>> Hi Krzysztof > >>>> > >>>> I'm not actively working on Ivy so take my response with a grain of > >>>> salt. > >>>> > >>>> On 2018-10-09, Dragan, Krzysztof wrote: > >>>> > >>>>> Hi, > >>>>> scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on > >>>>> jdk11 I noticed two problems with this jar. > >>>>> These two methods using internal jdk marked for removal and will be > >>> deleted: > >>>>> * class org/apache/ivy/util/FileUtil uses deprecated class > >>>>> java/util/jar/Pack200$Unpacker (forRemoval=true) > >>>>> * class org/apache/ivy/util/FileUtil uses deprecated class > >>>>> java/util/jar/Pack200 (forRemoval=true) > >>>> For background see https://openjdk.java.net/jeps/336 > >>>> > >>>> The Java community has decided to eventually remove support for the > >>>> pack200 format, but it still is there in Java11. Right now this is > >>>> only a warning, it will only become a real problem once the classes > >>>> actually get removed. They do not offer any alternative > >>> implementation > >>>> right now, and may never do (unlike the JAXB case, which is available > >>>> as an external library now). > >>>> > >>>> I am aware of an alternative based on the former Apache Harmony code > >>>> in https://github.com/pfirmstone/pack200 but am unsure about its > >>> state > >>>> - both technically and legally - I very vaguely recall the Pack200 > >>>> spec was encumbered with Oracle patents but may be totally wrong. > >>>> > >>>> In Ivy's case the only save option right now was to remove support > >>> for > >>>> pack200 archives and break existing setups that consume such archives > >>>> which seems to be excessive just in order to get rid of a warning. > >>>> > >>>> If yu ask me I'd recommend to live with the warning for now and wait > >>>> for an alternative to the class library's pack200 classes to become > >>>> available - which hopefully happens before the Java version removing > >>>> support gets released. > >>>> > >>>> Stefan > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > >>>> commands, e-mail: dev-h...@ant.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > >>> commands, e-mail: dev-h...@ant.apache.org > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >> For additional commands, e-mail: dev-h...@ant.apache.org > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
