POM design principles: what qualifies for the model?
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM design principles: what qualifies for the model?
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
Re: POM design principles: what qualifies for the model?
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
Re: POM design principles: what qualifies for the model?
On 7/28/11 12:51 PM, Benson Margulies wrote: I'm not trying to argue to murderscm 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 Caseyjdca...@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
Re: POM design principles: what qualifies for the model?
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM design principles: what qualifies for the model?
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 bimargul...@gmail.comwrote: 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
