[jira] Commented: (MASSEMBLY-185) When using different parent and aggregator poms, the assembly plugin does not package the ModuleSets of the aggregator modules

["Peter De Velder (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MASSEMBLY-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93131 ] 

Peter De Velder commented on MASSEMBLY-185:
-------------------------------------------

My current workaround to this problem is to include in the parentProj pom.xml an "assemble" profile, 

   ...
   <profiles>
      <profile>
         <id>assemble</id>
         <properties>
            <maven.test.skip>true</maven.test.skip>
         </properties>
         <modules>
            <module>../ChildProj1</module>
            <module>../ChildProj2</module>
         </modules>          
         <build>
           <plugins>
             <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                   <descriptors>
                      <descriptor>assemble/myassembly.xml</descriptor>
                    </descriptors>
                </configuration>
             </plugin>
            </plugins>
         </build>         
      </profile>
   </profiles>   
   ...

This makes sure the childproject-modules are explicitly called when creating a package using the assemble-profile,
and ONLY when creating the package:
   
   cd parentProj
   mvn -Passemble clean package assembly:assembly

   (or specified as an Eclipse m2eclipse external-tool, with 
      1. base directory: ${workspace_loc:/parentProj} 
      2. goal: clean install package assembly:assembly
      3. profile: assemble) 
   
The example project-directory structure is : 

   workspace
     +-- ChildProj1
     +-- ChildProj1
     +-- ParentProj
            +-- aggregProj
 
The aggregProj-pom is used for all other (non-assembly) maven goals: clean, install
(typically used in Eclipse m2eclipse external-tools, with base directory ${workspace_loc:/parentProj/aggregProj}) 

  <?xml version="1.0" encoding="UTF-8"?>
  <project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mastercard.admin</groupId>
    <artifactId>Aggregator</artifactId>
    <version>DONT-CARE</version>
    <packaging>pom</packaging>
    <name>Eclipse Aggregator</name>
    <description>Aggregator pom to be able to build all Eclipse projects at once</description>
    <modules>
      <module>../../ChildProj1</module>
      <module>../../ChildProj1</module>
    </modules>
  </project>

We are trying to learn here, and using a non-hierarchical Eclipse project structure. And using the same directory structure in Continuum.
Better ideas are certainly welcome!


> When using different parent and aggregator poms, the assembly plugin does not package the ModuleSets of the aggregator modules
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MASSEMBLY-185
>                 URL: http://jira.codehaus.org/browse/MASSEMBLY-185
>             Project: Maven 2.x Assembly Plugin
>          Issue Type: Bug
>    Affects Versions: 2.1
>            Reporter: Peter De Velder
>
> As mentioned on http://maven.apache.org/pom.html#Aggregation (see: A final note on Inheritance v. Aggregation), the aggregator project and parent project are conceptually not the same and can be split physically into 2 different projects. In the example below, the aggregProj just groups ChildProj1 and ChildProj2 in it's <modules> definition, while the ChildProj poms do NOT reference aggregProj, but they both refer to parentProj in their <parent>
> aggregProj
>   +-- ChildProj1  --> parentProj
>   +-- ChildProj2  --> parentProj
> mvn clean package assembly:assembly 
> in this case the ChildProj artifacts are not packaged, although they are referenced in the  <ModulesSets> of the aggregProj
> In other words if  the <artifactId> of aggregProj differs from the <artifactId> in the ChildProjX <parent> definitions, the packaging is incorrect.

-- 
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