The BRICCS Maven repository is currently (December 2010) a Maven2 repository.
The repository is important because it gives access to already built BRICCS artifacts. That is, a development environment is not required in order to build an artifact before deploying it in a live or test environment (eg: within Tomcat or JBoss); rather, an already built and versioned artifact should be available from the maven repository.
Over time the repository may also give access to third party artifacts (acting as a mirror for other publicly available repositories), but that is not the case at present.
Ideas for a Naming Standard
We need to differentiate between:
- Artifacts which have gone live; ie: the source is tagged within SVN. These could be historical as well as currently live versions.
- Artifacts built from source at the trunk within SVN; ie: developed but not deployed in a live environment yet.
The first of these is of prime importance: it represents official, released versions. The second is only there for developers to share for development or integration purposes.
Some organizations run two repositories to differentiate these levels. This seems a little too much for the level of BRICCS development at present, so I suggest:
- Artifacts built from tagged versions within SVN (ie: official releases) should have the standard version numbering system.
- Artifacts built from the trunk (but not yet released as official versions) should have SNAPSHOT within the name.
For instance, the unique id generator might have releases briccs-uidgen-1.0.jar and briccs-uidgen-1.0.1.jar, whereas the very latest source would (if it has been deployed within maven) have an unreleased artifact of briccs-uidgen-n.n.n-SNAPSHOT.jar where n.n.n is somewhere near the proposed next version number for a release.
Just a Note
The above seems sensible to me and in the spirit of Maven examples. But it is not how the Obiba repository is structured, where SNAPSHOT seems to be used as a sort of indication of tagging. But I find the Obiba way confusing.
I agree with pretty much all of this. However, I would like to add a timestamp to the SNAPSHOT builds. If we are working on fixing a bug, we may want to have several versions of a development branch available in our repository.
So for snapshot builds, I would extend what you have to add a timestamp briccs-uidgen-n.n.n-SNAPSHOT-yyymmddHHMMSS.jar
Whoops! Back to the drawing board. Shows my lack of knowledge of Maven 2...
I have found that if you include SNAPSHOT in the version number, eg: foo-1.0.2-SNAPSHOT, a deploy generates a suitable directory structure but the actual artifact name does not have SNAPSHOT in the name, although it is timestamped!
For example, something like this gets generated within the maven repo:
Actually, this looks acceptable to me. It means a snapshot will be recognizable from the inclusion of a timestamp. There should be few of these given that the official releases would be tagged versions within SVN. The official releases would not have a timestamp.