On Fri, 2003-03-14 at 15:24, J Aaron Farr wrote: > On Fri, 2003-03-14 at 11:14, Henri Yandell wrote: > > at compile-time maybe :) > > > > But you still end up with jar duplication, you just get to avoid having to > > think about it too much when compiling. > > > > I agree that maven has an excellent jar dependency solution for > compile-time, but I don't think there exists any (standard) solution for > run-time dependencies in java.
This is technically not a hard problem. For maven it's more an admistrative problem. Eventually only the compile time needs will be required in the Maven POM but in order to find the runtime dependencies you need all the POMs of the compile time dependencies of the target project. And there exist most of the POMs to do this it's just creating a mechanism where the POMs are stored safely, sync'd properly and a mechanism for retrieving them. There are glimpses of this already in some of the maven plugins where a single POM is used as the target and then all dependencies are traced and gathered. I'm doing this to produce avalon runtimes with great success and the method will eventually make it's way into Maven proper after more field testing. > Using a system level $CLASSPATH variable > becomes painful (as was mentioned). The general solution seems to be a > hierarchal set of /lib directories. > > To have a true run-time jar dependency solution you would need a > standard installation and launch mechanism. I suppose something based > on JNLP (WebStart) plus some sort of "ports" or "emerge" system could do > this, but I don't think it exists yet. Interesting idea though. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
