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
