On 2020-01-04, Emmanuel Bourg wrote: > Le 02/01/2020 à 11:06, Stefan Bodewig a écrit :
>> Any other ideas? > The removal of pack200 isn't an issue for the upcoming release yet since > we still target Java 7. For now this is just an issue with the CI using > Java 14+. Maybe we can deal with this by using a Maven profile excluding > the pack200 classes from the compilation when Java 14+ is used. This won't work as CompressorStreamFactory depends on the package. > This leaves some time to find an alternative implementation, I don't > think Commons Compress will require Java 14+ in the next 5 years. Me neither. > FYI I plan to fork the JDK pack200 implementation into a standalone > project. I've reserved the 'pack200' group on GitHub for this. The code > isn't published yet https://github.com/pack200/pack200 looks pretty public to me :-) > but I've already Mavenized the project and converted the tests to > JUnit. I'm struggling a bit to get the native code to build. I vaguely recall there've been some legal strings attached that were raised when Eclipse discussed ther alternatives for p2 but its been a while and I haven't re-read the threads, yet. > The fork will inherit the GPL2 with classpath exception license from > OpenJDK. I'm not sure Apache projects are allowed to depend on such > libraries, but that would be odd not to be able to use it since it's > exactly the same code that we used in the JDK. I'd say it is fair to call pack200 support an optional feature of Commons Compress https://apache.org/legal/resolved.html#optional Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
