Droids
  1. Droids
  2. DROIDS-130

Use explicit versions for the Maven plugins

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.2.0
    • Fix Version/s: 0.2.0
    • Component/s: None
    • Labels:
      None

      Description

      It's best practice to define the Maven plugins by using explicit versions. This improves the repeatability of the build, as it doesn't depend on the releases of new versions of these dependencies to Maven central.

      1. DROIDS-130_v2.patch
        21 kB
        Bertil Chapuis
      2. DROIDS-130_v1.patch
        5 kB
        Eugen Paraschiv

        Activity

        Hide
        Richard Frovarp added a comment -

        This appears to be fixed in trunk.

        Show
        Richard Frovarp added a comment - This appears to be fixed in trunk.
        Hide
        Eugen Paraschiv added a comment -

        Some time has passed since this patch was generated. I will resolve the conflicts and regenerate it as soon as possible.
        Thanks for making me aware of the problem.
        Eugen.

        Show
        Eugen Paraschiv added a comment - Some time has passed since this patch was generated. I will resolve the conflicts and regenerate it as soon as possible. Thanks for making me aware of the problem. Eugen.
        Hide
        Tobias Rübner added a comment - - edited

        This patch is broken!
        I think it has something to do with the module reorganisation DROIDS-107

        Show
        Tobias Rübner added a comment - - edited This patch is broken! I think it has something to do with the module reorganisation DROIDS-107
        Hide
        Eugen Paraschiv added a comment -

        OK, makes sense. I'll submit the patch to only contain versions for plugins that don't have any and also are not specified in the parent pom.

        Show
        Eugen Paraschiv added a comment - OK, makes sense. I'll submit the patch to only contain versions for plugins that don't have any and also are not specified in the parent pom.
        Hide
        Bertil Chapuis added a comment -

        Note I encourage specifying the version for the plugins which are not inherited from the apache pom.

        Show
        Bertil Chapuis added a comment - Note I encourage specifying the version for the plugins which are not inherited from the apache pom.
        Hide
        Bertil Chapuis added a comment -

        Sorry for the patch. This one should work. I totally agree with you about the versions of the dependencies (DROIDS-134). However for the plugins I don't really see the problem. I upgraded the trunk from the version 7 to the version 9 of the apache pom something like three weeks ago and I think nobody noticed the change. If a problem is encountered, since droids is a small project, it will be easy to solve it.

        Show
        Bertil Chapuis added a comment - Sorry for the patch. This one should work. I totally agree with you about the versions of the dependencies ( DROIDS-134 ). However for the plugins I don't really see the problem. I upgraded the trunk from the version 7 to the version 9 of the apache pom something like three weeks ago and I think nobody noticed the change. If a problem is encountered, since droids is a small project, it will be easy to solve it.
        Hide
        Eugen Paraschiv added a comment -

        About the default pom provided by Apache, I think there is certainly an advantage of having a simpler pom, but there are also some disadvantages.
        For one, Maven 3 is still very new, and plugins are being worked on and fixed with every new release. Not defining our own versions takes away that advantage.
        Second, the upgrade from this version of the Apache pom and the next is going to represent a leap instead of an incremental improvement, which is not something to be desired. The pom probably recognizes this, as it says: "Standard versions of plugins are also defined, these may be overridden by individual projects as well."
        Then, with Droids being a relatively small project, the advantage of not having a few version lines in the pom isn't really that big.
        The decision is likely going to be a balance between advantages and disadvantages.
        In any event, I will first provide a new small(er) patch addressing the plugins that do not have versions in our pom and also do not exist in the Apache pom.
        Thanks.

        Show
        Eugen Paraschiv added a comment - About the default pom provided by Apache, I think there is certainly an advantage of having a simpler pom, but there are also some disadvantages. For one, Maven 3 is still very new, and plugins are being worked on and fixed with every new release. Not defining our own versions takes away that advantage. Second, the upgrade from this version of the Apache pom and the next is going to represent a leap instead of an incremental improvement, which is not something to be desired. The pom probably recognizes this, as it says: "Standard versions of plugins are also defined, these may be overridden by individual projects as well." Then, with Droids being a relatively small project, the advantage of not having a few version lines in the pom isn't really that big. The decision is likely going to be a balance between advantages and disadvantages. In any event, I will first provide a new small(er) patch addressing the plugins that do not have versions in our pom and also do not exist in the Apache pom. Thanks.
        Hide
        Eugen Paraschiv added a comment -

        Unfortunately I have some conflicts when trying to apply the provided patch.

        Show
        Eugen Paraschiv added a comment - Unfortunately I have some conflicts when trying to apply the provided patch.
        Hide
        Bertil Chapuis added a comment -

        It doesn't really go in the direction of the initial patch. The aim was to define the plugin versions only when they are not present in the inherited apache pom project.

        The patch also removes the maven-eclipse-plugin definition since the behaviour defined in the pom can be obtained from the command line: mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true

        I also moved the versions from the properties section to the plugin or dependencies definitions and made some formatting changes.

        Show
        Bertil Chapuis added a comment - It doesn't really go in the direction of the initial patch. The aim was to define the plugin versions only when they are not present in the inherited apache pom project. The patch also removes the maven-eclipse-plugin definition since the behaviour defined in the pom can be obtained from the command line: mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true I also moved the versions from the properties section to the plugin or dependencies definitions and made some formatting changes.
        Hide
        Richard Frovarp added a comment -

        Sounds good.

        Show
        Richard Frovarp added a comment - Sounds good.
        Hide
        Bertil Chapuis added a comment -

        We inherit from http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom. Since this file will not change, we should probably keep the plugin versions proposed here and simplify our pom files as much as possible. We may also use plugin management to add consistency to our configuration. What do you think?

        Show
        Bertil Chapuis added a comment - We inherit from http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom . Since this file will not change, we should probably keep the plugin versions proposed here and simplify our pom files as much as possible. We may also use plugin management to add consistency to our configuration. What do you think?

          People

          • Assignee:
            Unassigned
            Reporter:
            Eugen Paraschiv
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development