On Wed, Aug 24, 2016 at 11:08 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:

> On Wed, Aug 24, 2016 at 8:41 AM, Fred Cooke <fred.co...@gmail.com> wrote:
> > Fair call re embedded pom, however it's quite convenient to just browse
> to
> > it and read.
> I'd like to vent another opinion: the build pom makes it hard to grok
> the information I need as a consumer of a library. I really don't need
> to wade through 20 pages of plugin configuration that doesn't affect
> me.
>

Something I'd like to add to this is that sometimes things in the build
section shouldn't really be exposed. In the OSS world it's probably not an
issue, but for enterprises it could be. So stripping the consumer POM would
solve that. For the parent POMs, plugin stuff needs to be available as it
could be inherited. Unfortunately as this is where this "sensitive" config
very often is handled. I don't see any solution to this though as unless we
introduce two different sorts of parents; artifact parents (think of
corporate poms) and parents available during build (think of parent in a
multi-module build). Could be too complicated though.

/Anders



>
> I would even posit that issueManagement, scm, and url should not be
> part of the consumer POM as these are external to the artifact and
> live separate lives. I'd rather see a different file that lists that
> particular information that can be updated when someone switches from
> JIRA to github issues, or from svn to git on bitbucket to git on
> github to a project specific git.project.io. Look what happened with
> codehaus or googlecode going away, or all projects moving from sf.net
> to github. Having the external information that doesn't relate to the
> particular version be external to the POM would make that much better.
>
> I really like the idea of consumer and producer POMs. Strip the
> consumer POM of everything <build> and <site> related.
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Reply via email to