It's a good idea to write such an IDE plugin. Very useful. Now the question is: there are many plugins there and each has a lot of properties, how can we write a generic IDE plugin?
Well, I think properties of plugins should be cleanly documented it an xml file and then read and interpreted by the IDE plugin and shown on screen. We've done something like that in xdoclet, each module has an xtags.xml file which defines all the @tags, properties of tags, type of the property, level and other constraints. So the IDEA/JEDit/whatever plugin reads it and constructs a gui that let's you edit them visually. This way we didn't have to create a specific plugin for each specific module. It's not a 'documentation' xml file like xdoc, it follows a well-defined dtd. Imho the same should be done for Maven too. So there will be a module-properties.xml file adhering to a dtd in meta-inf of each module. This file will be read by both the IDE gui and also XSLT-ed to xdoc for document generation. What do you think? Ara. > -----Original Message----- > From: Michal Maczka [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 25, 2002 12:06 PM > To: 'Turbine Maven Developers List' > Subject: RE: [plugin.properties] automated generation and documentation > > Hi dIon, > > I feel that this is very important from a perspective of integration of > Maven with IDE(s) or for Maven GUI(why not? :)). > I suppose that IDE can grab a plugin list, show it to user and enable to > set > appropriate properties > for the plugins which will be used. In this case plugin.xml should > possibly > contain as many information > as possible for GUI. What is difficult in this process: some properties > are > shared among many plugins and some properties are > coming directly from POM. I think that GUI should be aware of this > distinction of properties. > > Michal > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 21, 2002 11:59 PM > To: Turbine Maven Developers List > Subject: Re: [plugin.properties] automated generation and documentation > > > This is in the plan, however the format will more closely match that of > goals.xml, e.g. > > <?xml version="1.0"?> > <document> > > <properties> > <title>Maven Distribution Plug-in Goals</title> > <author email="[EMAIL PROTECTED]">dIon Gillard</author> > </properties> > > <body> > <properties> > <property> > <name>dist</name> > <optional>yes</optional> > <description> > This is the default goal of the plugin and simply attains > the <code>dist:build</code> goal. > </description> > </property> > .... > </properties> > </body> > </document> > -- > dIon Gillard, Multitask Consulting > Blog: http://www.freeroller.net/page/dion/Weblog > Work: http://www.multitask.com.au > > > Michal Maczka <[EMAIL PROTECTED]> wrote on 22/11/2002 02:09:59 AM: > > > I have observed that some of the plugins are missing a description of > > properties which they are sensitive to. > > This is sometimes very painful. > > > > If there is already a way (or will be soon) to automate generation of > > documentation for goals: > > plugin.jelly -> goals.xml -> goals.html > > > > Why not to have automated way for documenting properties: > > properties.xml -> plugin.properties > > -> xdocs/properties.xml -> properties.html > > > > > > The missing element of the puzzle which is not existing for the moment > is > > properties.xml file > > The content of that file may look like follows: > > > > <properties> > > > > <!--this lets to divide properties into logical groups - see e.g > > > http://jakarta.apache. > > org/turbine/maven/reference/plugins/java/properties.ht > ml -> > > > > <group> > <name>compile</name> > <title>Compile > > Settings</title> > <group> > <group> > <name>Jar > > Settings</name> > <title>jar</title> > <group> > > > <group> > <name>Deploy Settings</name> > > > <title>deploy</title> > <group> > <group> > > > <name>other</name> <!--it think that group should be predefined, > > or > there must me some other way (see #1 below) -> > <title>Other > > Settings</title> > <group> > > <property> > <name>maven. > > xxx.yyy</name> > <default>123</default> > <description> > > > khkjhkjHKJhkjhjkhkjhkj > dfssssssssssssssssfdds > > > fdssssssssssssssss > </description> > > > <optional>true</optional> > <group>compile<group> <!-- > > propertes can be gruped - this qualifies > this property to a given > > group defined above - > > </property> > <property> > ... > > > </property> > <property> > <name>maven.vvv.ssss</name> > > > <default>true</default> > <description> > Here is a > > description as now is in xdocs/properties.xml > </description> > > > <optional>false</optional> > <group>other</group> > > > </property> > <properties> > > > > Ad #1 > Often properties may be also > > used in other plugins or taken from POM. > In this case they should > > not be written to "plugin.properties" file even if > they are required > > > The group called "others" can be used to denote this situation. I > > guess that > smarter solutin can be found. > > I think that this should > > be fairly simple to implement. > > > Michal > > -- > To unsubscribe, e-mail: < > > mailto:[EMAIL PROTECTED]> > For > > additional commands, e-mail: > <mailto:[EMAIL PROTECTED] > > > > > > > ForwardSourceID:NT00091366 > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:turbine-maven-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-maven-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
