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