On 24/06/2010 4:39 AM, Anders Hammar wrote:
The import solution that Stephen suggests is the way to go. Kind of a
pre-mixin support...
I use that a lot for defining different sets of depMgmt. Very useful when
you work with app servers of different versions to make it possible to work
and test against the exact same version of dependencies that you will be
using in runtime.
/Anders
On Thu, Jun 24, 2010 at 10:26, Dunstan, Tom (SACE Board)<
[email protected]> wrote:
The best solution is to have either:
1. A project for spring 3 and a project for spring 2.5 that
defines the dependencyManagement for each of the spring
versions and then use dependency scope import to pull in the
spring 3 or the spring 2.5 dependency version info (assumes
that the same GAV coords exist in both versions of spring and
only the versions/exclusions change, and or the transitive
deps are pulling in the diffs)
OK, I wasn't aware of scope import, I'll have a look. Thanks
2. A project for spring 3 and a project for spring 2.5 that
pull in all the deps for these and then just depend on either
the spring 3 or the spring 2.5 version.
This is pretty horrible. I just want a nice way to share
dependencyManagement information between projects so that it's defined
somewhere central. This proposal actually changes the pulled in
dependencies.
We create a parent pom for the version of the application that we are
building.
In the parent pom we declare a project.version variable that is used to
select the dependencies of the shared libraries in the module poms.
This way the module poms can declare a dependency on
com.artifact_software.ourproject: pom-shared-spring:${project.version}
to get the right configuration of Spring.
To move a project module from one version to another, we only change the
version of the pom and the reference to the parent - everything else
that the module developer needs is setup by the person who builds the
libraries.
We have poms for:
spring-hibernate-mysql-tomcat which pulls together the main environment
stack
jasper for reporting
CXF for web services
jsf for shared JSF libraries
jsf-portlet for JSF components that have to be deployed with the webapp.
shared-libraries to control the dozens of Apache commons and other
smaller third party libraries for which we have a project-wide agreement
ob versions.
and our own internal libraries
We build jar files for each of these projects so we only deploy a small
number of jar files into the shared library of the container. This
reduces the war file size and speeds up loading.
This solved our problem of multiple versions of the same thing getting
deployed and made the project poms very stable - then depend on a small
stable set of poms that we define once.
The project poms hardly ever change, just set the version of the parent
that you want and you get the right version of all of the dependencies
for the version of the application that you are building.
The only overhead is rebuilding the libraries for each new project
version but that is a short mechanical task (change the pom version,
change the parent, redeploy to nexus) unless we are changing a
dependency. When we upgrade Spring, we will change 1 pom (pom-spring) in
the version of the project that will use 3.x and the rest of the poms
for that version will automatically get Spring 3.x
Ron
Thanks for the suggestions
Tom
---------------------------------------------------------------------
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]
