Inheritable Profiles or Decision making in POM

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Inheritable Profiles or Decision making in POM

Tibor Digana
I had a discussion with Robert about inheritable profiles.
As Robert said, this would introduce new issues and bugs. Altering
dependencies is a bad sing in project my company really need it at least in
POM with packaging WAR and runtime scope.

Profiles are not inheritable. This is user unfriendly because of adding the
same profile to all children POMs of multi-module project. Do we have a
chance to have inheritable profiles in build POM (version 4 or 5)?

I wan to alter dependencies according to a profile in parent. The
dependencies are not inheritable. It would be nice to have another new well
performed feature in Maven 4.0 or 5.0 in the client's POM. I do not want to
have a Groovy in XML but the branching would be suitable in some
circumstances.

Last to say is that we have one abstraction but two implementations and
developer can use JPA implementation of dependency instead of JMS impl.
Therefore switching dependencies impl.

--
Cheers
Tibor
Reply | Threaded
Open this post in threaded view
|

Re: Inheritable Profiles or Decision making in POM

Jörg Schaible
On Fri, 21 Dec 2018 17:50:42 +0100 Tibor Digana wrote:

> I had a discussion with Robert about inheritable profiles.

Actually, they are inherited, but just the declaration. The activation is based on the conditions of the current
(sub)project.

> As Robert said, this would introduce new issues and bugs. Altering
> dependencies is a bad sing in project my company really need it at least
> in POM with packaging WAR and runtime scope.

Why? A release will always just contain one of these special setups. If you want to release both variants, you
effectively have two projects.

> Profiles are not inheritable.

Wrong. But you seem to talk about dependencies now, that you try to switch using profiles and you expect
that Maven somehow knows later on on its own, which profile it should choose.

> This is user unfriendly because of adding
> the same profile to all children POMs of multi-module project.

You don't have to. You just have to activate it properly.

> Do we
> have a chance to have inheritable profiles in build POM (version 4 or
> 5)?

Why do you need it?

> I want to alter dependencies according to a profile in parent.

I am here with Robert. Once a POM is deployed, you can no longer rely on any profile activation (by OS or Java
runtime is stupid, properties must be known by the client and something like the flatten plugin will strip these
anyway). Therefore managing dependencies in profiles is a bad thing and discouraged, but still possible. You
may just have some surprising side-effects when you suddenly depend on a released version.

> The
> dependencies are not inheritable. It would be nice to have another new
> well performed feature in Maven 4.0 or 5.0 in the client's POM. I do not
> want to have a Groovy in XML but the branching would be suitable in some
> circumstances.

Actually you may be faced in future with stripped POMs in the repositories, because Maven will separate
between build time information and runtime information. Only the latter is required in the repo. And profiles
are meant to be build time.

> Last to say is that we have one abstraction but two implementations and
> developer can use JPA implementation of dependency instead of JMS impl.
> Therefore switching dependencies impl.

So provide two BOMs with the proper dependencies and the developer can select on its own, on which one
he wants to rely on.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Inheritable Profiles or Decision making in POM

Oliver B. Fischer-2
Hi Jörg,

Am 21.12.18 um 18:51 schrieb Jörg Schaible:
> Actually you may be faced in future with stripped POMs in the repositories, because Maven will separate
> between build time information and runtime information. Only the latter is required in the repo. And profiles
> are meant to be build time.
it is a widely used practice to define profiles in POMs to be shared
within a project or organisation. We use it for example in our project
to ensure a consistent build environment for all of our microservices.
Loosing this feature would be a huge drawback and decrease the
handsomeness of Maven.

Oliver

--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E [hidden email]
S oliver.b.fischer
J [hidden email]
X http://xing.to/obf

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Inheritable Profiles or Decision making in POM

Robert Scholte-8
You don't have to worry about parent poms, expectations are these will  
stay untouched. Pom optimizations effect non-parent, non-aggregator pom  
files.

thanks,
Robert

On Fri, 21 Dec 2018 20:13:48 +0100, Oliver B. Fischer  
<[hidden email]> wrote:

> Hi Jörg,
>
> Am 21.12.18 um 18:51 schrieb Jörg Schaible:
>> Actually you may be faced in future with stripped POMs in the  
>> repositories, because Maven will separate
>> between build time information and runtime information. Only the latter  
>> is required in the repo. And profiles
>> are meant to be build time.
> it is a widely used practice to define profiles in POMs to be shared  
> within a project or organisation. We use it for example in our project  
> to ensure a consistent build environment for all of our microservices.  
> Loosing this feature would be a huge drawback and decrease the  
> handsomeness of Maven.
>
> Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Inheritable Profiles or Decision making in POM

Robert Scholte-8
In reply to this post by Tibor Digana
In my opinion any commandline argument should *never* have any impact on  
the deliverables.
Not by -D arguments nor by activating profiles.
It should always be clear what kind of artifact you're getting.

Reflecting this to your usecase:
mycompanyproject-2.0.0-SNAPSHOT.war, is it based on JPA or JMS?
You can't tell, and it might be a different answer the next minute.
Hence here you should split it up into 2 difference warfiles:
mycompanyproject-jpa-2.0.0-SNAPSHOT.war
mycompanyproject-jms-2.0.0-SNAPSHOT.war

thanks,
Robert

On Fri, 21 Dec 2018 17:50:42 +0100, Tibor Digana <[hidden email]>  
wrote:

> I had a discussion with Robert about inheritable profiles.
> As Robert said, this would introduce new issues and bugs. Altering
> dependencies is a bad sing in project my company really need it at least  
> in
> POM with packaging WAR and runtime scope.
>
> Profiles are not inheritable. This is user unfriendly because of adding  
> the
> same profile to all children POMs of multi-module project. Do we have a
> chance to have inheritable profiles in build POM (version 4 or 5)?
>
> I wan to alter dependencies according to a profile in parent. The
> dependencies are not inheritable. It would be nice to have another new  
> well
> performed feature in Maven 4.0 or 5.0 in the client's POM. I do not want  
> to
> have a Groovy in XML but the branching would be suitable in some
> circumstances.
>
> Last to say is that we have one abstraction but two implementations and
> developer can use JPA implementation of dependency instead of JMS impl.
> Therefore switching dependencies impl.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Inheritable Profiles or Decision making in POM

Oliver B. Fischer-2
In reply to this post by Robert Scholte-8
Thank you for the clarification.

Bye,
Oliver

Am 22.12.18 um 10:57 schrieb Robert Scholte:

> You don't have to worry about parent poms, expectations are these will
> stay untouched. Pom optimizations effect non-parent, non-aggregator pom
> files.
>
> thanks,
> Robert
>
> On Fri, 21 Dec 2018 20:13:48 +0100, Oliver B. Fischer
> <[hidden email]> wrote:
>
>> Hi Jörg,
>>
>> Am 21.12.18 um 18:51 schrieb Jörg Schaible:
>> it is a widely used practice to define profiles in POMs to be shared
>> within a project or organisation. We use it for example in our project
>> to ensure a consistent build environment for all of our microservices.
>> Loosing this feature would be a huge drawback and decrease the
>> handsomeness of Maven.
>>
>> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E [hidden email]
S oliver.b.fischer
J [hidden email]
X http://xing.to/obf

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Inheritable Profiles or Decision making in POM

Hervé BOUTEMY
In reply to this post by Tibor Digana
I think there are 2 separate debates:

1. supporting *late profile activation*, in addition to current *early*
activation (see the first step of phase 1 [1]), which is IMHO a more accurate
description of what you call "inheritable profile".
a side effect of late profile activation is that there may be more flexible
activators than the few activators available in the current early activation
scenario

2. changing the scope of what can be defined in a profile [2]:
perhaps you don't really want to change the scope of what is defined in a
profile, but the effective result of the profile in a late activation scenario
is not really the same as in early activation
Whatever the case, defining a dependency in a profile, even in the current
early profile activation scenario, looks strange to me: this was already
something I discovered while working on consumer vs build POM [3]...
We should really share precise use cases to make choices, both for positive
cases (= something we want to support) and eventual abuse scenario (=
something that the feature makes possible but we don't think it's a good idea)

Regards,

Hervé

[1] https://maven.apache.org/ref/3.6.0/maven-model-builder/

[2] https://maven.apache.org/ref/3.6.0/maven-model/maven.html#profile

[3] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM

Le vendredi 21 décembre 2018, 17:50:42 CET Tibor Digana a écrit :

> I had a discussion with Robert about inheritable profiles.
> As Robert said, this would introduce new issues and bugs. Altering
> dependencies is a bad sing in project my company really need it at least in
> POM with packaging WAR and runtime scope.
>
> Profiles are not inheritable. This is user unfriendly because of adding the
> same profile to all children POMs of multi-module project. Do we have a
> chance to have inheritable profiles in build POM (version 4 or 5)?
>
> I wan to alter dependencies according to a profile in parent. The
> dependencies are not inheritable. It would be nice to have another new well
> performed feature in Maven 4.0 or 5.0 in the client's POM. I do not want to
> have a Groovy in XML but the branching would be suitable in some
> circumstances.
>
> Last to say is that we have one abstraction but two implementations and
> developer can use JPA implementation of dependency instead of JMS impl.
> Therefore switching dependencies impl.





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]