Eric, I have the eXACT same project. My command line tool needs a couple of
runtime dependencies.
Let me show how I organize a project which works for me beautifully (maybe
this will help):
<dependencies>
<dependency>
<groupId>acme-depedency-1</groupId>
<artifactId>acme-dpendency-1</artifactId>
<version>acme-dependency-1</version>
</dependency>
..
..
..
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<groupId>org.apache.maven.plugins</groupId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.0-beta-1</version>
<configuration>
<descriptor>src/main/assembly/acme-assembly.xml</descriptor>
<outputDirectory>target</outputDirectory>
<workDirectory>target/assembly/work</workDirectory>
<finalName>Acme</finalName>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.acme.main.class</mainClass>
</manifest>
</archive>
<jarName>acme.jar</jarName>
</configuration>
</plugin>
</plugins>
</build>
That creates the JAR file that I need to put in my application zip file to
distribute. It also adds the runtime dependencies to my manifest.
Then in my acme-assembly.xml:
<assembly>
<id>1.0</id>
<formats>
<format>tar.gz</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>target</directory>
<outputDirectory></outputDirectory>
<includes>
<include>*.jar</include>
</includes>
</fileSet>
<fileSet>
<outputDirectory></outputDirectory>
<directory>dist</directory>
<includes>
<include>*</include>
</includes>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>/</outputDirectory>
<unpack>false</unpack>
<scope>runtime</scope>
</dependencySet>
</dependencySets>
</assembly>
The dependencySets tag adds the runtime libraries to the root of my
tar.gzfile so when someone deploys it in a install directory, the
classpath
manifest entry is relative to the current path and everything just works.
When I do mvn package, I get a Acme-1.0.tar.gz with a acme.jar in it a long
with all of its runtime dependencies. I ALSO in "dist" have a bunch of
other static files (think license, README, etc.) that gets picked up as
well.
Not sure if this is the absolute best way or only way, but this works for me
every time no hassles!
Let me know,
-aps
On 12/4/06, Eric Wang <[EMAIL PROTECTED]> wrote:
Does your jar have any dependencies? If not, then your case is a
little bit different from mine.
My (maybe not so simple) command line application depends on two jars.
If I just run "mvn package" I get a jar in the target directory like
you. However that jar doesn't include my application's two
dependencies. I have to distribute them separately in order to run my
application.
The assembly plugin's jar-with-dependencies descriptor seems designed
to solve this problem by generating a self-contained jar containing
all dependencies. I want to leverage this to generate a self-contained
jar, and then zip that jar up along with various support files
(readme, etc.).
The approach I'm trying right now is to use the provided
jar-with-dependencies descriptor along a custom descriptor. My pom
looks something like this:
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<descriptors>
<descriptor>my-custom-descriptor.xml</descriptor>
</descriptors>
</configuration>
My custom descriptor is similar to yours. The problem is when I enter
"mvn assembly:assembly" my custom descriptor is always processed
first, before the jar-with-dependencies descriptor. Naturally, the
self-contained jar doesn't exist yet, and I end up with a zip file
full of support files, but no jar.
In a sense, my custom descriptor depends on the jar-with-dependencies
descriptor being run first, but I have no idea how to express this. I
will look into creating multiple modules to see if it will solve my
problem, however it seems somewhat overkill for my application.
Thanks for your help Alexander.
On 12/4/06, Alexander Sack <[EMAIL PROTECTED]> wrote:
> I won't speak for best practices but typically you would create another
> module to do the packaging (similar to some of the EAR examples).
>
> For a simple command-line application, my guess is one pom and one
assembly
> descriptor will be enough. For my command-line tool I generate the jar
and
> then assemble the whole applicaiton like so:
>
> snippet from my assembly descriptor XML file:
>
> <fileSets>
> <fileSet>
> <directory>target</directory>
> <outputDirectory></outputDirectory>
> <includes>
> <include>*.jar</include>
> </includes>
> </fileSet>
> <fileSet>
> <outputDirectory></outputDirectory>
> <directory>dist</directory>
> <includes>
> <include>*</include>
> </includes>
> </fileSet>
> </fileSets>
>
> Basically dist has some extra static files in it, target is where the
JAR
> gets built, and then the assembly plugin builds everything together.
>
>
> -aps
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
