Maven Assembly Plugin
  1. Maven Assembly Plugin
  2. 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.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2-beta-2
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP, Java 5
    • Number of attachments :
      0

      Description

      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.

        Activity

        Hide
        Renan Huanca added a comment -

        I have the same problem this is the code i used:

        ApplicationContext pathXmlApplicationContext = new ClassPathXmlApplicationContext("applicationContext.xml");

        I build a jar using the maven assembly plugin.

        When I try to execute de jar i get the following error:

        BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace http://www.springframework.org/schema/context

        I hope too, that is bug can be solved.

        Best regards.

        Show
        Renan Huanca added a comment - I have the same problem this is the code i used: ApplicationContext pathXmlApplicationContext = new ClassPathXmlApplicationContext("applicationContext.xml"); I build a jar using the maven assembly plugin. When I try to execute de jar i get the following error: BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace http://www.springframework.org/schema/context I hope too, that is bug can be solved. Best regards.
        Hide
        Simon Stemplinger added a comment -

        I'm also having the same isse. Any progress?

        Show
        Simon Stemplinger added a comment - I'm also having the same isse. Any progress?
        Hide
        Johan Walles added a comment -

        See also MASSEMBLY-209.

        Show
        Johan Walles added a comment - See also MASSEMBLY-209 .
        Hide
        Borys Marcelo Borches Herrera added a comment -

        I'm also having the same exception, it most likely to be an issue with TX or AOP parser than anything else. I've heard that adding the below MANIFEST entries should do the trick but nothing happened:

        <manifestEntries>
        <Class-Path>.</Class-Path>
        <Require-Bundle>org.springframework.bundle.spring,org.springframework.bundle.spring.aop,org.springframework.bundle.spring.beans,org.springframework.bundle.spring.context,org.springframework.bundle.spring.context.support,org.springframework.bundle.spring.core,org.springframework.bundle.spring.web,org.springframework.bundle.spring.webmvc
        </Require-Bundle>
        </manifestEntries>

        any thoughts? I'm trying to use Spring + JPA with Hibernate as the EntityManager provider.

        Show
        Borys Marcelo Borches Herrera added a comment - I'm also having the same exception, it most likely to be an issue with TX or AOP parser than anything else. I've heard that adding the below MANIFEST entries should do the trick but nothing happened: <manifestEntries> <Class-Path>.</Class-Path> <Require-Bundle>org.springframework.bundle.spring,org.springframework.bundle.spring.aop,org.springframework.bundle.spring.beans,org.springframework.bundle.spring.context,org.springframework.bundle.spring.context.support,org.springframework.bundle.spring.core,org.springframework.bundle.spring.web,org.springframework.bundle.spring.webmvc </Require-Bundle> </manifestEntries> any thoughts? I'm trying to use Spring + JPA with Hibernate as the EntityManager provider.
        Hide
        Chris Wilkes added a comment -

        While this doesn't fix the underlying problem it does get you started:

        Make a src/main/resources/META-INF/ directory
        explode the spring.jar (the large one) and put the spring.handlers and spring.schemas files from there into the above directory

        Now when your executable jar is built those two files will be the last ones copied over so they "win" and are included in the jar file.

        A better fix would be to make a plugin that gets those two files from all the spring-xxx.jars and concats them together.

        Show
        Chris Wilkes added a comment - While this doesn't fix the underlying problem it does get you started: Make a src/main/resources/META-INF/ directory explode the spring.jar (the large one) and put the spring.handlers and spring.schemas files from there into the above directory Now when your executable jar is built those two files will be the last ones copied over so they "win" and are included in the jar file. A better fix would be to make a plugin that gets those two files from all the spring-xxx.jars and concats them together.
        Hide
        john.sullivan added a comment -

        Chris Wilkes thanks for the comment! That fixed it for me!

        Show
        john.sullivan added a comment - Chris Wilkes thanks for the comment! That fixed it for me!
        Hide
        Benoit Xhenseval added a comment -

        Chris Wilkes... would you have a suggestion for this issue but with spring 3.0 M4?
        the 'big' jar no longer exists, I have found spring.handlers and sping.schemas in the org.framework.beans-3.0.0.M4.jar and followed your instructions...
        unfortunately, this does not seem to work with m2 2.2.1and an assembly like this:
        <descriptorRefs>
        <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>

        I get this:
        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
        Offending resource: class path resource [beans.xml]

        Using M2Eclipse works fine, I can run the application from within eclipse; if do a mvn assembly:assembly and then try to run the app, it fails on this beans.xml issue...
        Any suggestion?

        Show
        Benoit Xhenseval added a comment - Chris Wilkes... would you have a suggestion for this issue but with spring 3.0 M4? the 'big' jar no longer exists, I have found spring.handlers and sping.schemas in the org.framework.beans-3.0.0.M4.jar and followed your instructions... unfortunately, this does not seem to work with m2 2.2.1and an assembly like this: <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> I get this: 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 Offending resource: class path resource [beans.xml] Using M2Eclipse works fine, I can run the application from within eclipse; if do a mvn assembly:assembly and then try to run the app, it fails on this beans.xml issue... Any suggestion?
        Hide
        Keith Barlow added a comment -

        I have been using Chris Wilkes workaround for this issue for a while now without a problem until today. I happened to switch from the SpringSource Tool Suite 2.2.1 SR01 to Eclipse 3.5 SR01 at the end of last week and since doing so, the files from src/main/resources/META-INF do not seem to be the files getting placed in the jar-with-dependencies. I need to narrow down which spring.handlers and spring.schemas are being used but they are not the ones I defined. In fact, I can say that the versions in target/classes after the packaging is run are correct but the versions in the actual jar are not. Is there a way to fix this?

        I tried the following but the result was NO spring.handlers and spring.schemas files were in the resulting jar.:

        <dependencySets>
        <dependencySet>
        <unpack>true</unpack>
        <unpackOptions>
        <excludes>
        <exclude>**/spring.handlers</exclude>
        <exclude>**/spring.schemas</exclude>
        </excludes>
        </unpackOptions>
        <scope>runtime</scope>
        </dependencySet>
        </dependencySets>
        <fileSets>
        <fileSet>
        <directory>$

        {project.build.outputDirectory}

        </directory>
        <includes>
        <include>META-INF/spring.handlers</include>
        <include>META-INF/spring.schemas</include>
        </includes>
        </fileSet>
        </fileSets>

        Thanks.

        Keith

        Show
        Keith Barlow added a comment - I have been using Chris Wilkes workaround for this issue for a while now without a problem until today. I happened to switch from the SpringSource Tool Suite 2.2.1 SR01 to Eclipse 3.5 SR01 at the end of last week and since doing so, the files from src/main/resources/META-INF do not seem to be the files getting placed in the jar-with-dependencies. I need to narrow down which spring.handlers and spring.schemas are being used but they are not the ones I defined. In fact, I can say that the versions in target/classes after the packaging is run are correct but the versions in the actual jar are not. Is there a way to fix this? I tried the following but the result was NO spring.handlers and spring.schemas files were in the resulting jar.: <dependencySets> <dependencySet> <unpack>true</unpack> <unpackOptions> <excludes> <exclude>**/spring.handlers</exclude> <exclude>**/spring.schemas</exclude> </excludes> </unpackOptions> <scope>runtime</scope> </dependencySet> </dependencySets> <fileSets> <fileSet> <directory>$ {project.build.outputDirectory} </directory> <includes> <include>META-INF/spring.handlers</include> <include>META-INF/spring.schemas</include> </includes> </fileSet> </fileSets> Thanks. Keith
        Hide
        Andrew Phillips added a comment -

        @Keith: looks like we have a very similar set-up; the difference is that in our case the "merged" spring.handlers and spring.schemas files (see Chris Wilkes' comment above) are kept in src/main/resources/META-INF, i.e. not generated automatically during the build phase. That's not quite so nice, but since a project's Spring dependencies are generally unchanging it's not that much work to keep these files up to date manually. The assembly descriptor section is then simply:

        <dependencySets>
        <dependencySet>
        <unpack>true</unpack>
        <unpackOptions>
        <excludes>
        <exclude>META-INF/spring.handlers</exclude>
        <exclude>META-INF/spring.schemas</exclude>
        ...
        </excludes>
        </unpackOptions>
        </dependencySet>
        </dependencySets>

        and the spring.handlers and spring.schemas file from src/main/resources/META-INF is included automatically.

        Show
        Andrew Phillips added a comment - @Keith: looks like we have a very similar set-up; the difference is that in our case the "merged" spring.handlers and spring.schemas files (see Chris Wilkes' comment above) are kept in src/main/resources/META-INF, i.e. not generated automatically during the build phase. That's not quite so nice, but since a project's Spring dependencies are generally unchanging it's not that much work to keep these files up to date manually. The assembly descriptor section is then simply: <dependencySets> <dependencySet> <unpack>true</unpack> <unpackOptions> <excludes> <exclude>META-INF/spring.handlers</exclude> <exclude>META-INF/spring.schemas</exclude> ... </excludes> </unpackOptions> </dependencySet> </dependencySets> and the spring.handlers and spring.schemas file from src/main/resources/META-INF is included automatically.
        Hide
        Emilio Kazwell added a comment -

        @Andrew Phillip
        I'm using the jar-with-dependencies pre-defined assembly descriptor. Is there someway to add the code in your comment to the maven-assembly-plugin section of my pom, or do I actually need to find and extract the jar-with-dependencies descriptor and manually alter it for my build to include this exclusion?

        ...

        =/

        Thanks,

        -EK

        Show
        Emilio Kazwell added a comment - @Andrew Phillip I'm using the jar-with-dependencies pre-defined assembly descriptor. Is there someway to add the code in your comment to the maven-assembly-plugin section of my pom, or do I actually need to find and extract the jar-with-dependencies descriptor and manually alter it for my build to include this exclusion? ... =/ Thanks, -EK
        Hide
        Bob Miers added a comment -

        This is in response to the problem of having the error:
        Unable to locate Spring NamespaceHandler for XML schema namespace http://www.springframework.org/schema/tx
        I was getting this by running mvn assembly:assembly and then trying to run an executable jar file.
        I found a solution to this problem.
        1) Don't use mvn assembly:assembly. Instead use the Maven shade Plugin, which can accomplish the same thing.
        2) In your \src\main\resources\META-INF, create 2 files: spring.handlers & spring.schemas
        3) Go to your local maven repo, and then locate the org.springframework directory for the spring transaction package.
        On Windows 7 this would be:
        C:\Users\bsmith\.m2\repository\org\springframework\spring-tx\3.0.2.RELEASE\spring-tx-3.0.2.RELEASE.jar
        [If you had a difference namespace error such as context, then go to the spring-context directory.
        4) Open up the spring-tx-3.0.2.RELEASE.jar file, and then append your
        \src\main\resources\META-INF\spring.handlers file with the data found in the jar file.
        4B) Do the exact same thing for the spring.schemas file
        5) Setup your pom.xml file as described by the maven-shade-plugin documentation.
        All you have to do is add in the <plugin>...</plugin>
        6) run: mvn package
        7) again try: java -jar theprogram-1.0-SNAPSHOT.jar
        8) If you get another namespace error, again APPEND your \src\main\resources\META-INF\spring.handlers
        and spring.schemas file with the appropriate spring jar file.

        Show
        Bob Miers added a comment - This is in response to the problem of having the error: Unable to locate Spring NamespaceHandler for XML schema namespace http://www.springframework.org/schema/tx I was getting this by running mvn assembly:assembly and then trying to run an executable jar file. I found a solution to this problem. 1) Don't use mvn assembly:assembly. Instead use the Maven shade Plugin, which can accomplish the same thing. 2) In your \src\main\resources\META-INF, create 2 files: spring.handlers & spring.schemas 3) Go to your local maven repo, and then locate the org.springframework directory for the spring transaction package. On Windows 7 this would be: C:\Users\bsmith\.m2\repository\org\springframework\spring-tx\3.0.2.RELEASE\spring-tx-3.0.2.RELEASE.jar [If you had a difference namespace error such as context, then go to the spring-context directory. 4) Open up the spring-tx-3.0.2.RELEASE.jar file, and then append your \src\main\resources\META-INF\spring.handlers file with the data found in the jar file. 4B) Do the exact same thing for the spring.schemas file 5) Setup your pom.xml file as described by the maven-shade-plugin documentation. All you have to do is add in the <plugin>...</plugin> 6) run: mvn package 7) again try: java -jar theprogram-1.0-SNAPSHOT.jar 8) If you get another namespace error, again APPEND your \src\main\resources\META-INF\spring.handlers and spring.schemas file with the appropriate spring jar file.
        Hide
        Theo Platt added a comment -

        Thanks to Bob Mier I could (temporarily) solve a similar problem with Spring Batch.

        Similar set of circumstance except I was using maven to build an rpm. Everything works fine testing my Spring Batch project in Eclipse, but running the job on Linux after the rpm had been installed and I get the error.

        "Unable to locate Spring NamespaceHandler for XML schema namespace http://www.springframework.org/schema/batch"

        Following Bob's solution all I had to do was add my own spring.handlers and spring.schemas into my META-INF and copy the contents of both from both the Spring Core and Spring Batch jars.

        However - issue still gets my vote !

        Show
        Theo Platt added a comment - Thanks to Bob Mier I could (temporarily) solve a similar problem with Spring Batch. Similar set of circumstance except I was using maven to build an rpm. Everything works fine testing my Spring Batch project in Eclipse, but running the job on Linux after the rpm had been installed and I get the error. "Unable to locate Spring NamespaceHandler for XML schema namespace http://www.springframework.org/schema/batch " Following Bob's solution all I had to do was add my own spring.handlers and spring.schemas into my META-INF and copy the contents of both from both the Spring Core and Spring Batch jars. However - issue still gets my vote !
        Hide
        Faisal Feroz added a comment -

        Maven shade plugin (http://maven.apache.org/plugins/maven-shade-plugin/) is a better choice for these kind of issues. It has various transformers which can handle these situations easily.

        Show
        Faisal Feroz added a comment - Maven shade plugin ( http://maven.apache.org/plugins/maven-shade-plugin/ ) is a better choice for these kind of issues. It has various transformers which can handle these situations easily.
        Hide
        John Casey added a comment -

        add the container descriptor handler 'metaInf-spring' to consolidate these files.

        Show
        John Casey added a comment - add the container descriptor handler 'metaInf-spring' to consolidate these files.
        Hide
        Suresh Narasimhan added a comment -

        I am trying to use the beta 6 version which fixes this. But get this error

        org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException
        role: org.apache.maven.artifact.resolver.ArtifactResolver
        roleHint: project-cache-aware
        at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:238)
        at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:214)
        at org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
        at org.codehaus.plexus.PlexusLifecycleManager.contextualize(PlexusLi

        Show
        Suresh Narasimhan added a comment - I am trying to use the beta 6 version which fixes this. But get this error org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.artifact.resolver.ArtifactResolver roleHint: project-cache-aware at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:238) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:214) at org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721) at org.codehaus.plexus.PlexusLifecycleManager.contextualize(PlexusLi
        Hide
        gonfi den tschal added a comment -

        bob miers referred to http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html

        so his sentence: "All you have to do is add in the <plugin>...</plugin>" meant to do the part titled "Merging Content of Specific Files".

        i ended up with such a configuration in the shade plugin:

        <configuration>
        <transformers>
        <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
        <mainClass>org.mypackage.MyMainClass</mainClass>
        </transformer>
        <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
        <resource>META-INF/spring.handlers</resource>
        </transformer>
        <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
        <resource>META-INF/spring.schemas</resource>
        </transformer>
        </transformers>
        </configuration>

        thanks for the solution.

        Show
        gonfi den tschal added a comment - bob miers referred to http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html so his sentence: "All you have to do is add in the <plugin>...</plugin>" meant to do the part titled "Merging Content of Specific Files". i ended up with such a configuration in the shade plugin: <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>org.mypackage.MyMainClass</mainClass> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.handlers</resource> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.schemas</resource> </transformer> </transformers> </configuration> thanks for the solution.
        Hide
        John Casey added a comment -

        @Suresh - Unfortunately that error is bogus. It's something that slipped through in a maven-repository-builder release (used by the assembly plugin), and that component hasn't been re-released since.

        It's not going to affect your build at all; you can safely ignore it.

        Show
        John Casey added a comment - @Suresh - Unfortunately that error is bogus. It's something that slipped through in a maven-repository-builder release (used by the assembly plugin), and that component hasn't been re-released since. It's not going to affect your build at all; you can safely ignore it.
        Hide
        Bernhard Grünewaldt added a comment -

        This Error still appears for me.

        When Using Spring 3.x and using the following Schemas:

        <beans xmlns="http://www.springframework.org/schema/beans"
        	xmlns:aop="http://www.springframework.org/schema/aop"
        	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        	xsi:schemaLocation="http://www.springframework.org/schema/beans
        						http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        						http://www.springframework.org/schema/aop
        						http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">
        

        I used maven-assembly plugin together with maven 2.x

        I "solved" ist by using the OneJar Plugin.
        http://one-jar.sourceforge.net/

        I tried all the hints about manually merging the context and schema files but nothing helped.
        Is there a Version of the Assembly Plugin which can deal with this issue by itself?

        I really want to go back using the assembly plugin.

        Show
        Bernhard Grünewaldt added a comment - This Error still appears for me. When Using Spring 3.x and using the following Schemas: <beans xmlns= "http: //www.springframework.org/schema/beans" xmlns:aop= "http: //www.springframework.org/schema/aop" xmlns:xsi= "http: //www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http: //www.springframework.org/schema/beans http: //www.springframework.org/schema/beans/spring-beans-3.0.xsd http: //www.springframework.org/schema/aop http: //www.springframework.org/schema/aop/spring-aop-3.0.xsd"> I used maven-assembly plugin together with maven 2.x I "solved" ist by using the OneJar Plugin. http://one-jar.sourceforge.net/ I tried all the hints about manually merging the context and schema files but nothing helped. Is there a Version of the Assembly Plugin which can deal with this issue by itself? I really want to go back using the assembly plugin.
        Hide
        Steven Swor added a comment -

        I still have this issue with Spring 3.1.1-RELEASE and maven-assembly-plugin 2.3 in Maven 3.0.3. I went with Bernhard's solution because it did not require me to add any additional files to my project as a workaround.

        Show
        Steven Swor added a comment - I still have this issue with Spring 3.1.1-RELEASE and maven-assembly-plugin 2.3 in Maven 3.0.3. I went with Bernhard's solution because it did not require me to add any additional files to my project as a workaround.
        Show
        Robert Scholte added a comment - - edited The maven-shade-plugin supports this. http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#Merging_Content_of_Specific_Files_with_AppendingTransformer_and_XmlAppendingTransformer
        Hide
        Viktor Podzigun added a comment -

        This also can be solved by using two other plugins instead:

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

        The idea is that dependencies are not unpacked, but put into the internal lib classpath directory inside the final jar.

        Show
        Viktor Podzigun added a comment - This also can be solved by using two other plugins instead: <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> The idea is that dependencies are not unpacked, but put into the internal lib classpath directory inside the final jar.

          People

          • Assignee:
            John Casey
            Reporter:
            Marielle Enderman
          • Votes:
            22 Vote for this issue
            Watchers:
            27 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: