The way that we solved this is to build a set of pom files that identify
the 3rd party libraries that we use and version the POM with the version
of the product that we are building.
For example, we have a pom-spring-hibernate-mysql-tomcat project that
builds a jar with the spring, hibernate, mysql and tomcat jars that we
use in the specific project version.
In the in-house projects, we reference the ${project.version} of the
pom-spring-hibernate-mysql-tomcat project as a POM that is
PROVIDED(since we deploy the library to the shared tomcat /lib directory).
For example our web-service1's pom.xml is version 1.8.3 and depends on
pom-spring-hibernate-mysql-tomcat version 1.8.3.
We have similar poms for CXF (our web service), Jetspeed (portal),
shared (apache commons and other things), Jasper(reporting), etc.
This way the developers only have to know that they are building 1.8.3
and they use the libraries set up for 1.8.3.
Once the decision has been made about what versions of spring,
hibernate, mysql, etc is made and built into a set of POM, the version
is settled.
We treat our own library projects like 3rd party projects (just more
volatile in the 1.8.3-SNAPSHOT phase).
It means that there is an overhead step at the start of a new version.
You need to establish the versions of the dependencies and revise your
library poms if they change.
Most of the time you simply change the POM's version and leave the
library's dependencies alone and redeploy into the Nexus to make the new
1.8.4-SNAPSHOTs ready for the developers to use.
If during the building of 1.8.4-SNAPSHOT, you decide to upgrade the CXF,
you just change the pom-CXF project and redeploy the pom-CXF and its
jar-with-dependencies as new 1.8.4-SNAPSHOT. The rest of the
1.8.4-SNAPSHOT projects will automatically get the new CXF when they build.
This gives a very repeatable build and deploy since all of your 3rd
party libraries are included in the library jars. You don't have to go
looking through 60 jar files to be sure that you have deployed the right
commons-xxx.jar for the version that you have deployed.
Ron
On 14/06/2010 3:51 PM, Michael O'Cleirigh wrote:
Hello,
The case I am looking at is that I have two maven artifact hierarchies
that are independent.
Hierarchy A artifacts are core code that is shared between a bunch of
different projects.
Hierarchy B artifacts are for a single project and in some cases
depend on artifacts from A.
Now the A artifacts pull in the dependencies and define property
values to represent the version of the artifact.
The B projects don't care about the version but we need to make sure
that the versions used in B match the versions used in A.
In the A hierarchy I can define the ${something.version} and then in A
modules it will be able to resolve it.
My question is if there is a way to get the ${something.version}
property from the A artifact from within the B hierarchy.
Right now I have to create a matching ${something.version} in the B
pom and manually keep them matched on the same version. But I think
there must be a command or module that will allow this kind of inter
artifact property resolution.
A concrete example would be that A sets a ${spring.version} and in B
we want to include a different spring artifact but have the version be
aligned with what is being included with the A artifacts.
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
