new features I would like in 1.6.
1) import task to import in-line
at the moment, it imports at the end of the build file, thus
messing up order for top level defines.
2) ability to have custom conditions - see bugzilla 17199 :-)
3) add if and unless attributes for some tasks
e.g. in
>
>
>
>
>
>
> Which would add the or the or both depending on the
> property settings.
>
> I can see all kinds of ways to simplify builds by having something like
> that.
>
Has anyone used java 1.1 on linux with ant?
I have just tried ibm 1.1.8 with ant 1.4.1 and ant 1.5.2,
ant -version. ant -version hangs on my machine (patched
redhat 8.0) with 100% cpu utilialization.
Peter.
18 Mar 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > Has anyone used java 1.1 on linux with ant?
>
> Yes (Blackdown's 1.1.8_v3 on RedHat 7.x). I haven't encountered any
> unusual problems, even most my testcases pass (but I have
+1
On Wednesday 19 March 2003 14:16, Steve Cohen wrote:
> +1
>
> -Original Message-
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 19, 2003 12:45 AM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] JDK 1.1 support
>
>
> Hi,
>
> This is to formalize the discussions which
another user error)
Sorry for causing time wastage. :-)~
Peter.
On Thursday 20 March 2003 15:54, Stefan Bodewig wrote:
> On Tue, 18 Mar 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > 1.5.1 and 1.5: java.lang.ClassFormatError: Bad major version number
>
> I do not get
Ant Dev with java gives an example.
I used DynamicConfigurator to implement custom
conditions in bugzilla bug no : 17199
I did not have the problems you describe.
Peter
On Thursday 20 March 2003 18:45, Brett Wooldridge wrote:
> Hello list,
>I'm trying to use DynamicConfigurator and am having
Included is a gzipped tar file containing a patch to concat to
1) takes a path for source files
2) does optional dependency checking (sourcefiles->destfile)
3) has optional filterchains to filter the source files
4) has optional header and a footer element
The file contains the patch and fil
remove this silly restriction of requiring a base dir for all files in the
> filelist! --DD
>
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2003 4:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Ant-contrib-developers] 1.5.1
Unless the tasks require changes to core ant :-)~
Peter.
On Wednesday 26 March 2003 16:26, Stefan Bodewig wrote:
> On Wed, 26 Mar 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > That said (one more ;-), if Ant ever comes up with an easier way to
> > integrate third party tasks
>
> Ea
I would include filters, mappers, conditions and selectors to
the list.
A relatively simple mod to the core ant makes this
possible (bugzilla 17199) basically get ConditionBase.java,
AbstractFileSet, FilterChain implement DynamicConfigurator.
and get UnknownElement (bugzilla 18312) call setProject
Costin Manolache wrote:
> > I would include filters, mappers, conditions and selectors to
> > the list.
>
> I would exclude them :-)
>
> Taks, types, mappers, filters, whatever are just ant components -
> and they shouldn't need a special syntax from user perspective.
That is what I meant to say..
*
*
* Note:
*
* x
* createDynamicMethod should possible throw different
* exceptions for the various error conditions:
*
* name not found
* name found but no matching dynamic element method
*
* At the moment the method simply returns null for these
* conditions.
*
*
Dominique Devienne wrote:
>>Interesting... So how come DynamicTag is not compatible with
>>Ant 1.6, when it compiles and works fine with 1.5.1??? Sounds
>>like an incompatible API change to me, which hopefully will be fixed.
It compiles on Ant 1.6, but currently the unknownelement returned
does not
And the original author was Matthew Inger.
Peter
On Tuesday 22 April 2003 10:43, [EMAIL PROTECTED] wrote:
> I took a look at cvs log
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ant-contrib/ant-contrib/src/
>n et/sf/antcontrib/property/PropertyCopy.java
>
> The initial version was introduced b
Hi,
Your guess is nearly right, I originally used beanshell,
after modifying it to use apache BSF. When submitting
I modified the tests to use javascript, but missed the
test to check if script is available.
Cheers,
Peter
On Tuesday 15 April 2003 07:39, Stefan Bodewig wrote:
> In addition, test
On Tuesday 15 April 2003 01:05, Conor MacNeill wrote:
> I have some questions about this patch
>
> On Tue, 15 Apr 2003 03:21 am, [EMAIL PROTECTED] wrote:
> > +Project.setProjectOnObject(project, o);
>
> Why is this a static method rather than a plain method like this:
> project.
A flat namespace is a bit problematic :-
for example: is "containsregexp" a filter, condition or a selector
The antlib proposal does provide associating the same
name to different classes using roles.
If a flat namespace is used, there is not much point in
proceeding with the xml based descrip
On Wednesday 23 April 2003 17:41, Dominique Devienne wrote:
> Let's turn around your question: Tell me of a (string) role (beside the
> special task/type cases) that would not be an interface? What good a bean
> is, if it's not of an expected Java type? What method or field are you
> going to use/c
On Wednesday 23 April 2003 17:57, Dominique Devienne wrote:
> Yes, it could be a problem. But running the risk of speaking yet another
> anathema, I'm starting to believe the Jelly approach of using XML
> namespaces is the right one...
+1
Seems simple to implement and fits in with current usage.
On Monday 21 April 2003 22:23, Antoine Levy-Lambert wrote:
> I am trying to update the antlib proposal (proposal/sandbox/antlib).
>
.
.
> I would like, based on this email, to read what you find OK and what should
> be changed in the antlib proposal. Once I have the comments from everybody
> on the
testAddTaskDefinition
testTaskDefinitionContainsKey
testTaskDefinitionContains
Included is the a gziped diff file (cvs diff -u) against current CVS of
Project.java
Peter
On Wednesday 23 April 2003 18:37, Antoine Levy-Lambert wrote:
> Peter Reilly wrote
>
> A couple of points:
On Thursday 24 April 2003 11:47, Jose Alberto Fernandez wrote:
> Obviously (b) is much better. So they define their antlib as follows:
>
>
>classname="com.amazing.queries.CpuUsage"
> adaptor="com.amazing.ant.ConditionAdaptor"/>
>classname
On Friday 25 April 2003 08:31, Stefan Bodewig wrote:
> On Thu, 24 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> > Look - adding "roles" concept to ant, and adding antlib are 2
> > separate issues.
+1
>
> I tend to agree - that's why I proposed to get antlib into the main
> trunk with supp
On Friday 25 April 2003 10:42, Stefan Bodewig wrote:
> Yes, that's one way to implement it. The tricky part starts if you
> want to support polymorphism for more than one nested element.
true.
The problem exists in CVS HEAD for TokenFilter, it can take
TokenFilter.Filter and TokenFilter.Tokenizer
On Friday 25 April 2003 11:54, Stefan Bodewig wrote:
> On Fri, 25 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > I do not see the problem here: suppose Path implements
> > dynamicElement(Path path)
* public void execute() {
*if (resolver == null)
* throw new BuildException();
*buildPath = resolver.getBuildPath();
* }
* }
*
*
* Note:
*
* x
* createDynamicMethod should possible throw different
* exceptions for the various error conditions:
*
* name not found
* n
On Friday 25 April 2003 14:30, Stefan Bodewig wrote:
>
> because it feels more natural?
>
>
>
>
> or
>
>
>
I see. This is an interesting idea, whether is more natural is debatable ;-).
A thing to note is that "ant:" assumes that an xml namespace is set-up,
<... xmlns:ant="...">
Another similar
On Friday 25 April 2003 14:34, Stefan Bodewig wrote:
> On Fri, 25 Apr 2003, Jose Alberto Fernandez
>
> In simple non-ambiguos cases like the above this could be without the
> trick.
>
>
>
>
>
>
>
>
This is exactly what dynamicElement is for. For example:
as ConditionBase has dynamicEleme
On Friday 25 April 2003 16:45, Wannheden, Knut wrote:
>
> It'd be natural to people who've worked with XML Schema Instance documents,
> where you'd write something like:
>
>
>
> Maybe the XML Namespace like notation of "my:somekindofpath" could mean
> that "somekindofpath" is a task/type define
On Friday 25 April 2003 18:32, Erik Hatcher wrote:
> On Friday, April 25, 2003, at 01:25 PM, Costin Manolache wrote:
> > All I ask is to do the changes in the core separately.
>
> +1
>
+1
> I'm in agreement with you on the order of events, Costin, 100%.
> with tasks/datatypes is fair game to migr
I would agree nearly 100% with Costin.
Proposal:
There will be only one mapping defined elementtag -> java class.
Introspection Mapping -
This class will be used if there is no add[Configured]()
The introspection mapping should be extended to handle
4. public v
On Monday 28 April 2003 17:28, peter reilly wrote:
> An object of Cimpl gets method 3, An object of ABImpl is ambiguous and is
> allowed.
That should be "not" allowed
Peter
On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
> > Or even:
> >
>
> That syntax abuses the purpose of XML Namespaces, IMO. Although a
> namespace is identified by an URI, I don't think attaching semantics to it
> is correct.
I am no expert in xml ns usage (my only experiance with xml is
My comments in-line:
On Monday 28 April 2003 16:35, Costin Manolache wrote:
> To keep things simple and make it easier to get an agreement -
> let's let adapters out, and focus on the core issue.
>
> IMO it seems what everything leads to is the need to extend
> the introspection patterns with anot
On Monday 28 April 2003 18:41, Nicola Ken Barozzi wrote:
> peter reilly wrote, On 28/04/2003 19.37:
> > On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
>
> ...
>
> >>but maybe the buildfile author wants/needs to specify the namespace URI
> >>(anything real
On Monday 28 April 2003 18:40, Jose Alberto Fernandez wrote:
>
>
>
>
>
> yes
> no
>
>
>
>
This particular example does not get through the rules,
If extends ConditionBase, but does not exte
First, I must say that it would be nice to have
context dependent element names - my core example
is the element name "containsregexp" - is this a condition,
filter or selector ? , the different meaning may mean
that different classes should implement them.
However, I think that expressing this i
Two points
1)
Using /org/apache/.../anlib.xml defeats the purpose of the antlib
proposal.
However it is in keeping with current ant practice.
it could be supported using
or using nested elements
antlibs would still have the fix
On Tuesday 29 April 2003 10:46, Jose Alberto Fernandez wrote:
> > If you don't want to be useable as a condition - don't make it
> > implement condition.
>
> It sounds very nice, but the reality is that already exists and has
> existed for a long time. Hence we can not go and change it just becau
On Tuesday 29 April 2003 12:49, Stefan Bodewig wrote:
> On Mon, 28 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >4. public void add(NestedElement anInner)
> >5. public void addConfigured(NestedElement anInner)
>
> Make NestedElement a FileSet and explain
On Tuesday 29 April 2003 13:12, Stefan Bodewig wrote:
>
> I think the learning curve for beginners to grok
>
>
>
>
>
>
> is steeper than the alternative
>
>
>
>
>
This is debatable as the new type can take completly different attributes
and nested elements. Beginners would get equa
).
In any case, the main issue of removing param(name="", value="") pattern
is removed by your approach.
On Tuesday 29 April 2003 13:52, Stefan Bodewig wrote:
> On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > This is debatable
>
> I said
On Tuesday 29 April 2003 16:50, Stefan Bodewig wrote:
> On Tue, 29 Apr 2003, Jose Alberto Fernandez
>
> <[EMAIL PROTECTED]> wrote:
> > This continues with the two-tier issue, the core conditions of ANT
> > you can just named, but the third party ones need to use some funny
> > syntax.
>
> core cond
On Wednesday 30 April 2003 16:24, Stefan Bodewig wrote:
> On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >> it is, with an addXYZ(Condition) method marking it up - I'm not
> >> really fond of any of the proposed naming conventions so far.
> &
I think that agreement is very close.
What about this proposal:
The current types and tasks properties files may be combined
into a antdef.xml file of the form:
...
...
Definer (in the form of or ) can use
this either as a file or as a resource.
or
or
(if antcontib-xyz.jar
On Wednesday 30 April 2003 17:54, Costin Manolache wrote:
> Stefan Bodewig wrote:
> > On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >> We are still left the problem of the Type create() pattern.
> >
> > I don't think that it was so
On Wednesday 30 April 2003 19:33, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Wednesday 30 April 2003 16:24, Stefan Bodewig wrote:
> > > On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > >
On Wednesday 30 April 2003 18:17, Costin Manolache wrote:
> All the discussions so far were about adding an addSomething() - while
> leaving all existing use cases unmodified.
Stefan introduced the concept of a typedef attribute, which allows
the ant core code to substitute a different class (name
On Wednesday 30 April 2003 18:28, Costin Manolache wrote:
> peter reilly wrote:
> > I think that agreement is very close.
> >
> > What about this proposal:
> >
> > The current types and tasks properties files may be combined
>
Replying to myself ;-)
On Thursday 01 May 2003 09:55, peter reilly wrote:
>
> The concept was introduced in the ant lib proposal.
>
> I propose to add it to Definer (and hence to typedef and taskdef). This
> is to allow the use-case of optional tasks. Currently all the types/task
Ok, I have coded ant-type magic attribute over lunch.
I will update Patch 19446 over the weekend with
the changes.
Peter.
On Thursday 01 May 2003 09:24, peter reilly wrote:
> On Wednesday 30 April 2003 18:17, Costin Manolache wrote:
> > All the discu
I have done a little further work on my patch
to allow nested elements to have Project type
as a constructor.
If the object contains both add() and create(),
the add() method is used.
example:
I will upload the modified patch over the weekend.
Peter
On
On Friday 02 May 2003 11:46, Wannheden, Knut wrote:
> Peter,
>
> > example:
> >
> >
> >> newattribute="MyFileSet attribute"/>
> >
> >
> >
> >> newattribute="MyPath attribute"/>
> >
>
> I assume you meant to write "ant:type"
For the weblogic stuff, they would surely come
from the same antlib - say weblogic-ant.jar
using namespace (example for demo purposes only)
or using prefixes:
Grante
, or have a ComponentHelper per uri.
Peter
On Friday 02 May 2003 15:42, Costin Manolache wrote:
> peter reilly wrote:
>
> \>> > example:
> >> >
> >> >
> >> >&g
I would agree with most of what Nicola says. I think
that XML ns is a "heavy" solution for name clashing
of names defined in a antlib. Moreover I do not
think that the antlib needs to define a qualified name.
The "prefix" attribute idea of the task could
be used - even with the current command.
On Monday 05 May 2003 20:20, J.Pietschmann wrote:
> peter reilly wrote:
> > I would agree with most of what Nicola says. I think
> > that XML ns is a "heavy" solution for name clashing
> > of names defined in a antlib. Moreover I do not
> > think that the an
On Tuesday 06 May 2003 17:39, [EMAIL PROTECTED] wrote:
> BTW
> You´re using the old email adress [EMAIL PROTECTED]
> The new one is
> [EMAIL PROTECTED]
that is
[EMAIL PROTECTED]
Peter
The normal way is get debug output is to
use log(..., Project.MSG_VERBOSE);
And then use -debug at the command line.
This however results in a lot of debug output
So some tasks have a verbose attribute - like for
ant -Ddelete.verbose="yes" ...
Check the source (ant.apache.tools.ant.task
I would agree with XML namespace usage like this.
There are however some major and minor consequences
- in no particular order.
1) the code to handle XML namespaces in ProjectHelper2 is
not yet complete.
- namespaces of attributes is not handled yet - the
code uses getQName()
t; as this implies more baggage.
(Also my work in progress implementation uses an ant task
for the xml parsing and the root element name is the task
name ;-)).
On Wednesday 07 May 2003 15:56, Costin Manolache wrote:
> peter reilly wrote:
> > I would agree with XML namespace usage like this.
&g
On Wednesday 07 May 2003 20:40, J.Pietschmann wrote:
> peter reilly wrote:
> > - namespaces of attributes is not handled yet - the
> > code uses getQName() on the attributes and does
> > not pass the URI of the attributes to the attribute list
On Friday 09 May 2003 04:08, Costin Manolache wrote:
> peter reilly wrote:
> > Using property files is nice but with new attributes
> > to typedef (adaptor for example) it would be better to
> > use an xml file/resource.
>
> I think we already agreed on XML - the
You would probally change the input to include the .java
in the filename. and use the "includes" attribute of
javac and not the include sub-element.
>
On Monday 12 May 2003 12:12, Dharnidhar Vemuri wrote:
> > Hi,
> >
> > I have an xml file with the
Dharnidhar Vemuri wrote:
> Peter,
>
> It still takes the first java file, It does not compile the second file
> at all
>
>
>
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 12, 2003 17:25
> To: Ant Developers List
> Sub
ers,
Peter
>
>
>
>
> -Original Message-----
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 12, 2003 17:52
> To: Ant Developers List
> Subject: Re: FW: Retrieve all the nodes in an XML file using xmlproperty
>
>
> OK, just tested.
> My e
I was afraid you may say this ;-)
The .java is added to the end of the property value of
"${suite.testcases.filename}" not to each of the components
of the string.
You will need to do something like xsl to convert
the input xml.
something like:
http://www.w3.org/1999/XSL/Transform";>
al third party
ant tasks.
>
> I would be glad to hear your comments concerning :
> 1) the functionality provided by the contribution
> 2) the implementation
> I am quoting Peter Reilly here :
>
> This patch adds 4 new features (the code is interrelated,
> but may be split).
&g
gt; > 1) the functionality provided by the contribution
> > 2) the implementation
>
> Well I have not given the fight on the need for roles and separate
> symbol-tables for different Types.
Roles/separate symbol-tables could be dealt with later.
>I would like for someone to expl
On Wednesday 14 May 2003 13:23, Conor MacNeill wrote:
>
> > ant-type polymorphism is not a priority for me,
>
> Pity - it solves most extensibility problems :-).
>
Hi Conor, et al
I have merged the ant-type code into my antlib code.
However it uses a "magic" attribute name "ant-type" to
achieve t
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
> On Thu, 15 May 2003 12:56 am, peter reilly wrote:
> > I have merged the ant-type code into my antlib code.
> > However it uses a "magic" attribute name "ant-type" to
> > achieve the effect and not
and done
> in few steps.
>
> > peter reilly wrote:
> >> On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
> >>
> >> I would prefer to use the XML schema attribute for this.
> >
> > Mmmm, this would be confusing as the XML schema attribute
On Saturday 17 May 2003 20:13, Costin Manolache wrote:
> peter reilly wrote:
> > for example:
> >
> >
> >
> > to allow loading of tasks/types from different 3rd party with some tasks
> > haveing the same name, I have added a "prefix" attri
t concerning the antlib thread of discussion.
> >
> > I was thinking maybe we do not need to look further and we could commit
> > this contribution ?
> >
> > I would be glad to hear your comments concerning :
> > 1) the functionality provided by the cont
On Monday 19 May 2003 10:01, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Saturday 17 May 2003 19:59, Costin Manolache wrote:
> > > I think should be treated as a special
> >
> > with TaskAdapter
> >
>
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
> Peter,
>
> > >
> > >
> > > This would allow arbitrary NSURIs ( for people who like
> >
> > meaning-free URIs)
> >
> > > and allow the classpath association.
> >
> > I do not want meaning-free URIs.
> > I want ant to ignore URIs that it does n
/Target be done by PH2#ElementHandler?
I think one should be able to plug in handlers for different URIs, or URI
patterns. My UnknownUriHandler is an (possibly not very good) example.
On Monday 19 May 2003 15:33, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PRO
To embed the config information, the easiest
is to map the info to objects.
Ant introspection is very powerfull and easy
to use for normal java data object.
Alternatively one can use the DynamicConfigurator
interface. This provides the name of the unknown element
and the name/value of unknown at
feedback is received from the
community.
Peter
On Tuesday 20 May 2003 08:34, Costin Manolache wrote:
> peter reilly wrote:
> > There are a number of issues here.
> >
> > 1) are build script authors allowed to specify arbitary
> > URIs for ant type definitions?
> &g
On Wednesday 21 May 2003 08:21, Stefan Bodewig wrote:
> On Mon, 19 May 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > 1) are build script authors allowed to specify arbitary
> > URIs for ant type definitions?
> > I do not think this is a good idea.
>
>
element test
on-components = foo,bar
element include
name = **/XYZComp/*Test
element configuration
element xyz-comp
id = foo
element zyx-comp
id = bar
element arbitrary
value = null
Peter.
On Tuesday 20 Ma
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
>
> My main concern is the same as Conor's - having this decoupled and done
> in few steps.
Ok I will chop it up into a sequence of patches.
>
> That means you have to start with add(Type), then anttypdef, then onerror.
The first patch adds
On Thursday 22 May 2003 10:29, Stefan Bodewig wrote:
> On Thu, 22 May 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > Ok I will chop it up into a sequence of patches.
>
> Thanks.
>
> > The first patch adds the add(Type) introspection method and
> > imple
I also think the roles concept is good for the following reasons:
* The current implemention of conditions/selectors/filters (a
big sequence of add()) is tightly coupled.
The implementation means that new conditions/selectors/filters
(to be used in the same way as current conditions/
I am thinking of commiting patch number 6453 from
http://issues.apache.org/bugzilla/show_bug.cgi?id=19897
This adds the add(Type) introspection rule and implements
it in condition, filterchain and selectors.
I have had a couple of +1s to the patch but would like to
confirm this before committin
Hi, I have just been made a ant committer.
I have found a bug in ant's regular expession
handling for replacing matched groups.
Ant uses \n to identify the matched group,
jdk14 and jakarta-oro uses $n to identify the
group. The code in ant correctly replaces the \
with $. However, it does not es
I do not think this is a good idea. It will
add @property@ to ${property} as a way
for dealing with properties.
This could be a custom filter or nearly
the same behaviour could be achieved by
using replaceregex and expandproperties:
(when I fix the bug with regex
s,
> Magesh
>
> ----- Original Message -
> From: "peter reilly" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 28, 2003 6:57 AM
> Subject: Advice required on committing
>
>
> Hi, I have just been made a ant committer.
I am thinking of commiting patch number 6453 from
http://issues.apache.org/bugzilla/show_bug.cgi?id=19897
This adds the add(Type) introspection rule and implements
it in condition, filterchain and selectors.
On Wednesday 28 May 2003 12:30, Magesh Umasankar wrote:
>
> P.S. Please prefix mark th
rovide a mechanism that we can go foward with that would keep a bunch
> of people from having to switch over our tokenized files.
>
> Magesh Umasankar wrote:
> >oh, ok. That takes care of David's needs,
> >I would think.
> >
> >Cheers,
> >Magesh
> &
On Wednesday 28 May 2003 15:04, Conor MacNeill wrote:
> On Wed, 28 May 2003 11:27 pm, Erik Hatcher wrote:
> > If folks feel strongly about it, I'll revert it.
>
> I'm not into strong feelings :-). Let's see what people think.
+1 to keep the if attribute
I use this all the time with cc:
On Wednesday 28 May 2003 15:21, [EMAIL PROTECTED] wrote:
> bodewig 2003/05/28 07:21:05
>
> Modified:docs contributors.html
>xdocscontributors.xml
> Log:
> This is supposed to be sorted ;-)
Opps.
Peter
I would rather use the "C" logic for this.
Unless the value is explicity "false/off/no" or "",
the value is treated as true.
This would break less scripts. But it is still
not bc and third party tasks would also need
to be changed to follow the new behaviour.
Peter.
On Wednesday 28 May 2003 17:3
I think you should prefix them like the jprobe tasks.
My reasoning is that they are separate tasks,
and so should not be wrapped in an outer element.
Namespaces will probally be introduced in ant 1.6 and
this will address name clashing and name context issues,
however your tasks are usefull now and
bit the task from Ant-Contrib by Peter
> Reilly... Also does away with Ant's pour if/unless conditions on targets to
> directly execute what needs to be done.
>
> Peter even added the ability to have no target files, and just source
> files, which are thus only checked for existenc
Hi Antoine,
Thanks for your detailed comments.
On Tuesday 03 June 2003 20:26, you wrote:
> - Original Message -
> From: "peter reilly" <[EMAIL PROTECTED]>
> To: "Antoine Levy-Lambert" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 03, 2003 2:01 PM
On Wednesday 04 June 2003 10:48, Antoine Levy-Lambert wrote:
> Peter,
>
> thanks for your work.
>
> Your explanations concerning the scope of different flavours of typedef
> declarations are important, make sure that they make their way in the
> documentation.
Ah yes documentation.
Peter
pretty awesome.
Peter
On Wednesday 04 June 2003 13:18, [EMAIL PROTECTED] wrote:
> umagesh 2003/06/04 05:18:55
>
> Modified:docs ant_task_guidelines.html
> Added: .patch.xml
> Log:
> Suggest using Ant to generate a patch file for Ant.
>
> Revision ChangesPat
I see the problem.
It is in the TaskAdapter, if the
adapted task throws a build exception,
this is logged at "error" level.
Method executeM = null;
try {
Class c = proxy.getClass();
executeM = c.getMethod("execute", new Class[0]);
if (executeM =
1 - 100 of 1354 matches
Mail list logo