On Dec 12, 2006, at 5:32 PM, Kevan Miller wrote:
On Dec 12, 2006, at 3:52 PM, Dain Sundstrom wrote:
Kevan asked me to go over the development/release process used
when we have a single version number.
1 Make a development module in specs/trunk
[Maintince] svn cp specs/tags/<artifactId>-<latestVersion> specs/
trunk/<artifactId>
[New] make a new mvn module at specs/trunk/<artifactId>
2 Make changes
There is no need to update inner spec depenencies since all will
be marked as scope provided in the pom, so we don't get transitive
problems.
3 Vote and Release
update pom version
create jars
vote
publish
svn mv specs/trunk/<artifactId> specs/tags/<artifactId>-<version>
Alternatively, we can use the release plugin but the release
plugin means we can't vote on the final jars since it
automatically publishes to the final repository.
Thanks for the info Dain.
Not sure what you mean by "inner spec"
Dependencies between two specs. For example, connector depends on
transaction.
and I should read up on "scope provided".
Provided basically turns of transitive dependencies for those using
the module. This is very important for specs like connector since
that same connector version is used by both j2ee 1.4 and jee 5, which
would mean a dependency clash over JTA 1.0.1B in j2ee 1.4 and 1.1 in
jee5. With provided the spec uses what ever version is provided by
the environment.
What happens to the parent pom and the parent pom version during
the release of a spec?
The parent pom version is not used by the child pom so there is no
parent pom version problems during release. An example of the
latter, is the generic apache pom which some projects extend from.
This pom contains general apache information like the locations of
the apache repositories:
http://repo.mergere.com/maven2/org/apache/apache/3/apache-3.pom
-dain
