Thanks that was very instructive. I understand that SNAPSHOT is the one on the bleeding edge, but is there a way to declare the "latest on that development branch", or in other words the "1.2.x" where "x" denotes the latest revision of the 1.2 series.
We are following the convention of major.minor.revision numbering and it would be great if I don't have to change all the project files if we release a new revision of a library (which shouldn't change the semantics of the interface).
Can I do this already?
Yes and no. You can declare a dependency on version "1.2-SNAPSHOT", but you can't build something that looks like that!
Ok, you can sortof, via ugly hacks.
Ugly hack #1: put part of the version number in the artifact name. ie artifactid = foo-1.2, install-snapshot will now produce 'foo-1.2-20030708.094617.jar' (or something like that). Not quite what you wanted.
Ugly hack #2: locally we use a repository webapp as our 'remote repo'. This lets us resolve requests for 'foo-SNAPSHOT.jar', or 'foo-1.2-SNAPSHOT.jar' as if it matched files to the regexp /foo-1\.2.*\.jar/ and returned the most recent file. I've posted the webapp to the list before. It doesn't play well with the 'release' plugin though, which makes going through releases a pain.
Ugly hack #3: get your jelly on. Write a goal in your maven.xml to create the missing jars in your repo. It should do something like: build the normal jar first, then for each period in your version, create a SNAPSHOT jar in your local repo with that prefix. e.g. build foo-1.2.3.jar, then install foo-1-SNAPSHOT.jar, foo-1.2-SNAPSHOT.jar, foo-1.2.3-SNAPSHOT.jar. (with these names, not the timestamps). This just fakes up what the repo webapp does, but you can make it work without a repo server. Again, the release plugin won't play well with this.
This kind of stuff has been discussed to death on the mailing lists, there are no great answers, because by design the remote repo is usually 'dumb' - which allows you to use any server, ftp, file, http, scp... to serve the files up. The various differences and weaknesses in the protocols conspire to make it hard to maintain decent versioning information.
-Baz
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
