I think these are all good ideas. In particular I'm keen on having some kind of 'depends on a project.xml' feature, just as this level of indirection will enable us to avoid cutting and pasting dependency information all over the place. I'm particularly keen on using this for projects that have a core part and optional extra bits and pieces which are seperate, but related, maven projecst (like the Jelly core and optional tag libraries).
James ----- Original Message ----- From: "Stephen Haberman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 27, 2002 6:36 AM Subject: dependencies > I've been pondering how dependencies could work in Maven over the last > few days and just thought I'd post my thoughts to the list. > > The idea I just had was abstracting out versioning from jar names to > enable Maven to automatically get the latest builds for you. This may or > may not be a good idea, and I seem to remember someone had said > something about standardized naming before, so there may already be > plans like it. But generally if I just want the latest 2.x version of > Turbine, I could put in a dependency that would somehow reflect that and > Maven could automatically upgrade from 2.1 to 2.2 when it becomes > stable. > > E.g, inside the dependency element from project.xml: > > <version>2</version> - could be any 2.x version > <release>released</release> - only released versions - turbine-2.1.jar > <release>stable</release> - b2/b3/etc. versions are allowed - > turbine-2.2-b2.jar > <release>any</release> - dev versions are also allowed - > turbine-3.0-dev.jar > > And perhaps the <jar> element could be completely dropped; instead, let > Maven deduce the correct jar to download based on the desired > version/release info and what's available in the repository. > > The other small example of something I'd think would be cool is for a > dependencies.xml for each repository (be it local or remote...?). > > There were three cases I came up with that I thought would be useful: > referring to another project.xml on the web (either the same repository > or a different one), referring to another project.xml in CVS, and the > last just simple file linking (both same repository and different? And > then should this allow the same non-strict filename feature outlined > above? I don't know if that's safe or not.). > > The only thing is that referring to other repositories and CVS servers > could get slow, so perhaps the dependency tree that gets built should be > cached. Again, I'm not quite sure if this is a good idea or not, I'm > just throwing things out. > > Sample dependencies.xml (completely contrived): > > <jars> > <jar name="torque-3.0-b2.jar"> > <http-project name="torque-project-3.0-b2.xml" > url="http://jakarta.apache.org/turbine/jars"/> > </jar> > <jar name="turbine-3.0-alpha.jar"> > <cvs-project name="project.xml" cvsRoot="..." passfile="?" > module="jakarta-turbine-3" tag="3.0-alpha?" /> > </jar> > <jar name="commons-io.jar"> > <file>commons-xo.jar</file> > <file > remote-lib="http://share.whichever.com";>village-1.5.3.jar</file> > </jar> > </jars> > > The ideas are rather rough, but I thought they might be of use. > > Thanks, > Stephen > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
