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