> With eclipse we do autocompletion for nested elements using reflection, if > type information is available (e.g. generics are used for List and Map > elements) in almost the same as in Maven (almost - because maven takes > config and tries to apply each separate value, while from the editor we > need to discover what the model is overall - this might lead to > inconsistencies in some corner cases).
Sounds good :) Is it also possible to use enum values for autcompletion when within a tag referencing an enum value ? That would be awesome. > Also it's worth to note that maven > doesn't look at @Parameter annotations in nested elements, it's all > reflection. Ah, didn't know this. So its not possible to specify default values and/or whether a (inner) config parameter is required. An XSD based implementation could automatically insert tags for required values here, too (is the XSD is prepared accordinglingly with a minOccurs=1). ... roland > 2016-06-05 23:23 GMT+03:00 Roland Huss <[email protected]>: > >> >>> 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.) >> >> That's true for IDEA as well. Autocompletion works nicely on top-level >> configuration elements, however for nested structures like lists and >> maps it doesn't work so well. I.e. deducing the element name of a >> list-element it e.g. not possible by an IDE since in Maven afaik any >> name is allowed for a list-element's tag. In my case >> (docker-maven-plugin) I have configuration which is nested up to four >> levels. That's one of the reason wgy I'm looking for IDE support here >> (which as I said seems to work only on the top-level in IDEA). >> >> How is the situation in Eclipse ? Is it possible to do autocompletion on >> list elements (and their @Parameter), too ? >> >> In general I have the feeling that support for XSD based autocompletion >> is much more matured in IDEs. >> >> ... roland >> >> >>> 2016-06-05 12:32 GMT+03:00 Stian Soiland-Reyes <[email protected]>: >>> >>>> +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" <[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] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
