You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by jv...@apache.org on 2004/01/06 21:48:47 UTC
cvs commit: maven-plugins/announcement plugin.properties
jvanzyl 2004/01/06 12:48:47
Modified: announcement plugin.properties
Log:
o property is gleaned within the plugin using the pom directly.
Revision Changes Path
1.2 +1 -1 maven-plugins/announcement/plugin.properties
Index: plugin.properties
===================================================================
RCS file: /home/cvs/maven-plugins/announcement/plugin.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- plugin.properties 16 Nov 2003 22:48:56 -0000 1.1
+++ plugin.properties 6 Jan 2004 20:48:46 -0000 1.2
@@ -3,4 +3,4 @@
# -------------------------------------------------------------------
# Version for which to create a release note.
-maven.announcement.version = ${pom.currentVersion}
+## maven.announcement.version = ${pom.currentVersion}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2004-01-06 at 15:52, Vincent Massol wrote:
> Hi Jason,
>
> There was one nice benefit of having properties defined in
> plugin.properties: it was clearly stating what properties where public
> and what were private. By removing them you are removing this "feature".
>
> How can we restore this?
In addition to @tags which I think would be very useful as the generated
properties.xml file would come from the source we could also use a
convention like:
maven.xdoc.version = default
Which would indicate a default value will be selected within the plugin.
Not crazy on but it's a suggestion. I think people could just look at
the top of the jelly.plugin and know it was up-to-date.
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: jvanzyl@apache.org [mailto:jvanzyl@apache.org]
> > Sent: 06 January 2004 21:49
> > To: maven-plugins-cvs@apache.org
> > Subject: cvs commit: maven-plugins/announcement plugin.properties
> >
> > jvanzyl 2004/01/06 12:48:47
> >
> > Modified: announcement plugin.properties
> > Log:
> > o property is gleaned within the plugin using the pom directly.
> >
> > Revision Changes Path
> > 1.2 +1 -1 maven-plugins/announcement/plugin.properties
> >
> > Index: plugin.properties
> > ===================================================================
> > RCS file: /home/cvs/maven-plugins/announcement/plugin.properties,v
> > retrieving revision 1.1
> > retrieving revision 1.2
> > diff -u -r1.1 -r1.2
> > --- plugin.properties 16 Nov 2003 22:48:56 -0000 1.1
> > +++ plugin.properties 6 Jan 2004 20:48:46 -0000 1.2
> > @@ -3,4 +3,4 @@
> > #
> -------------------------------------------------------------------
> >
> > # Version for which to create a release note.
> > -maven.announcement.version = ${pom.currentVersion}
> > +## maven.announcement.version = ${pom.currentVersion}
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2004-01-06 at 16:36, Jason van Zyl wrote:
> > I think we need something more. Making it mandatory for the plugin to
> > work would be better I think.
>
> Currently there is no real way to distinguish between a public property
> and a private one even though in most cases they are almost always
> public.
>
> I would be all for requiring some structure in the plugin.jelly or
> project.xml that could be examined by the plugin plugin and not built
> the plugin if the required structure is missing.
>
> You're right that the docs suck and this would be one way to try and
> enforce it. If there are no public properties then that would have to be
> explicity stated too.
>
Having doco for properties is actually a more general problem as any
Maven project requires this come to think of it. People may have
properties for their particular build so maybe we could expand the
project/properties to include optional descriptions and default values
and we could easily generate doco for that. This obviously requires more
work but may be a better solution in the long run and not really hard to
implement.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Michal Maczka <mm...@interia.pl>.
> You're right that the docs suck and this would be one way to try and
> enforce it. If there are no public properties then that would have to be
> explicitly stated too.
>
I am all for not only explicitly stating public properties(+1) but also for
a) stating public goals
b) expressing constrains of properties
(I have "dumb" GUIs in my mind, which can try to help to customize plugin).
IMHO all those things are somehow linked together and can be most likely
solved in a common way.
Having in mind that we are aiming at having not only jelly plugins (Java
rocks :)),
we can think ahead and try to find a common way of describing the
functionality exported by the given plugin.
Maybe some 'smart' XML file stating plugin "exports" could be a solution
(exports = goals + properties).
This file can be probably auto-generated from jelly script or java code.
[off topic]
Other think we can think of is to enforce that goal
( an example) war:war is implemented in war plugin (string before colon
determines the plugin name)
It's not that simple as goals can be overridden in maven.xml etc.
It is important for make things like:
maven help -Dplugin=war (displays goals exported by war plugin)
possible
but first of all it's required for better scalability
and for simplifying lazy loading of plugins and possibly downloading them on
demand
(war plugin was requested via invocation of war:war goal, and if it's not
installed - we can try to fetch it).
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2004-01-07 at 09:33, dion@multitask.com.au wrote:
> Jason van Zyl <jv...@maven.org> wrote on 07/01/2004 08:36:28 AM:
>
> > Currently there is no real way to distinguish between a public property
> > and a private one even though in most cases they are almost always
> > public.
>
> Aren't properties in a plugin's project.properties not overrideable?
I was only talking about plugin.properties that within that file the
developer might have place a property in there for internal use. There
is no way to distinguish. As far as the processing of project.properties
they are really for the plugin build but as the plugin is processed as a
normal project I'm sure some have mistakenly used it for the plugin
runtime.
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by di...@multitask.com.au.
Jason van Zyl <jv...@maven.org> wrote on 07/01/2004 08:36:28 AM:
> Currently there is no real way to distinguish between a public property
> and a private one even though in most cases they are almost always
> public.
Aren't properties in a plugin's project.properties not overrideable?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2004-01-06 at 16:26, Vincent Massol wrote:
> The problem is that, as you know, documentation is far from reality...
> :-)
That is now the problem of the plugin developers, but I agree it has
been a problem in the past.
> Just look at existing plugin documentation and you'll see that the
> properties.xml files are not a good reflect of reality. OTOH, the
> plugin.properties file can only be accurate.
It can be off too as there can be properties that aren't used but the
same is true of using @tags in the top of jelly.plugin. If you don't
care for your plugin it's not going to grow up :-)
> Whenever I use a plugin, I never rely on its properties.xml doc. I
> always go to the source (i.e the plugin.properties file) as I know it
> cannot be wrong. The only thing wrong it can have is not to define a
> property as public.
>
> >
> > But it would be nice to have something generate this. How about
> > something at the top of a jelly plugin like:
> >
> > <!--
> > @maven.announcement.version The variable controlling the ann
> version.
> > -->
>
> That's still documentation. And as it's not mandatory, plugin writer may
> (and will!) still forget adding it.
>
> >
> > And have that create properties.xml files?
>
> I think we need something more. Making it mandatory for the plugin to
> work would be better I think.
Currently there is no real way to distinguish between a public property
and a private one even though in most cases they are almost always
public.
I would be all for requiring some structure in the plugin.jelly or
project.xml that could be examined by the plugin plugin and not built
the plugin if the required structure is missing.
You're right that the docs suck and this would be one way to try and
enforce it. If there are no public properties then that would have to be
explicity stated too.
> Any idea?
>
> Thanks
> -Vincent
>
> >
> >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: jvanzyl@apache.org [mailto:jvanzyl@apache.org]
> > > > Sent: 06 January 2004 21:49
> > > > To: maven-plugins-cvs@apache.org
> > > > Subject: cvs commit: maven-plugins/announcement plugin.properties
> > > >
> > > > jvanzyl 2004/01/06 12:48:47
> > > >
> > > > Modified: announcement plugin.properties
> > > > Log:
> > > > o property is gleaned within the plugin using the pom directly.
> > > >
> > > > Revision Changes Path
> > > > 1.2 +1 -1
> maven-plugins/announcement/plugin.properties
> > > >
> > > > Index: plugin.properties
> > > >
> ===================================================================
> > > > RCS file:
> /home/cvs/maven-plugins/announcement/plugin.properties,v
> > > > retrieving revision 1.1
> > > > retrieving revision 1.2
> > > > diff -u -r1.1 -r1.2
> > > > --- plugin.properties 16 Nov 2003 22:48:56 -0000 1.1
> > > > +++ plugin.properties 6 Jan 2004 20:48:46 -0000 1.2
> > > > @@ -3,4 +3,4 @@
> > > > #
> > > -------------------------------------------------------------------
> > > >
> > > > # Version for which to create a release note.
> > > > -maven.announcement.version = ${pom.currentVersion}
> > > > +## maven.announcement.version = ${pom.currentVersion}
> > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.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
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 06 January 2004 22:12
> To: Maven Developers List
> Subject: RE: cvs commit: maven-plugins/announcement plugin.properties
>
> On Tue, 2004-01-06 at 15:52, Vincent Massol wrote:
> > Hi Jason,
> >
> > There was one nice benefit of having properties defined in
> > plugin.properties: it was clearly stating what properties where
public
> > and what were private. By removing them you are removing this
"feature".
> >
> > How can we restore this?
>
> How about this:
>
> http://cvs.apache.org/viewcvs.cgi/maven-
> plugins/announcement/xdocs/properties.xml?rev=1.1&view=auto
The problem is that, as you know, documentation is far from reality...
:-) Just look at existing plugin documentation and you'll see that the
properties.xml files are not a good reflect of reality. OTOH, the
plugin.properties file can only be accurate.
Whenever I use a plugin, I never rely on its properties.xml doc. I
always go to the source (i.e the plugin.properties file) as I know it
cannot be wrong. The only thing wrong it can have is not to define a
property as public.
>
> But it would be nice to have something generate this. How about
> something at the top of a jelly plugin like:
>
> <!--
> @maven.announcement.version The variable controlling the ann
version.
> -->
That's still documentation. And as it's not mandatory, plugin writer may
(and will!) still forget adding it.
>
> And have that create properties.xml files?
I think we need something more. Making it mandatory for the plugin to
work would be better I think.
Any idea?
Thanks
-Vincent
>
>
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: jvanzyl@apache.org [mailto:jvanzyl@apache.org]
> > > Sent: 06 January 2004 21:49
> > > To: maven-plugins-cvs@apache.org
> > > Subject: cvs commit: maven-plugins/announcement plugin.properties
> > >
> > > jvanzyl 2004/01/06 12:48:47
> > >
> > > Modified: announcement plugin.properties
> > > Log:
> > > o property is gleaned within the plugin using the pom directly.
> > >
> > > Revision Changes Path
> > > 1.2 +1 -1
maven-plugins/announcement/plugin.properties
> > >
> > > Index: plugin.properties
> > >
===================================================================
> > > RCS file:
/home/cvs/maven-plugins/announcement/plugin.properties,v
> > > retrieving revision 1.1
> > > retrieving revision 1.2
> > > diff -u -r1.1 -r1.2
> > > --- plugin.properties 16 Nov 2003 22:48:56 -0000 1.1
> > > +++ plugin.properties 6 Jan 2004 20:48:46 -0000 1.2
> > > @@ -3,4 +3,4 @@
> > > #
> > -------------------------------------------------------------------
> > >
> > > # Version for which to create a release note.
> > > -maven.announcement.version = ${pom.currentVersion}
> > > +## maven.announcement.version = ${pom.currentVersion}
> > >
> > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2004-01-06 at 15:52, Vincent Massol wrote:
> Hi Jason,
>
> There was one nice benefit of having properties defined in
> plugin.properties: it was clearly stating what properties where public
> and what were private. By removing them you are removing this "feature".
>
> How can we restore this?
How about this:
http://cvs.apache.org/viewcvs.cgi/maven-plugins/announcement/xdocs/properties.xml?rev=1.1&view=auto
But it would be nice to have something generate this. How about
something at the top of a jelly plugin like:
<!--
@maven.announcement.version The variable controlling the ann version.
-->
And have that create properties.xml files?
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: jvanzyl@apache.org [mailto:jvanzyl@apache.org]
> > Sent: 06 January 2004 21:49
> > To: maven-plugins-cvs@apache.org
> > Subject: cvs commit: maven-plugins/announcement plugin.properties
> >
> > jvanzyl 2004/01/06 12:48:47
> >
> > Modified: announcement plugin.properties
> > Log:
> > o property is gleaned within the plugin using the pom directly.
> >
> > Revision Changes Path
> > 1.2 +1 -1 maven-plugins/announcement/plugin.properties
> >
> > Index: plugin.properties
> > ===================================================================
> > RCS file: /home/cvs/maven-plugins/announcement/plugin.properties,v
> > retrieving revision 1.1
> > retrieving revision 1.2
> > diff -u -r1.1 -r1.2
> > --- plugin.properties 16 Nov 2003 22:48:56 -0000 1.1
> > +++ plugin.properties 6 Jan 2004 20:48:46 -0000 1.2
> > @@ -3,4 +3,4 @@
> > #
> -------------------------------------------------------------------
> >
> > # Version for which to create a release note.
> > -maven.announcement.version = ${pom.currentVersion}
> > +## maven.announcement.version = ${pom.currentVersion}
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: cvs commit: maven-plugins/announcement plugin.properties
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Jason,
There was one nice benefit of having properties defined in
plugin.properties: it was clearly stating what properties where public
and what were private. By removing them you are removing this "feature".
How can we restore this?
Thanks
-Vincent
> -----Original Message-----
> From: jvanzyl@apache.org [mailto:jvanzyl@apache.org]
> Sent: 06 January 2004 21:49
> To: maven-plugins-cvs@apache.org
> Subject: cvs commit: maven-plugins/announcement plugin.properties
>
> jvanzyl 2004/01/06 12:48:47
>
> Modified: announcement plugin.properties
> Log:
> o property is gleaned within the plugin using the pom directly.
>
> Revision Changes Path
> 1.2 +1 -1 maven-plugins/announcement/plugin.properties
>
> Index: plugin.properties
> ===================================================================
> RCS file: /home/cvs/maven-plugins/announcement/plugin.properties,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- plugin.properties 16 Nov 2003 22:48:56 -0000 1.1
> +++ plugin.properties 6 Jan 2004 20:48:46 -0000 1.2
> @@ -3,4 +3,4 @@
> #
-------------------------------------------------------------------
>
> # Version for which to create a release note.
> -maven.announcement.version = ${pom.currentVersion}
> +## maven.announcement.version = ${pom.currentVersion}
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org