> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Fri, 20 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> > I meant that the core - conditions, filters, mappers can be in
> > separate namespaces, but that these could still be in
> ant.jar, one can
> > have multiple antlib.xml 's i
Stefan Bodewig wrote:
On Fri, 20 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I meant that the core - conditions, filters, mappers can be in
separate namespaces, but that these could still be in ant.jar, one
can have multiple antlib.xml 's in ant.jar.
Wouldn't that break backwards comp
On Fri, 20 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> I meant that the core - conditions, filters, mappers can be in
> separate namespaces, but that these could still be in ant.jar, one
> can have multiple antlib.xml 's in ant.jar.
Wouldn't that break backwards compatibility?
would
Stefan Bodewig wrote:
I think we need that in order to decompose ant.jar.
If this means making multiple jars from ant.jar, I would be against.
Why?
Even "core tasks" contains a bunch of tasks that really should go into
a separate antlib - the cvs tasks for example. I didn't say we'd st
On Tue, 17 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> However on thinking about this (naming problem, namespace issues,
> types etc) I realized that one could use the antlib scheme to solve
> the problem:
I like what you outline.
> Stefan Bodewig wrote:
>
>>On Thu, 12 Feb 2004, Peter R
See inline for comments.
However on thinking about this (naming problem, namespace issues, types
etc) I
realized that one could use the antlib scheme to solve the problem:
For example:
I used the new package for conditions to allow consistence:
org.apache.t
On Thu, 12 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> I have reactivated my code for restricted/roled types.
I think we need that in order to decompose ant.jar.
> The basic idea is that one can define a type that can only
> be used as a nested element in a type container. The type
> may
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Hi,
> I have reactivated my code for restricted/roled types.
>
+1
> The basic idea is that one can define a type that can only
> be used as a nested element in a type container. The type
> may not be used at the top-level.
>
> The main usecase
Dominique Devienne wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
For example there is an "or" condition, and an "or" selector.
The patch allows these two to be defined as restricted typedefs:
The user-level issues would be:
Is the attribute "contact" a good name for this attribute (us
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> For example there is an "or" condition, and an "or" selector.
> The patch allows these two to be defined as restricted typedefs:
>
> contract="org.apache.tools.ant.taskdefs.condition.Condition"
> classname="org.apache.
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
> Hi,
> I have reactivated my code for restricted/roled
> types.
>
I like this... :)
> The user-level issues would be:
> Is the attribute "contact" a good name for this
> attribute (use "role",
> "restrict", "instanceof" or ?).
I kind of like "contra
11 matches
Mail list logo