Vincent Massol wrote:
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.-----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 directorystructure?)Vincent Massol wrote: [snip]jakarta-cactus |_ anttasks (only keep in this subproject the Ant tasks that are notrelatedto Cactus. This subproject is expected to disappear over timeasit is expected Ant will provide solutions to perform what wearedoing)[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 "").
Okay. AFAICT, <cvschangelog> doesn't support filesets. BTW, that would be patternsets, no?---------------------------------------------------------- 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).
Again, I'll try to get that into the Ant code base as soon as I find some time (probably not so soon :-P ).
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.---------------------------------------------------------- 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.
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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
