> - 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.
True this looks bad. Case is I'm using an ueberjar inside an ueberjar,
ueberjar inside ueberjar ...interesting :)
which would not much be the case. It is however possible the pom
contains duplicate entries and/or dependencies are added explicitly
via
the pom and implicitly via dependencies. Since compilation does not
fail in this case, ueberpackaging shouldn't too.
I see your point
Checking MD5 is indeed a satisfying solution, but do just fail -
let the
user exclude one -. Resources although may need to be handled
differently,
as you say further on.
OK ...so either exclude, failfast or pick the first one (with
warning). We can make that configurable. All checking with MD5s. How
does that sound?
> - 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!
ueber.jar
a/org/some/Class.class
a/some.properties
URL url = getResource("some.properties"); -> a/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.
I saw your comments in the code. Since most of the time there are no
conflicting resources, this shouldn't be needed often. Don't know what
side effects this causes. I'm thinking you should first release 1.0
and
later add this feature (optionally).
Naa... this is really required. This is not purely for the sake of
conflicting resources. Imagine inside a jar there is code to load
some properties that are inside that jar. Packaged with ueberjar this
would fail.
Side effects are close to none. We are just calling out to a static
method to resolve to the new name.
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 :)
Since most of the time an ueberjar is created, the user wants it to be
an executable jar, this is plausible. But then again, what if he
doesn't?
Well, of course the magic should be configurable ;)
So I think it should either come from one of the manifest files or
as a
property to the plugin (an empty property resolving the main
method??).
What we could do is:
if main class is configured {
use that for the new manifest
return
}
options = list the found main classes and main classes from manifests
if options.size() == 1 {
if option "use best bet" is set {
use that for the new manifest
return
}
}
don't specify a main class in new manifest
list the options on warn level
How does that sound?
Does that make sense?
For a solid solution, yes.
I'll subscribe to the mailinglist and do some reading this weekend.
Cool
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
