On 7/9/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote:
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.
This is a good idea.
If you still believe it should also work without the commons-cli,
I do, but it's only one issue among a lot of other one, so I don't know if
it'll ever be implemented.
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).
Mmm, if we can work without commons cli, I don't think I'll preserve the
commons cli parsing. It would be twice as much code to maintain when you
change CLI options.
Cheers,
Xavier
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/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
