Re: beating the dead Ant 1.6 horse
Conor MacNeill wrote: The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. What's the status on that ? Any decision on how to deal with the loaders ? I'll have some time next week, I wanted to finish the classloader task - is it still usefull ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Dominique Devienne wrote, On 12/08/2003 15.37: I'm also interested PropertyHelper, and in particular Costin's experimental XPath based one. I'd like to be able to define functions (defined as part of an AntLib) to operate directly on property values, kind of like XPath functions, and it sounds like property helper is the way to get this!?!? --DD Yes. PropertyHelper is a property interceptor, and it simply rocks. In essence, you register a helper with Ant. Then, at each request for a property, each registered helper is asked for the property value in turn; the first one that has it, returns it. A typical one is the xpath one, as you say, that resolves the request as an xpath in the Ant Project, if the property starts with xpath:. Centipede has been using it for a long time, basically to read an xml file as a property in a more powerful way than simply using xmlproperty. Now we are doing our own helper that reads the Gump descriptor, the Maven one, etc and makes them all accessible as a single virtual descriptor. In this way Ant users can have any descriptor they want and use that to gather properties and infos for the project. Just an example of the usage of PropertyHelper. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: beating the dead Ant 1.6 horse
On Thursday 14 August 2003 06:38, Costin Manolache wrote: Conor MacNeill wrote: The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. What's the status on that ? Any decision on how to deal with the loaders ? I'll have some time next week, I wanted to finish the classloader task - is it still usefull ? Most definitely. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Sounds great!
In anticipation of this feature I have used a few namespaced properties for
my custom tasks. And since Ant 1.5 doesn't have any value for these, I've
just made the tasks resolve them explicitly.
This raises a question: Are properties whose values are resolved by custom
PropertyHelpers always converted to Strings? I see that the return type of
PropertyHelper#getPropertyHook(String, String, boolean) has Object as the
return type. But if that's always converted to a String then my custom
PropertyHelper will need to make sure that this is done correctly, i.e. that
the Object yields a meaningful String representation.
But for tasks which have a setXXX(Object) method it would maybe make sense
to preserve the property value as an Object instance, if that's what's
actually in the buildfile. E.g.
foo xxx=${my:bar}/
would not convert the ${my:bar} property to a String.
Cheers,
--
knut
Nicola Ken Barozzi [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dominique Devienne wrote, On 12/08/2003 15.37:
I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able to define
functions (defined as part of an AntLib) to operate directly on
property values, kind of like XPath functions, and it sounds like
property helper is the way to get this!?!? --DD
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for a
property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
A typical one is the xpath one, as you say, that resolves the request as
an xpath in the Ant Project, if the property starts with xpath:.
Centipede has been using it for a long time, basically to read an xml
file as a property in a more powerful way than simply using xmlproperty.
Now we are doing our own helper that reads the Gump descriptor, the
Maven one, etc and makes them all accessible as a single virtual
descriptor. In this way Ant users can have any descriptor they want and
use that to gather properties and infos for the project.
Just an example of the usage of PropertyHelper.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for
a property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
Completely not following this property helper discussion up to this
point so I may be repeating something, (forgive me if I am) but this
sounds like the results of the request for a property could change if a
new property helper gets added... Does this break immutability? It may
be that the value of a property object never changes, but if the value
of ${foo} is one thing and then becomes another when a helper is
added I suspect whatever you have done is not going to cause this,
but what about someone writing a custom task that intentionally adds and
removes property helpers. What happens if someone writes a setproperty
task built on this idea? what happens if the property helper intercepts
built in things like ${basedir}? Sounds like the basis for a possible
chdir task :). Sounds highly abusable to me...
If you have set it up so ant doesn't accept new property helpers after
it starts executing the file, then this probably isn't an issue...
Just curious,
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Knut Wannheden wrote:
Sounds great!
In anticipation of this feature I have used a few namespaced properties
for
my custom tasks. And since Ant 1.5 doesn't have any value for these, I've
just made the tasks resolve them explicitly.
This raises a question: Are properties whose values are resolved by custom
PropertyHelpers always converted to Strings? I see that the return type
of PropertyHelper#getPropertyHook(String, String, boolean) has Object as
the
return type. But if that's always converted to a String then my custom
PropertyHelper will need to make sure that this is done correctly, i.e.
that the Object yields a meaningful String representation.
But for tasks which have a setXXX(Object) method it would maybe make sense
to preserve the property value as an Object instance, if that's what's
actually in the buildfile. E.g.
foo xxx=${my:bar}/
would not convert the ${my:bar} property to a String.
If you read the comments on top of PropertyHelper - that was one of the
goals, but I don't think it is implemented yet. The return value for the
property interceptors is already an object, but the code that does property
replacement doesn't know how to deal with ${prop}.
Costin
Cheers,
--
knut
Nicola Ken Barozzi [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dominique Devienne wrote, On 12/08/2003 15.37:
I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able to define
functions (defined as part of an AntLib) to operate directly on
property values, kind of like XPath functions, and it sounds like
property helper is the way to get this!?!? --DD
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for a
property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
A typical one is the xpath one, as you say, that resolves the request as
an xpath in the Ant Project, if the property starts with xpath:.
Centipede has been using it for a long time, basically to read an xml
file as a property in a more powerful way than simply using xmlproperty.
Now we are doing our own helper that reads the Gump descriptor, the
Maven one, etc and makes them all accessible as a single virtual
descriptor. In this way Ant users can have any descriptor they want and
use that to gather properties and infos for the project.
Just an example of the usage of PropertyHelper.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: RE: beating the dead Ant 1.6 horse
---BeginMessage---
...Hi, I kind of hear, that you are discussing, what kind of appears to be
in the domain of taskdef and its classpath-attribute and how classes are
loaded? Am I wrong here?
I have some examples with what could be called local
classpath/classloader-use - I can make it work with the somewhat complex
Jegustator - had a chat with the author - but not with JDepend, which
requires global modification of ${ant.home}/lib...
Something one of you care to discuss? -See two examples of mine?
Does some kind of textual explanation of classloading in Ant X.X.X/Ant 1.6
exist?
Regards,
Morten Sabroe Mortensen
-Original Message-
From: peter reilly
To: Ant Developers List
Sent: 14-08-03 10:36
Subject: Re: beating the dead Ant 1.6 horse
On Thursday 14 August 2003 06:38, Costin Manolache wrote:
Conor MacNeill wrote:
The others are antlib/namespace/polymorph stuff. I'm wondering if we
can
get to the point where the ant optional tasks are packaged as
antlibs and
potentially not added to the root loader if their supporting
libraries
are not also available to the root loader. This would allow them to
be
taskdef'd in later in a build.
What's the status on that ? Any decision on how to deal with the
loaders ?
I'll have some time next week, I wanted to finish the classloader task
- is
it still usefull ?
Most definitely.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---End Message---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
beating the dead Ant 1.6 horse
I know the quote is there is no timeframe yet on this release. But is there a ballpark? 2003? Some particular half of 2004? Thanks, Matt __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: beating the dead Ant 1.6 horse
On Tuesday 12 August 2003 04:20, Conor MacNeill wrote: On Tue, 12 Aug 2003 06:53 am, Matt Benson wrote: I know the quote is there is no timeframe yet on this release. But is there a ballpark? 2003? Some particular half of 2004? Ant 1.6 is very much alive, IMHO. 2003. :-) IMHO, I would hope to have it soon (where soon is undefined :-)) but I want to resolve a few things first ... Import is one of them - and it is important to get right. There are many different views on this from simple include to include with simple renaming to something close to an object model and even xslt style operation. I've been a little busy lately to push this along. I'll be back ... The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. I would rather leave this for after 1.6 release. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: beating the dead Ant 1.6 horse
The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. I would rather leave this for after 1.6 release. And how about the new PropertyHelper which lets you plugin additional PropertyHelpers to process properties prefixed with a namespace, i.e. foo:my-property? -- knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: beating the dead Ant 1.6 horse
I'm also interested PropertyHelper, and in particular Costin's experimental XPath based one. I'd like to be able to define functions (defined as part of an AntLib) to operate directly on property values, kind of like XPath functions, and it sounds like property helper is the way to get this!?!? --DD -Original Message- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 4:33 AM To: [EMAIL PROTECTED] Subject: Re: beating the dead Ant 1.6 horse The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. I would rather leave this for after 1.6 release. And how about the new PropertyHelper which lets you plugin additional PropertyHelpers to process properties prefixed with a namespace, i.e. foo:my-property? -- knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
