Maven 1
  1. Maven 1
  2. MAVEN-1161

goal mapper does not follow j:import tags

    Details

    • Number of attachments :
      1

      Description

      RC2 displays an error message for tag libraries that are imported and declared in maven.xml.

      RC1 does not.

      See zip file attachment for sample to reproduce the bug.

      Here is the output from running the sample with RC2 and then RC1.

      C:\Temp\mavenBug>maven showBug
      __ __

      \/ __ Apache_ ___
        \/ / ` \ V / -) ' \ ~ intelligent projects ~
      _   _,_ _/___ _ _ v. 1.0-rc2-SNAPSHOT

      Tag library requested that is not present: 'bug' in plugin: 'maven:maven'
      showBug:
      [echo] Hello World
      BUILD SUCCESSFUL
      Total time: 7 seconds
      Finished at: Thu Feb 12 15:45:47 EST 2004

      C:\Temp\mavenBug>mavenrc1 showBug
      __ __

      \/ __ Apache_ ___
        \/ / ` \ V / -) ' \ ~ intelligent projects ~
      _   _,_ _/___ _ _ v. 1.0-rc1-SNAPSHOT

      showBug:
      [echo] Hello World
      BUILD SUCCESSFUL
      Total time: 18 seconds
      Finished at: Thu Feb 12 15:46:17 EST 2004

        Issue Links

          Activity

          Hide
          dion gillard added a comment -

          Sample

          Show
          dion gillard added a comment - Sample
          Hide
          Brett Porter added a comment -

          this is only because it is using j:import - if it is in a plugin or in maven.xml itself it works fine.

          There's another bug around like this.

          Show
          Brett Porter added a comment - this is only because it is using j:import - if it is in a plugin or in maven.xml itself it works fine. There's another bug around like this.
          Hide
          Brett Porter added a comment -

          had to rollback change

          Show
          Brett Porter added a comment - had to rollback change
          Hide
          Brett Porter added a comment -

          this is problematic as uri may be an expression which cannot be evaluated at this point.

          Don't see this being fixed in maven1

          Show
          Brett Porter added a comment - this is problematic as uri may be an expression which cannot be evaluated at this point. Don't see this being fixed in maven1
          Hide
          dion gillard added a comment -

          Should we start a list of known issues for maven 1.0?

          Show
          dion gillard added a comment - Should we start a list of known issues for maven 1.0?
          Hide
          dion gillard added a comment -

          Would it be possible to just implement the case where the uri is not an expression and document the expression as a known limitation?

          Show
          dion gillard added a comment - Would it be possible to just implement the case where the uri is not an expression and document the expression as a known limitation?
          Hide
          Brett Porter added a comment -

          sure - but I don't see this happening a lot in the real world so its an edge case.

          Show
          Brett Porter added a comment - sure - but I don't see this happening a lot in the real world so its an edge case.
          Hide
          dion gillard added a comment -

          I'm fine with it being scheduled post 1.0

          Show
          dion gillard added a comment - I'm fine with it being scheduled post 1.0
          Hide
          Brett Porter added a comment -

          fixed again!

          Show
          Brett Porter added a comment - fixed again!
          Hide
          Anthony F. added a comment -

          Hi! With maven-1.0-rc1, I used to import a globally shared jelly script from my subprojects maven.xml file, using something like that:

          <project xmlns:j="jelly:core">
          <j:include file="$

          {myGlobalVariable}/mySubDirectory/mySharedScript.jelly" />
          </project>

          Now and since the 1.0-rc2, I use <j:import/> instead of <j:include/> tag but, as you explained, expressions are not parsed here. Gasp'. So, I've modified the maven-1.0-rc3-SNAPSHOT PluginScriptParser class and it fixes my problem, allowing me to use a global variable.


          I've added one static member:

          -><-----------------------------
          /** Maven Expression Factory. */
          private static MavenExpressionFactory mavenExpressionFactory = new MavenExpressionFactory();
          -><-----------------------------


          and inside the startElement(String, String, String, Attributes) method, I've replaced the three following comment lines:

          -><-----------------------------
          // We could evaluate this as an expression, but the only thing set at this point is ${basedir}
          // and some expressions will spit out exceptions (eg ${context.getVariable('blah')})
          // TODO: maybe sub in basedir, plugin.resources and plugin.dir?
          -><-----------------------------


          by:

          -><-----------------------------
          // Quick fix for evaluating simple expressions such as
          // <j:import file="${myGlobalVariable}

          /mySubDir/myScript.jelly"/>
          //
          // It will crash if you use some more complex objects in
          // your expression.
          try
          {
          MavenJellyContext context = jellyScriptHousing.getProject().getContext();

          if ( context != null )

          { log.debug( rawName + " try to evalutate uri attribute as an expression." ); Expression expr = JellyUtils.decomposeExpression( importUri, mavenExpressionFactory, context ); importUri = expr.evaluateAsString( context ); }

          }
          catch ( Exception e )

          { log.error( rawName + " can't evaluate uri attribute, bypassing." ); }

          -><-----------------------------

          I hope this may help, even if it doesn't support all cases.
          Bye bye, Thonio –

          Show
          Anthony F. added a comment - Hi! With maven-1.0-rc1, I used to import a globally shared jelly script from my subprojects maven.xml file, using something like that: <project xmlns:j="jelly:core"> <j:include file="$ {myGlobalVariable}/mySubDirectory/mySharedScript.jelly" /> </project> Now and since the 1.0-rc2, I use <j:import/> instead of <j:include/> tag but, as you explained, expressions are not parsed here. Gasp'. So, I've modified the maven-1.0-rc3-SNAPSHOT PluginScriptParser class and it fixes my problem, allowing me to use a global variable. I've added one static member: - >< ----------------------------- /** Maven Expression Factory. */ private static MavenExpressionFactory mavenExpressionFactory = new MavenExpressionFactory(); - >< ----------------------------- and inside the startElement(String, String, String, Attributes) method, I've replaced the three following comment lines: - >< ----------------------------- // We could evaluate this as an expression, but the only thing set at this point is ${basedir} // and some expressions will spit out exceptions (eg ${context.getVariable('blah')}) // TODO: maybe sub in basedir, plugin.resources and plugin.dir? - >< ----------------------------- by: - >< ----------------------------- // Quick fix for evaluating simple expressions such as // <j:import file="${myGlobalVariable} /mySubDir/myScript.jelly"/> // // It will crash if you use some more complex objects in // your expression. try { MavenJellyContext context = jellyScriptHousing.getProject().getContext(); if ( context != null ) { log.debug( rawName + " try to evalutate uri attribute as an expression." ); Expression expr = JellyUtils.decomposeExpression( importUri, mavenExpressionFactory, context ); importUri = expr.evaluateAsString( context ); } } catch ( Exception e ) { log.error( rawName + " can't evaluate uri attribute, bypassing." ); } - >< ----------------------------- I hope this may help, even if it doesn't support all cases. Bye bye, Thonio –
          Hide
          Brett Porter added a comment -

          "// It will crash if you use some more complex objects in your expression. "

          And this is exactly why this change won't be put into the parser

          Goals will still be used from the included script as long as you can convince Maven to use the plugin containing itself - use a dependency hook to do this.

          If this is in maven.xml, just ignore the warnings

          Show
          Brett Porter added a comment - "// It will crash if you use some more complex objects in your expression. " And this is exactly why this change won't be put into the parser Goals will still be used from the included script as long as you can convince Maven to use the plugin containing itself - use a dependency hook to do this. If this is in maven.xml, just ignore the warnings

            People

            • Assignee:
              Brett Porter
              Reporter:
              dion gillard
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: