Hi,
I've implemented enhancement request 14255 so that <jar index="true"/>
can now create an index for referenced jars in addition to the current
jar.
Before I add docs and close the report, I wanted to explain the
implementation and get some feedback.
The main addition is a nested <indexjars> element that is a <path>.
This element lists all the jars that are supposed to be indexed in
addition to this jar. If it is not present, only the current jar's
content gets into the index.
If the current jar doesn't have a Class-Path manifest entry, the task
assumes that all jars in <indexjars> get into the index and it assumes
that the jars will live side by side with the current jar so that the
relative URL is just the filename of the other jar.
If it has a Class-Path, the task applies some heuristics to guess
which of the Class-Path entries is the one that any given jar from
<indexjars> belongs to. The value of the Class-Path entry will become
the relative URL for the index. If the task can't guess the match,
the jar from the <indexjars> path will simply be skipped.
This means that
<jar ... index="true">
<indexjars>
<fileset dir="${ant.home}/lib"/>
</indexjars>
</jar>
will get INDEX.LIST sections for all jars in ANT_HOME/lib while
<jar ... index="true">
<indexjars>
<fileset dir="${ant.home}/lib"/>
</indexjars>
<manifest>
<attribute name="Class-Path" value="ant.jar"/>
</manifest>
</jar>
only contains a section for ant.jar.
Why <indexjars>?
Because I think it is pretty unlikely that the jars already have the
locations relative to each other they will have in the end when we
create the jar. I assume that there will be a final "copy jars into a
distribution location" in most situations. So we need the user's help
to find the jars.
This is the same reason why I didn't implement auto-discovery from the
Class-Path at all.
The heuristics to find the Class-Path entry that "belongs" to a jar
from <indexjars> is simply that the longest match wins. The absolute
path of the archive is matched against all Class-Path entries (matched
isn't the right term, it's an endsWith() comparison) - all entries are
matched at the full length and then by chopping directory names from
the start.
So /a/b/c/d.jar with "Class-Path: e.jar f/d.jar" will not match e.jar
at all. It doesn't match f/d.jar directly, but after chopping f/. So
the match is "d.jar" and the result in the index file will be f/d.jar.
If Class-Path read "f/d.jar c/d.jar", both would match but c/d.jar is
the longer match and wins.
This again is because I assume that the jars are not in the correct
relative position to each other while the archive is created - but
that directory names are more likely to be a bit correct than
completely wrong.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
