You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Kek (JIRA)" <ji...@codehaus.org> on 2010/02/01 10:53:55 UTC
[jira] Closed: (MASSEMBLY-467) Sharing assembly descriptor across
sub modules does not work if invoked from parent project - bad resolve of
the classpath
[ 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