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

Reply via email to