On Fri, 2003-03-14 at 18:17, Dominique Devienne wrote: > Could you please provide a link where to start looking to try to understand > how you are doing it? Like maybe a ViewCVS link? Thanks, --DD
Right now we use three approaches we have a WerkzResolver for short-lived graphs which we use for the CLI and a resolver based on the graph package in the commons-sandbox which will be used for long-lived graphs: http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/java/org/apache/maven/jelly/tags/maven/ What's in the Plexus plugin is just brute-force walking through POMs. I will eventually incorporate the use of the commons-graph package. > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 5:08 PM > To: Jakarta General List > Subject: RE: so many jars > > On Fri, 2003-03-14 at 18:07, Dominique Devienne wrote: > > Why can't the POM be stored in the artifact itself? > > That certainly can be done and has been suggested, but the POM can be > uesd for so many other things. It's certainly one of the routes we could > go. > > > Assuming most Maven > > projects generate JAR artifacts, couldn't you store the POM in the JAR, > like > > in META-INF/maven/project.xml, and then use that info at runtime? Seems > like > > all you would need is some bootstrap class (a modified forehead?) that > knows > > where to find JAR artifacts (the runtime equivalent to the current > > maven.repository); When requested to start a main class from a given JAR, > it > > would read the POM from the JAR, and start looking up the necessary > runtime > > JARs dependencies (declared in the POM) in the repository(ies). If these > JAR > > dependencies in turn also contain their own POM, you can fully resolve the > > dependencies (transitive closure). > > > > Or am I completely in left field? --DD > > Nope, that's what I'm doing to create avalon runtimes. > > > -----Original Message----- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 14, 2003 4:53 PM > > To: Jakarta General List > > Subject: RE: so many jars > > > > 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]
