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). Also it's worth to note that maven doesn't look at @Parameter annotations in nested elements, it's all reflection.
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] > > -- Regards, Anton.
