[ 
http://jira.codehaus.org/browse/MNG-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203361#action_203361
 ] 

Jamie Townsend commented on MNG-1983:
-------------------------------------

I was able to successfully work around this issue by adding the extract below 
to the "different project" pom.xml.  We have 3 layers of Abstracts, hence 
copying the 3 files.  Of course these 3 files are in the svn:ignore list.

{code:xml} 
  <dependencies>
    <dependency>
      <groupId>com.progress.maven.plugins</groupId>
      <artifactId>maven-sonicesb-plugin</artifactId>
      <version>${maven-sonicesb-plugin.version}</version>
      <classifier>sources</classifier>
      <scope>provided</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
      <!-- this is a nasty hack to get around 
http://jira.codehaus.org/browse/MNG-1983
           Do NOT check the files listed below into Subversion for this project 
-->
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <id>unpack-dependencies</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>unpack-dependencies</goal>
            </goals>
            <configuration>
                <includeArtifactIds>maven-sonicesb-plugin</includeArtifactIds>
                <includeScope>provided</includeScope>
                <includeClassifiers>sources</includeClassifiers>
                
<includes>com/progress/maven/plugins/sonic/AbstractSonicMojo.java,com/progress/maven/plugins/sonic/esb/AbstractESBMojo.java,com/progress/maven/plugins/sonic/esb/AbstractESBConnectMojo.java</includes>
                <outputDirectory>src/main/java</outputDirectory>
                <overWrite>true</overWrite>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
{code}

> Mojo parameters defined in abstract-mojo class not set, when 
> concrete/abstract mojo class in different JARs
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-1983
>                 URL: http://jira.codehaus.org/browse/MNG-1983
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Plugins and Lifecycle
>    Affects Versions: 2.0.2
>         Environment: Maven-2.0.2 (also in Maven-2.0.1)
> Win-XP/Pro - Cygwin
> $ java -version
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
>            Reporter: Shash Chatterjee
>             Fix For: 3.x
>
>         Attachments: abstractmojotest.zip
>
>
> Have an abstract mojo class, which extends AbstractMojo.  This abstract class 
> defines some mojo parameters with expressions to set default values.
> Have a concrete class, in the same project (JAR) and package, which simply 
> extends the abstract mojo class.  This works fine, in that the parameter 
> values are initialized correctly.
> Have an identical concrete class, but this time in a different project which 
> defines a Maven dependency on the previous JAR.  This time the parameters 
> defined in the abstract class are not initialized correctly.  Whether this 
> second concrete mojo is in the same Java package as the abstract class, or 
> not, does not seem to make a difference.
> I have attached a ZIP file which demonstrates the problem.  Included are 
> three very simple Maven modules, all created with "mvn archetype:create".  
> The first project, "testplugin-one" contains an abstract and a concrete Mojo 
> class.  The second project, "testplugin-two" contains just a concrete Mojo 
> class.  The third project "testplugin-driver" contains a POM that invokes the 
> two mojos: the first time the parameters have values, the second time they 
> are null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to