profile activation on property set but !value vs property not set

[Justin Georgeson]

Seeing that I can ! the property value in a profile activation, I assumed there 
were three states to consider when evaluating the property activation:

1. Property not set
2. Property set and value does not match
3. Property set and value does match

With this assumption I thought that with profiles such as these



default-reactor
!platform


platform-reactor

platform!all


all-platforms-reactor

platformall



I would only see one of the three profiles active at a time. However when I run 
Maven 'mvn help:active-profiles' with no 'platform' property then both the 
'default-reactor' and 'platform-reactor' are active. When I set the 'platform' 
property then I see the behavior I expected. Looking at the source

https://github.com/apache/maven/blob/38300cf2832e9a40198091aa9e0bf6d3dbc3268d/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/PropertyProfileActivator.java#L95

It's doing a string compare of the activation's declared property value against 
the context's property value, but it's not checking the context has a property 
set. But I would infer from the comment on L94 ("we have a value, so it has to 
match the system value...") that an unset property should not match a !value 
activation.

Should I open a JIRA issue as a bug, or as a feature request?

--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

ipad air 2

[mostafa shahdadi]

Sent from my iPad

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

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

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

[Alix Lourme]

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
-- 
Alix Lourme