That is essentially what we do and was included in my earlier recommendation
We use several projects to keep things organized and bit modular.

It makes risk assessment a bit easier to know that projectA does not have a dependency on Tomcat, MySql or Hibernate so a change to the versions in the Tomcat-Mysql-Hibernate project is unlikely to affect ProjectA.

It may help address the management of versions in Christofer Dutz's case where there is a strong centralization of the version selection decisions and a lot of project managers. It might be easier to know who to consult if a change to a version of a library is proposed. Finding the projects and the modules within a project that depend on Hibernate is easier if there are groups of libraries.

It should also make it easier to move to a container-based deployment since one could provide containers preloaded with the set of libraries so that projects only have to worry about loading up their own code. This can save a lot of time during testing. Much easier of move 5 mb around rather 100mb.

Ron

On 09/01/2016 11:57 AM, Michael wrote:
One solution would be to create a separate project that contains all the dependencies 
that work for all the applications.  Deploy that project to the server such that all 
the dependency jars are deployed to a single lib directory  (see 
https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html 
<https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html>).

Then specify all of those dependencies as ‘provided’ in the application 
projects, and include the common lib directory in the classpath for each of the 
applications:

CLASSPATH={commonlibs}/lib/*

Michael


On Jan 9, 2016, at 8:03 AM, Christofer Dutz <[email protected]> wrote:

Well the maven-dependency-plugin has a goal "analyze-only" 
(https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html) which 
reports dependencies, that are used, but not declared and that reports unused, but 
declared dependencies. We are simply using this.

We had problems like if the Application consists of Project A, B and C then 
xml-apis is in version X, if we only use A and B, then it's a different 
version, because a different dependency imported another version transitively. 
We had a lot of problems with code that worked in 10 different Applications, 
but in one it broke. Usually it tuned out to be exactly one of these problems.

Well for an example there is one lib, that references some other lib, that 
contains part of the JMS API 1.0. Unfortunately only part of it. Then in a 
different place we import the real JMS API 1.1. Now we needed to make sure the 
1.1 versions are taken and then all of the API is imported. Without this we 
would have some parts be JMS 1.0 and the other half of the API classes be 1.1. 
We solved the problem by excluding the half JMS 1.0 api artifact and manually 
added the full JMS 1.1 artifact in parallel. This works, but it's ugly. So I 
had the idea that it would be good to have something like this:

<dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>group-a</groupId>
         <artifactId>artifact-a</artifactId>
         <version>1.0</version>

         <exclusions>
           <exclusion>
             <groupId>half-apis</groupId>
             <artifactId>jms</artifactId>
           </exclusion>
         </exclusions>
         <inclusions>
           <inclusion>
             <groupId>javax.jms</groupId>
             <artifactId>jms</artifactId>
             <version>1.1</version>
           </inclusion>
         </inclusions>
       </dependency>

To actually fully manage the dependencies of "artifact-a"

Hope that's a little clearer.

And I don't quite understand how it would break things. After all, all I'm doing is declare ... if you add a 
dependency to "artifact-a" leave away "half-apis:jms" and add 
"javax.jms:jms:1.1" instead.

Chris

________________________________________
Von: Karl Heinz Marbaise <[email protected]>
Gesendet: Samstag, 9. Januar 2016 13:39
An: Maven Users List
Betreff: Re: AW: AW: AW: How to manage dependency "includes"?

HI,

On 1/9/16 10:59 AM, Christofer Dutz wrote:

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 ;-)
Unfortunately true...

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.
Sounds like a good idea...

Additionally we enforced the rules of the dependency plugin to
declare used dependencies and not to rely on transitive dependencies.
That is what i don't understand...where is the relationship to
maven-dependency-plugin.....May be i missed things here....

With this a lot of our problems were solved.
Which kind of problems...may be i missed things here...


Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break things,
and would it be ok to fix up a Pull request implementing that
functionality?

Hm...so you can do things like this (exclusion) single parts...

<dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>group-a</groupId>
         <artifactId>artifact-a</artifactId>
         <version>1.0</version>

         <exclusions>
           <exclusion>
             <groupId>group-c</groupId>
             <artifactId>excluded-artifact</artifactId>
           </exclusion>
         </exclusions>

       </dependency>

and since Maven 3.2.1 you exclude all transitive dependencies via:

<dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>group-a</groupId>
         <artifactId>artifact-a</artifactId>
         <version>1.0</version>

         <exclusions>
           <exclusion>
             <groupId>*</groupId>
             <artifactId>*</artifactId>
           </exclusion>
         </exclusions>

       </dependency>
...

Apart from that...an include does not make sense from my point of view
cause this could lead to the impression that you you could add
dependencies transitively..which makes no sense..

Furthermore changing the pom structure here would break all things....
This kind of changed could only be made (may be ...) in Maven 4???


Kind regards
Karl Heinz Marbaise


---------------------------------------------------------------------
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]




--
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]

Reply via email to