Re: [plugin.properties] automated generation and documentation

saimon Mon, 25 Nov 2002 14:41:04 -0800

+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:[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]>

__________________________________________________
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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [plugin.properties] automated generation and documentation

Reply via email to