You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by saimon <sa...@yahoo.co.uk> on 2002/12/11 01:20:57 UTC
Re: [plugin.properties] automated generation and documentation
Any thoughts about adopting a standard xml structure where each plugin
would list its properties so that gui wrappers have an easy time of
getting at all the plugin properties...
Martin, how are you tackling this atm?
Saimon
saimon wrote:
> +1. Would make my life a whole lot easier... ;)
>
> Currently, I have defined my own xml file for the properties, which
> would be a nightmare to maintain. I think that the core and each
> plugin should supply and maintain it's own properties.xml, something
> like....
>
> <category name = "user">
> <property name = "lib.repo" scope="" value = "/home/saimonm/"
> type="java.io.File"/>
> <property name = "maven.repo.local" scope="" value =
> "/home/saimonm/" type="java.io.File"/>
> <property name = "maven.plugin.dir" scope="" value =
> "/home/saimonm/" type="java.io.File"/>
> <property name = "maven.repo.remote" scope="" value = "xxx"
> type="java.lang.String"/>
> <property name = "maven.repo.central" scope="" value = "xxx"
> type="java.lang.String"/>
> <property name = "maven.repo.central.directory" scope="" value
> = "xxx" type="java.lang.String"/>
> <property name = "maven.updateSite" scope="" value = "xxx"
> type="java.lang.String"/>
> <property name = "maven.repo.remote.enabled" scope="" value =
> "true" type="java.lang.Boolean"/>
> <property name = "maven.home" scope="" value = "/home/saimonm/"
> type="java.io.File"/>
> <property name = "maven.username" scope="" value = "xxx"
> type="java.lang.String"/>
> </category>
>
> This is an excerpt of what I came up with to handle properties in
> mavenizer (when it's done you can find it in
> http://mevenide.sourceforge.net. It's quite common sense I think. The
> scope attribute is only used internally by mavenizer to make sure the
> property is written back to the appropriate property file (one of
> project, user, build).
>
> The 'type' attribute is just an 'extra' I added in maveniser to allow
> groovy property editors.
>
> I divided the properties into 'categories', which is handy when
> navigating through the properties. Each plugin would get it's own root
> category and could define any subcategories (At the moment I only
> handle one category level.)
>
> This would really help gui tools around maven IMHO...
>
> Saimon
>
> Ara Abrahamian wrote:
>
>> 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:Mmaczka@cqs.ch]
>>> 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: dion@multitask.com.au [mailto:dion@multitask.com.au]
>>> 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="dion@multitask.com.au">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 <Mm...@cqs.ch> 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:turbine-maven-dev-unsubscribe@jakarta.apache.org>
>>>>
>>>
>>> For
>>>
>>>
>>>> additional commands, e-mail:
>>>>
>>>
>>> <mailto:turbine-maven-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>> ForwardSourceID:NT00091366
>>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>> --
>>> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
>>> unsubscribe@jakarta.apache.org>
>>> For additional commands, e-mail: <mailto:turbine-maven-dev-
>>> help@jakarta.apache.org>
>>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: [plugin.properties] automated generation and documentation
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2002-12-10 at 19:20, saimon wrote:
> Any thoughts about adopting a standard xml structure where each plugin
> would list its properties so that gui wrappers have an easy time of
> getting at all the plugin properties...
There is a plugin object, which extends a project object, so put it in
the model somewhere so that GUI tools can simply use MavenUtils pull in
the plugin object and then everything is simple.
>
> Martin, how are you tackling this atm?
>
> Saimon
>
> saimon wrote:
>
> > +1. Would make my life a whole lot easier... ;)
> >
> > Currently, I have defined my own xml file for the properties, which
> > would be a nightmare to maintain. I think that the core and each
> > plugin should supply and maintain it's own properties.xml, something
> > like....
> >
> > <category name = "user">
> > <property name = "lib.repo" scope="" value = "/home/saimonm/"
> > type="java.io.File"/>
> > <property name = "maven.repo.local" scope="" value =
> > "/home/saimonm/" type="java.io.File"/>
> > <property name = "maven.plugin.dir" scope="" value =
> > "/home/saimonm/" type="java.io.File"/>
> > <property name = "maven.repo.remote" scope="" value = "xxx"
> > type="java.lang.String"/>
> > <property name = "maven.repo.central" scope="" value = "xxx"
> > type="java.lang.String"/>
> > <property name = "maven.repo.central.directory" scope="" value
> > = "xxx" type="java.lang.String"/>
> > <property name = "maven.updateSite" scope="" value = "xxx"
> > type="java.lang.String"/>
> > <property name = "maven.repo.remote.enabled" scope="" value =
> > "true" type="java.lang.Boolean"/>
> > <property name = "maven.home" scope="" value = "/home/saimonm/"
> > type="java.io.File"/>
> > <property name = "maven.username" scope="" value = "xxx"
> > type="java.lang.String"/>
> > </category>
> >
> > This is an excerpt of what I came up with to handle properties in
> > mavenizer (when it's done you can find it in
> > http://mevenide.sourceforge.net. It's quite common sense I think. The
> > scope attribute is only used internally by mavenizer to make sure the
> > property is written back to the appropriate property file (one of
> > project, user, build).
> >
> > The 'type' attribute is just an 'extra' I added in maveniser to allow
> > groovy property editors.
> >
> > I divided the properties into 'categories', which is handy when
> > navigating through the properties. Each plugin would get it's own root
> > category and could define any subcategories (At the moment I only
> > handle one category level.)
> >
> > This would really help gui tools around maven IMHO...
> >
> > Saimon
> >
> > Ara Abrahamian wrote:
> >
> >> 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:Mmaczka@cqs.ch]
> >>> 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: dion@multitask.com.au [mailto:dion@multitask.com.au]
> >>> 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="dion@multitask.com.au">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 <Mm...@cqs.ch> 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:turbine-maven-dev-unsubscribe@jakarta.apache.org>
> >>>>
> >>>
> >>> For
> >>>
> >>>
> >>>> additional commands, e-mail:
> >>>>
> >>>
> >>> <mailto:turbine-maven-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>> ForwardSourceID:NT00091366
> >>>>
> >>>
> >>> --
> >>> To unsubscribe, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>> For additional commands, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>>
> >>> --
> >>> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> >>> unsubscribe@jakarta.apache.org>
> >>> For additional commands, e-mail: <mailto:turbine-maven-dev-
> >>> help@jakarta.apache.org>
> >>>
> >>
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <ma...@jakarta.apache.org>
> >>
> >>
> >>
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: [plugin.properties] automated generation and documentation
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hi Saimon,
Currently (a part of) the list you specify is supported by the mevenide
eclipse plugin (actually one on the few things that work). It's just
added to the preference page in eclipse. So eclipse arranges storage of
those settings via the generic preference stuff in eclipse.
Probably I need to start working on it again, currently the project is
kind of sleeping :) Probably need some planning to set some priorities
:)
Mvgr,
Martin
On Wed, 2002-12-11 at 01:20, saimon wrote:
> Any thoughts about adopting a standard xml structure where each plugin
> would list its properties so that gui wrappers have an easy time of
> getting at all the plugin properties...
>
>
> Martin, how are you tackling this atm?
I
>
> Saimon
>