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/
