+1 to ignore duplicate class name with the same md5, but bails out when md5
are the same.
It is crucial to display the jar name as well
On 3/8/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Hey there again :)
> I've included both the new files and the diff-u for
> UeberJarMojo.java and JarUtils.java
The diffs against trunk are more than enough :)
Thanks for that!
> Fixes in this version are:
> - Duplicate entries are ignored (project artifact entries take
> precedence)
Actually I am not really sure how to handle this best. Your fix is a
work around - this needs to be handled ...but essential it means you
have more than version of a certain class in your classpath. Which is
quite bad. I thought about being a bit smarter and verify the md5.
Then we could filter out classes that are really equal and still barf
(=showing a big warning) if there are two versions.
> - Manifest files are combined into the newly created jar (this way
> the sections and Main-Class are preserved)
>
> Should the last feature be optional? If so, please tell me and I'll
> adjust the code. While it works, I don't feel quiet comfortable
> with the manifest solution, since it can result into non-matching
> main entries. I've added the example at the bottom.
The manifest is another story that is related to resource re-mapping.
Once I've finished my work on the underlying library jars that are
getting in-lined will retain their resource paths!
A.jar
org/some/Class.class
some.properties
URL url = getResource("some.properties");
B.jar
org/other/Thing.class
some.properties
URL url = getResource("some.properties");
After the inlining this will transparently become:
ueber.jar
a/org/some/Class.class
a/some.properties
URL url = getResource("some.properties"); -> a/some.properties
b/org/other/Thing.class
b/some.properties
URL url = getResource("some.properties"); -> b/some.properties
So in theory this should also work for code inside that jar accessing
its manifest - but... I am not 100% sure and of course this will not
work for code outside the jar. So the ueberjar should in fact get a
new manifest telling what is inside. So that is where we could use
your code.
As for the main class - the other stuff are dependencies. I think it
would be fair to assume that the main class actually comes from the
project artifact. Actually we could even try to find a "public static
void main(String[])" method ...and if there is only one take that :)
Does that make sense?
cheers
--
Torsten
PS: I've taken this to list as there a few people currently
interested in this.
Would be great if you could subscribe dev-
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
