On Tuesday 23 November 2004 14:19, Brett Porter wrote: > > Jason, you are absolutely correct - the requirement is *not* > > separate repositories. I think the fundamental requirement is > > the ability to classify artifacts and to select artifacts based > > on classification. > > I agree with Jason that this is getting too complicated, and what > I Was pushing towards was the same thing. > > You should be signifying these different things by version. > > > Here are my dependency use cases: > > 1) set artifact/group to released version of an artifact/group > > ok, 1.0 Agree
> > > 2) set artifact/group to latest release of an artifact/group > > 1.0-SNAPSHOT Not quite. I deal with 20 odd products on an essentially monthly release cycle. 20 products with an average of 2 concurrent devstreams and 4 components per product => 160 POMs that I have to review and update monthly. It would be nice to be able to specify use the latest production release. With luck transitive dependencies will reduce the number of POMs that need to be reviewed to around 40 which is still a large number. (By the way, I've been arguing against the above complexity for years) I do consider this a nice to have and not a requirement. > > 3) set artifact/group to specific version released to QA > > 1.0-QA-1 ? Agree > > 4) set artifact/group to latest version released to QA > > 1.0-QA-SNAPSHOT, though Maven support isn't there for this yet - > you'd need to look it up, or have the JAR republished. See my > thoughts on the release cycle later. Agree. What is needed for maven to handle this? > > 5) set artifact/group to latest bleeding edge version > > 1.0-SNAPSHOT. This is no different to the above use case. Agree. The use case is different in that here someone in the developer role "asks maven to deploy a bleeding edge version" and in the above case someone in the CM role "asks maven to deploy a QA version" > As I said before, this is a release management issue, rather than > repository/pom issue. Except how do I prevent a developer from deploying a bleeding edge artifact as a QA artifact to the repository by accident? > going on to the next email in the thread: > > 1) One should not need to modify the POM in order to execute > > any of these use cases. In a team of 10 developers 9 will be > > executing use case #4 while only one may be executing use case > > 1. In other words I need to be able to specify the artifact > > using a property. > > maven.jar.override=on > maven.jar.foo=1.0-QA > > is this ok? They can even do that globally. Agree. > But also, why can't that developer edit their checkout of > project.xml and only commit the final version? Two reasons. With 75 different developers of various skills and technical proficiency I can't assume that all will grok a POM or how to modify it. This is especially true of web page developers who are not used to build systems in general and those who need to modify a POM on an irregular basis. Second, I need to disallow developers from checking in a POM at all. Why? With 20 odd products with interlocking dependencies and a monthly release cycle it is imperative that changes to dependencies not only de tracked, but made only after due deliberation and analysis. My experience indicates that unless the authority to modify dependencies is strictly controlled, then they will drift. Bottom line - a single repository using version identifiers will work so long as: 1) maven can distinguish between a release version, a QA version and a bleeding edge version based on the version tag 2) there is some mechanism to control deployment (so that a developer cannot deploy an artifact tagged as QA to the repository) -steve -- Stephen Nesbitt Senior Configuration Management Engineer The Cobalt Group 206.219.8271 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
