Hi Alix, Why not stick with the old version of maven-assembly-plugin until you have to refactor your build more thoroughly?
Regards, Curtis -- Curtis Rueden LOCI software architect - https://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden On Tue, Mar 14, 2017 at 1:06 PM, Alix Lourme <alix.lou...@gmail.com> wrote: > Hello, > > Even if using aggregator is not a good practice in this case ... if there > is a technical possibility to force the aggregation for a goal by pom > configuration, I'll take it. > Because after continuing to dig, I am in a dead-end ^^ > > Many thanks. > Best regards > > 2017-03-14 10:45 GMT+01:00 Alix Lourme <alix.lou...@gmail.com>: > > > Hi Karl Heinz, > > > > Thanks for your answer (and sorry for mine late). > > > > the best thing to create a separate module in your build with packaging > >> pom and only put the maven-assembly-plugin in it and bind it to the life > >> cycle > >> This is simply a good way of following single responsibility principle. > >> > > try to get it as simple as possible which will result in just: mvn clean > >> package. > >> > > > > I'm fully agree with you (there is no debate), and this is an objective > to > > achieve in the future ... > > > > But ... when you have many projects (multiple hundred) using this bad > way (*mvn > > install assembly:attached*): > > * Upgrading a parent (company pom) & changing a 'goal' is simple > > * Reviewing completely the archive generation process (new module, > > descriptor content) is a little bit more complicated > > > > So I hoped for a consensus to accompagn the transition > > (maven-assembly-plugin v3.0.0) without project structure change :-). > > I will affine pro & cons and ruling on the possibilities. > > > > > > What I don't understand is your reference to maven-release-plugin and > >> maven-invoker-plugin ? > >> > > > > When you are using the previous (bad) way on maven-release-plugin, you > > could define goals > > <https://maven.apache.org/maven-release/maven-release- > plugin/perform-mojo.html#goals> > > with: *-Dgoals="install assembly:attached".* The result is "one Maven > > command" like: > > ------------------ > > > > [DEBUG] Executing: cmd.exe /X /C ""C:\[...]\mvn.bat" -B -X -D > > maven.repo.local=C:\[...]\.m2\repository -f myApp -s > > C:\[...]\AppData\Local\Temp\release-settingsXXX.xml -D > > performRelease=true -P someProfiles install assembly:attached" > > ------------------ > > This reference to maven-release-plugin or invoker was just an argument > for > > a "only one Maven command" need ; avoiding ideas like: "*Just do two step > > command, 'mvn install' and after 'mvn assembly:attached*'" > > > > Thanks > > Best regards > > > > 2017-03-11 16:31 GMT+01:00 Karl Heinz Marbaise <khmarba...@gmx.de>: > > > >> Hi, > >> > >> If you like to produce a package (zip/tar/whatever kind of > >> archive/bundle) which contains some modules/artifacts etc. from your > multi > >> module build it is the best thing to create a separate module in your > build > >> with packaging pom and only put the maven-assembly-plugin in it and > bind it > >> to the life cycle. This project contains all the needed dependencies in > >> your assembly project pom...which should be packaged into your resulting > >> archive (zip/tar/whatever). > >> > >> The assembly descriptor contains the appropriate > >> dependencySets/moduleSets/sources etc. entries as needed. > >> > >> This makes it absolutely sure that using a simple: > >> > >> mvn clean package > >> > >> or > >> > >> mvn install > >> > >> everything is correctly packaged into the resulting bundle you would > like > >> to build. > >> > >> This is simply a good way of following single responsibility principle. > >> > >> > >> This produces each time a correct and the same result in contradiction > to > >> your supplemental goal calling from command line (you just simply miss > it?). > >> > >> Apart from that using fileSets is usually not the correct way cause it > >> relies on the content which is on the file system which might sometimes > not > >> what you really like if you don't do: > >> > >> mvn clean > >> > >> before. > >> > >> If you do things like this: > >> > >> mvn install > >> ...Doing something here... > >> mvn install assembly:attached > >> > >> The resulting bundle which has been produced by using assembly:attached > >> could contain artifacts which are not part of the build.. > >> > >> This is also an problem in reproducibility of builds. > >> > >> From my point of view a single command like this: > >> > >> > >> mvn clean package > >> > >> is easier and more in the paradigm of Maven. Use conventions... > >> > >> Adding a supplemental call to a plugin goal does not make it easier.. > >> > >> I will rely on just the build as it...without using supplemental goals > or > >> using some properties needed to be defined on the command line which I > >> often see in other projects where you need to call some goals of plugins > >> before or after things. I will alway try to get it as simple as possible > >> which will result in just: mvn clean package. > >> > >> What I don't understand is your reference to maven-release-plugin and > >> maven-invoker-plugin ? > >> > >> > >> Kind regards > >> Karl Heinz Marbaise > >> > >> > >> On 11/03/17 15:56, Alix Lourme wrote: > >> > >>> Hello, > >>> > >>> Since maven-assembly-plugin v3.3.0, the *attached* goal has been > removed > >>> ( > >>> MASSEMBLY-704 <https://issues.apache.org/jira/browse/MASSEMBLY-704>). > >>> > >>> This *attached* goal was an aggregator (v2.6 source > >>> <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-a > >>> ssembly-plugin-2.6/src/main/java/org/apache/maven/plugin/ass > >>> embly/mojos/AttachedAssemblyMojo.java>) > >>> but not the *single* goal (v3.0.0 source > >>> <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-a > >>> ssembly-plugin-3.0.0/src/main/java/org/apache/maven/plugins/ > >>> assembly/mojos/SingleAssemblyMojo.java> > >>> ). > >>> > >>> Even *attached* goal "*leads to non-standard builds*", it was very > useful > >>> on a multi modules project to generate a bundle with some modules items > >>> (artifacts, anything produced on *package* phase, ...) when the > >>> descriptor > >>> contains only *fileSets* definitions, using only one Maven command > >>> (e.g.: "*mvn > >>> install assembly:attached*") ; because assembly executed after > >>> package/install/deploy phase in each modules. > >>> > >>> With module binaries > >>> <https://maven.apache.org/plugins/maven-assembly-plugin/faq. > >>> html#module-binaries> > >>> configuration, this job could be done ; but forces reviewing all > assembly > >>> descriptors (usage of *moduleSet* in addition of *fileSet*), or using > two > >>> steps Maven command. > >>> If you consider that using one command is a prerequisite ( > >>> *maven-release-plugin* plugin usage or some jobs with *maven-invoker*), > >>> the > >>> v2.x -> v3.x *maven-assembly-plugin* migration could be a little > tricky. > >>> > >>> => Is there a way to execute single goal as an aggregator, via pom > >>> configuration (inheritable from a super/company parent pom) ? With > >>> that the *migration > >>> *could be just to replace *attached* by *single*. > >>> > >>> Many thanks in advance for tips or idea > >>> Best regards > >>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > -- > > Alix Lourme > > > > > > -- > Alix Lourme >
