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: [email protected] For additional commands, e-mail: [email protected]
