Op Tue, 27 May 2014 22:37:50 +0200 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:
Am 26.05.2014 21:03, schrieb Robert Scholte:
Hi Jörg,
Hi Robert,
I very much appreciate your support and contribution.
However, your "in the middle of the discussion" commit caused me some
SVN conflict and merge trouble.
I did my best to resolve but as a consequence removed a part of your
changes (Model vs. FlattenDescriptor).
However, I like to make things explicit and using Model allows to
configure elements that make no
sense in this place. Also to see what this is about (e.g. in JavaDoc
links, it makes things more clear). So hopefully you consider this as an
improvement, too. I would like to avoid "fighting" via SVN.
Agree on the avoid SVN fighting :) I needed to clean up stuff, otherwise
the code wouldn't compile.
However, I think that in the end Model would be a perfect match if you
want to finetune on microlevel.
I could have named it Xpp3Dom, but then you're missing to much info,
unless we have proper usage pages.
Any other object might restrict us in the future.
IMHO the flattened pom should be the bare minimum by default. In that
case there's no need for a 'remove'.
I never intended this option and could also have used null instead.
However, the repositories section was copied to flattened POM by default
what can be undesired in
some situations. I removed this default behaviour for now. You can now
use
<flattenMode>all</flattenMode>
or
<pomElements>
<repositories/>
...
</pomElements>
if you want to keep the repositories. We could also add them by default
(if nothing is configured)
but would it be consistent to strip them if flattenMode "oss" or "ossrh"?
Please note that OSSRH has a policy that prevents adding repositories as
central should be self contained.
If you don't copy the repositories, then it's very plausible that it won't
build with Maven3 anymore, even if it's available in your local
repository. Maven3 keeps track of the origins per artifact, so if that
repository is gone and the artifact is not available via other
repositories, the build will fail. There's an enforcer rule for this,
which verifies if there are repositories specified in the pom. That's how
it should be blocked, and not by the flatten-maven-plugin.
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.
I had a different opinion but I can live with what we have now. If
necessary I than can override the config of flatten-maven-plugin in
child modules. And for "name" it should be easy enough to add it to your
own POM (however, this does not really follow the
convention-over-configuration of Maven but this might be more of a
question why OSSRH requires name in validation).
Robert
So what we should finally clarify is:
* is it OK to have repositories removed by default (change of
behaviour to previous version)?
No, see previous comment
* I followed the "short" names trend you guys seem to like instead of
more expressive syntax. However, what I created right now might need
some revisit as it appears confusing. <flattenMode>all</flattenMode>
does not "flatten" 'all' additional POM elements but keeps them. So
should we rename this to additionalElementsMode or what? Or should it be
'keepAll' instead?
I'd say minimum instead of all
Also <pomElements> lists the elements to keep. In the context of
flattening one might initially expect the opposite.
As soon as this is finallized I would love to go for the next release.
Cheers Jörg
[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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
