maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject AW: AW: AW: How to manage dependency "includes"?
Date Sat, 09 Jan 2016 09:59:31 GMT
Thanks for that detailed post, but it's still not what I asked for :-(
I just finished the transition of ALL of the projects of a large international bank from Ant
to Maven. In parallell 
what was initially about 70 more or less separate projects, that were assembled to one huge
monolithic application was changed in order to create modules and the ability to assemble
several applications, each with different focusses.

It was a huge challenge as you have to coordinate the wishes of uncountable project-managers,
developers and other stakeholders. We encountered quite a large number of serious problems.
Everyone that has worked for a Bank knows you can't just go there and tell them what the standard
is, cause they'll tell you what their standard is ;-)

So in the end we prohibited (by maven plugin) providing the version of third party libraries,
enforced the usage of a company-wide dependencyManagement pom that is used in every project.
Additionally we enforced the rules of the dependency plugin to declare used dependencies and
not to rely on transitive dependencies. With this a lot of our problems were solved. Even
if the developers complain every now and then, but I guess that's the price to pay for giving
them the freedom they need and the flexibility they want. Introducing a rather strict policy
on the process as you describe, is completely out of the question. You can't get 40 project
managers to discuss new versions. This meeting would probably never, ever end ;-)

So back to the question none has answered yet (would be cool if maybe someone on the dev-team
of Maven could respond): 
Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break things, and would
it be ok to fix up a Pull request implementing that functionality?


Von: Ron Wheeler <>
Gesendet: Freitag, 8. Januar 2016 15:58
Betreff: Re: AW: AW: How to manage dependency "includes"?

In our setup, each project has its own parent POM and set of aggregated
third party libraries. Some sharing is done between products for really
common stuff like Spring, Apache Commons, Tomcat, etc.
The library com.artifact_software.projectA:reporting-library:1.2 might
be different from com.artifact_software.projectB:reporting-library:1.2
if one used BIRT and the other used Jasper Reports.

These should be under the control of the person/team that is responsible
for deciding what version of the third party libraries are to be allowed.
The following might be involved in the selection of a new library or a
request by a developer to upgrade a library.
- Product Manager - legal/licensing, market acceptance, documentation,
functionality issues
- Project manager - scheduling, testing, risk assessment, aggregation
- Lead developer - risk assessment, alternatives, technical analysis,
aggregation strategy

At the beginning of each development sprint, we review the current
libraries to see what versions should be updated.
This does not completely eliminate changes to versions during the
development process as programmers run into opportunities to use
features from newer versions or discovery of critical bugs that require
a library upgrade in mid-sprint.

This review is pretty short and usually involves the entire team so that
we can estimate the cost of changing a library - what modules will be
affected and require testing even if they are not being modified as part
of the sprint.

Once this is done, the developers do not have to worry about
dependencies. Once the version of
com.artifact_software.projectA:commons-library:1.2 is set, the
developers do not have to worry about what version of each of the Apache
Commons libraries are included and module POMs should not include any
third party libraries unless there is a good reason not to have it under
team management.

This also minimizes the changes to POMs.
The parent POM's dependency management sets the versions for the release
being developed so once the reference to the parent POM is changed, all
the right versions of everything is automatically included in the
module. This makes life really easy for developers - change one number
in the module POM and start working.

I hope that this helps.


On 08/01/2016 5:03 AM, Christofer Dutz wrote:
> I agree, but this only woks as long as there is "THE" project manager. Here there are
several ones. The central instance that manages libraries and their versions and handles conflict
resolution is simply the one managing the central dependencyManagement pom. All the project
POMs are part of the projects and these are responsibility of those teams and even live in
separate repos.
> But coming back to my initial question:
> Would maven support of "exclusions" and "inclusions" in dependency management break anything?
If yes - what? I still think that this could solve a lot of problems we were having and shouldn't
have a big impact on Maven itself. If it doesn't break anything and I would implement something
like that ... what would the chances that it gets accepted be?
> Chris
> ________________________________________
> Von: Ron Wheeler <>
> Gesendet: Donnerstag, 7. Januar 2016 16:06
> An:
> Betreff: Re: AW: How to manage dependency "includes"?
> If you are using Eclipse with the m2e plug-ins (we use Eclipse/STS which
> comes with this), it will tell you what versions are being included as
> transitive dependencies.
> Our approach removed the decision about library versions from the
> developers and put it into the project manager's hand so that:
> - Adding a library had some management visibility - license
> compatibility, vendor/developer stability, avoiding duplication of
> functionality, library testing
> - Programmers did not have to worry about incorrect or missing dependencies
> - Programmers could move to a new project quickly.
> - updating a library version updated automatically updated all projects
> It took a bit of work once we decided to get organized but it paid off
> very quickly in programmer productivity and improved project schedule
> stability
> Once you have found the source jar for the library and included it in
> one of your libraries, it is available for every module.
> Ron
> On 07/01/2016 9:25 AM, Christofer Dutz wrote:
>> Hi Ron,
>> Well I guess that's out of the question.
>> We were thinking about that, but the normal workflow would be:
>> - Search in the company nexus which lib provides a given package
>> - Include that in the pom
>> That would work around the "managed-pom" approach. So users would have to look at
each dependency, if there is a special pom version in the system. I think that's definitely
not going to work.
>> In this company there are about 200 developers working on 50-60 different projects,
that are assembled to about 20 different products. Currently we'll live with excluding stuff
and having users add missing dependencies during the unit-, integration- , acceptance-test
phases, but it would have been easier with some "exclusions/inclusions" mechanism.
>> Chris
>> ________________________________________
>> Von: Ron Wheeler <>
>> Gesendet: Montag, 4. Januar 2016 17:19
>> An:
>> Betreff: Re: How to manage dependency "includes"?
>> You can simplify the problem that you are having by making a module that
>> includes the correct version of the third party modules and having your
>> modules depend on that with a "provided" scope.
>> This also makes all of your jars and wars a lot smaller since only one
>> copy of each API is included in the whole project rather than having the
>> code appear in every one of your modules that needs it.
>> This speeds your builds by a lot and save individual developers from
>> having to think about the "correct" version of each library. They just
>> include the aggregated libraries that they need.  For example Apache
>> Commons stuff would be supplied by your module
>> com.example:myapachecommons:1.0-SNAPSHOT with scope provided.
>> might be a useful set
>> of articles.
>> Ron
>> On 04/01/2016 3:38 AM, Christofer Dutz wrote:
>>> Hi,
>>> I am currently cleaning up in the dependencies of a quite big set of big projects.
For this I am making a lot of use of dependency management. One thing I did come across quite
a lot of times is this problem:
>>> Some libs reference undesired libs, mostly API libs (in most cases they reference
artifacts that contain parts of some API packages). To prevent them from being used, we exclude
them in the dependencyManagement section. Now the downside is that now the API packages are
missing. In order to fix this, we now have to manually add dependencies to the API modules
wherever the artifact is used. It would be cool, if there was not only an "exclusion" but
also an "inclusion" mechanism in dependencyManagement, so we could actually manage situations
like this.
>>> Is there a better way of resolving this type of problem? Would adding a feature
like the "inclusions" to Maven be a good idea? If not, what are the problems with it? If yes,
what can I do to help get it in (Would be glad to contribute something like this)?
>>> Chris
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email:
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message