On Sat, 4 Jan 2020 at 11:19, Stefan Bodewig <bode...@apache.org> wrote:
> 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 > > That only applies if Commons Compress still works without the optional component. > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
