On 31/12/2010 4:27 PM, Steve Cohen wrote:
No. Sorry. But thanks.
I thought I'd struck gold with that appassembler thing and by the time
I figured out that I hadn't I had forgotten all about your sample.
Now that I look at it, it seems that what you are doing and what I am
doing are not that different. And your example shows the use of the
root-level <dependencySet> which I'm thinking would probably let me
work without using appassembler.
But it's New Year's Eve, time to put this to bed.
Thanks again.
Steve
Have a great evening.
If you need any more details, let me know.
It is pretty easy and we build a few batch jobs so I may be able to show
something more similar to your job.
Ron
On 12/31/2010 02:14 PM, Ron Wheeler wrote:
Did you try the POM and assembly that I sent you?
It is pretty straightforward.
Ron
On 31/12/2010 2:47 PM, Steve Cohen wrote:
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"<sco...@javactivity.org> 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<sco...@javactivity.org>
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
