You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bu...@apache.org on 2001/06/21 20:19:33 UTC
[Bug 2274] New: - failonerror does not work
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2274
*** shadow/2274 Thu Jun 21 11:19:33 2001
--- shadow/2274.tmp.11095 Thu Jun 21 11:19:33 2001
***************
*** 0 ****
--- 1,52 ----
+ +============================================================================+
+ | failonerror does not work |
+ +----------------------------------------------------------------------------+
+ | Bug #: 2274 Product: Ant |
+ | Status: NEW Version: 1.3 |
+ | Resolution: Platform: PC |
+ | Severity: Blocker OS/Version: Other |
+ | Priority: Other Component: Build Process |
+ +----------------------------------------------------------------------------+
+ | Assigned To: ant-dev@jakarta.apache.org |
+ | Reported By: schuller@kjunction.com |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ I have two test files Test1.java and Test2.java.
+
+ Test1.java has a compile error. I would like to continue the build process of
+ Test2.java.
+
+ According to the documentation this was fixed in 1.3.
+
+
+ build.xml
+
+
+ <project name="Release36" default="compile" basedir=".">
+
+ <!-- set global properties for this build -->
+ <property name="src" value="."/>
+ <property name="build" value="build"/>
+ <property name="dist" value="dist"/>
+
+ <target name="init">
+ <!-- Create the time stamp -->
+ <tstamp/>
+ <!-- Create the build directory structure used by compile -->
+ <mkdir dir="${build}"/>
+ </target>
+
+ <target name="compile" depends="init">
+ <!-- Compile the java code from ${src} into ${build} -->
+ <javac srcdir="${src}" destdir="${build}" failonerror="false" />
+ </target>
+
+ <target name="clean">
+ <!-- Delete the ${build} and ${dist} directory trees -->
+ <delete dir="${build}"/>
+ <delete dir="${dist}"/>
+ </target>
+ </project>
\ No newline at end of file
Re: [ant2] Optional and Core designations
Posted by Peter Donald <do...@apache.org>.
On Fri, 22 Jun 2001 05:38, Jim Jackl-Mochel wrote:
> I just finished reading through the summary of the ant2 features
> and it looks good. Now come the questions. :-)
>
> [1] Are we planning on having the ant2 optional and core tasks
> continue to be part of seperate packages ?
>
> I would love to
> see another mechanism used to distribute these. Having done
> many rebuilds of ANT in which I have had to remove/add
> core/optional tasks I would love to have a cleaner mechanism
> to define what is included in a current configuration of ANT.
> The idea of changing a package name when an optional task becomes
> partt of the core seems awkward.
>
> This may already be handled/covered in the revised task definition
> mechanism.
> Is it ?
They way the current thinking works is basically there will not be
"core" tasks or "optional" tasks. There will be a number of task libraries,
some of which ship with ant. Each task library will contain types (ie tasks,
datatypes, mappers, listeners, aspect handlers etc). The types will be
grouped according to some mechanism (undecided atm). I would like the
categorization be according to function (ie jdk task library, file task
library, text manip task library etc) others want to have a central core task
library.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: [ant2] Optional and Core designations
Posted by Jim Jackl-Mochel <jm...@foliage.com>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Friday, June 22, 2001 1:38 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: [ant2] Optional and Core designations
>
>
> Jim Jackl-Mochel <jm...@foliage.com> wrote:
>
> > [1] Are we planning on having the ant2 optional and core tasks
> > continue to be part of seperate packages ?
>
> This will drop out of the task library concept IMHO.
>
> Core tasks and types are those that ship with a "core distribution" of
> Ant. Whether they will form a single library or several has not been
> decided. I'd expect this core task library to be a rather small
> subset of the tasks that currently make up Ant.
>
> Optional tasks will get distributed as task libraries. Related tasks
> grouped into one library, but it will be more than one lib.
>
This is what I had hoped for !
> > Having done many rebuilds of ANT in which I have had to remove/add
> > core/optional tasks I would love to have a cleaner mechanism to
> > define what is included in a current configuration of ANT.
>
> The mechanism will be something like "everything that lives in a task
> library in ANT_HOME/lib will be available". The distinction between
> core and optional tasks is a question of organization on the Apache
> side of things, an instance of Ant won't know whether a task has been
> optional or a core task.
>
> This will also make things a lot more modular - rebuilding Ant
> shouldn't be necessary.
>
Excellent ! I was going to suggest this if appropriate.
> > The idea of changing a package name when an optional task becomes
> > partt of the core seems awkward.
>
> Have we ever done that?
>
Not to my Knowledge, but the existence of the classification implies
the possibility of promotion...
> > [2] Has any consideration been given to BuildID and VersionID tasks
> > ?
>
> All it needs is somebody to write them 8-)
OK, it looks like I am volunteering... :-)
>
> Stefan
Re: [ant2] Optional and Core designations
Posted by Stefan Bodewig <bo...@apache.org>.
Jim Jackl-Mochel <jm...@foliage.com> wrote:
> [1] Are we planning on having the ant2 optional and core tasks
> continue to be part of seperate packages ?
This will drop out of the task library concept IMHO.
Core tasks and types are those that ship with a "core distribution" of
Ant. Whether they will form a single library or several has not been
decided. I'd expect this core task library to be a rather small
subset of the tasks that currently make up Ant.
Optional tasks will get distributed as task libraries. Related tasks
grouped into one library, but it will be more than one lib.
> Having done many rebuilds of ANT in which I have had to remove/add
> core/optional tasks I would love to have a cleaner mechanism to
> define what is included in a current configuration of ANT.
The mechanism will be something like "everything that lives in a task
library in ANT_HOME/lib will be available". The distinction between
core and optional tasks is a question of organization on the Apache
side of things, an instance of Ant won't know whether a task has been
optional or a core task.
This will also make things a lot more modular - rebuilding Ant
shouldn't be necessary.
> The idea of changing a package name when an optional task becomes
> partt of the core seems awkward.
Have we ever done that?
> [2] Has any consideration been given to BuildID and VersionID tasks
> ?
All it needs is somebody to write them 8-)
Stefan
[ant2] Optional and Core designations
Posted by Jim Jackl-Mochel <jm...@foliage.com>.
I just finished reading through the summary of the ant2 features
and it looks good. Now come the questions. :-)
[1] Are we planning on having the ant2 optional and core tasks
continue to be part of seperate packages ?
I would love to
see another mechanism used to distribute these. Having done
many rebuilds of ANT in which I have had to remove/add
core/optional tasks I would love to have a cleaner mechanism
to define what is included in a current configuration of ANT.
The idea of changing a package name when an optional task becomes
partt of the core seems awkward.
This may already be handled/covered in the revised task definition
mechanism.
Is it ?
[2] Has any consideration been given to BuildID and VersionID tasks ?
One of the awkward things about components is that they often need to be
versioned separately from the build number so both IDs are needed.
Thanks for listening ,
Jim JM