Re: [mojo-dev] Re: [mojo-scm] [19715] trunk/mojo/flatten-maven-plugin/src/site/xdoc/usage.xml: MOJO-2027: added documentation

[Jörg Hohwiller]

Hi,

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.

So if I understand properly, this time I caused the pain for your local changes. Sorry for that.

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.

Currently a specific set of POM elements is supported. You can see them in the code and JavaDoc. If you configure elements not supported, you will get an error. With Model this would be a lot different.

Any other object might restrict us in the future.

There is no restriction right now for what we will do in the future about this. If we later will come to the point, that we will even allow to configure subsections of POM elements we can still go for switchting to Model, as then it will perfectly make sense. However, nothing of that is currently implemented or planned. If we want to go for it, we can switch to Model. IMHO for now it is just fine.

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

<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)

Please note that OSSRH has a policy that prevents adding repositories as
central should be self contained.

some situations. I removed this default behaviour for now. You can now use but would it be consistent to strip them if flattenMode "oss" or "ossrh"?

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

This should be fine.

I changed this so by default repositories are kept. If you want to remove them, you need to use "pomElements" and list exactly those elements you want to keep (excluding repositories).

  * 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

Good. Renamed in Code, ITs and documentation.

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.

Anything left? Nothing from my side.

Cheers Jörg

Regards
  Jörg

smime.p7s
Description: S/MIME Cryptographic Signature