> -----Original Message-----
> From: Christopher Lenz [mailto:[EMAIL PROTECTED]]
> 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 "").
>
> ----------------------------------------------------------
> 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).
>
> ----------------------------------------------------------
> 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.
>
> ---- 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?
>
> ------------------------------------------------------------
> 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 ;-)
> 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
Thanks
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
