On 6/26/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote:
Wow thanks for the very detailed reply. Although I haven't looked into you're suggested project http://xooctory.xoocode.org/ for looking up details, I added an extra option 'cp' into the org.apache.ivy.Main, which only get red out in the case the option 'main' is given. This option 'cp' is an 'extra classpath', which can be used to load the org.bar.foo.FooMain class, based on a jar or directory. This makes live easier for development (without needing to generate the jar for the Ivy repository (so no setup for a personal Ivy repository is needed either!)).
Indeed, this is nice for development! The method 'invoke(...)' get an extra argument with a list of File instance.
Representing the classpath parts. Which then are added to the URL list. This way the mainClass is loaded through the URLClassLoader, so it can make use of all the classes/package in that classloader :) Tjeerd PS: If appreciate to small code 'patch' could be send.
Sure. Could you please open a jira issue and attach the patch to it? Xavier On 6/26/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > On 6/26/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote: > > > > When I would like to make use of Ivy as a classloader for an application > > FooMain, which also depends on commons-lang, > > it is nessesary that the class org.bar.foo.FooMain, is loaded through > the > > Ivy process? Or simpler said, that the class needs to ne in a 'jar' > which > > is > > loaded through the Ivy process? > > > Yes. This is a classloader problem, if you put your FooMain class in your > java classpath, it won't have access to class loaded by Ivy classloader > (which is actually a mere URLClassloader). > > But since Ivy is very flexible about its repositories, you can simply > define > an additional repository in which Ivy will find your application jar. With > a > pattern like [artifact].[ext], your jar can be in the directory in which > you > launch Ivy and it's enough. > > Another solution is to use Ivy to package your apps and its dependencies, > then use Ivy as a launcher. > > I've used this technique in another open source project where you can have > a > look at the build scripts if you are interested (not very well documented, > but shouldn't be too difficult to understand): > Project home: http://xooctory.xoocode.org/ > Build script: > > http://www.xoocode.org/wsvn/xoocode/org.xoocode.xooctory/trunk/xooctory/build.xml?op=file&rev=0&sc=0 > > Have a look at the distrib target, which packages the app. You can also > have > a look at the packaged application (available from the download page). > > In this case I keep a public repository in my settings to make it easily > possible to change the libraries used by updating the main ivy file. But > this is not mandatory. > > HTH, > > Xavier > > java org.apache.ivy.Main -dependency apache commons-lang 2.1 -main > > org.bar.foo.FooMain > > > > or > > > > java org.apache.ivy.Main -main org.bar.foo.FooMain > > with a ivy.xml (which contains the reference to apache commons-lang 2.1) > > > > This class 'org.bar.foo.FooMain', must be on the classpath loaded > through > > Ivy! > > > > And not on the normal java classapth like: > > java -cp foo.jar org.apache.ivy.Main -dependency apache commons-lang > > 2.1 > > -main org.bar.foo.FooMain > > > > > > Regards, Tjeerd > > > > > > -- > Xavier Hanin - Independent Java Consultant > Manage your dependencies with Ivy! > http://incubator.apache.org/ivy/ >
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
