Maven versions and release procedure
by Adrian Brock
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 10 months
Common eclipse .classpath for maven2
by Anil Saldhana
Rather naïve question. If each project migrates to maven2 and has an eclipse .classpath file, the dependent libraries all exist in local maven2 repository (which may be C:\xxxx\.m2\repository).
How do we ensure that we can check in a .classpath file into the source repository just the way we do with our current build setup?
19 years, 10 months
RE: [JBoss-dev] Re: Version numbers in library filenames - Bad
by Ryan Campbell
Well, removing the versioned jars will break the maven builds depending
on this module, such as security, with more to come. Maven is expecting
the jars to have the version info in them.
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Thursday, September 21, 2006 10:28 AM
To: JBoss.org development list
Subject: Re: [JBoss-dev] Re: Version numbers in library filenames - Bad
I don't want both as this just requires that only maven can be used to
get around having to update all derived artifacts (classpaths, docs,
wikis, installer, ...). I know Ruel said inclusion of the version in the
artifact was a big discussion item, but unless maven is your world its
just a pain in the ass as it propagates version info everywhere.
Ryan Campbell wrote:
We will want both, correct? versionless jars for non-maven, versioned
for maven?
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Thursday, September 21, 2006 9:44 AM
To: Carlo de Wolf
Cc: JBoss.org development list
Subject: [JBoss-dev] Re: Version numbers in library filenames - Bad
It looks like the jarName can be overriden. I'll see if I can rebuild
the jboss-common jars without the version as it will require a constant
updating of the eclipse projects in jbossas since jbossas is not build
using maven yet.
Carlo de Wolf wrote:
It is possible by specifying extra parameters with the goal.
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html
I don't have an example at hand.
Carlo
On Wed, 2006-09-20 at 07:54 -0700, Scott M Stark wrote:
I agree, but this is the maven convention and as far as I know
cannot be
undone short of hacking the jar plugin.
Dimitris Andreadis wrote:
I've seen a few cases where in repository.jboss.com the
version number
for a library is included in the library filename,
E.g.
antlr-2.7.6.jar
addressing-1.0.jar
odmg-3.0.jar
quartz-all-1.5.2.jar
dtdparser121.jar
commons-lang-2.1.jar
myfaces-impl-1.1.3.jar
Even worse:
Cglib/2.1.0/lib/cglib.jar, cglib-2.1.1.jar
This is wrong, because
- whenever a library is updated we have to correct all
explicit
references to it
- If you don't wipe your thirdparty on every update you
may end up with
3 different versions of the same library and wonder for
hours what's
wrong.
The version is encoded in the path and the library's
META-INF/MANIFEST.MF, not the filename, e.g:
apache-logging/1.0.3/lib/commons-logging.jar
For existing libs the harm is already done, but for new
library
additions to repository.jboss.com, please have that in
mind and remove
any version number from the filenames.
Thanks
/Dimitris
________________________________
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
19 years, 10 months
