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