Just on a side note, eclipse m2e pom editor does have an autocomplete for plugin configuration based on the plugin descriptor and the classes that are used. +1 to namespace support though, since it could be used to provide autocomplete for parts that cannot be deduced by looking at the model (xpp3dom elements, maps, etc.)
2016-06-05 12:32 GMT+03:00 Stian Soiland-Reyes <st...@apache.org>: > +1 to ALLOW (but not require) the second use case of <configuration > xmlns=..>, this let you have autocomplete say in Eclipse's XML editor. > However I believe a xsi schemalocation would then still be needed per > plugin unless a catalogue is accessible out of bands, so it would still be > a bit verbose. > > (I never understood why the default xsi schemalocation can't be the > namespace) > On 5 Jun 2016 8:38 a.m., "Roland Huss" <roland.h...@gmail.com> wrote: > > > > Do you really think introducing XML namespaces would make the handling > > > of the pom better ? In particular if you have a separate namespace for > > > every plugin? (At apache maven project we have 49 plugins ? This would > > > mean in consequence 49 namespaces? And at mojohaus there are about > > > another 50 plugins? So this means having to use the configuration > > > parameters for all the plugins and on top you need to do namespace > > > configuration in your pom file? I'm the opinion this would make things > > > worse than better...(There are some things which are better)... > > > > I don't request to *require* the use of namespaces, but not to break if > > a namespace is used. It would be competely sufficient when Maven would > > ignore namespaces. The <configuration> element is specified having a > > <xs:any> content anyway. > > > > BTW, you don't have to specify the namespace on top, but can do at > > directly on the enclosing element itself. > > > > Here's my use case: I'm writing a Maven plugin which has an XSD for its > > configuration. This is useful for rich autocompletion and inline > > documentation tooltips in a decent IDE. > > > > There are two ways how you could use this xsd: > > > > * You can declare a namespace with prefix in the preamble of your > > pom.xml but then have to use the prefix for all your configuration > > options (which is quite a lot in my use case). You are not required to > > use a namespace, though (because of the <xs:any> type of a configuration) > > > > * Or, the better, more elegant way is to switch to the default namespace > > to your plugin int the <configuration> element : > > > > <project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xmlns="http://maven.apache.org/POM/4.0.0"; > > xsi:schemaLocation="...."> > > ... > > <plugin> > > .... > > <m:configuration > > xmlns:m="http://maven.apache.org/POM/4.0.0"; > > xmlns="https://myplugin.org/v1";> > > > > <myOption>bla</myOption> > > .... > > </m:configuration> > > </plugin> > > ... > > </project> > > > > Both usage patterns are currently broken in Maven 3.3.9 > > > > > In general pom changes in any way could only become part of pom model 5 > > > (Maven 4/5 in line) cause it would break to many things...You can take > > > a deep look into the jira for Maven 4.. > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330198 > > > > There is no change in the pom syntax required at all (i.e. the Schema is > > exactly the same as defined in http://maven.apache.org/POM/4.0.0), its > > only about the proper XML parsing of a pom model 4 with namespaces > > (which btw each decent XML parser is capable of). > > > > But even then, is the document > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model > > obsolete /wrt to XML namespaces ? Or what is the status of namespace > > support for the next major Maven version ? (sorry, couldn't find any > > information about this). > > > > cheers ... > > ... roland > > > > > > > > > > > > > > Kind regards > > > Karl Heinz Marbaise > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > -- Regards, Anton.
