I sent two e-mails to ant-dev recently that have not appeared on the list
(both sent after the e-mail congestion problems were resolved). Any ideas
why these two mails didn't go through?
I've attached them both - one regarding the ${a} undefined discussion, which
has already been agreed upon. Another is for Ken Wood regarding the
discussion of <parallel> and starting/stopping an application server.
Erik
--- Begin Message ---
This is a reply to Ken - have you looked into Cactus for doing the deploy,
start, test, stop fuctionality? There is an interesting Ant task that is
part of that project that is designed as a "controller" of three Ant tasks -
start, test, and stop. They already have many common app. servers
integrated nicely into it.
As an aside - if anyone has done this with WebSphere I'd love to hear from
you! I'm beginning to implement Cactus testcases against WebSphere, and
I've yet to find examples of how to do that - I guess I'll have to break new
ground and document it for the Cactus project if/when I figure it out.
Erik
----- Original Message -----
From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 29, 2001 10:02 PM
Subject: Re: Problem with parallel mode
From: "Ken Wood" <[EMAIL PROTECTED]>
> Parallel, async, I don't care the details
> of the implementation. I just need to get
> my job done.
>
Isn't that what we all want?
> The requirement is also to be able to shutdown
> cleanly in the event of a test stuck in a loop, and
> to be able to shutdown cleanly in the event of
> a build exception. The specifics of how that requirement
> are moot to me.
>
In the case of build exceptions (build failures), the standard answer is to
use a BuildListener which shutsdown
the server in case of a failure. Yes it requires programming from you, but
it could be as simple as executing an ANT target that runs the code to
shutdown.
> However, why am I using <parallel> right now?
>
> 1. It EXISTS. It's there. All the rest is discussion.
> And I don't have time to be doing the programming
> or extensions, or I would already have done it...
>
Well if you cannot contribute the work, you may need to wait for others to
have the time to contribute the code.
> 2. The Ant 1.4 documentation specifically uses the example
> of starting a server and running tests against it and
> stopping the server. If that is NOT what <parallel> is
> for, then better documentation and examples are in order...
>
I never believed too much on those particular examples, to tell you the
truth. But I did not created that task. ;-)
> How do I 'check "tests.succesful" to verify if tests passed or not'?
> That sounds like scripting to me, and Ant doesn't have conditionals
> or branching... :^)
>
The pattern for doing this is quite well understood given the current ANT
semantics, you just need a conditional target that tests for it:
<target name="tests" depends="run-tests, check-tests" />
<target name="check-tests" unless="tests.successful" >
<fail message="Error during testing" />
</target>
<target name="run-tests">
<!-- more or less the code I proposed before -->
</target>
Jose Alberto
>
> Jose Alberto Fernandez wrote:
> >
> > From: "Ken Wood" <[EMAIL PROTECTED]>
> >
> > > Another aspect to consider is, how much do we want to focus
> > > on near term fixes to the Ant 1.x stream of development vs.
> > > discussing the best way to do it in Ant 2.x? Since Conor
> > > added the parallel task, I'd be happy to see his proposal,
> > > and unless there is some tremendous reason NOT to, let Conor
> > > update parallel for Ant 1.x while we debate Ant 2.x design.
> > >
> >
> > The problem I have here is the BCS (Backward Compatibility Syndrome)
whatever we define today (in a rush) we will have to provide the same
functionality in the future. Like, for example, the issue with <ant> where
all the management of "basedir" is really a mess IMHO. But because that the
way it is, now there is no way to change it.
> > Even in Ant2, I suspect, we will have to provide ways to mimic this odd
behaviour (even if with different notation) so that people have a way to
port their builds over.
> >
> > > In other words, I'd like a solution this week, not 3 months
> > > of debate (be it civil or not :^) while I continue to kludge
> > > this by manualing shutdown the server from another console,
> > > then ending the build from the command line with CTRL-C...
> > >
> >
> > One of the things I notice in the kind of problem you are facing is that
you are trying to use <parallel> to workaround the fact that ANT is unable
to spawn new processes which is what starting a server should mean IMHO.
> > If you were to have such capability, then one could solve your problem
as follows:
> >
> > <target ....>
> > <spawn ...> <!-- command to start the server -->
> > <timed maxtime="3600" failoncancel="no" >
> > <junit ... failonerror="no" >
> > <property name="tests.succesful" value="true" />
> > </timed>
> > <exec ...> <!-- stop server call -->
> > <!-- check "tests.succesful" to verify if tests passed or not -->
> > </target>
> >
> > Now, here I am trying to get back to using a single thread of execution
by having a way to really fork a process.
> > I think such functionality is quite feasible or in the worst case it can
be emulated using daemon Threads.
> > The other task I propose is <timed> (for lack of a better name). The
point of this task is to alot a certain amount
> > of time to execute its body, if time is exceeded <timed> is stopped and
depending on the setting the task will fail or not.
> >
> > Now, this does not diminish the usefulness of <parallel> nor the need
for more supporting tasks, but it may give us more time to discuss how to do
it right.
> >
> > Would something like this cover your needs?
> >
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--- End Message ---
--- Begin Message ---
This change will have serious implications to many build files currently
(unless I'm missing some context to this issue) - and an automated
conversion of an 1.x build.xml to a 2.0 build.xml will not be possible.
Take for example:
<echo message="junit.present = ${junit.present}"/>
This type of construct is used a lot in the nicest example of an Ant build
script I know of that is publicly accessible - Jakarta Slide (if there are
other banner quality build.xml's out there, I'd love to see them - perhaps a
topic for another thread!) - to easily troubleshoot when something is not
configured properly.
By having a BuildException thrown it would change its behavior. What if
later in the build this is done:
<target name="test" if="junit.present">
How would a build file be capable of displaying its properties without dying
if one is not set?
I'm not sure what my opinion is on whether it should fail or not, as I
haven't thought through any other implications, but I just wanted to toss
this out as food for thought and see how it should be handled in 2.0.
Erik
----- Original Message -----
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2001 4:37 AM
Subject: [VOTE] how will Ant2 deal with undefined properties
> As a side effect of the "tasks as sibblings of targets" thread, there
> seemed to be agreement that ${a} should throw a BuildException if
> there is no property "a" in Ant2.
>
> As only three committers have participated in this discussion, others
> may have missed that, so I'm putting it up for a formal vote.
>
> If there is no property a, shall ${a}
>
> (1) throw a BuildException
>
> or
>
> (2) evaluate to ${a} like it does in Ant 1.x.
>
> Stefan
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--- End Message ---
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
