Maven Shared Components
  1. Maven Shared Components
  2. MSHARED-35

Recreating pom.properties always breaks the archivers uptodate check

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: maven-archiver
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.

      The attached patch proposes a solution for the same problem. What the patch does:

      • It is obviously bad, that the generated pom.properties file is in the projects directory. The
        patch moves the file to $ {project.build.directory}

        /maven-archiver, which seems to me to
        be a more sensible solution.

      • Second, whether we like it or not, there are projects, which create multiple artifacts. In other
        words, it isn't good to have a single file. The patch renames the pom.properties file to
        $ {groupId}

        /$artifactFinalName.properties. Hopefully, this is sufficiently unique.

      • Finally, the patch makes the maven-archiver check, whether the pom.properties file has
        actually changed. (In other words, whether groupId, artifactId, or version have changed.)
        It does so, by writing the file to an internal buffer and comparing the file on the disk and
        the internal buffer (after skipping the line with the timestamp).

      In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.

      1. maven-archiver-MNG2854-4.patch
        11 kB
        Jochen Wiedmann
      2. maven-archiver-properties.patch
        6 kB
        Jochen Wiedmann
      3. maven-archiver-properties-2.patch
        14 kB
        Jochen Wiedmann
      4. maven-archiver-properties-3.patch
        10 kB
        Jochen Wiedmann

        Issue Links

          Activity

          Hide
          Jochen Wiedmann added a comment -

          Possible duplicate

          Show
          Jochen Wiedmann added a comment - Possible duplicate
          Hide
          Jason van Zyl added a comment -

          Point one is fine.

          Point two is not fine. One artifact and so many people expect the pom.properties file and is what we document. That can't change and I will never support the widespread production of multiple artifacts.

          Point three is fine.

          Fix up the second point and I will apply the patch. Also, how did you test this?

          Show
          Jason van Zyl added a comment - Point one is fine. Point two is not fine. One artifact and so many people expect the pom.properties file and is what we document. That can't change and I will never support the widespread production of multiple artifacts. Point three is fine. Fix up the second point and I will apply the patch. Also, how did you test this?
          Hide
          Jochen Wiedmann added a comment -

          Ok, here's an updated version of the patch. Note, that it contains a test case (MavenArchiverTest.testRecreation) that verifies whether the jar file is indeed created when invoked for the first time, but isn't for the second time.

          Show
          Jochen Wiedmann added a comment - Ok, here's an updated version of the patch. Note, that it contains a test case (MavenArchiverTest.testRecreation) that verifies whether the jar file is indeed created when invoked for the first time, but isn't for the second time.
          Hide
          Trygve Laugstøl added a comment -

          A couple of code comments:

          • Call the class PomPropertiesUtil instead of Manager. There are a lot of other Manager classes in Maven and they are Plexus components, while this is a normal utility class.
          • Use org.codehaus.plexus.util.IOUtil.close() to close streams.
          • When comparing the properties file why not generate Properties object and load the existing properties file and use Properties.equals()? That should save you some hassle.
          Show
          Trygve Laugstøl added a comment - A couple of code comments: Call the class PomPropertiesUtil instead of Manager. There are a lot of other Manager classes in Maven and they are Plexus components, while this is a normal utility class. Use org.codehaus.plexus.util.IOUtil.close() to close streams. When comparing the properties file why not generate Properties object and load the existing properties file and use Properties.equals()? That should save you some hassle.
          Hide
          Jochen Wiedmann added a comment -

          Done.

          Thanks for the hint regarding Properties.equals(...). One learns all the time. Of course, this simplifies the code drastically.

          Show
          Jochen Wiedmann added a comment - Done. Thanks for the hint regarding Properties.equals(...). One learns all the time. Of course, this simplifies the code drastically.
          Hide
          Carlos Sanchez added a comment -

          Please add the apache license to PomPropertiesUtil.java if you grant the license to the ASF

          Show
          Carlos Sanchez added a comment - Please add the apache license to PomPropertiesUtil.java if you grant the license to the ASF
          Hide
          Jochen Wiedmann added a comment -

          Done.

          Show
          Jochen Wiedmann added a comment - Done.
          Hide
          Carlos Sanchez added a comment -

          Applied in 2.3-SNAPSHOT

          Show
          Carlos Sanchez added a comment - Applied in 2.3-SNAPSHOT

            People

            • Assignee:
              Carlos Sanchez
              Reporter:
              Jochen Wiedmann
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: