Let's incorporate this into the
http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation page.
I'm not finding anything like a synchronize plugin/goal.
What transitive dependency mechansim?
http://maven.apache.org/guides/introduction/introduction-to-dependency-me...
Do you mean pushing dependency statements to the parent pom?
There is also the inconsistent groupId usage. I don't see why we just
don't use jboss as the groupId.
What is the
Adrian Brock wrote:
We need to be careful with the versions and release procedure
on Maven. I've found two issues from simple testing:
1) Dependency Synchronization
We need to keep the dependencies in synch,
Maven has no notion of a project being part of a build
only a top level build incorporating other builds.
e.g. The common project is at 2.0.1.GA (released)
If you build from the top level "build" folder it works fine.
It uses the "modules" defined there.
If you build at the lower level, e.g.
common-logging-log4j, it is broken
because that has an out-of-date dependency:
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-logging-spi</artifactId>
<version>2.0.0</version>
</dependency>
Solution:
I believe there is a report you can run that helps
you "synchronize" dependencies across projects/modules.
We should also use the transitive dependency mechansim
of Maven2 where possible to reduce the amount of
explicit dependencies we right.
2) Changing the version after a release.
If you look at JBoss Common, it is released at 2.0.1.GA
The pom files in trunk still say 2.0.1.GA
so if I do "maven install" after doing some changes
I overwrite the released jars with my own.
This potentially breaks the other builds that expect
2.0.1.GA not my 2.0.2.alpha stuff.
Solution:
The release procedure should be something like:
a) Set all the versions to the release version
b) Run the report mentioned in (1) to check
dependencies are consistent
c) Tag and Release
d) Update the versions to the next development version