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