Yes, I see what you mean. And indead although it's maybe not 100% 'THE'
solution for the problem, it makes it better then it is at the moment.
For the case when the jar is downloaded without the commons-cli jar, a check
like this one:
try
{
// Check if the Command Line Interface (commons-cli) is on the
classpath.
ClassLoader.getSystemClassLoader().loadClass("
org.apache.commons.cli.Option");
}
catch (ClassNotFoundException e)
{
System.err.print("Expected to have access to the package 'Apache
Jakarta Commons - Command Line Interface'.");
}
could the user also provide with a hint, or some detailed text explaining
what exactly to do would to correct the problem.
If you still believe it should also work without the commons-cli, I would go
for the sollution that goes the internal / alternative way, only if the
commons-cli package can't be found (in that case just drop the previous
System.err as a warning).
Tjeerd
On 7/9/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 7/8/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote:
>
> Created a possible solution for this 'real' problem.
>
> The real problem is not that there is a dependency, but when using stand
> alone ivy, multiple jars need to be included in the classpath (ivy-core
> and
> commons-cli).
>
> This can indeed be solved by (re)implementing commons-cli in ivy, but
this
> would duplicate code with all it's negative side effects.
>
> What I did was added the Manifest attribute 'Class-Path', which it the
way
> to add references to other jars, on which ivy depens (ok, only
> commons-cli)
> at the moment.
>
> Having this problem solved, reminded me also to check if the Manifest
> attribute 'Main-Class' was used and it wasn't :( This attribute makes it
> possible to just start a jar! No additional path to the class with the
> main
> method is needed.
>
> So before you could start ivy with:
> java -cp ivy-core.jar:../../commons-cli.jar org.apache.ivy.Main
>
> Now becomes:
> java -jar ivy-core.jar
>
> IMO also a better solution, as I think it's better to make use of
existing
> and proven code, then to re implement it yourself again. Plus this lets
> the
> option open to make use of more / other external libs. Where a solution
of
> reimplementing cli, would also close to door of making use of other
libs.
>
Comment cross posted on the issue:
"I agree than duplicating code instead of reusing is a very bad practice,
that's why we have created Ivy: to make code reuse easier. The problem
with
Ivy is that since it's a dependency manager itself, it's difficult to
manage
its dependencies. That's why we always ensure the core is usable without
any
dependency, even though we're not fan of pure SAX parsing for xml for
instance, we keep our code dependent on core jdk. For commons-cli we are
not
talking about the core, but the standalone usage, that's why we accepted a
third party dependency. But it makes usage more difficult: even with your
patch, the dependencies need to be in one directory relative to the main
jar. People do not always use an ivy zip distribution, but sometimes only
the ivy jar alone downloaded from an http server. So the solution of
providing classpath and main class MANIFEST entries is better than
nothing,
but not as good as removing the dependency. BTW, we do not provide the
main
class entry only because it can't work without the dependency.
So I'd recommend opening another issue for attaching your patch, because I
don't think closing this one with your patch is a good idea. Does it make
sense?"
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
