Maven
  1. Maven
  2. MNG-3536

REGRESSION: pom.build.sourceDirectory in Maven 2.0.9: it doesn't work anymore

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.9
    • Fix Version/s: 2.1.0-M1
    • Component/s: None
    • Labels:
      None
    • Environment:
      MacOSX, Java 6, Maven 2.0.9
    • Complexity:
      Intermediate
    • Number of attachments :
      3

      Description

      On one of my projects, I have the following property:

      <model.uri>file:$

      {project.build.sourceDirectory}

      /myapp.xmi</model.uri>

      Knowing that in the same POM, sourceDirectory is configured that way:

      <sourceDirectory>$

      {project.basedir}

      /src/main/uml</sourceDirectory>

      With Maven 2.0.8, model.uri was correctly mapped to /Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi
      But with Maven 2.0.9, now it's mapped to /Users/sarbogast/dev/myapp/Users/sarbogast/dev/myapp/src/main/uml/myapp.xmi, which is not good at all.

      I have attached a test project that builds with Maven 2.0.8 but not with Maven 2.0.9.
      It's not the simplest project ever but it's a real AndroMDA skeleton project.
      All the configuration is in mda/pom.xml

        Issue Links

          Activity

          Hide
          Shane Isbell added a comment -

          Bug fix here: https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536

          This is part of a rewrite of the interpolation code.

          Show
          Shane Isbell added a comment - Bug fix here: https://svn.apache.org/repos/asf/maven/sandbox/branches/MNG-3536 This is part of a rewrite of the interpolation code.
          Hide
          Shane Isbell added a comment -
          Show
          Shane Isbell added a comment - Interpolator patch containing IT tests. Apply to https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests
          Show
          Shane Isbell added a comment - Test mojo needed to verify patch. Apply to: https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-testing-plugins
          Hide
          John Casey added a comment -

          We need to look into converging the interpolation code in this branch with the code in plexus-interpolation, which is a split-off of the interpolator code from plexus-utils. It can be found here:

          http://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-components/plexus-interpolation

          I've already refactored the trunk project builder to use plexus-interpolation, and the assembly plugin is using the pre-split code in plexus-utils, but will be updated to use plexus-interpolation once it's released to avoid inconsistencies with forced versions of plexus-utils from mavens past.

          In short, we have interpolation needs that go beyond the project builder, and need to handle other model class trees than maven-model. If we can use the same codebase to achieve this, it will help greatly in the consistency department.

          We already have an interpolator in maven-project, one in plexus-utils that has moved into plexus-interpolation, another in plexus-expression-evaluator (not used in maven, afaik), and now this one...hopefully we can find a way to consolidate some of this work and realign all of our efforts to some extent...and maybe refocus on consistency regardless of the model (or file) being interpolated.

          Show
          John Casey added a comment - We need to look into converging the interpolation code in this branch with the code in plexus-interpolation, which is a split-off of the interpolator code from plexus-utils. It can be found here: http://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-components/plexus-interpolation I've already refactored the trunk project builder to use plexus-interpolation, and the assembly plugin is using the pre-split code in plexus-utils, but will be updated to use plexus-interpolation once it's released to avoid inconsistencies with forced versions of plexus-utils from mavens past. In short, we have interpolation needs that go beyond the project builder, and need to handle other model class trees than maven-model. If we can use the same codebase to achieve this, it will help greatly in the consistency department. We already have an interpolator in maven-project, one in plexus-utils that has moved into plexus-interpolation, another in plexus-expression-evaluator (not used in maven, afaik), and now this one...hopefully we can find a way to consolidate some of this work and realign all of our efforts to some extent...and maybe refocus on consistency regardless of the model (or file) being interpolated.
          Hide
          John Casey added a comment -

          plugin configuration that uses $

          {project.build.outputDirectory}

          /foo will still fail in the current 2.0.10-RC codebase, since this will resolve to:

          $

          {project.build.directory}

          /classes/foo

          when delegated within the PathTranslatingValueSource. This translating value source will then attempt to align that value to the base directory, which is incorrect. Rather, the expression needs further recursion to resolve project.build.directory before attempting to align to the base directory.

          I'll have to look into why out current unit/integration tests don't test for this problem.

          Show
          John Casey added a comment - plugin configuration that uses $ {project.build.outputDirectory} /foo will still fail in the current 2.0.10-RC codebase, since this will resolve to: $ {project.build.directory} /classes/foo when delegated within the PathTranslatingValueSource. This translating value source will then attempt to align that value to the base directory, which is incorrect. Rather, the expression needs further recursion to resolve project.build.directory before attempting to align to the base directory. I'll have to look into why out current unit/integration tests don't test for this problem.
          Hide
          John Casey added a comment -

          Okay, I've improved the integration test to take this new scenario into account. I've also added the concept of a post-processor that has access to format/change a value after all interpolation has occurred recursively for an expression, then shifted the PathTranslatingValueSource to be a PathTranslatingPostProcessor.

          I've verified that this fixes the issue, and I'm going to release plexus-interpolation 1.1 so we can use it in 2.0.10-RC2. My maven changes for this new interpolator api should be committed soon.

          Show
          John Casey added a comment - Okay, I've improved the integration test to take this new scenario into account. I've also added the concept of a post-processor that has access to format/change a value after all interpolation has occurred recursively for an expression, then shifted the PathTranslatingValueSource to be a PathTranslatingPostProcessor. I've verified that this fixes the issue, and I'm going to release plexus-interpolation 1.1 so we can use it in 2.0.10-RC2. My maven changes for this new interpolator api should be committed soon.

            People

            • Assignee:
              John Casey
              Reporter:
              Sebastien Arbogast
            • Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: