Re: Plugin assembly: Howto use 'single' goal as an agregator ?

[Alix Lourme]

Hi Curtis,

Why not stick with the old version of maven-assembly-plugin until you have
> to refactor your build more thoroughly?
>

I thought to that, but it collides another (philosophical) concept: to use
always the last version of plugins ! ^^

More seriously and to explain, the "problem" is that the configuration is
inside a company parent pom, and the CI has some template builds containing
this assembly call.
This refactor is simple for a project, but more difficult to instruct on
many many projects.
So not upgrading the plugin version is just delay the problem ...

In short, this is the classic life of components migration for a company,
and when you don't really consider a depreciation tag :-)
But if it is not technically possible (aggregation by pom configuration), I
will take the problem by the horns.

Many thanks for the informations and suggestions.
Best regards

2017-03-14 19:29 GMT+01:00 Curtis Rueden :

> 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 
> 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 :
> >
> > > 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
> > >  > 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 :
> > >
> > >> 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 

Re: Plugin assembly: Howto use 'single' goal as an agregator ?

[Curtis Rueden]

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  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 :
>
> > 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
> >  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 :
> >
> >> 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 

Re: Plugin assembly: Howto use 'single' goal as an agregator ?

[Alix Lourme]

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 :

> 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
> 
> 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 :
>
>> 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 ).
>>>
>>> This *attached* goal was an aggregator (v2.6 source
>>> >> 

Re: Plugin assembly: Howto use 'single' goal as an agregator ?

[Alix Lourme]

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

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 :

> 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 ).
>>
>> This *attached* goal was an aggregator (v2.6 source
>> > 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
>> > 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 

Re: Plugin assembly: Howto use 'single' goal as an agregator ?

[Karl Heinz Marbaise]

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 ).

This *attached* goal was an aggregator (v2.6 source
)
but not the *single* goal (v3.0.0 source

).

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

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