Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The following integration tests are failing with the following messages

      Test Message
      anttasks-1\pom.xml startup failed, script1325740092621.groovy: 3: unexpected char: '\' @ line 3, column 51.
      execute\execute-props-3\pom.xml java.lang.NullPointerException
      at java.util.Hashtable.put(Hashtable.java:432)
      at java.util.Properties.setProperty(Properties.java:161)
      at org.apache.maven.project.ModelUtils.cloneProperties(ModelUtils.java:1264)
      at org.apache.maven.project.ModelUtils.cloneModelBaseFields(ModelUtils.java:318)
      at org.apache.maven.project.ModelUtils.cloneModel(ModelUtils.java:953)
      at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1855)
      at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteState(DefaultMavenProjectBuilder.java:1814)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.calculateConcreteState(DefaultLifecycleExecutor.java:795)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.calculateAllConcreteStates(DefaultLifecycleExecutor.java:783)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:587)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
      at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
      at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
      at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
      at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:601)
      at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
      at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
      at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
      at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      expansion-1\pom.xml startup failed, script1325740245800.groovy: 10: unexpected char: '\' @ line 10, column 44.

        Issue Links

          Activity

          Hide
          Keegan Witt added a comment -

          It's worth noting that these results are from Windows (with Java 1.7.0-b147). On Linux (with Java 1.6.0_26-b03), only execute-props-3 fails (with the same error, but different line numbers for the first 2 points because of JDK differences – see below).

          java.lang.NullPointerException
          at java.util.Hashtable.put(Hashtable.java:394)
          at java.util.Properties.setProperty(Properties.java:143)
          ...

          Show
          Keegan Witt added a comment - It's worth noting that these results are from Windows (with Java 1.7.0-b147). On Linux (with Java 1.6.0_26-b03), only execute-props-3 fails (with the same error, but different line numbers for the first 2 points because of JDK differences – see below). java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:394) at java.util.Properties.setProperty(Properties.java:143) ...
          Hide
          Keegan Witt added a comment -

          For the backslash issues: This is because the string attempted to be executed contains unescaped backslashes from Maven properties (e.g. $

          {project.build.directory}

          ) because on Windows, file separators are backslashes. I fixed this by escaping all backslashes. This does have the impact though that one shouldn't escape backslashes in the pom.xml, since that will be done before the script is executed. I didn't see any way to avoid this. I'm still trying to figure out where the NPE is occurring.

          Show
          Keegan Witt added a comment - For the backslash issues: This is because the string attempted to be executed contains unescaped backslashes from Maven properties (e.g. $ {project.build.directory} ) because on Windows, file separators are backslashes. I fixed this by escaping all backslashes. This does have the impact though that one shouldn't escape backslashes in the pom.xml, since that will be done before the script is executed. I didn't see any way to avoid this. I'm still trying to figure out where the NPE is occurring.
          Hide
          Keegan Witt added a comment -

          Also, to help me debug this, I changed the toString methods of the source and the context to provide more information. I committed this change as well.

          Show
          Keegan Witt added a comment - Also, to help me debug this, I changed the toString methods of the source and the context to provide more information. I committed this change as well.
          Hide
          Keegan Witt added a comment -

          Actually, my original strategy won't work. Paths that come from Maven can be UNC (e.g. \\ComputerName\SharedFolder\Resource), and users may have appended Unicode references or other Java escape codes that do not need escaped. The challenge is that by the time the mojo gets the source string, it is a mix of things that need escaped and things that don't need escaped. I've not come up with a strategy yet that would be able to diffrentiate between the two. If I'm right, this means that file references like the one in anttasks-1 and expansion-1 don't work on Windows unless I can find a way of escaping only the parts that need escaped.

          Show
          Keegan Witt added a comment - Actually, my original strategy won't work. Paths that come from Maven can be UNC (e.g. \\ComputerName\SharedFolder\Resource), and users may have appended Unicode references or other Java escape codes that do not need escaped. The challenge is that by the time the mojo gets the source string, it is a mix of things that need escaped and things that don't need escaped. I've not come up with a strategy yet that would be able to diffrentiate between the two. If I'm right, this means that file references like the one in anttasks-1 and expansion-1 don't work on Windows unless I can find a way of escaping only the parts that need escaped.
          Hide
          Keegan Witt added a comment -

          Proposed solution for backslash issue (already committed): require all backslashes input by users in execute sources to be escaped. Any that are not escaped will be assumed to be from Maven and will be escaped. Anything that is already escaped (from user) is unescaped before passing to executor.

          Show
          Keegan Witt added a comment - Proposed solution for backslash issue (already committed): require all backslashes input by users in execute sources to be escaped. Any that are not escaped will be assumed to be from Maven and will be escaped. Anything that is already escaped (from user) is unescaped before passing to executor.
          Hide
          Keegan Witt added a comment -

          I never did trace the cause of the two other issues, but I suspect they got fixed by the GMAVEN-100 fix.

          Show
          Keegan Witt added a comment - I never did trace the cause of the two other issues, but I suspect they got fixed by the GMAVEN-100 fix.
          Hide
          Jason Dillon added a comment -

          Not sure this is/was a valid/good fix. There are already some issues with maven interpolation vs. gstring interpolation, and it would have be generally better to avoid interpolation here to solve this problem instead of adding additional escaping behavior.

          Show
          Jason Dillon added a comment - Not sure this is/was a valid/good fix. There are already some issues with maven interpolation vs. gstring interpolation, and it would have be generally better to avoid interpolation here to solve this problem instead of adding additional escaping behavior.

            People

            • Assignee:
              Keegan Witt
              Reporter:
              Keegan Witt
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: