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

Reply via email to