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