You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steve Cohen <sc...@javactivity.org> on 2010/12/30 21:16:23 UTC
Assembly Plugin adventures - further review
After a very frustrating couple of days trying to understand the new
features of the assembly plugin, let me try to specify what I am TRYING
to do and see if there isn't a better (i.e. more mavenish) way of doing
it. Maven is flexible as long as you don't stray too far out of the
beaten path.
I am supporting two main applications in this system.
One is a fairly standard war file that runs under Tomcat. It isn't
really a web application, but from this perspective, one might as well
assume that it is.
The other is a not really standard zip file that contains a standalone
java application. The standalone application deals with batch processes
pertaining to the backend database that is used by the "web
application". While there may be other ways to organize this code,
let's say that this mode of organization is an unalterable requirement.
The two applications share some modules - for database access, and for
contacting some external web services of which both applications are
clients at various points.
The structure I use is that each module is a separate Eclipse project
and a separate SVN project. Each project is ultimately descended from a
parent POM that governs which dependency version to use for each
dependency and which plugin version to use.
Since some of the modules need to be "owned" by both of the
applications, they aren't actually owned by either. Instead, I try to
treat them as much like third-party jars as possible. They are
installed into the local repository and then used as appropriate. They
aren't quite as stable as most third-party jars, they are evolving to
different degrees, along with the main applications.
This applications of this system can be built both in m2eclipse and by a
server process that builds automatically after getting pristine source
from svn.
As far as building the "webapp", that presents no problems. But the
standalone batch process application presents many problems. Besides
the module jars and third party jars that it needs to package into the
zip file, it also needs to package in some configuration files that will
ultimately live on the server file system.
For this purpose, I have been using the assembly plugin. I have a
configuration that works, for the most part, using the assembly:assembly
goal, which is now deprecated. I have tried to build using the
recommended way (using the single goal and the <useAllReactorProjects>
tag) and I ran up against mind-boggling difficulties which I wasn't able
to resolve. (See
http://www.mail-archive.com/users@maven.apache.org/msg115460.html)
Evidently my system is enough out of the norm that this won't work for me.
So, to make a long story short, I'm looking for a better way to organize
this system that would fit more with Maven. I find it aggravating that
what would be a simple thing to lay out with make or ant is seemingly
almost impossible to achieve in Maven - especially since I am trying to
convert my organization into using Maven. I don't know if I'm dealing
with bugs, or with things that Maven was never designed to be able to do
in the first place.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Barrie Treloar <ba...@gmail.com>.
On Sat, Jan 1, 2011 at 12:22 AM, Steve Cohen <sc...@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
Running assembly:assembly is the bug that caused the goal "single" to
be created.
Because assembly is attached the lifecycle it incorrectly causes the
entire lifecycle to be run twice.
You will notice the same thing with surefire-report:report.
Its a known problem that I think is being addressed in Maven 3.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Benson Margulies <bi...@gmail.com>.
Never do anything interesting in a aggregate project (what I think
you're calling an uber-project). Make a separate leaf project, listed
last in the list of modules, to run assembly:single.
On Fri, Dec 31, 2010 at 8:52 AM, Steve Cohen <sc...@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<sc...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Ron Wheeler <rw...@artifact-software.com>.
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"<sc...@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<sc...@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-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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
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"<sc...@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<sc...@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-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Ron Wheeler <rw...@artifact-software.com>.
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"<sc...@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<sc...@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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"<sc...@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<sc...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Stephen Connolly <st...@gmail.com>.
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" <sc...@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<sc...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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<sc...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Benson Margulies <bi...@gmail.com>.
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 <sc...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Dennis Lundberg <de...@apache.org>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Dan Tran <da...@gmail.com>.
On Thu, Dec 30, 2010 at 2:23 PM, Steve Cohen <sc...@javactivity.org> 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?
That is exactly what I did to get my standalone java app bundle
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 30/12/2010 5:05 PM, Dan Tran wrote:
> use a combination of antrun, dependency plugin to prepare a staging
> directory, then use the assembly to create the package.
Way too much work. Not needed. Maven can build batch jobs by itself.
Ron
> -D
>
> On Thu, Dec 30, 2010 at 1:55 PM, Steve Cohen<sc...@javactivity.org> wrote:
>> On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
>> Thanks, Dennis. This looks very interesting on the surface. Before I dive
>> too deeply into it, though, let me ask you some questions about it.
>>
>> I am already using commons-daemon to "daemonize" the thing and the script to
>> launch the thing is already written and basically never changes. I don't
>> need something to manage this side of the process. Is this going to get in
>> my way? Or can I easily avoid dealing with this aspect?
>>
>> All I want to do is build my stuff and copy the config files, the modules,
>> and the third party dependencies into a zip file. End of story. Can I do
>> it in less than a day?
>>
>> Sorry to be so gun-shy but I'm still recovering from the assembly-plugin
>> experience.
>>
>>
>>> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Dan Tran <da...@gmail.com>.
use a combination of antrun, dependency plugin to prepare a staging
directory, then use the assembly to create the package.
-D
On Thu, Dec 30, 2010 at 1:55 PM, Steve Cohen <sc...@javactivity.org> wrote:
> On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
> Thanks, Dennis. This looks very interesting on the surface. Before I dive
> too deeply into it, though, let me ask you some questions about it.
>
> I am already using commons-daemon to "daemonize" the thing and the script to
> launch the thing is already written and basically never changes. I don't
> need something to manage this side of the process. Is this going to get in
> my way? Or can I easily avoid dealing with this aspect?
>
> All I want to do is build my stuff and copy the config files, the modules,
> and the third party dependencies into a zip file. End of story. Can I do
> it in less than a day?
>
> Sorry to be so gun-shy but I'm still recovering from the assembly-plugin
> experience.
>
>
>> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Steve Cohen <sc...@javactivity.org>.
On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
Thanks, Dennis. This looks very interesting on the surface. Before I
dive too deeply into it, though, let me ask you some questions about it.
I am already using commons-daemon to "daemonize" the thing and the
script to launch the thing is already written and basically never
changes. I don't need something to manage this side of the process. Is
this going to get in my way? Or can I easily avoid dealing with this
aspect?
All I want to do is build my stuff and copy the config files, the
modules, and the third party dependencies into a zip file. End of
story. Can I do it in less than a day?
Sorry to be so gun-shy but I'm still recovering from the assembly-plugin
experience.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Dennis Lundberg <de...@apache.org>.
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
> features of the assembly plugin, let me try to specify what I am TRYING
> to do and see if there isn't a better (i.e. more mavenish) way of doing
> it. Maven is flexible as long as you don't stray too far out of the
> beaten path.
>
> I am supporting two main applications in this system.
>
> One is a fairly standard war file that runs under Tomcat. It isn't
> really a web application, but from this perspective, one might as well
> assume that it is.
>
> The other is a not really standard zip file that contains a standalone
> java application. The standalone application deals with batch processes
> pertaining to the backend database that is used by the "web
> application". While there may be other ways to organize this code,
> let's say that this mode of organization is an unalterable requirement.
>
> The two applications share some modules - for database access, and for
> contacting some external web services of which both applications are
> clients at various points.
>
> The structure I use is that each module is a separate Eclipse project
> and a separate SVN project. Each project is ultimately descended from a
> parent POM that governs which dependency version to use for each
> dependency and which plugin version to use.
>
> Since some of the modules need to be "owned" by both of the
> applications, they aren't actually owned by either. Instead, I try to
> treat them as much like third-party jars as possible. They are
> installed into the local repository and then used as appropriate. They
> aren't quite as stable as most third-party jars, they are evolving to
> different degrees, along with the main applications.
>
> This applications of this system can be built both in m2eclipse and by a
> server process that builds automatically after getting pristine source
> from svn.
>
> As far as building the "webapp", that presents no problems. But the
> standalone batch process application presents many problems. Besides
> the module jars and third party jars that it needs to package into the
> zip file, it also needs to package in some configuration files that will
> ultimately live on the server file system.
>
> For this purpose, I have been using the assembly plugin. I have a
> configuration that works, for the most part, using the assembly:assembly
> goal, which is now deprecated. I have tried to build using the
> recommended way (using the single goal and the <useAllReactorProjects>
> tag) and I ran up against mind-boggling difficulties which I wasn't able
> to resolve. (See
> http://www.mail-archive.com/users@maven.apache.org/msg115460.html)
> Evidently my system is enough out of the norm that this won't work for me.
>
> So, to make a long story short, I'm looking for a better way to organize
> this system that would fit more with Maven. I find it aggravating that
> what would be a simple thing to lay out with make or ant is seemingly
> almost impossible to achieve in Maven - especially since I am trying to
> convert my organization into using Maven. I don't know if I'm dealing
> with bugs, or with things that Maven was never designed to be able to do
> in the first place.
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Assembly Plugin adventures - further review
Posted by Ron Wheeler <rw...@artifact-software.com>.
This is very similar to what we have done with out portal that consists
of 70+ maven projects that produce libraries, servlets, portlets and
batch jobs.
The batch jobs include:
- A batch job that is run on a third party's server that extracts data
from another 3rd party's database and puts the data into our server.
- A batch job that is triggered by a portlet to run a data upload that
takes 40 minutes to validate and update the database once the portlet
has accepted the data and done a preliminary validation of 3 files that
the user specified.
We did not have any Maven issues using the assembly plug-in to build the
resulting artifacts.
On 30/12/2010 3:16 PM, Steve Cohen wrote:
> After a very frustrating couple of days trying to understand the new
> features of the assembly plugin, let me try to specify what I am
> TRYING to do and see if there isn't a better (i.e. more mavenish) way
> of doing it. Maven is flexible as long as you don't stray too far out
> of the beaten path.
>
> I am supporting two main applications in this system.
>
> One is a fairly standard war file that runs under Tomcat. It isn't
> really a web application, but from this perspective, one might as well
> assume that it is.
>
Pretty easy.
> The other is a not really standard zip file that contains a standalone
> java application. The standalone application deals with batch
> processes pertaining to the backend database that is used by the "web
> application". While there may be other ways to organize this code,
> let's say that this mode of organization is an unalterable requirement.
>
Not unusual. Batch is not going away for some tasks that are either long
running or need to be scheduled to run without user intervention..
> The two applications share some modules - for database access, and for
> contacting some external web services of which both applications are
> clients at various points.
>
We call them "libraries".
> The structure I use is that each module is a separate Eclipse project
> and a separate SVN project. Each project is ultimately descended from
> a parent POM that governs which dependency version to use for each
> dependency and which plugin version to use.
>
We do not put dependency management in the parent but that is just my
decision - not necessarily universally regarded as the best choice by my
team but .....
> Since some of the modules need to be "owned" by both of the
> applications, they aren't actually owned by either. Instead, I try to
> treat them as much like third-party jars as possible. They are
> installed into the local repository and then used as appropriate.
> They aren't quite as stable as most third-party jars, they are
> evolving to different degrees, along with the main applications.
>
Libraries again. I would not tolerate the use of unreleased code in a
production dependency. Write the library, test it and deploy it as a
SNAPSHOT until it is ready to release.
Just because we wrote it does not mean that we don't have to do it
right. Deploy it as a release once you are ready to release the modules
that it supports or you are sure that it will not change. No local
repositories - everything goes into Nexus as soon as the programmer is
willing to warranty its perfection.
> This applications of this system can be built both in m2eclipse and by
> a server process that builds automatically after getting pristine
> source from svn.
>
We are happy to go from the Nexus release repo into production but I can
see the value of testing from the svn to ensure that programmers are
behaving professionally and committing properly. We are pretty fortunate
to have guys who actually care about quality.
> As far as building the "webapp", that presents no problems. But the
> standalone batch process application presents many problems. Besides
> the module jars and third party jars that it needs to package into the
> zip file, it also needs to package in some configuration files that
> will ultimately live on the server file system.
>
We put the config files in the jar which is enough to get them on the
classpath and we do not need to change them after they are released.
> For this purpose, I have been using the assembly plugin. I have a
> configuration that works, for the most part, using the
> assembly:assembly goal, which is now deprecated. I have tried to
> build using the recommended way (using the single goal and the
> <useAllReactorProjects> tag) and I ran up against mind-boggling
> difficulties which I wasn't able to resolve. (See
> http://www.mail-archive.com/users@maven.apache.org/msg115460.html)
> Evidently my system is enough out of the norm that this won't work for
> me.
>
We have a very simple assembly and I do not understand why you need
anything special just to build a batch job.
> So, to make a long story short, I'm looking for a better way to
> organize this system that would fit more with Maven. I find it
> aggravating that what would be a simple thing to lay out with make or
> ant is seemingly almost impossible to achieve in Maven - especially
> since I am trying to convert my organization into using Maven. I
> don't know if I'm dealing with bugs, or with things that Maven was
> never designed to be able to do in the first place.
>
Forget everything that you know about Ant. It is a great software but it
is not a good model for Maven.
Does this relate to your situation?
Ron
Example assembly for a batch job - jar-with-dependencies-assembly.xml
This project includes 3 xml configuration files and a properties file.
They are all in the project at the top level of the "src" folder(same
level as "com").
<assembly>
<id>jar-with-dependencies</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory></outputDirectory>
<outputFileNameMapping></outputFileNameMapping>
<unpack>true</unpack>
<scope>runtime</scope>
</dependencySet>
</dependencySets>
</assembly>
Here is the <build> section from the POM
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>jar-with-dependencies-assembly.xml</descriptor>
</descriptors>
<archive>
<manifest>
<mainClass>com.x.ourproject.contractrenew.main.ContractRenewBatchMain</mainClass>
<packageName>com..x.ourproject..contractrenew.main</packageName>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
</manifestEntries>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>attached</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org