assert task?

[Robi Khan <rk...@databeacon.com>]

Hi,
I've been following the back and forth on whether the fail task should take an if/unless attribute. The counterargument seems to be that this is a slippery slope that would lead to all tasks having if/unless.

Perhaps. What I've done in our builds is define an assert task that works with the existing property and conditional stuff.

e.g.
	<available file="fubar.xml" property="isXmlThere"/>
	<assert condition="isXmlThere" message="Could not find fubar.xml file"/>

The implementation is too trivial to worth mention. And it has all the benefits that assert has in programming languages. For example, I use it often to validate input parameters to targets. In general I think it's a good fit for larger Ant projects.

Comments?

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: ant task compatible with other build.properties?

[Diane Holt <ho...@yahoo.com>]

The build.xml you're calling has the following:
  <property file="${user.home}/build.properties" /> 
  <property file="${user.home}/.build.properties" /> 
  <property file="build/build.properties" /> 

But note that they have 'basedir=".."', which is why the read in
"build/build.properties" instead of just "build.properties". But there
setting of basedir isn't going to happen, since you've effectively set
basedir to ${jetspeed}/build via your <ant>'s 'dir' attribute. I think
your choices are:
  - add another <property> task to read in just "build.properties"
  - copy build.properies to your ${user.home}

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

ant task compatible with other build.properties?

[Jeremy Kuhnash <ze...@empirion.com>]

Hi all,

    I am actually trying to execute the Jetspeed 'jar' task within it's
build.xml from another build.xml (within my own portal that relies on the
jetspeed jar, especially changes to the cvs source ...)


Here is my task def --

     <ant antfile="build.xml" dir="${jetspeed.dir}/build" target="jar"/>



upon exectution --

------------- SNIP -----------------------------

$ ant install
Buildfile: build.xml

install:

init:
      [echo] ---------- Jetspeed Portal Implementation 1.3a3-dev ----------

      [echo] java.class.path =
d:\ant\jakarta-ant-1.5Beta1\lib\xmlParserAPIs.jar;
d:\ant\jakarta-ant-1.5Beta1\lib\xercesImpl.jar;d:\ant\jakarta-ant-1.5Beta1\l
ib\o
ptional.jar;d:\ant\jakarta-ant-1.5Beta1\lib\ant.jar;c:\jdk1.3.1_03\lib\tools
.jar


      [echo] java.home = c:\jdk1.3.1_03\jre
      [echo] ant.home = d:\ant\jakarta-ant-1.5Beta1
      [echo] user.home = D:\Documents and Settings\jkuhnash

      [echo] basedir = D:\cvs\code\jetspeed\build

      [echo] cactus-22.jar = ${cactus-22.jar}
      [echo] cactus-23.jar = ${cactus-23.jar}
      [echo] cactus.ant.jar = ${cactus.ant.jar}
      [echo] junit.jar = ${junit.jar}
      [echo] build.compiler = ${build.compiler}
      [echo] locale.default = en

BUILD FAILED
D:\cvs\code\jetspeed\build\build.xml:148: taskdef class
org.apache.cactus.ant.Ru
nServerTestsTask cannot be found

Total time: 3 seconds
----------------- SNIP -------------------------------------------------


In Jetspeed the variables that are not interpolated above come from a
build.properties file within the jetspeed/build path.

So what I want to know is this really on the Ant side of the fence, Jetspeed
dev side of the fence or my own.

Another thing I am wondering is how Gump executes builds because that
appears to work.  Would it be better using <java /> or <exec /> ???


Thanks in Advance,
Jeremy Kuhnash






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: assert task?

[Diane Holt <ho...@yahoo.com>]

--- Robi Khan <rk...@databeacon.com> wrote:
> I've been following the back and forth on whether the fail task should
> take an if/unless attribute. The counterargument seems to be that this
> is a slippery slope that would lead to all tasks having if/unless.

The pro argument won -- <fail> now supports if/unless in Ant1.5Beta1.

Diane


=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>