>> I think it would be better not relying on external dependencies for >> launching. >> Then you direcly start the jar. >> >> You could do that in a two step process: >> - Launcher >> -- Options: debug, verbose, warn, error, ? >> -- maybe also: realm, host, username, passwd >> -- pass the rest options to 2nd step >> 1. Instantiates "raw" Ivy >> 2. Uses that Ivy to load its own dependencies >> 3. Start Main >> - Main >> Do the normal stuff > > >The idea is interesting, but where should get Ivy dependencies? From maven >repository? In this case the launcher "requires" an internet access, which >is not always the case. Or we should use the settings provided by the user, >thus requiring him to add Ivy dependencies to his repository. >But what if the repository requires an Ivy dependency (commons-vfs, ...)? > >Therefore I think we should stick with providing Ivy dependencies on the >classpath, but if we get rid of commons-cli (the only mandatory dependency >for command line usage), users could use it without any complex classpath >setting, at least for simple cases. And for complex cases, they could still >use the Ivy launcher to resolve Ivy dependencies and run another instance to >run the actual class :-)
Yes, no dependency is better than a (maybe) easy resolvable... I thought about this because there are round about 30 options. Jan
