You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Viktor Podzigun (JIRA)" <ji...@codehaus.org> on 2013/09/19 09:39:53 UTC
[jira] (MASSEMBLY-360) When using mulitple Spring dependencies, the
files from META-INF (from the Spring jars) overwrite each other in an
executable jar-with-dependencies.
[ https://jira.codehaus.org/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332990#comment-332990 ]
Viktor Podzigun commented on MASSEMBLY-360:
-------------------------------------------
This also can be solved by using two other plugins instead:
{code:xml}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<archive>
<manifest>
<mainClass>your.main.Class</mainClass>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
{code}
The idea is that dependencies are not unpacked, but put into the internal *lib* classpath directory inside the final jar.
> When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-360
> URL: https://jira.codehaus.org/browse/MASSEMBLY-360
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-2
> Environment: Windows XP, Java 5
> Reporter: Marielle Enderman
> Assignee: John Casey
> Fix For: 2.2
>
>
> I'm working on a Java 5 project with maven 2 and I need to deliver an executable jar file. In this project I'm using different Spring dependencies:
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-beans</artifactId>
> <version>2.5.5</version>
> </dependency>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-context</artifactId>
> <version>2.5.5</version>
> </dependency>
> For maven packaging I'm using the maven-assembly plugin to create an executable jar with dependencies (using the jar-with-dependencies descriptor). Everything works fine, except that Spring's XSD files can't be found. At least: not all of them. The fact is: Every Spring JAR file contains a META-INF directory with files like spring.handlers and spring.schemas which contain list of locations of respectively namespace handlers and schemas. Unfortunately these files aren't merged during packaging so the META_INF of the executable JAR file only contains the last one added.
> This can result in errors like this:
> Example 1: The spring-context-2.5.xsd can't be found:
> WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored XML validation warning org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
> Example 2: The NamespaceHandler for the spring context namespace can't be located:
> Exception in thread "main" org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context]
> When I manually merge the files, the executable JAR file works fine.
> I hope this problem can be solved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira