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
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 arguments.
> This should be independent of using antlibs/jars
Jose Alberto Fernandez wrote:
Is there a DTD for XSLT? Can I validate an XSLT template against a DTD?
Not in general. This is a restriction of DTDs, which can't cope with
XML namespaces. DTDs are a SGML heritage and predate XML namespaces.
You can always construct a DTD which a certain class of (us
peter reilly wrote:
The NS standard http://www.w3.org/TR/REC-xml-names/
allows one to do somthing like this:
message
of course it is up to the ant software to understand the xml file,
but "unsupported attribute 'class'" is not a usefull error message
in this case.
I would make ele
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 given
> > to
>
> Most
Thanks for the detailed reply.
I will reply in-line.
However, I think that I did not make my main point
clear in my original e-mail. So I will detail it
first.
Currently 3rd party add-ons to ant are done using
and/or . These can either define
the tasks or types in-line or by using property files
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> >
> > But ANT is not for experience XML users but for Java programmers
> > or C or .NET (with the new tasks). ANT is popular because
> > it is simple to use you do not have construccions that require
> > you
Jose Alberto Fernandez wrote:
But ANT is not for experience XML users but for Java programmers
or C or .NET (with the new tasks). ANT is popular because
it is simple to use you do not have construccions that require
you to read a full spec to understand. I am not against NS, but
I am against forci
Conor MacNeill wrote:
> On Thu, 8 May 2003 12:30 am, Costin Manolache wrote:
>>
>> The URI however should be chosen by the antlib author ( maybe based on
>> some rules specific to ant ), and should serve as an ID of the library.
>>
>> My proposal is to use the (main) package name. There are other
Jose Alberto Fernandez wrote:
>> As someone already said, it's about "not reinventing the
>> wheel", not about
>> enabling the use of fancy tools. But as ubiquitous and
>> accepted as XML
>> namespaces are, I see many things that could be gained from using
>> namespaces. Also, I suspect most us
> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
>
> > I have no problem on allowing people to use namespaces, but I do
> > have a problem on forcing people to use them just because
> some others
> > want to use some fancy XML tool. The buildfile belongs to the
> > user and s/he should be in ch
On Thu, 8 May 2003 12:30 am, Costin Manolache wrote:
>
> The URI however should be chosen by the antlib author ( maybe based on some
> rules specific to ant ), and should serve as an ID of the library.
>
> My proposal is to use the (main) package name. There are other options -
> but I don't think
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
>
> I think you started with wrong assumptions here.
>
> There is no need to change anything in the core or optional tasks,
> you can have an antlib that uses multiple jars ( and most
> likely antlibs
> will eventually use some dependency me
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Stefan Bodewig wrote:
>
> > On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> >> Jose Alberto Fernandez wrote:
> >>
> >>> The important point is for the user (which is the one who has to
> >>> deal with name clashes) to have
Jose Alberto Fernandez wrote:
I have no problem on allowing people to use namespaces, but I do
have a problem on forcing people to use them just because some others
want to use some fancy XML tool. The buildfile belongs to the
user and s/he should be in charge.
The buildfile belongs to the user, b
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 given
to
Most vocabularies don't use namespaces for attributes, the reason being
that th
On Wed, 07 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> If you're reffering to the prefix
I was.
> - of course, that's how NS works.
I know.
Stefan
Jose Alberto Fernandez wrote:
>> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
>>
>> >
>> > Let's not reinvent the wheel here.
>> >
>> > The solution for names conflicts is namespaces - not rewriting.
>> >
>>
>> I agree. With the new ProjectHelper2 everything should be in
>> place to start
of having short and long names where the long names are
>> > form by adding a prefix defined not by the antlib writer, but by the
>> > antlib user:
>> >
>> >
>> >
>> > which would allowme to use either:
>> >
>>
Stefan Bodewig wrote:
> On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
>> Jose Alberto Fernandez wrote:
>>
>>> The important point is for the user (which is the one who has to
>>> deal with name clashes) to have control of the final naming scheme
>>> used in his/her buildfile.
>
> > >
> > > Let's not reinvent the wheel here.
> > >
> > > The solution for names conflicts is namespaces - not rewriting.
> > >
> >
> > I agree. With the new ProjectHelper2 everything should be in
> > place to start
> > using namespaces.
> >
>
> I have no problem on allowing people to use
> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
>
> >
> > Let's not reinvent the wheel here.
> >
> > The solution for names conflicts is namespaces - not rewriting.
> >
>
> I agree. With the new ProjectHelper2 everything should be in
> place to start
> using namespaces.
>
I have no prob
lisions and conflict resolution apply.
> >
> > The important point is for the user (which is the one who has to
> > deal with name clashes) to have control of the final naming scheme used
> > in his/her buildfile. And we are not impossing any wierd semantics or
> > mak
>
> Let's not reinvent the wheel here.
>
> The solution for names conflicts is namespaces - not rewriting.
>
I agree. With the new ProjectHelper2 everything should be in place to start
using namespaces.
This would also allow antlibs to have a DTD or XML Schema which could be
used in XML edit
On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> Jose Alberto Fernandez wrote:
>
>> The important point is for the user (which is the one who has to
>> deal with name clashes) to have control of the final naming scheme
>> used in his/her buildfile.
>
> Let's not reinvent the whee
On Wed, 7 May 2003 03:14 pm, Costin Manolache wrote:
> Let's not reinvent the wheel here.
>
> The solution for names conflicts is namespaces - not rewriting.
>
+1
Conor
antics or making
> assumptions, if I decide to use the same prefix for two antlibs it is up
> to me to make sure there are no conflicts.
>
>
>
>> -Original Message-
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>> Sent: 02 May 2003 14:35
>> To: [EMAIL PROTECTED]
Hi guys,
I was away on vacation so hasn't been around to make comments about the entire
discussion.
I will try to sumarize here some comments that go across several messages I
have read today.
The current provides a way for the user of a particular antlib to
rename
one or more elements that a
On Fri, 2 May 2003 09:55 pm, peter reilly wrote:
>
> No...
> Ant does not have the infrastructure at the moment to support XML
> namespaces, and their associated contexts.
>
It may be better to add that infrastructure then :-) It may also be better to
use XML Schema's syntax for Polymorphism as t
peter reilly wrote:
> Yes, but more infrastructure is needed.
> (Also, in current ant cvs, ComponentHelper is not used).
It's not used because I wanted some feedback on its interfaces.
The code is (almost) the same with the one in Project, and it
requires one little step to be enabled and pass t
Yes, but more infrastructure is needed.
(Also, in current ant cvs, ComponentHelper is not used).
My knowledge on this subject is very small, but here
is my understanding (based on looking at jelly source
code).
To support XML ns one needs to know the uri associated
with the namespace prefix.
The
peter reilly wrote:
\>> > example:
>> >
>> >
>> > > > newattribute="MyFileSet attribute"/>
>> >
>> >
>> >
>> > > > newattribute="MyPath attribute"/>
>> >
>>
>> I assume you meant to write "ant:type" instead of "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
On Wed, 30 Apr 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> The problem you are overlooking is the case of element
> in , , , etc.
Maybe not really overlooking but understimating.
The alternative would be to use and
for the different interfaces. If they come from different antli
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"
Peter,
>
> example:
>
>
> newattribute="MyFileSet attribute"/>
>
>
>
>newattribute="MyPath attribute"/>
>
>
I assume you meant to write "ant:type" instead of "ant-type"...
I suppose in both examples all further attribut
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 Wed, 30 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> Can you explain again what's wrong with create ? I think I missed
> it...
You can't pass in a subclass of the type returned by the createXYZ
method as the object creation happens inside the task. If you want to
use a subclass of
On Wed, 30 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>
>> I don't see a need for separate namespaces depending on the
>> interfaces, so only using the child's element name (and namespace)
>> could be enough. I'm not sure whether I'm overlooking a problem.
>
>
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 discussions so fa
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 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:
> > > >> it is, with an addXYZ(Condition) method markin
> 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:
> > >> it is, with an addXYZ(Condition) method marking it up - I'm not
> > >> really fond of any of the proposed naming conven
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Tue, 29 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> > Stefan Bodewig wrote:
>
> >>> - Should we use (, ) tuple to find the class?
> >>> Should we use (ParentClass, , ) tuple ?
> >>
> >> I'm not sure what the difference is, here
peter reilly wrote:
> 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 solvable. Almost any sol
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 solvable. Almost any soltion world require
> > coope
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 solvable. Almost any soltion world require
> cooperation of the classes implementing the create method.
>
> What w
Stefan Bodewig wrote:
> On Tue, 29 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
>> Stefan Bodewig wrote:
>
- Should we use (, ) tuple to find the class?
Should we use (ParentClass, , ) tuple ?
>>>
>>> I'm not sure what the difference is, here.
>>
>> In the second case, the pa
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.
> >
> > Whats wrong with add(Condition) ?
>
Some more thoughts on namespaces...
>
> > I do not like the "type" attribute, type is already use on several
> > places like
>
> names ...
>
> This is where I'd really see a magical namespace for attributes that
> get parsed by Ant's core.
>
Then the whole thing would resemble XML Schema Ins
On Tue, 29 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>>> - Should we use (, ) tuple to find the class?
>>> Should we use (ParentClass, , ) tuple ?
>>
>> I'm not sure what the difference is, here.
>
> In the second case, the parent class is also used when cons
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.
>
> Whats wrong with add(Condition) ?
Nothing so far.
>> We still need a solution for the ambiguos cas
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 solvable. Almost any soltion world require
cooperation of the classes implementing the create method.
What we can do is adapting all core classes
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 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 use the same funny syntax, if it wasn't for
backwards c
On Tue, 29 Apr 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> Let me start by saying that the roles proposal had not in mind
> solving the polimorphism issue (which I think is what is at the
> bottom of your points here).
It simply occured to me that may not need any notion of roles
a
My example was incorrect (well it was pure nonsense)
I would agree that your approach is more complete and
in most cases more correct. So I think it should
be implemented.
I would still like to keep the add(Type) and addConfigured(Type)
methods for container like objects. For example scriptfilter
Stefan Bodewig wrote:
> On Mon, 28 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
>
>> If ParentClass has no addMyChild()/createMyChild() method, we'll
>> need to look up in some table and find a class associated with
>> .
>
> OK, well, maybe, see below for an alterbative view.
>> We'll
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>
> > Rather than (to take a perverse example)
> >
> >
> > >
>
> Ouch. I'd rather envision
>
>
>
> with a new public addCondition(Condition) method. The dupli
Hi Stefan,
Let me start by saying that the roles proposal had not in mind
solving the polimorphism issue (which I think is what is at the bottom
of your points here). I have no problem on arriving to a solution that
covers this aspect, but I do not want it to be the stumbling block
on the whole t
On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> This is debatable
I said I wasn't sure 8-)
> I think we should allow both approaches.
The main difference between them is that in approach 1 the child
determines the name of the element while it is the parent who does so
in the seco
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
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 Mon, 28 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> If ParentClass has no addMyChild()/createMyChild() method, we'll
> need to look up in some table and find a class associated with
> .
OK, well, maybe, see below for an alterbative view.
> We'll then look in ParentClass for an add
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
ClassFileset or ZipFileSet as either srcfiles or destfiles in
d
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
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> > Assume class C implements role intrefaces P, Q, and R then
> >
> >
> >
> >
> > will cause two definitions for "P" and "Q" each. There is no way to
> > assign different names separately. On the other app
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
Jose Alberto Fernandez wrote:
> Assume class C implements role intrefaces P, Q, and R then
>
>
>
>
> will cause two definitions for "P" and "Q" each. There is no way to
> assign different names separately. On the other approach:
>
>
>
>
>
>
>
> here you can get different names for diffe
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
> 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
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> 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 case. Let's agree
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
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
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
>
> >> In any case, all you really need is the tag name and the
> >> class name - the
> >> roles will be available as interfaces or superclasses.
> >> Nothing special for
> >> this association.
> >>
> >
> >
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
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
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 case. Let's agree
on this pattern first.
Assuming:
If ParentClas
Jose Alberto Fernandez wrote:
>> You'll have a task TaskA, with a method "addRoleB".
>> And in XML:
>>
>>
>>
>>
>>
>> TaskA doesn't know anything about the implementation - it
>> will only use an
>> interface ( or base class ) "RoleB" as parameter.
>>
>>
>> I assume you will need
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> > What does it all mean? It means we can now write a task,
> well typed, which
> > can be accept different XML subelements depending on the
> declarations of
> > other objects present on the build. The vend
Jose Alberto Fernandez wrote:
> What does it all mean? It means we can now write a task, well typed, which
> can be accept different XML subelements depending on the declarations of
> other objects present on the build. The vendor specific elements of
> , and others are typical examples of where
Hi I want to start a new thread to discuss specifically
the concept of Roles (as they were conceived in the ANTLIB proposal)
Costin has suggested we take this separately and whatever it comes of it
will be supported at that time by the antlibs, of course.
So here are my points on what roles are fo
81 matches
Mail list logo
