> +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.
That's true, the schema location would need to be specified for the plugins where you intend to use autocompletion. But as you said, for all the default plugins, if they would provide an XSD for their configuration, one could establish an internal default catalog. But most plugins are probably not that complicated to justify the effort. However, there exist more complex setups like e.g. our docker-maven-plugin (here's an example: https://github.com/fabric8io/docker-maven-plugin/blob/master/samples/data-jolokia-demo/pom.xml#L292-L340). I don't know if that's the typical use case, but I know that people for similar use cases often go away from configuring things within a pom.xml and refer to external e.g. YAML files, which leads imo to sub-optimal developer experience because of the 'media break' and even less IDE support. ... roland > (I never understood why the default xsi schemalocation can't be the > namespace) > On 5 Jun 2016 8:38 a.m., "Roland Huss" <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
