@Peter Lee Sorry if I miss anything. >We have already discussed this before. I remember in an old thread we discussed about this, but I have no idea whether we've already made a decision. I see Emmanuel Bourg trying to maintain a p200 fork, so will we use it? I just didn't get what the final decision we made...
> I'm only talking about the build failures here. Yep, we can just set them to allow_failure, and wait for the decisions. But Pack200 had been removed for a long time(since 14, and now we have jdk16 ea), and I think it is a good time to solve it, at least decide which way to go (if not yet). Peter Lee <peter...@apache.org> 于2020年8月21日周五 下午4:09写道： > Hi Xeno, > > This is another topic. We have already discussed this before. You can > check the old thread. > I'm only talking about the build failures here. > cheers, > Lee > > On 8 21 2020, at 4:04 , Xeno Amess <xenoam...@gmail.com> wrote: > > though each of the ways have some quite annoying things. > > 1. we remove Pac200 as well, as jdk do. > > will break BC. > > 2. we fork the Pac200 from jdk and create a new lib for it, and we invoke > > that lib instead of jdk's Pac200. > > if we change the package name, see 3. > > if we do not change the package name, it will cause dependency hell. > > I guess everybody here have experience handling some dependency hells > > for org.apache.xerces.parsers.* , I do not want commons-compress to > become > > like that. > > 3. we clean room a implementation of Pac200 (seems not quite worthy) > > It will be time costing. > > > > Xeno Amess <xenoam...@gmail.com> 于2020年8月21日周五 下午3:45写道： > > > Yes, Pac200 is already removed from jdk lib... > > > So what is the solution? > > > We have to face this someday eventually, so why not today? > > > > > > I can only get ideas of 2 ways... > > > > > > 1. we remove Pac200 as well, as jdk do. > > > 2. we fork the Pac200 from jdk and create a new lib for it, and we > invoke > > > that lib instead of jdk's Pac200. > > > 3. we clean room a implementation of Pac200 (seems not quite worthy) > > > > > > So which will we pick? > > > Or, any better ideas? > > > > > > Peter Lee <peter...@apache.org> 于2020年8月21日周五 下午3:24写道： > > > > > >> > > >> > Compress master now requires Java 8, so we can drop Java 7 from > Jenkins, > > >> > please do go ahead. > > >> > > > >> > > >> Done. > > >> > > >> > For Java 14 and up, failures are due to the removal of Pack200 > support > > >> from > > >> > the JDK. > > >> > > > >> > > >> Yes, we all know this. Before we managed to figure out the solution, > I'm > > >> just thinking if we should make the builds' status green on JDK14+ by > > >> setting some "allow failure" config in GH actions and jenkins. > > >> cheers, > > >> Lee > > >> > > >> On 8 20 2020, at 8:06 , Gary Gregory <garydgreg...@gmail.com> wrote: > > >> > On Thu, Aug 20, 2020 at 7:57 AM Peter Lee <peter...@apache.org> > wrote: > > >> > > > >> > > Hi all, > > >> > > > > >> > > The builds in jenkins and github actions are failing. > > >> > > For jenkins, the java7, 14 and 16 builds are failing. As we have > moved > > >> > > from JAVA 7 to 8, maybe we should disable java 7 build in jenkins? > > >> Besides > > >> > > the java 14 and 16 are also failing, and we can have some "allow > > >> failure" > > >> > > config on them. > > >> > > For github actions, the java 14 and 15 builds are failing. We can > > >> easily > > >> > > make java 14 build a part of experimental build to have it > > >> > > continue-on-error. > > >> > > What do you think? > > >> > > > > >> > > > >> > Compress master now requires Java 8, so we can drop Java 7 from > Jenkins, > > >> > please do go ahead. GitHub and Travis do not build on Java 7, their > > >> lowest > > >> > Java version is 8. > > >> > > > >> > For Java 14 and up, failures are due to the removal of Pack200 > support > > >> from > > >> > the JDK. I think we are still trying to figure out how to remedy > this > > >> > within Compress, maybe by bringing in Apache Harmony code. For a > > >> Compress > > >> > 2.0, we could talk about dropping Pack200 altogether along with any > BC > > >> > breaking changes we might want to do. > > >> > > > >> > Gary > > >> > cheers, > > >> > > Lee > > >> > > > > >> > > > >> > > >> > > > >
