maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarkko Rantavuori (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (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.
Date Sun, 03 Dec 2017 11:44:00 GMT

    [ https://issues.apache.org/jira/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275889#comment-16275889
] 

Jarkko Rantavuori commented on MASSEMBLY-360:
---------------------------------------------

Status of this bug indicates that this was already fixed in 2.2, when MetaInfSpringHandler
was added. You can still see the file in the code base: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/filter/
(However relevant test case is no longer there.)

However, it is not fixed. I forked an example project to demonstrate the issue:https://github.com/eis/assembly-plugin-spring-handler-testcase

You can see that the build in master, using shade plugin, works. The build in assembly-plugin
branch using assembly plugin does not: spring.handlers is not populated properly and application
fails on startup. Using latest assembly-plugin version, 3.1.0. I also tested with assembly-plugin
version 2.2, and it was never fixed there as well: issue is the same.

> 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://issues.apache.org/jira/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 was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message