Well, all I can say is that I was doing approximately as you have
described and it didn't really work.
I was using assembly:assembly (single for some reason failed to bring in
everything needed - perhaps the mistake was mine), I also used a
separate uber-project to do nothing but the assembly. But I noticed,
once I started actually doing the JUnit tests during the build run that
they were being run twice, first as the dependent jars were being built
and then again in the assembly run. These were described as modules.
Dissatisfaction with that led me down the path of
<useAllReactorProjects> - which I didn't even understand - and this was
a total failure.
All I frickin wanted to do was package up stuff that had already been
built. I didn't want to think about module sets, dependency sets, any
of that nonsense at that point. Everything on the java side had been
built with that carefully thought through. At this point, all I wanted
was something that let me think of them as filesets to be combined into
an archive. This appassembler plugin let me do that. Whatever they are
doing is much cleaner than what the assembler plugin does.
This is even simpler than your approach: I am able to dispense with the
extra project just for the assembly and move it into the project that
builds the jar with the main() class. A single maven command does it
all from scratch:
clean install package appassembler:assemble assembly:single
Now it very well may be that there is a way to do the same thing with
the assembly plugin alone. But the documentation and the examples for
that plugin do not explain that way for me. Instead I get dragged into
discussions of "Reactors" and all sorts of things that I shouldn't need
to understand (and don't), just to perform my simple aggregation task.
So I think the Codehaus appassembler folks are onto something here and
the maven assembly folks might want to look at it and figure out a
SIMPLE way to handle this scenario without it. Alternatively, the
appassembler folks could add packaging to their plugin and there'd be no
need of the assembly plugin.
Or, maybe it's better that there are two projects, each with its own
aims. That's the unix small-tools approach. But that was supposed to
be what the assembler plugin was about and in this instance it falls
short of the mark.
On 12/30/2010 09:31 PM, Benson Margulies wrote:
I do this all the time.
I use assembly:single.
I run it from a project that has pretty much nothing else in it except
the assembly run.
For shared config files and such, I package them up as zip files, push
them to nexus, and stage them with dependency:unpack.
For jar file dependencies that can't be called out in the
dependencySet, I use dependency:copy to stage them and then, again,
pick them up as part of a fileSet.
I've even managed to share the assembly descriptors by using the 'grab
them from an artifact' business.
On Thu, Dec 30, 2010 at 10:02 PM, Steve Cohen<[email protected]> wrote:
Now that was good, but the question is why can't something like that be
available through the assembly plugin itself?
Build the main jar and its dependencies, install the non-third party jars
into the local repository, then pull them back out into an assembly staging
area, together with third party deps, along with any config files (all of
which is done easily by the appassembler plugin), then bundle the whole mess
into whatever kind of archive you choose.
This could be a mode of the assembly plugin, but it isn't. Call it a
feature request. It would be worthwhile to combine these two
functionalities.
On 12/30/2010 06:00 PM, Steve Cohen wrote:
BINGO!!!!!
Thanks so much, Dennis for pointing me in the RIGHT direction!!
This is simple, just what I wanted.
The last piece of the puzzle was the need to use the flat
<repositoryLayout>
Just what I wanted in under 2 hours, as opposed to two days fighting
with the complexities of the assembler plugin!
Happy New Year, to all who helped me here!! You're the best!
Steve
On 12/30/2010 05:41 PM, Dennis Lundberg wrote:
On 2010-12-31 00:08, Steve Cohen wrote:
I think this is going to work.
I absolutely don't need any of the shellscript generation (it would be
nice to be able to turn it off) but I can ignore that. The creation of
the repository inside the target is slick, and I assume I can use that
to suck all the jars into the assembly plugin.
Yep, here's the assembly descriptor I use:
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
<id>dist</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>target/appassembler</directory>
<outputDirectory></outputDirectory>
<excludes>
<exclude>lib/maven-metadata-appassembler.xml</exclude>
<exclude>lib/${project.artifactId}-${project.version}-site.xml</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>
and the relevant parts of the POM:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>1.0</version>
<configuration>
<programs>
<program>
<mainClass>my.class.name</mainClass>
<name>MyProgram</name>
</program>
</programs>
<repositoryLayout>flat</repositoryLayout>
<repositoryName>lib</repositoryName>
</configuration>
<executions>
<execution>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Must come after appassembler-maven-plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>src/main/assembly/assembly.xml</descriptor>
</descriptors>
<tarLongFileMode>gnu</tarLongFileMode>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
On 12/30/2010 04:23 PM, Steve Cohen wrote:
Thanks again, Dennis. I've now read the documentation more carefully
and
this doesn't look as though it does any actual packaging into an
archive
(be it zip, jar, tar, etc.) It seems to be ALL about the launch script
and might have been the way to go before I developed all this by hand
with commons-daemon and NOT AT ALL about the actual packaging.
Is the idea then to assemble everything in a directory and THEN pass
this as a fileSet to the assembly plugin?
Or am I missing something?
On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
Hi Steve
May I suggest that you have a look at the Appassembler Maven Plugin
for
your batch processing application.
http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/usage-program.html
On 2010-12-30 21:16, Steve Cohen wrote:
After a very frustrating couple of days trying to understand the new
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
