Yes, you are basically right. You can't get away from the need of the
aggregator project. And the dual testing was caused by specifying too
many phases on the command line.
I was overly exuberant in my earlier praise of appassembler. It
appeared to do what I want, but the way I had it set up, it was getting
the dependency modules from my local repository (put there by a previous
build), not building them, as was my intention. For that, it was
necessary to specify them as modules in the aggregator project. And
then by binding them to a phase in an <execution> element, I was able to
avoid the command line specification. Live and learn.
I still like appassembler and how it just pulls all the dependencies
into its "repository".
The way I have it set up now, and it's working as I want, appassembler
is bound to the package phase of the main project, aggregating all stuff
needed in the ultimate zip file in target/appassembler of the main project.
The aggregator project using the assembly plugin then pulls these as
filesets from this location.
There may be (and probably is, I would guess) a way to do this using
only the assembly plugin and not appassembler. But the documentation is
somewhat lacking in explaining all the confusing options that are available.
Just one example:
In the assembly descriptor document, it is possible to place a
<dependencySets> element at the root level of the descriptor OR within
the <moduleSets><moduleSet><binaries> element of the root level. And
the difference is not explained at all on
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
Using the appassembler plugin as I have done, this is all quite clear.
And it spares me the need of specifying dependencies of the aggregator
project as described here:
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
So to sum up:
I prepare the staging directory in the package phase of the main
application project with the appassembler plugin.
Then I build the target zipfile in the aggregator project from this
staging directory in the aggregator project.
But there may be a better way. I am still learning.
On 12/31/2010 08:19 AM, Stephen Connolly wrote:
Install implies package.
If you run
mvn clean install package
Yoyr tests will run twicr because you asked maven to run them twice
Also you should be binding assembly: single to tgen lifecycle, not invoking
directly
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Dec 2010 13:52, "Steve Cohen"<[email protected]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
