: peter reilly [mailto:[EMAIL PROTECTED]
Sent: 14 March 2003 11:32
To: Ant Developers List
Subject: Re: 1.6 milestones ?
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
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
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
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.
throw different
* exceptions for the various error conditions:
* dl
* liname not found/li
* liname found but no matching dynamic element method/li
* /dl
* At the moment the method simply returns null for these
* conditions.
* /p
*
* @author Peter Reilly
*/
public class
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 get
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 by
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,
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:
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
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/call
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 Thursday 24 April 2003 11:47, Jose Alberto Fernandez wrote:
Obviously (b) is much better. So they define their antlib as follows:
antlib
condition name=cpuusage
classname=com.amazing.queries.CpuUsage
adaptor=com.amazing.ant.ConditionAdaptor/
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 support for
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
null for these
* conditions.
* /p
*
* @author Peter Reilly
*/
public class DynamicElementHelper {
private Vector nestedDynamicMethods = new Vector();
/**
* Constructor for DynamicElementHelper.
*
* @param clazz the class to reflect over
*/
public
On Friday 25 April 2003 14:30, Stefan Bodewig wrote:
because it feels more natural?
classpath ant:type=PathThatIgnoresBuildSysclassPathToTrickGump
or
PathThatIgnoresBuildSysclassPathToTrickGump ant:element=classpath
I see. This is an interesting idea, whether is more natural is debatable
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.
copy ...
classfileset ...
/copy
condition
true/
/condition
This is exactly what dynamicElement is for. For
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:
classpath xsi:type=my:somekindofpath/
Maybe the XML Namespace like notation of my:somekindofpath could mean
that
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%.
antlib with tasks/datatypes is fair game to
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:
antelope:if xmlns:antelope=antlib:${ant-contrib.jar} /
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
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 another
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 really), in which case an additional ns attribute
On Monday 28 April 2003 18:40, Jose Alberto Fernandez wrote:
condition property=x
and
if
istrue value=yes/
thenechoyes/echo/then
elseechono/echo/else
/if
istrue value=yes/
/and
/condition
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 in
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
typedef definitionresource=/org/apache/commons/modeler/ant/antlib.xml
classpath path=${commons.modler/
On Tuesday 29 April 2003 10:46, Jose Alberto Fernandez wrote:
If you don't want if to be useable as a condition - don't make it
implement condition.
It sounds very nice, but the reality is that if already exists and has
existed for a long time. Hence we can not go and change it just because
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 how you'd support accepting
On Tuesday 29 April 2003 13:12, Stefan Bodewig wrote:
I think the learning curve for beginners to grok
copy ...
classfileset .../
zipfileset .../
/copy
is steeper than the alternative
copy ...
fileset type=classfileset .../
fileset type=zipfileset .../
/copy
This is
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 conditions would
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:
antdef
taskdef name=acme classname=org.acme.Acme
onerror=fail/report/ignore/
...
...
/antdef
Definer
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 createName() pattern.
I don't think that it was solvable. Almost any soltion world require
cooperation
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 (named
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
into a antdef.xml file of the form:
antdef
taskdef name=acme classname
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 discussions so far were about adding an addSomething() - while
leaving all existing use cases unmodified.
Stefan introduced
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 addElement() and createElement(),
the addElement() method is used.
example:
typedef myfileset mypath anttest etc ..
copy todir=output
fileset
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 antlib needs to define a qualified name.
The prefix
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
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 - there is no reason to continue
adding
/xmlproperties/classes
[mkdir] Created dir: /home/preilly/proj/learning/xmlproperties/classes
[echo] MyModule.java,MyModule1.java
[javac] Compiling 2 source files to
/home/preilly/proj/learning/xmlproperties/classes
Cheers,
Peter
-Original Message-
From: peter reilly [mailto
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:
suite
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).
* adapter attribute added to typedef
* add(Type) method added
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 explain
how ejbjar, jspc, serverdeploy can have vendor dependent
weblogic, jboss, etc. within this model.
I am quoting Peter Reilly here
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 the effect
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 as discussed before - the
namesspaced attribute name
.
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
has an associated URI http://www.w3.org/2001/XMLSchema; which
implies a lot more
On Saturday 17 May 2003 20:13, Costin Manolache wrote:
peter reilly wrote:
for example:
typedef resource=org/acme/mydefinitions.xml classpath=classes/
to allow loading of tasks/types from different 3rd party with some tasks
haveing the same name, I have added a prefix attribute
.
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 contribution
2) the implementation
I am quoting Peter Reilly here :
This patch adds 4 new features
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
Peter,
acme:hellp xmlns:acme=NSURI
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
/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 PROTECTED
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
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.
I've seen that Costin and Conor prefer
Loritsch wrote:
peter reilly wrote:
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.
The problem is that it only works when you know in advance
what the configuration elements
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
implements this in condition, filterchain, tokenfilter
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
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:
filterchain
replaceregex pattern=@([EMAIL
: 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 have found a bug in ant's regular expession
handling for replacing matched groups.
Ant uses \n to identify
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 the
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:
compiler
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:37,
/
/targetfiles
/outofdate
echo message=${no.need.to.create}/
/target
Peter
On Friday 30 May 2003 23:17, Dominique Devienne wrote:
I myself like quite a bit the outofdate task from Ant-Contrib by Peter
Reilly... Also does away with Ant's pour if/unless conditions on targets to
directly execute
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
TypeAdapter behaves in the same way as the current
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 ChangesPath
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 ==
Hi Dawid,
You may consider having a parallel set of code
for bsh CVS head as some of the bsh apis
have changed since 1.2.x
Peter.
On Friday 06 June 2003 15:53, Dawid Weiss wrote:
Dear ANT community,
I thought one day: maybe it would be fun if I could define ANT tasks INSIDE
the ANT
Sounds cool.
Peter.
On Monday 09 June 2003 14:58, Conor MacNeill wrote:
Hi all,
I've just added a scriptdef task to allow tasks to be created using
scripts. It's loosely based on something I wrote a while back for Mutant.
Attached below is an example usage. I had to make a few small mods to
jython does support named parameters, one
can do some bizarre stuff:
script language=jython
from java.io import File
def twrapper(taskname, **args):
t = project.createTask(taskname)
for a in args.keys():
exec(t.%s = %s % (a, args[a]))
t.execute()
twrapper('echo', message='hello
, dir=File('todir'))
twrapper('mkdir', dir=File(todir))
twrapper('copy', file=File(fromfile), todir=File(todir))
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2003 4:59 AM
To: Ant Developers List
Subject: Re: Ant scripting from
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
Cheers,
Peter
On Thu, 2003-06-19 at 08:43, Nick Chalko wrote:
?xml version=1.0 ?
project default=test name=junit.antlib
path id=ant.deps
Ah, I see.
That would be nice, but the classloader task is not
yet complete.
Peter
On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
peter reilly wrote:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
Please do!
On Thu, 2003-06-19 at 14:13, Denis N.Antonioli wrote:
Hi
Is there any plan to offer a FilterChain for FixCRLF?
I could use this in my present project... and have nothing
against contributing it ;-)
Greetings
dna
I think java.io.tmpdir is not used because
it is not in java 1.1.
As Ant does not support 1.1 (except to
generated 1.1 classes), use should
probably be made of java.io.File#createTempFile().
Peter.
On Thu, 2003-06-19 at 23:32, Antoine Levy-Lambert wrote:
One user complained that FixCrLf
. The code that instantiate
the tasks needs to have a reference to the child loader, and I don't
think core tasks have dependencies on the classes in the optional.
peter reilly wrote:
Ah, I see.
That would be nice, but the classloader task is not
yet complete.
Hi Costin,
looking
You need to wait for ant 1.6
or use a nightly build.
Peter
On Mon, 2003-06-23 at 18:23, Harsha Kalidindi wrote:
Hi:
I am using Ant 1.5.3.
I have few custom tasks. Can I have any of them be configured to
be valid at the project level? Right now, I cannot seem to specify
Well done!
On Tue, 2003-06-24 at 21:25, [EMAIL PROTECTED] wrote:
antoine 2003/06/24 13:25:58
Modified:src/testcases/org/apache/tools/ant/taskdefs ZipTest.java
Log:
An error was happening under Windows when executing the cleanup,
test3.zip could not be deleted.
This is
Hi Steve,
do you have a HEAD copy of Jdk14RegexpRegexp. I made
a bug fix to that recently - I put in the dollar test
to test it. (bug report 20306).
Peter.
On Wed, 2003-06-25 at 01:30, Steve Loughran wrote:
running on redhat 9.0, [SMP] and I'm seeing a regexp failure on Sun's
SDK:
+1
especially if he can get a proper cvs connection ;-)
On Wed, 2003-06-25 at 11:06, Conor MacNeill wrote:
I'd like to propose Jan Materne as an Ant committer. I think his contribution
in recent months has been quite obvious both on the dev and user lists and
also the bug reports. I think he
I am about to commit the second of the patches for
the antlib update -
http://issues.apache.org/bugzilla/show_bug.cgi?id=19897
patch - 6762.
If anyone has objections please veto.
Peter
-
To unsubscribe, e-mail: [EMAIL
Ok:
1) polymorphism
2) loading of antlib.xml files/resource
3) namespace
4) roles
Peter
On Wed, 2003-06-25 at 10:25, Stefan Bodewig wrote:
On 25 Jun 2003, peter reilly [EMAIL PROTECTED] wrote:
The roadmap could be:
1) roles (allowing the typedef definition to be optionally
Opps,
Sorry, the patch has been outstanding for weeks
(since 2003-05-29) and I wanted to move to
the next step.
Peter.
On Thu, 2003-06-26 at 14:26, Stefan Bodewig wrote:
On 25 Jun 2003, peter reilly [EMAIL PROTECTED] wrote:
If anyone has objections please veto.
Nit picking, I know
Yep, I realize that getTaskDefinitions returns
an empty table and that this behaviour is not
backward compatible.
The problem is that as tasks are now types, the getTypeDefinitions()
should now return everything. Current code that use
getTaskDefinitions also need to to call getTypeDefinitions()
I can see the problem here.
Previously property/ was a special
task that was created differently from
the other tasks (it was created in Ant#init()).
I had removed this, and made it a normal
task but missed the usage from Ant#reinit
(and perhaps other places).
I have not been able to write a
Yep it works with CVS versions,
but the latest released versions of both
do not work together.
bsf 2.3.0 rc1
and Rhino 1.5R4 or Rhino 1.5R41
gives the error:
java.lang.NoSuchMethodError:
org.mozilla.javascript.Context.getDebuggableEngine()Lorg/mozilla/javascript/debug/DebuggableEngine;
Peter
On
The only thing thats needs to be done is that
the ant manual for 1.6 should be correct.
The contents of the manual would indicate the
versions that do work - this will depend
on when ant 1.6 is released ;-)
and when newer versions of BSF are released.
Peter
On Mon, 2003-06-30 at 12:17, Stefan
Excellent work.
I have a problem with three rules:
major: The DesignForExtensionCheck seems a bit silly.
minor: The LeftCurlyCheck is against my in-house rule that
if there is a multi line condition, the { should be
on a separate line - but I can live the rule.
minor:
I know ...
Ah well,
Peter
On Thu, 2003-07-03 at 16:30, Stefan Bodewig wrote:
On 03 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
minor: The LeftCurlyCheck is against my in-house rule that
if there is a multi line condition, the { should be
on a separate line
Yep,
However it is not used at the moment, and it
got placed in by accident in the first place.
Peter
On Fri, 2003-07-04 at 10:01, Stefan Bodewig wrote:
This also remove the format attribute, won't we need that for XML
style task definitions to come?
Stefan
On Fri, 2003-07-04 at 11:23, Conor MacNeill wrote:
On Fri, 4 Jul 2003 05:32 pm, Antoine Levy-Lambert wrote:
Hi Conor,
actually, it might be even better if the pages were generated by a cron job
running daily, or even better, if a kind of cvs commit daemon would
regenerate the pages
I just downloaded mozilla 1.4, and the tooltips
work fine on Linux.
Peter
On Fri, 2003-07-04 at 11:51, Stefan Bodewig wrote:
On Fri, 4 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:
Works on Mozilla 1.2.1 on Linux :-( It is just a title attribute in
an anchor with no href.
It seems
I am surprised you do not see the tooltips
The mozilla page
http://www.mozilla.org/docs/web-developer/faq.html
makes a little song and dance over suporting
tooltips for the title attribute.
Peter
On Fri, 2003-07-04 at 12:50, Stefan Bodewig wrote:
On Fri, 4 Jul 2003, Conor MacNeill [EMAIL
I think this is due to a change of using
an iterator instead of a enumerator.
The test code in question was inserting tasks
into the current target, and this does not
seem to be a good idea.
I moved the place where the task is being placed
to another target and the test passes.
Peter
Conor
the way the task list of a target is
visitied.
Peter.
On Mon, 2003-07-07 at 08:37, Stefan Bodewig wrote:
On 04 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
The test code in question was inserting tasks
into the current target, and this does not
seem to be a good idea.
In general
I am thinking of committing the keep-alive
feature:
http://issues.apache.org/bugzilla/show_bug.cgi?id=21144
Do any of the ant commiters have a problem with
this feature?
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On Mon, 2003-07-07 at 18:12, Steve Loughran wrote:
peter reilly wrote:
I am thinking of committing the keep-alive
feature:
http://issues.apache.org/bugzilla/show_bug.cgi?id=21144
Do any of the ant commiters have a problem with
this feature?
I am mostly neutral. I can see its
On Mon, 2003-07-07 at 09:37, Stefan Bodewig wrote:
On 07 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
I am not sure that that depending on an undocumented (I think)
feature of Vector/Enumeration is a good idea.
I agree, though it is sort-of documented in Vector's javadocs (the
class
On Tue, 2003-07-08 at 13:19, Stefan Bodewig wrote:
On 08 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
On Mon, 2003-07-07 at 09:37, Stefan Bodewig wrote:
So if we agreed that it is OK to add/remove tasks to the target
currently being executed, we simply needed to provide a better
1 - 100 of 1211 matches
Mail list logo
