I'm opposed to namespaces for two reasons. One is a global reason, the other applies only to 'core' configuration.
The global reason: read all the very cogent writing from the HTML5 process as to why they have run screaming away from namespaces. The more local reason: Consider what started this discussion recently: adding a declaration to a POM that indicates that the project serves the purpose of multiple artifacts for dependency management. If you put that in a namespace, how to do you explain it? "It was invented in 2011" is one possible explanation. Pretty soon, we're up our ears in a confusing collection of namespaces. Spring, at least, groups things functionally into namespaces. But that doesn't work if the criteria is 'new feature -> new namespace'. And you've got users cursing us as they try to remember which namespace goes with which feature. On the other hand, if you want to open the door for new information in the POM that 'belongs to' particular plugins (e.g. m2e), namespaces would at least make logical sense, unless you are persuaded by the HTML analogy. On Wed, Jun 29, 2011 at 9:07 AM, Nigel Magnay <nigel.mag...@gmail.com> wrote: >> >> >> >> If tools validate against the schema, they know when a POM is, in >> fact, valid for its declared model. Thus, any elements that the tool >> does not recognize are proved to be 'messengers from the future'. >> >> > It would help enormously if 'messengers from the future' used an appropriate > XML namespace so that they could be discarded by clients that don't > understand them. > > It always surprised me that the pom files never allowed the plugins to > extend the meaning. For example, using some plugins I'm forced to maintain a > separate config file, referencing much of the same information by > coordinate. It'd be nice to be able to do things like > > <dependency> > <groupId>grp<groupId> > <artifactId>flex-components> > <version>1.0</version> > <scope fm:domain="default" fm:url="/components/flex.swf">rsl</scope> > <dependency> > > > I guess existing tooling is sadly not namespace aware. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
