POM design principles: what qualifies for the model?

[Benson Margulies <bi...@gmail.com>]

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.

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.

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM design principles: what qualifies for the model?

[Arnaud Héritier <ah...@gmail.com>]

Something what was denounced in the past was the mix of delivery
informations (identity, dependencies, ...) and project informations (build
configuration, build environment, team, ....)
delivery informations are immutable whereas for project informations it
depends. Build configuration used to create the delivery should be inmutable
(I need to be able to reproduce the binaries creation). But some others part
may change over the time. The most frequent is the scm, the project mailing
list ... Even if when the delivery was done with its sources in SCM X (svn
for example) and its support was done on the project mailing list Y (hosted
by sourceforge), when I will want to use the delivery I will want to know
were sources are now (perhaps git) and how to contact its team (perhaps
google groups).
Thus all of that to say that we cannot/shouldn't deny the fact that a
project lives. For some information it is important to have them immutable
while for some others we should provide a mechanism to be able to keep them
up-to-date with the project life.

Note : Yes it doesn't help on the how to do :-)

Arnaud


On Thu, Jul 28, 2011 at 7:16 PM, Benson Margulies <bi...@gmail.com>wrote:

> >>
> >> 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.
> >
> > what about existing xml tools for this: namespaces, URNs, etc.?
>
> Let me do some thinking and writing on the wiki.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: POM design principles: what qualifies for the model?

[Benson Margulies <bi...@gmail.com>]

>>
>> 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.
>
> what about existing xml tools for this: namespaces, URNs, etc.?

Let me do some thinking and writing on the wiki.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM design principles: what qualifies for the model?

[John Casey <jd...@commonjava.org>]

On 7/28/11 12:51 PM, Benson Margulies wrote:
> I'm not trying to argue to murder<scm>  and friends, just to
> understand how we got here.

"murder" nice. :-)

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

what about existing xml tools for this: namespaces, URNs, etc.?

I know we'd have to re-solve the problem for other syntaxes, but that's 
minor compared to creating the other syntax in the first place, right?

>
> On Thu, Jul 28, 2011 at 11:10 AM, John Casey<jd...@commonjava.org>  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 descriptive...to 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> John Casey
>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

-- 
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM design principles: what qualifies for the model?

[Benson Margulies <bi...@gmail.com>]

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 <jd...@commonjava.org> 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 descriptive...to 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: POM design principles: what qualifies for the model?

[John Casey <jd...@commonjava.org>]

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 descriptive...to 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

-- 
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org