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