I did a simple version using plain <jar> and <zipfileset>. Jan
> -----Ursprüngliche Nachricht----- > Von: Stefan Bodewig [mailto:bode...@apache.org] > Gesendet: Sonntag, 18. September 2016 12:21 > An: dev@ant.apache.org > Betreff: Re: Multi-Release JARs > > On 2016-09-17, Jan Matèrne (jhm) wrote: > > >> * Multi-Release JARs need a special manifest attribute, we should > add an > >> attribute to the jar task that sets this. > > > I dont think so. We could set this flag by ourself if the > > <new-kind-of-zipfileset> is set. > > Agreed. People who want to manually put together the jar would have to > set the attribute themselves, then. > > > We discussed also the possibility of merging different jars. > > Say you have a Java8 jar, a Java9 jar and a Java10 jar, you could > > merge these into a multirelease jar. > > > Because of the different classfile versions, the common files of > these > > jars arent identical, so we cant find them easily. So the easy, but > > not smart, solution ends in having the common files in every version > branch of the jar. > > <jar ....> > <zipfileset src="java8.jar"/> > <new-kind-of-zipfileset src="java9.jar" version="9"/> > ... > </jar> > > could work that way. Likely would need to perform some fiddling WRT > manifest attributes. > > > Another idea I had (for few minutes) is combining the jar'ing with > the > > compiling. > > <mrjar ...> > > <default targetdir=""><src-resource-collection></default> > > <version version="9" targetdir=""><src-resource-collection> > point > > to > > Java9 only </version> > > <version version="10" targetdir=""><src-resource-collection> > > point to Java10 only </version> <mrjar> would do three compile runs > > now > > * default: Java8 > > * version=9: Java9, with classes from previous runs on classpath > > (havent thought about the identical names yet ... ;) > > * version=10: Java10, ... > > Finally create the MRJar. > > I guess configuration of the task will be quite longish but I can see > how this would streamline hte process. > > 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
