maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: POM design principles: what qualifies for the model?
Date Thu, 28 Jul 2011 16:51:45 GMT
I'm not trying to argue to murder <scm> and friends, just to
understand how we got here.

I am now going to go to the wiki page and add some more thinking about
the use of extensible (e.g. property-set) XML for things like scm.

On Thu, Jul 28, 2011 at 11:10 AM, John Casey <> wrote:
> On 7/28/11 7:43 AM, Benson Margulies wrote:
>> I'm trying to think about the questions of what might go into pom5,
>> and I realized that I am confused about the current design.
>> M3 deprecated 'reporting' but not 'scm'. I don't see the logic.
>> I propose to divide all POM content into two categories: things read
>> by the core of maven, and things read by plugins.
> I think you need another category: things that describe the project
> infrastructure.
> While there may not be plugins used in the project's build that require the
> <scm/> tag, it would be a MAJOR problem for tooling that reads POMs from the
> repository not to have access to that information.
> Even though some projects don't provide it, it's possible to mandate within
> an organization that this section be present and correct. If we instead
> mandate that a particular plugin configuration be present and correct, this
> is a very different type of instruction.
> Plugins are the mechanism by which projects get built, and those use a mix
> of project-level information and plugin-level information. However, there's
> another aspect of the POM, which is purely give people a
> fair chance at interacting with project infrastructure if all they have is
> the POM.
>> The rationale for eliminating reporting, as I thought I understood it,
>> was that it was 'only read by a plugin.'
>> Well, scm, licensing, distribution management, resources, ... most of
>> the POM is 'only read by a plugin.' Sometimes by plugins that are
>> called out in the superpom, and sometimes not.
>> scm strikes me particularly as a target: It's used for three things,
>> and those things can be in conflict. One is to produce a
>> human-readable report about where humans can find the source, another
>> is to give the release plugin enough information to tag a release, and
>> the third is to provide defaults to the maven-scm-plugin.
> I also have tooling that relies on this section to checkout and perform a
> test build, for all dependencies of a given project. This external tooling
> should have access to project infrastructure.
> If we want to use a different - more flexible? - syntax to provide that
> information, that's totally cool...but we can't just ignore that use case of
> the POM.
>> We wouldn't be having this painful discussion about how to make git
>> work if the second item had just been handled by configuration in the
>> release plugin itself instead of being a top-level element. On the
>> other hand, we'd be having a problem allowing for the 'base my url on
>> my parent's url'.
>> Can someone clarify this for me?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> John Casey
> Developer, PMC Chair - Apache Maven (
> Blog:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message