Changes between Version 1 and Version 2 of Maven


Ignore:
Timestamp:
12/07/10 21:18:48 (14 years ago)
Author:
jeff.lusted
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Maven

    v1 v2  
    33The BRICCS Maven repository is currently (December 2010) a Maven2 repository.[[BR]]
    44
    5 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 versioned artifact should be available from the maven repository.[[BR]]
     5The 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.[[BR]]
    66
    7 Over time it 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.
     7Over 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.
    88
    99=== Ideas for a Naming Standard ===
    … …  
    1212 * Artifacts built from source at the trunk within SVN; ie: developed but not deployed in a live environment yet.
    1313
    14 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:
    15  * Artifacts built from tagged versions within SVN (ie official releases) should have the standard version numbering system.
     14The 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.
     15
     16Some 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''':
     17 * Artifacts built from tagged versions within SVN (ie: official releases) should have the standard version numbering system.
    1618 * Artifacts built from the trunk (but not yet released as official versions) should have SNAPSHOT within the name.
    1719
    18 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 the proposed next version number proposed for its release.
     20For 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 the proposed next version number for its release.
    1921
     22=== Just a Note ===
     23The 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.
     24