> 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

> 2) set artifact/group to latest release of an artifact/group

1.0-SNAPSHOT

> 3) set artifact/group to specific version released to QA

1.0-QA-1 ?

> 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.

> 5) set artifact/group to latest bleeding edge version

1.0-SNAPSHOT. This is no different to the above use case.

As I said before, this is a release management issue, rather than repository/pom
issue.

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.

But also, why can't that developer edit their checkout of project.xml and only
commit the final version?

> 2) The repository remains standardized. In other words, a developer
> working on project A who decides he needs bleeding edge artifacts
> from the m2 effort of project B doesn't need to talk to a developer
> in group B to determine groupIds or repository names, etc. The
> developer can simply indicate they want bleeding edge of m2.

I think the above covers this.

Sticking to versions will keep it a lot simpler. Here is what I think the cycle
should be:
1.0-SNAPSHOT
1.0-SNAPSHOT     -> release 1.0-QA-1 (and as 1.0-QA-SNAPSHOT)
1.0-SNAPSHOT     -> release 1.0-QA-2 (and as 1.0-QA-SNAPSHOT)
1.0-SNAPSHOT     -> release 1.0
1.1-SNAPSHOT...

Cheers,
Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to