control

Control may refer to: read more at WikiPedia

  • apache_maven

    It is not unusual in a project to have a huge number of third party artifacts and Plug-in. Apache Maven help you keep track of them, along with their transitive dependencies.

    But how do you know when a new version of an artifact is available?  This is where the Maven Versions plug-in come hand in.

    The Versions Plug-in is used when you want to manage the versions of artifacts in a project's POM.

    By running

    mvn versions:display-dependency-updates

    in any Apache Maven project or modules, you’ll get for example (we have a lot of 25 Maven modules, here is only one presented as an example, the list being too long)

    [INFO] --------------------------------------------------------------------------------------------------
    [INFO] Building Unnamed - com.innoveo:skye-services-api:jar:2.2.0-M-06
    [INFO] --------------------------------------------------------------------------------------------------
    [INFO]
    [INFO] The following dependencies in Dependency Management have newer versions:
    [INFO]   junit:junit............................................. 4.4 -> 4.8.1
    [INFO]   log4j:log4j......................................... 1.2.15 -> 1.2.16
    [INFO]   org.springframework:spring...................... 2.5.6 -> 2.5.6.SEC02
    [INFO]   org.springframework:spring-test............... 2.5.6 -> 3.0.4.RELEASE

    Attention:

    It is not always an easy task to update some core components or 3rd party libraries in a complex software, as it may introduce some regressions, incompatibilities..

    At least thanks to this Versions plug in, you are aware that they may be something newer to try. What this plug in do not report is why you may want to update some artifacts libraries:

    • Do I have to use the latest version x.y.z because of  security issues?
    • Will i get more performances by updating to x.y.z?
    • New Version x.y.z resolve bug xxxx, will I have other annoying issues?

    In all the above case, you are on your own, but this is not the scope of this plug in. You’ll have anyway to

    1. Carefully decide which library can be updated,
    2. Match it to your software roadmap,
    3. Have enough confidence in your test suite (unit test, BDD, integration tests) and testing team,
    4. Communicate with your customer (for security issues in 3rd party library)
    5. .. and the list goes on

    The Versions Plug-in has a lot of interesting goals.

    Some are also updating values across all pom.xml for you.

    • versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM.
    • versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version.
    • versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match).
    • versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4
    • versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT.
    • versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used.
    • versions:set can be used to set the project version from the command line.
    • versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version.
    • versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version.
    • versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version.
    • versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version.
    • versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version.
    • versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version.
    • versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version.
    • versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in "Poor Man's SCM".
    • versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in "Poor Man's SCM".

    The easiest way to live dangerously is to try to update all 3rd parties in one shot by issuing

    mvn versions:use-latest-versions

    but that’s another story :-)

  • apache_maven

    What can you do to avoid that when you use one Maven dependency, to also inherit some other undesirable older
    dependency (which is to say from an older transitive dependency).

    The fix to this is to add an exclusion to the dependency in question.
    For example, if we start with a dependency upon version 1.2 of the jxpath library:

    <dependency>
       <groupId>common-jxpath</groupId>
       <artifactId>common-jxpath</artifactId>
       <version>1.2</version>
       <scope>compile</scope> <!-- default scope for sake of example-->
    </dependency>

    This dependency to jxpath 1.2 will bring in an old version of log4j 3.8. In order to ensure that I am using the latest
    versions of log4j (4.4),

    I need to put in an exclusion for these transitive dependencies of common-jxpath, which I do as follows:

    <dependency>
       <groupId>common-jxpath</groupId>
       <artifactId>common-jxpath</artifactId>
       <version>1.2</version>
       <scope>compile</scope> 
       <exclusions>
          <exclusion>
             <artifactId>junit</artifactId>
             <groupId>junit</groupId>
          </exclusion>
          <!-- I can put many of these here -->
    </exclusions> </dependency>

    Having excluded them, they will be any longer in the build.

    Now, there is still too many thing that can occur in the background

    • Another 3rd party artifact may include log4j by using a transitive dependencies, and then you will have to rely/trust transitive
      dependency mediation
    • You can explicitly include the versions that you want in all pom.xml or better in your parent pom.xml

    Transitive dependency mediation

    Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are
    encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of
    the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it
    explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until
    Maven 2.0.4 it was not defined which one would win, but since Maven 2.0.5 it's the order in the declaration that counts: the
    first declaration wins.
    "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if
    dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A
    because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0

    find out what the transitive dependencies are?

    You can't control what you do not know!

    One that can be use during build stage or explicitly use on command line, is the maven plugin maven-dependency-plugin

       <build>
          <plugins>
             <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
             </plugin>
          </plugins>
       </build>

    and then use the goal dependency:tree, so a typical build strategy could look like 

    mvn clean install dependency:tree
    or
    mvn clean install dependency:list   (easier to tokenize in excel sheet)
    So it look like
    With no exclusions

    [INFO] [dependency:tree]
    [INFO] com.test:test:jar:0.0.1-SNAPSHOT
    [INFO] \- commons-jxpath:commons-jxpath:jar:1.2:compile
    [INFO]    +- xerces:xerces:jar:1.2.3:compile
    [INFO]    +- javax.servlet:servlet-api:jar:2.2:compile
    [INFO]    +- junit:junit:jar:3.8:compile
    [INFO]    +- ant:ant-optional:jar:1.5.1:compile
    [INFO]    +- xml-apis:xml-apis:jar:1.0.b2:compile
    [INFO]    +- jdom:jdom:jar:b9:compile
    [INFO]    +- commons-beanutils:commons-beanutils:jar:1.4:compile
    [INFO]    +- commons-logging:commons-logging:jar:1.0:compile
    [INFO]    \- commons-collections:commons-collections:jar:2.0:compile
    [INFO] [dependency:list]
    [INFO]
    [INFO] The following files have been resolved:
    [INFO]    ant:ant-optional:jar:1.5.1:compile
    [INFO]    commons-beanutils:commons-beanutils:jar:1.4:compile
    [INFO]    commons-collections:commons-collections:jar:2.0:compile
    [INFO]    commons-jxpath:commons-jxpath:jar:1.2:compile
    [INFO]    commons-logging:commons-logging:jar:1.0:compile
    [INFO]    javax.servlet:servlet-api:jar:2.2:compile
    [INFO]    jdom:jdom:jar:b9:compile
    [INFO]    junit:junit:jar:3.8:compile
    [INFO]    xerces:xerces:jar:1.2.3:compile
    [INFO]    xml-apis:xml-apis:jar:1.0.b2:compile

     

    With exclusions

    [dependency:tree]
    [INFO] com.test:test:jar:0.0.1-SNAPSHOT
    [INFO] \- commons-jxpath:commons-jxpath:jar:1.2:compile
    [INFO]    +- xerces:xerces:jar:1.2.3:compile
    [INFO]    +- javax.servlet:servlet-api:jar:2.2:compile
    [INFO]    +- ant:ant-optional:jar:1.5.1:compile
    [INFO]    +- xml-apis:xml-apis:jar:1.0.b2:compile
    [INFO]    +- jdom:jdom:jar:b9:compile
    [INFO]    +- commons-beanutils:commons-beanutils:jar:1.4:compile
    [INFO]    +- commons-logging:commons-logging:jar:1.0:compile
    [INFO]    \- commons-collections:commons-collections:jar:2.0:compile
    [INFO] [dependency:list]
    [INFO]
    [INFO] The following files have been resolved:
    [INFO]    ant:ant-optional:jar:1.5.1:compile
    [INFO]    commons-beanutils:commons-beanutils:jar:1.4:compile
    [INFO]    commons-collections:commons-collections:jar:2.0:compile
    [INFO]    commons-jxpath:commons-jxpath:jar:1.2:compile
    [INFO]    commons-logging:commons-logging:jar:1.0:compile
    [INFO]    javax.servlet:servlet-api:jar:2.2:compile
    [INFO]    jdom:jdom:jar:b9:compile
    [INFO]    xerces:xerces:jar:1.2.3:compile
    [INFO]    xml-apis:xml-apis:jar:1.0.b2:compile

     
    see Maven Dependency Plugin