Hi Jörg,
IMHO the flattened pom should be the bare minimum by default. In that case
there's no need for a 'remove'.
For the parent inheritance it's the same story: the parent defines the
required elements, children can only extend them. There are some magic
plexus attributes[1] which can overwrite the behavior of the parent, but I
think these are rare cases. So *if* users really want this, they can
already do so. No need to solve this with Keep*/Remove values, just sum
the elements you'd like to include in your flattened pom.
Robert
[1]
http://blog.sonatype.com/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/
Op Sun, 25 May 2014 23:27:35 +0200 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:
Am 24.05.2014 12:03, schrieb Robert Scholte:
Hi,
Hi Robert,
seems like I missed a mail.
no worries...
What I don't understand is why you want to overcomplicate things by
using KeepOrAdd (and what would the value of add be?), KeepIfExist and
remove. I'd prefer to just naming those elements you'd like to copy,
warn if the element is not there.
There is a difference between inherited elements and those taken from
the actual POM.
I assume that flatten-maven-project is used by large
multi-module-builds. Typically you will have one "policy" how flattening
shall happen that is defined in your parent POM.
Then maybe some child modules will explicitly define POM elements such
as url, issueManagement, etc. that should be be deployed while child
modules that do not contain such elements shall be deployed without
these elements that would otherwise be inherited.
Also for name "keepOrAdd" will add a default value (artifactId) while
"keepIfExists" would not.
Might be that I see things complicated. And if all others agree, I might
drop this but...
...what would be the value in your case? "add" or "remove"? Or where you
saying that one should list the element names as a single String in a
comma separated list?
IMHO the default use-case will be that someone will choose a predefined
descriptor and just needs one line such as
<flattening>OSSHR</flattening>. But if someone decides to configure the
"descriptor" individual at all this might be a very specific situation
and then why not giving all the flexibility I already implemented?
Unlike a comma separated list, this approach is also extensible for
upcoming requests...
I'll give it a the next couple of days.
thanks,
Robert
Thanks
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
