maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael <mlgir...@gmail.com>
Subject Re: How to manage dependency "includes"?
Date Sat, 09 Jan 2016 16:57:58 GMT
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 <christofer.dutz@c-ware.de> 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 <khmarbaise@gmx.de>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message