Generate an xml file with all dependencies with ma

问题:

I need to generate module.xml file for JBoss7 for a maven project which has a lot of jar-dependencies. What is the easiest way to do it? The file looks like:

<module xmlns="urn:jboss:module:1.0" name="ats.platform">
  <resources>
    <resource-root path="dom4j-1.6.1.jar"/>
    <resource-root path="jdom-1.0.jar"/>
...
  </resources>
</module>

so that the <resource-root> element should be created for each project jar-dependency.

Or maybe I doing something wrong? What's correct way to create a JBoss7 module from a maven project?

回答1:

I don't really know about JBoss and whether there's another way to do this, but you can do it quite simply with GMaven:

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.3</version>
    <configuration>
        <source>
            def sw = new StringWriter()
            def xml = new groovy.xml.MarkupBuilder(sw)
            xml.module(xmlns:'urn:jboss:module:1.0', name:'ats.platform') {
              resources {
                project.runtimeClasspathElements.each {
                  def path = it.find(".*?([\\w\\.-]*\\.jar)") { it[1] }
                  !path?:'resource-root'(path:path)
                }
              }
            }
            println sw
        </source>
    </configuration>
</plugin>

A couple of things to note:

1. That script spits the XML out to stdout, but you can obviously write it to a file or whatever very easily.
2. The runtimeClasspathElements contain absolute paths to the jar, which is why I parse it with a regex. You can adjust the regex to include more of the path or just prepend a string if you need more than just the jar file name.

I've posted a working example on github (it's just a POM) where I've bound the above plugin configuration to the initialize build phase. If you have git, you can clone and run it yourself with:

git clone git://github.com/zzantozz/testbed tmp
cd tmp
mvn -q initialize -pl stackoverflow/7755255-gmaven-to-build-xml-from-classpath

In the sample project, I added jdom 1.0 and dom4j 1.6.1 as dependencies, and here's the output it created:

<module xmlns='urn:jboss:module:1.0' name='ats.platform'>
  <resources>
    <resource-root path='jdom-1.0.jar' />
    <resource-root path='dom4j-1.6.1.jar' />
    <resource-root path='xml-apis-1.0.b2.jar' />
    <resource-root path='aspectjrt-1.6.11.jar' />
  </resources>
</module>

Note: I'm not a groovy expert, so there may be a groovier way to do it, but you can see how easy it is even so.

回答2:

You could try smartics-jboss-modules-maven-plugin

It provides quite powerful dependency control:

• exclusions and inclusions (also with wildcards) of project deps,
• definition of deps to other JBoss modules,
• transitive dependencies handling
• and lot more

With proper descriptor, generated module is ready to be copied 'as is' to JBoss 7.

Example jboss-modules/foo.bar.foo-module.xml:

<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="foo.bar.foo-module">
    <match>
        <includes>
            <include>
                <groupId>foo.*</groupId>
            </include>
            <include>
                <groupId>org.*</groupId>
            </include>
        </includes>
        <excludes>
            <exclude>org.slf4j.slf4j-api</exclude>
        </excludes>
    </match>

    <apply-to-module>
        <dependencies>
            <module name="org.slf4j" />
        </dependencies>
    </apply-to-module>
</module>

Also set excludeDependencyManagementDependenciesInPomProject to true in smartic plugin configuration to avoid including 50 MB of deps :)

回答3:

This can be easily solved in a few steps.

1. run mvn dependency:list -DoutputFile=dep.list -DoutputAbsoluteArtifactFilename=true in your shell

   you will receive a file like this:

   The following files have been resolved:
       ch.qos.logback:logback-classic:jar:0.9.30:test:C:\Dokumente und Einstellungen\michael-o.m2\repository\ch\qos\logback\logback-classic\0.9.30\logback-classic-0.9.30.jar
       ch.qos.logback:logback-core:jar:0.9.30:test:C:\Dokumente und Einstellungen\michael-o.m2\repository\ch\qos\logback\logback-core\0.9.30\logback-core-0.9.30.jar
       classworlds:classworlds:jar:1.1-alpha-2:compile:C:\Dokumente und Einstellungen\michael-o.m2\repository\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar
   

   The important information is indented by 4 spaces in the file.

2. Now grep out the important information and do not forget to limit to compile and runtime scope.

3. split columns with cut -d ':' -f <colNum> and get the last column.
4. Get the filename after the last (back)slash.
5. Now build an XML file with the information.

Every can be packed in a nice shell script.

See the maven-dependency-plugin for reference.

A quick command looks like this: cat dep.list | grep -E ':(compile|runtime):' | cut -d ':' -f 7 | sed -e 's/\///g' | xargs -I {} basename '{}' | xargs -I {} echo "<resource-root path=\"{}\" />"

The output contains the jar files names:

<resource-root path="classworlds-1.1-alpha-2.jar" />
<resource-root path="jsr305-1.3.9.jar" />
<resource-root path="guava-10.0.1.jar" />
<resource-root path="commons-codec-1.3.jar" />
<resource-root path="commons-io-2.0.1.jar" />
<resource-root path="commons-lang-2.6.jar" />
<resource-root path="junit-4.9.jar" />

Now wrap with XML header and footer, and you are done!

回答4:

Although this question is quite old and already has a valid answer, I'd like to mention another alternative.

As we started with JBoss modules we wrote a small plugin for Maven that generates module folders with module.xmls based on XML descriptors. The plugin is called smartics-jboss-modules-maven-plugin and you'll find additional information about it at the project's blog.

We just started to work with it, but it already makes the process of synchronization between the POM and the module.xml (plus directory structure) for our projects very easy.

The downside of this approach is that you have to learn an additional XML descriptor and have to configure an additional Maven plugin. So for small projects you may be better off following the solutions of the answers above.

If you want to give it a try, the plugin is licensed under Apache License 2.0.