As one of the fans of a non-Maven way to deal with this, I will point
you to some documentation on the approach.
http://blog.artifact-software.com/tech/?tag=maven
This should get you 4 articles that discuss our approach to Maven.
http://blog.artifact-software.com/tech/?p=121
Specifically addresses the problem that you are working through.
It works well for us.
Our big project had over 30 independent modules that depended on more
than 70 third party modules - Tomcat, Jetspeed, Apache Commons, Spring,
Hibernate, Mysql JSF, CXF, Jasper Reports, etc.
We are currently actively developing 2 projects each with about 10
modules (Maven Projects) with the same technology stack (Jackrabbit
replacing MySQL and adding Spring-Data) and have continued the same
approach.
It works well and makes the war files very small and cuts the build time
dramatically.
It relieves the developer from dealing with versions and dependency
configurations.
The individual shared libraries have the "right" versions with the
required exclusions already fixed up so inter-library conflicts are
resolved.
The developer just have to make sure that their code works.
If they want to add a third party library that is not included in the
"corporate" utility libraries, this is supposed to be discussed at the
project level to see if it should be shared or not.
We don't make a big deal about this now that we have a really good core
stack settled.
At the beginning of each release cycle we review the "approved" versions
and upgrade as appropriate. This lets us review and test dependency
changes as a team.
We use the STS version of Eclipse so we have full support for Maven and
can easily see where dependencies are coming from and where potential
dependency conflicts occur between third party software so exclusions
can be adjusted.
Ron
On 31/01/2014 5:33 AM, Anders Hammar wrote:
1. Provide a single/coherent dependencyManagement section so that users
using P do not have to care about the different versions of the
sub-projects: they use P and all the required dependencies are pulled
automatically
Some confusion here. You're talking about depMgmt and then say that the
required deps should be pulled in autoamtically. That will not happen. You
still need to specify the deps you have.
In any case, this is ok if you want to stay on the "Maven way". This
depMgmt could be handled/provided in a separate pom which is then included
in those projects that want to use the platform/product. Sometimes this is
called a BOM (Bill of Material). JBoss provides such a BOM for their app
server for example. A quick Google gave this page talking about that:
http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms
There is also the possibility of creating a "grouping pom", which lists all
artifacts as dependencies. You would then declare a dependency to that
grouping pom and get all deps magically sucked in. However, this is not
really the "Maven way" in my opinion as you wouldn't specify your direct
deps bu sort of relly on transitive deps. There are some fans of this
approach though here on this list.
2. Build configs that *force* each sub-project to run with the list of
dependencies for the project (to ensure all tests pass, etc). This is to be
used alongside the regular build job for validation purpose
Maybe some enforcer rule?
/Anders
I started to look at this and my first trial was to generate a report with
all the dependencies of each project and build a consolidated report that I
can match against the candidates. This would help manage the first goal as
if a dependency gets added, removed or updated, the global
dependencyManagement has to be impacted manually (do we upgrade or not,
etc).
For the second part, it's not easy to force a dependency change in Maven,
especially if the version has been specified at the project level.
Thanks for reading that far. If you have any idea or know any organisation
that tried to implement that, I'd be interested
Thanks!
S.
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
