You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2003/01/05 21:06:04 UTC
Re: Cactus Ant Tasks (was Re: [PROPOSAL] New directory structure?)
Vincent Massol wrote:
>
>>-----Original Message-----
>>From: Christopher Lenz [mailto:cmlenz@gmx.de]
>>Sent: 26 December 2002 16:13
>>To: Cactus Developers List
>>Subject: Cactus Ant Tasks (was Re: [PROPOSAL] New directory
>
> structure?)
>
>>Vincent Massol wrote:
>>[snip]
>>
>>>jakarta-cactus
>>> |_ anttasks
>>> (only keep in this subproject the Ant tasks that are not
>>
> related
>
>>> to Cactus. This subproject is expected to disappear over time
>>
> as
>
>>> it is expected Ant will provide solutions to perform what we
>>
> are
>
>>> doing)
>>
>>[snip]
>>
>>I'll take this as an opportunity to assemble an overview of what
>>currently exists in the anttasks module, and attach my thoughts about
>>each of the parts ...
>
>
> cool :-)
>
>
>> ---- Used at build time ----
>>
>>----------------------------------------------------------
>>org.apache.cactus.ant.ArgListTask
>>----------------------------------------------------------
>>I haven't completely understood why this task exists. IMHO
>>it could be just kicked out (deprecated ;-) ), and its use
>>replaced with the normal <arg>, <vmarg> and <sysproperty>
>>stuff instead, which also have more power when it comes to
>>handling paths etc.
>
>
> <arg>, <vmarg>, etc are not able to pass optional properties. If you
> write <vmarg value="-Dxxx=${some.properties}"/> and some.properties is
> not defined the called Ant script will receive a property xxx whose
> value is "${some.properties}" (and not "").
Hmm.. a possible solution would be to make <arg> et al accept if/unless
attributes. That would be in the Ant code base, of course. When I find
some time, I'll try to submit a corresponding patch to the Ant team.
>>----------------------------------------------------------
>>org.apache.cactus.ant.ChangeLogTask
>>----------------------------------------------------------
>>Without having looked at it closely, couldn't the use of
>>this task be replaced with the standard <cvschangelog> ?
>
>
> Almost, except that <cvschangelog> (which by the way was included in Ant
> by Peter Donald and myself) does not allow to specify to include/exclude
> files, which we need (it may do that now as I think I have asked to add
> this feature some while ago).
Okay. AFAICT, <cvschangelog> doesn't support filesets. BTW, that would
be patternsets, no?
Again, I'll try to get that into the Ant code base as soon as I find
some time (probably not so soon :-P ).
>
>>----------------------------------------------------------
>>org.apache.cactus.ant.CheckPropertiesTask
>>org.apache.cactus.ant.CheckPropertyItem
>>org.apache.cactus.ant.PropertyName
>>----------------------------------------------------------
>>All for checking whether a specific property has been set,
>>and optionally if it refers to an existing file. It is
>>used to check whether required JAR locations have been set
>>as properties, bailing if not. In addition, it outputs the
>>value of the properties.
>>IMHO, this task can be replaced by standard mechanisms,
>>using <available>, <fail>, etc. The drawback is a somewhat
>>longer build file.
>>
>>I'd like to avoid having to compile Ant tasks before being able to
>>compile the framework. I think that for <argList> and
>
> <checkProperties>
>
>>the additional overhead is not warranted. But just IMHO ;-)
>
>
> I'm +1 to remove any Ant non-standard Ant task provided we don't loose
> anything in functionality. ATM I don't see how to do this, except by
> trying to get our Ant tasks in the Ant optional jars (I tried some while
> ago but it is so hard to get heard on the Ant list that I stopped).
>
> WRT <checkProperties>, I don't know any nice out of the box Ant solution
> to this problem. The best solution I have is:
>
> <target name="check.property1">
> <available property="property1.exist" file="${property1}"/>
> <echo unless="property1.exist">XXXXXXXXXX</echo>
> </target>
>
> <target name="check.property2">
> <available property="property2.exist" file="${property2}"/>
> <echo unless="property2.exist">XXXXXXXXXX</echo>
> </target>
>
> [...]
>
> <target name="check.all"
> depends="check.property1,check.property2,[...]"/>
>
> So, if you have 10 properties to check, you need to add 60 lines of
> build code simply to check that the properties exist. And, it won't even
> tell you if the property is not defined or if it points to an invalid
> directory/file (but you can guess that). And you don't factorize the
> message being echoed, etc.
>
> There may be a better solution though...
>
> But I'm all with you with removing these custom tasks, so if you find
> solutions please go ahead if you have an itch to scratch.
For *required* properties, I don't think so much overhead is required.
Just one target with some <condition> and <fail unless='...'> tasks. For
optional properties, you usually need a separate 'warn' target (because
<echo> doesn't have if/else-support AFAIK), so that's more complex.
Anyway, I seldomly see the <checkProperty> task do anything useful,
because the master build file doesn't use it, and I usually invoke
everything from the master build file.
Usually, simply running ant with the "-verbose" option reveals any
problems that might occur during build, and in a more detailled fashion
than <checkProperty>.
[An additional problem with <checkProperty> is, that it only checks
whether the property is set, and optionally whether it points to a valid
file. It won't detect if a property points the the wrong file, for
example. In my build files, I use <available classname='...'> to check
for one central class per library.]
>
>> ---- Used at run time ----
>>
>>------------------------------------------------------------
>>org.apache.cactus.ant.AbstractServerRun
>>org.apache.cactus.ant.EnhydraRun
>>org.apache.cactus.ant.ResinRun
>>------------------------------------------------------------
>>These are all classes for starting/stopping containers.
>>IMHO they could be useful outside of the Ant tasks module.
>>What about moving them into the framework?
>
>
> I would like the framework to be completely independent of the
> frontends. These tasks are definitely needed only by front ends (maybe
> not only by Ant tasks although I have not found such a need). Do you
> currently have a real world use case for them outside of Ant?
Nope ;-)
But then, I don't use any front end other than Ant, currently ;-)
>>------------------------------------------------------------
>>org.apache.cactus.ant.RunServerTestsTask
>>org.apache.cactus.ant.StartServerHelper
>>org.apache.cactus.ant.StartServerTask
>>org.apache.cactus.ant.StopServerHelper
>>org.apache.cactus.ant.StopServerTask
>>------------------------------------------------------------
>>The <runservertests>-Task is probably the only task from
>>this module that most (all?) users have ever used. I'm not
>>sure about use cases for the StartServerTask/StopServerTask.
>
>
> Hum.... right.... I can't think of any need either ;-)
Candidates for deprecation/removal, then?
>>But overall, this code should stay where it is (speaking of
>>packages), but moved to frontends/ant eventually.
>>We should have an example that uses
>><parallel>/<sequential>/<http>/<waitfor> instead of
>><runservertests>.
>
>
> +1
>
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cactus Ant Tasks (was Re: [PROPOSAL] New directory structure?)
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 05 January 2003 20:06
> To: Cactus Developers List
> Subject: Re: Cactus Ant Tasks (was Re: [PROPOSAL] New directory
> structure?)
>
[snip]
> >>----------------------------------------------------------
> >>org.apache.cactus.ant.ArgListTask
> >>----------------------------------------------------------
> >>I haven't completely understood why this task exists. IMHO
> >>it could be just kicked out (deprecated ;-) ), and its use
> >>replaced with the normal <arg>, <vmarg> and <sysproperty>
> >>stuff instead, which also have more power when it comes to
> >>handling paths etc.
> >
> >
> > <arg>, <vmarg>, etc are not able to pass optional properties. If you
> > write <vmarg value="-Dxxx=${some.properties}"/> and some.properties
is
> > not defined the called Ant script will receive a property xxx whose
> > value is "${some.properties}" (and not "").
>
> Hmm.. a possible solution would be to make <arg> et al accept
if/unless
> attributes. That would be in the Ant code base, of course. When I find
> some time, I'll try to submit a corresponding patch to the Ant team.
Cool.
>
> >>----------------------------------------------------------
> >>org.apache.cactus.ant.ChangeLogTask
> >>----------------------------------------------------------
> >>Without having looked at it closely, couldn't the use of
> >>this task be replaced with the standard <cvschangelog> ?
> >
> >
> > Almost, except that <cvschangelog> (which by the way was included in
Ant
> > by Peter Donald and myself) does not allow to specify to
include/exclude
> > files, which we need (it may do that now as I think I have asked to
add
> > this feature some while ago).
>
> Okay. AFAICT, <cvschangelog> doesn't support filesets. BTW, that would
> be patternsets, no?
>
> Again, I'll try to get that into the Ant code base as soon as I find
> some time (probably not so soon :-P ).
Cool again. Be careful that the cactus cvschangelog task creates an
empty result XML file if the cvs command fails. This is needed for the
XSL stylesheet that includes the CVS changelog.
>
> >
> >>----------------------------------------------------------
> >>org.apache.cactus.ant.CheckPropertiesTask
> >>org.apache.cactus.ant.CheckPropertyItem
> >>org.apache.cactus.ant.PropertyName
> >>----------------------------------------------------------
> >>All for checking whether a specific property has been set,
> >>and optionally if it refers to an existing file. It is
> >>used to check whether required JAR locations have been set
> >>as properties, bailing if not. In addition, it outputs the
> >>value of the properties.
> >>IMHO, this task can be replaced by standard mechanisms,
> >>using <available>, <fail>, etc. The drawback is a somewhat
> >>longer build file.
> >>
> >>I'd like to avoid having to compile Ant tasks before being able to
> >>compile the framework. I think that for <argList> and
> >
> > <checkProperties>
> >
> >>the additional overhead is not warranted. But just IMHO ;-)
> >
> >
> > I'm +1 to remove any Ant non-standard Ant task provided we don't
loose
> > anything in functionality. ATM I don't see how to do this, except by
> > trying to get our Ant tasks in the Ant optional jars (I tried some
while
> > ago but it is so hard to get heard on the Ant list that I stopped).
> >
> > WRT <checkProperties>, I don't know any nice out of the box Ant
solution
> > to this problem. The best solution I have is:
> >
> > <target name="check.property1">
> > <available property="property1.exist" file="${property1}"/>
> > <echo unless="property1.exist">XXXXXXXXXX</echo>
> > </target>
> >
> > <target name="check.property2">
> > <available property="property2.exist" file="${property2}"/>
> > <echo unless="property2.exist">XXXXXXXXXX</echo>
> > </target>
> >
> > [...]
> >
> > <target name="check.all"
> > depends="check.property1,check.property2,[...]"/>
> >
> > So, if you have 10 properties to check, you need to add 60 lines of
> > build code simply to check that the properties exist. And, it won't
even
> > tell you if the property is not defined or if it points to an
invalid
> > directory/file (but you can guess that). And you don't factorize the
> > message being echoed, etc.
> >
> > There may be a better solution though...
> >
> > But I'm all with you with removing these custom tasks, so if you
find
> > solutions please go ahead if you have an itch to scratch.
>
> For *required* properties, I don't think so much overhead is required.
> Just one target with some <condition> and <fail unless='...'> tasks.
For
> optional properties, you usually need a separate 'warn' target
(because
> <echo> doesn't have if/else-support AFAIK), so that's more complex.
>
> Anyway, I seldomly see the <checkProperty> task do anything useful,
> because the master build file doesn't use it, and I usually invoke
> everything from the master build file.
>
> Usually, simply running ant with the "-verbose" option reveals any
> problems that might occur during build, and in a more detailled
fashion
> than <checkProperty>.
>
> [An additional problem with <checkProperty> is, that it only checks
> whether the property is set, and optionally whether it points to a
valid
> file. It won't detect if a property points the the wrong file, for
> example. In my build files, I use <available classname='...'> to check
> for one central class per library.]
hum. Good points. I just don't like the extra verbosity required in the
build file but please go ahead and remove the checkProperty task.
>
> >
> >> ---- Used at run time ----
> >>
> >>------------------------------------------------------------
> >>org.apache.cactus.ant.AbstractServerRun
> >>org.apache.cactus.ant.EnhydraRun
> >>org.apache.cactus.ant.ResinRun
> >>------------------------------------------------------------
> >>These are all classes for starting/stopping containers.
> >>IMHO they could be useful outside of the Ant tasks module.
> >>What about moving them into the framework?
> >
> >
> > I would like the framework to be completely independent of the
> > frontends. These tasks are definitely needed only by front ends
(maybe
> > not only by Ant tasks although I have not found such a need). Do you
> > currently have a real world use case for them outside of Ant?
>
> Nope ;-)
>
> But then, I don't use any front end other than Ant, currently ;-)
;-)
ATM, let's keep them in the Ant front-end. If we find that several front
ends need to share classes, then we'll refactor.
>
> >>------------------------------------------------------------
> >>org.apache.cactus.ant.RunServerTestsTask
> >>org.apache.cactus.ant.StartServerHelper
> >>org.apache.cactus.ant.StartServerTask
> >>org.apache.cactus.ant.StopServerHelper
> >>org.apache.cactus.ant.StopServerTask
> >>------------------------------------------------------------
> >>The <runservertests>-Task is probably the only task from
> >>this module that most (all?) users have ever used. I'm not
> >>sure about use cases for the StartServerTask/StopServerTask.
> >
> >
> > Hum.... right.... I can't think of any need either ;-)
>
> Candidates for deprecation/removal, then?
ok. Maybe an email on the user list to ask if anyone is using them or
has a use case, before we remove/deprecate?
>
> >>But overall, this code should stay where it is (speaking of
> >>packages), but moved to frontends/ant eventually.
> >>We should have an example that uses
> >><parallel>/<sequential>/<http>/<waitfor> instead of
> >><runservertests>.
> >
> >
> > +1
> >
>
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>