> > I think the issue has to do with dependencies of projects > > that are branched. I can see the case where you would like > > to have the head of a particular branch (say torque 3.0 tree > > -vs- the head of development). > > > > I see how this can be useful, but I think the complexity it > > adds (and confusion it can cause) overshadows the added value. > > What confusion would it cause? I fail to see how it would be confusing at > all.
I can't think of a clean way to get branch specific SNAPSHOTs without adding more complexity. Convince me otherwise... I can show how this scenario can be aligned to my current (in progress) proposal: This can be addressed with the addition of a repository.xml meta file: <dependency> <id>tomcat</id> <version>SNAPSHOT</version> <groupID>org.apache.jakarta</groupID> <artifactID>tomcat-4.1</artifactID> <dependency> Now in Tomcats project repository space (PRS) you would have <PRS>/repository.xml <project-repository> <artifact name="tomcat-4.1" version="*" location="jars/tomcat-4.1/"/> </project-repository> Where <PRS> would equal -> <repository dir>/org/apache/jakarta/tomcat/ - Mike > > -1 > > > > SNAPSHOT == bleeding edge == CVS HEAD > > > > Another note: (please correct me if I'm wrong) but can't > > this be addressed on a project-by-project basis with > > <artifcatID> elements > > > > It can be addressed in that way but it doesn't make sense. In the case of > Tomcat's major versions (3, 4, 5), it makes the most sense (which is still > none). Think about the implications for upgrading a dependency to a > project that changes the artifactId to allow for multiple snapshot > versions: > > <dependency> > <id>tomcat-3</id> > <version>3.3</version> > <dependency> > > Upgrading to 3.4 makes sense.... > > <dependency> > <id>tomcat-3</id> > <version>3.4</version> > <dependency> > > Upgrading to 4.1 does not makes sense.... > > <dependency> > <id>tomcat-4</id> > <version>4.1</version> > <dependency> > > From a user's point of view, it makes no sense to include version in the > artifactId. It should be Tomcat, not Tomcat-X. > > For a project like Torque, it makes even less sense to do something like > that. > > > - Mike > > > > > -----Original Message----- > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, March 04, 2003 2:38 PM > > > To: Turbine Maven Developers List > > > Subject: RE: Update > > > > > > On Tue, 2003-03-04 at 14:26, Quinton McCombs wrote: > > > > I think this has been discussed before but why can't we have > > commons- > > > collections-2.1-SNAPSHOT? There are some projects which will have > > > multiple development versions. Torque, for example, has 3.0.1 and > > 3.1. > > > > > > Because snapshot means approximately HEAD (or whatever the > > equivalent > > is > > > in other SCMs). I figured the the current version as part of the > > > snapshot denotation was misleading. Even if you have development > > > versions those are in fact releases and should not use snapshots. Or > > if > > > they are going on at the same time and haven't been > > released then you > > > should just use a timestamp. > > > > > > If I'm not understanding you correctly feel free to make additional > > > comments. > > > > > > > > -----Original Message----- > > > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > > > > Sent: Tuesday, March 04, 2003 1:18 PM > > > > > To: Turbine Maven Developers List > > > > > Subject: Re: Update > > > > > > > > > > > > > > > On Tue, 2003-03-04 at 11:36, Stéphane Mor wrote: > > > > > > > > > > > > > > > > > > > look e.g. at the commons-collections directory. There is > > > > > > > > > > > > > > commons-collections-2.0.20020914.015953 > > > > > > > commons-collections-2.0.20020914.020746 > > > > > > > commons-collections-2.0.20020914.020858 > > > > > > > commons-collections-2.1-dev.jar > > > > > > > > > > > > > > which one should commons-collections-SNAPSHOT > > map to? IMHO > > > > > > > it maps to the wrong version. 2.1-dev is newer than > > > > > > > 2.0.<something> > > > > > > > > > > > > > > > > > > > Patches welcome. > > > > > > > > > > I missed this one. Patches aren't needed. When a snapshot is > > > > > deployed a mapping created which creates a pointer: > > > > > > > > > > > http://www.ibiblio.org/maven/commons-jelly/jars/commons-jelly- > snapshot- > > version > > > > > > So the version stated in that file is what the snapshot corresponds > to > > if you wish to resolve it. > > > > > > I made a tool for the last maven release that uses these mappings to > > interactively resolve all snapshots in a project.xml file. You can > > actually do this interactively or just let maven go to town and do it > for > > you. > > > > > > We are actually trying to build things too, we realize snapshots can > be > > hazardous to your health but we know that. We have tried to make > snapshots > > convenient to use during development and easy to resolve for release. > > -- > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
