• Icon: Task Task
    • Resolution: Fixed
    • Icon: Major Major
    • plugin-pom
    • None

      You should not need to ignore .flattened-pom.xml: it should live inside target.

          [JENKINS-51247] Move flattened POM into target directory

          Jesse Glick created issue -
          Jesse Glick made changes -
          Epic Link New: JENKINS-50686 [ 189770 ]
          Jesse Glick made changes -
          Link New: This issue is blocking JENKINS-51046 [ JENKINS-51046 ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Jesse Glick added a comment -

          What seems to be working so far in most cases: remove executions of the clean goal, and override

          <outputDirectory>${project.build.directory}</outputDirectory>
          <flattenedPomFilename>${project.artifactId}-${project.version}.pom</flattenedPomFilename>
          

          I noticed one behavioral change in findbugs-maven-plugin (relative paths in findbugs.excludeFilterFile are not resolved), but it is not clear what the correct behavior was there anyway; prepending ${project.basedir}/ fixes it.

          Now I am tracking down a problem in frontend-maven-plugin: node commands get run from target as the CWD. This code seems to be getting the wrong value—but only when the project version is not a snapshot. Of course I cannot reproduce a similar problem using a simple test mojo. This seems to have something to do with source:jar running a forked Maven execution, thus rerunning lots of mojos, in which the basedir is apparently wrong. The produce-incrementals profile runs this mojo, which is presumably the trigger.

          I notice that MavenProject.deepCopy is wrong (calls setFile and thus sets basedir of the clone to target). I am guessing that is the culprit behind both problems—they involve forked executions. (@Execute annotation)

          Summary: making this switch is not completely safe, but can be done.

          Jesse Glick added a comment - What seems to be working so far in most cases: remove executions of the clean goal, and override <outputDirectory> ${project.build.directory} </outputDirectory> <flattenedPomFilename> ${project.artifactId}-${project.version}.pom </flattenedPomFilename> I noticed one behavioral change in findbugs-maven-plugin (relative paths in findbugs.excludeFilterFile are not resolved), but it is not clear what the correct behavior was there anyway; prepending ${project.basedir}/ fixes it. Now I am tracking down a problem in frontend-maven-plugin : node commands get run from target as the CWD. This code seems to be getting the wrong value—but only when the project version is not a snapshot. Of course I cannot reproduce a similar problem using a simple test mojo. This seems to have something to do with source:jar running a forked Maven execution, thus rerunning lots of mojos, in which the basedir is apparently wrong. The produce-incrementals profile runs this mojo, which is presumably the trigger. I notice that MavenProject.deepCopy is wrong (calls setFile and thus sets basedir of the clone to target ). I am guessing that is the culprit behind both problems—they involve forked executions. ( @Execute annotation) Summary: making this switch is not completely safe, but can be done.

          Jesse Glick added a comment -

          I think I have it. Given this mojo

          @Mojo(name = "test", defaultPhase = LifecyclePhase.GENERATE_SOURCES)
          public class TestMojo extends AbstractMojo {
              @Parameter(defaultValue = "${basedir}")
              private File workingDirectory;
              public void execute() throws MojoExecutionException {
                  getLog().info("running in " + workingDirectory);
              }
          }
          

          invoked as

          <plugin>
              <groupId>test</groupId>
              <artifactId>flatten-maven-plugin-53</artifactId>
              <version>1.0-SNAPSHOT</version>
              <executions>
                  <execution>
                      <id>test</id>
                      <goals>
                          <goal>test</goal>
                      </goals>
                  </execution>
              </executions>
          </plugin>
          

          If produce-incrementals is configure to use source:jar, it gets run twice, once with the basedir, once with target. Using source:jar-no-fork, it runs just once, with the correct basedir.

          Jesse Glick added a comment - I think I have it. Given this mojo @Mojo(name = "test" , defaultPhase = LifecyclePhase.GENERATE_SOURCES) public class TestMojo extends AbstractMojo { @Parameter(defaultValue = "${basedir}" ) private File workingDirectory; public void execute() throws MojoExecutionException { getLog().info( "running in " + workingDirectory); } } invoked as <plugin> <groupId> test </groupId> <artifactId> flatten-maven-plugin-53 </artifactId> <version> 1.0-SNAPSHOT </version> <executions> <execution> <id> test </id> <goals> <goal> test </goal> </goals> </execution> </executions> </plugin> If produce-incrementals is configure to use source:jar , it gets run twice, once with the basedir, once with target . Using source:jar-no-fork , it runs just once, with the correct basedir.
          Jesse Glick made changes -
          Remote Link New: This issue links to "MNG-6405 (Web Link)" [ 20643 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "incrementals-tools PR 1 (Web Link)" [ 20644 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "plugin-pom PR 105 (Web Link)" [ 20645 ]
          Jesse Glick made changes -
          Remote Link New: This issue links to "artifact-manager-s3 PR 21 (Web Link)" [ 20646 ]

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: