maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kek (JIRA)" <j...@codehaus.org>
Subject [jira] Closed: (MASSEMBLY-467) Sharing assembly descriptor across sub modules does not work if invoked from parent project - bad resolve of the classpath
Date Mon, 01 Feb 2010 09:53:55 GMT

     [ http://jira.codehaus.org/browse/MASSEMBLY-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kek closed MASSEMBLY-467.
-------------------------

       Resolution: Cannot Reproduce
    Fix Version/s: 2.2-beta-6

The problem is on other place, so I close this bug and create new one with right problem description
and some project for simulation.

> Sharing assembly descriptor across sub modules does not work if invoked from parent project
- bad resolve of the classpath
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MASSEMBLY-467
>                 URL: http://jira.codehaus.org/browse/MASSEMBLY-467
>             Project: Maven 2.x Assembly Plugin
>          Issue Type: Bug
>    Affects Versions: 2.2-beta-5
>         Environment: Winfows7, Maven 2.2.1, Sun JDK1.6.0_u18
>            Reporter: Kek
>             Fix For: 2.2-beta-6
>
>         Attachments: build-log.txt
>
>
> My problem is similar to http://jira.codehaus.org/browse/MASSEMBLY-391, but in my opinion
it is BUG, not request for new feature.
> I have project structure like:
> module
>   submodule-1
>   submodule-2
>   my-assembly-descriptor-submodule
> The submodule-1 and submodule-2 use the shared my-assembly-descriptor-submodule to produce
attached zip-artifact with configuration files.
> The creation of the zip-artifact is defined on parent module by use of assembly plugin.

> <plugin>
>         <artifactId>maven-assembly-plugin</artifactId>
>         <version>2.2-beta-5</version>
>         <dependencies>
>           <dependency>
>             <groupId>org.mymodule</groupId>
>             <artifactId>my-assembly-descriptor-submodule</artifactId>
>             <version>${project.version}</version>
>           </dependency>
>         </dependencies>
>         <executions>
>           <execution>
>             <id>zip-config</id>
>             <phase>package</phase>
>             <goals>
>               <goal>single</goal>
>             </goals>
>             <configuration>
>               <descriptors>
>                 <descriptor>config-assembly.xml</descriptor>
>               </descriptors>
>             </configuration>
>           </execution>
>         </executions>
>       </plugin>
> Everything works fine, when I install the shared assembly-descriptor to local repository
and run the "mvn clean package" separately in submodule-1 and submodule-2.
> But when I try to run the same command in parent module, than the build fails - the 
config-assembly.xml is not found on classpath.
> [INFO] Error reading assemblies: Error locating assembly descriptor: config-assembly.xml
> [1] [INFO] Searching for file location: D:\mymodule\submodule-1\config-assembly.xml
> [2] [INFO] File: D:\mymodule\submodule-1\config-assembly.xml does not exist.
> [3] [INFO] Invalid artifact specification: 'config-assembly.xml'. Must contain at least
three fields, separated by ':'.
> [4] [INFO] Failed to resolve classpath resource: assemblies/config-assembly.xml from
classloader: org.codehaus.classworlds.RealmClassLoader@11a75a2
> [5] [INFO] Failed to resolve classpath resource: config-assembly.xml from classloader:
org.codehaus.classworlds.RealmClassLoader@11a75a2
> [6] [INFO] File: D:\mymodule\config-assembly.xml does not exist.
> [7] [INFO] Building URL from location: config-assembly.xml
> Error:
> java.net.MalformedURLException: no protocol: config-assembly.xml
> 	at java.net.URL.<init>(URL.java:567)
> 	at java.net.URL.<init>(URL.java:464)
> 	at java.net.URL.<init>(URL.java:413)
> 	at org.apache.maven.shared.io.location.URLLocatorStrategy.resolve(URLLocatorStrategy.java:54)
> 	at org.apache.maven.shared.io.location.Locator.resolve(Locator.java:81)
> 	at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyFromDescriptor(DefaultAssemblyReader.java:309)
> 	at org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:140)
> 	at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:352)
> 	at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> 	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> 	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:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	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)
> The workaround exists:
> 1) install/deploy the shared descriptor in isolated build
> 2) remove <module>my-assembly-descriptor-submodule</module> from parent module
to avoid build of this submodule in the same build-cycle as submodules that need it.
> 3) than the my-assembly-descriptor-submodule will be always resolved from repository
and the problem doesn't occurre.
> But you can not all-in-one build.

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

        

Mime
View raw message