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
