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