You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/11/02 22:33:59 UTC
Re: XmlProperty
On Wed, 2 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:
> To make sure we understand each other, what I mean
> here is to allow e.g.:
> <copy resource="url:someurl" tofile="foo" />
> or something similar, IH would pass "url:someurl" to a
> ResourceHelper class or some such that would attempt
> to locate a Resource type defined as "url" and call a
> String constructor with "someurl".
Hmm, I'd prefer (ab?)using PropertyHelpers for this instead of adding
new helpers.
<copy resource="${resource:url:someurl}"/> or something similar.
> This is more useful for specifying resources for
> output than for input.
Agreed.
> This has been another of my so-odd-as-to-likely-be-unpopular ideas,
You have no idea what type of odd ideas I have for resource
collections 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Kev Jackson <ke...@it.fts-vn.com>.
>Something I've been meaning to propose for two years but never had the
>time to fully think through. Allow each task to take input in form of
>a ResourceCollection and to declare its output as a ResourceCollection
>as well.
>
>Using this, provide a <pipe> task that chains the output of task n to
>the input of task n+1, something like
>
><pipe>
> <javac .../>
> <jar .../>
></pipe>
>
>
>
This is sweet!
>where jar would update an archive with the output of the javac task
>(no idea whether this is useful).
>
>More interesting, make targets have input and output - the input is
>passed to the first task, the output provided by the last task in the
>target. Extend this to a whole project as well.
>
>With this, <ant buildfile="projectA.xml"/> would provide the build
>artifacts of projectA as outputs. Let's say projectA creates a jar
>that my current project depends on, then I can add the <ant> task's
>output to a path to use it in <classpath> settings, or I can copy it
>around.
>
>My main goal here is to make projects less strongly coupled, I only
>need to know that I need the jar created by projectA, I don't need to
>know where it ends up or how it is called.
>
>
Should also completely prevent problems due to filesystems/locations of
files - it sounds great, but also a lot of work ;)
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Dale Anson <da...@grafidog.com>.
Awesome!
Steve Loughran wrote:
> Dale Anson wrote:
>
>> I'm not up on the code, but I like the concept, and I like the idea
>> of retrofitting existing tasks to use a generic resource rather than
>> methods for each specific type. My original question was about
>> having the XmlProperty task read from a property as well as a file,
>> I've always wanted similar functionality in the "get" task -- it only
>> writes the response to a file, when on occassion it would be much
>> handier to write it to a property so subsequent tasks could act
>> directly on the response.
>>
>> Dale
>
>
> the moment i commit my updated http antlib, <http:get> will save the
> response and/or http status code to properties.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Steve Loughran <st...@apache.org>.
Dale Anson wrote:
> I'm not up on the code, but I like the concept, and I like the idea of
> retrofitting existing tasks to use a generic resource rather than
> methods for each specific type. My original question was about having
> the XmlProperty task read from a property as well as a file, I've always
> wanted similar functionality in the "get" task -- it only writes the
> response to a file, when on occassion it would be much handier to write
> it to a property so subsequent tasks could act directly on the response.
>
> Dale
the moment i commit my updated http antlib, <http:get> will save the
response and/or http status code to properties.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Matt Benson <gu...@yahoo.com>.
--- Dale Anson <da...@grafidog.com> wrote:
> I'm not up on the code, but I like the concept, and
> I like the idea of
> retrofitting existing tasks to use a generic
> resource rather than
> methods for each specific type. My original
> question was about having
> the XmlProperty task read from a property as well as
> a file, I've always
> wanted similar functionality in the "get" task -- it
> only writes the
> response to a file, when on occassion it would be
> much handier to write
> it to a property so subsequent tasks could act
> directly on the response.
>
<get> is just one example of the motivations behind
this (fairly large) effort. :)
-Matt
> Dale
>
>
> Matt Benson wrote:
>
> >--- Stefan Bodewig <bo...@apache.org> wrote:
> >
> >
> >
> >>On Fri, 4 Nov 2005, Matt Benson
> >><gu...@yahoo.com> wrote:
> >>
> >>
> >>>--- Stefan Bodewig <bo...@apache.org> wrote:
> >>>
> >>>
> >>>
> >>>>On Wed, 2 Nov 2005, Matt Benson
> >>>><gu...@yahoo.com> wrote:
> >>>>
> >>>>
> >>>>>--- Stefan Bodewig <bo...@apache.org> wrote:
> >>>>>
> >>>>>
> >>>>>>Hmm, I'd prefer (ab?)using PropertyHelpers for
> >>>>>>
> >>>>>>
> >>this instead of
> >>
> >>
> >>>>>>adding new helpers.
> >>>>>>
> >>>>>><copy resource="${resource:url:someurl}"/> or
> >>>>>>something similar.
> >>>>>>
> >>>>>>
> >>>>>Hmm... this appears doable... it will require
> >>>>>
> >>>>>
> >>that the properties
> >>
> >>
> >>>>>be resolved by IntrospectionHelper instead of
> >>>>>
> >>>>>
> >>RuntimeConfigurable
> >>
> >>
> >>>>>though, which could require the usual
> >>>>>
> >>>>>
> >>backwards-compatibility
> >>
> >>
> >>>>>acrobatics.
> >>>>>
> >>>>>
> >>>>Do we really need to resolve that in
> >>>>
> >>>>
> >>IntrospectionHelper? Why?
> >>
> >>
> >>>What's the alternative? setResource(String)
> >>>
> >>>
> >>(after
> >>
> >>
> >>>which every implementor has to call resolution
> >>>
> >>>
> >>code)?
> >>
> >>I guess I need to re-read the code, its been a
> long
> >>time. IIUC you
> >>think we need to modify IntrospectionHelper so
> that
> >>the correct object
> >>type can be created right there, correct?
> >>
> >>OK, I see the problem now. PropertyHelper - or
> the
> >>way we use it -
> >>isn't really suited for property expansions that
> >>yield something other
> >>than a String.
> >>
> >>It's probably easier to have some kind of
> >>ResourceFactory that
> >>returned Resource instances (or subclasses
> thereof)
> >>based on Strings
> >>and explicitly code support for this into
> >>IntrospectionHelper (much
> >>like the special cases for boolean or File). Your
> >>original idea,
> >>isn't it?
> >>
> >>
> >
> >Yeah, basically. :) So if anyone other than
> myself
> >and Stefan have been paying attention to this
> >conversation, does that scare anyone? DD? ;)
> >
> >-Matt
> >
> >
> >
> >>Stefan
> >>
> >>
> >>
> >>
>
>---------------------------------------------------------------------
> >
> >
> >>To unsubscribe, e-mail:
> >>dev-unsubscribe@ant.apache.org
> >>For additional commands, e-mail:
> >>dev-help@ant.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >__________________________________
> >Yahoo! Mail - PC Magazine Editors' Choice 2005
> >http://mail.yahoo.com
> >
>
>---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> >For additional commands, e-mail:
> dev-help@ant.apache.org
> >
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Dale Anson <da...@grafidog.com>.
I'm not up on the code, but I like the concept, and I like the idea of
retrofitting existing tasks to use a generic resource rather than
methods for each specific type. My original question was about having
the XmlProperty task read from a property as well as a file, I've always
wanted similar functionality in the "get" task -- it only writes the
response to a file, when on occassion it would be much handier to write
it to a property so subsequent tasks could act directly on the response.
Dale
Matt Benson wrote:
>--- Stefan Bodewig <bo...@apache.org> wrote:
>
>
>
>>On Fri, 4 Nov 2005, Matt Benson
>><gu...@yahoo.com> wrote:
>>
>>
>>>--- Stefan Bodewig <bo...@apache.org> wrote:
>>>
>>>
>>>
>>>>On Wed, 2 Nov 2005, Matt Benson
>>>><gu...@yahoo.com> wrote:
>>>>
>>>>
>>>>>--- Stefan Bodewig <bo...@apache.org> wrote:
>>>>>
>>>>>
>>>>>>Hmm, I'd prefer (ab?)using PropertyHelpers for
>>>>>>
>>>>>>
>>this instead of
>>
>>
>>>>>>adding new helpers.
>>>>>>
>>>>>><copy resource="${resource:url:someurl}"/> or
>>>>>>something similar.
>>>>>>
>>>>>>
>>>>>Hmm... this appears doable... it will require
>>>>>
>>>>>
>>that the properties
>>
>>
>>>>>be resolved by IntrospectionHelper instead of
>>>>>
>>>>>
>>RuntimeConfigurable
>>
>>
>>>>>though, which could require the usual
>>>>>
>>>>>
>>backwards-compatibility
>>
>>
>>>>>acrobatics.
>>>>>
>>>>>
>>>>Do we really need to resolve that in
>>>>
>>>>
>>IntrospectionHelper? Why?
>>
>>
>>>What's the alternative? setResource(String)
>>>
>>>
>>(after
>>
>>
>>>which every implementor has to call resolution
>>>
>>>
>>code)?
>>
>>I guess I need to re-read the code, its been a long
>>time. IIUC you
>>think we need to modify IntrospectionHelper so that
>>the correct object
>>type can be created right there, correct?
>>
>>OK, I see the problem now. PropertyHelper - or the
>>way we use it -
>>isn't really suited for property expansions that
>>yield something other
>>than a String.
>>
>>It's probably easier to have some kind of
>>ResourceFactory that
>>returned Resource instances (or subclasses thereof)
>>based on Strings
>>and explicitly code support for this into
>>IntrospectionHelper (much
>>like the special cases for boolean or File). Your
>>original idea,
>>isn't it?
>>
>>
>
>Yeah, basically. :) So if anyone other than myself
>and Stefan have been paying attention to this
>conversation, does that scare anyone? DD? ;)
>
>-Matt
>
>
>
>>Stefan
>>
>>
>>
>>
>---------------------------------------------------------------------
>
>
>>To unsubscribe, e-mail:
>>dev-unsubscribe@ant.apache.org
>>For additional commands, e-mail:
>>dev-help@ant.apache.org
>>
>>
>>
>>
>
>
>
>
>
>__________________________________
>Yahoo! Mail - PC Magazine Editors' Choice 2005
>http://mail.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 4 Nov 2005, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@apache.org> wrote:
> >
> >> On Wed, 2 Nov 2005, Matt Benson
> >> <gu...@yahoo.com> wrote:
> >> > --- Stefan Bodewig <bo...@apache.org> wrote:
> >>
> >> >> Hmm, I'd prefer (ab?)using PropertyHelpers for
> this instead of
> >> >> adding new helpers.
> >> >>
> >> >> <copy resource="${resource:url:someurl}"/> or
> >> >> something similar.
> >> >
> >> > Hmm... this appears doable... it will require
> that the properties
> >> > be resolved by IntrospectionHelper instead of
> RuntimeConfigurable
> >> > though, which could require the usual
> backwards-compatibility
> >> > acrobatics.
> >>
> >> Do we really need to resolve that in
> IntrospectionHelper? Why?
> >
> > What's the alternative? setResource(String)
> (after
> > which every implementor has to call resolution
> code)?
>
> I guess I need to re-read the code, its been a long
> time. IIUC you
> think we need to modify IntrospectionHelper so that
> the correct object
> type can be created right there, correct?
>
> OK, I see the problem now. PropertyHelper - or the
> way we use it -
> isn't really suited for property expansions that
> yield something other
> than a String.
>
> It's probably easier to have some kind of
> ResourceFactory that
> returned Resource instances (or subclasses thereof)
> based on Strings
> and explicitly code support for this into
> IntrospectionHelper (much
> like the special cases for boolean or File). Your
> original idea,
> isn't it?
Yeah, basically. :) So if anyone other than myself
and Stefan have been paying attention to this
conversation, does that scare anyone? DD? ;)
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 4 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
>> On Wed, 2 Nov 2005, Matt Benson
>> <gu...@yahoo.com> wrote:
>> > --- Stefan Bodewig <bo...@apache.org> wrote:
>>
>> >> Hmm, I'd prefer (ab?)using PropertyHelpers for this instead of
>> >> adding new helpers.
>> >>
>> >> <copy resource="${resource:url:someurl}"/> or
>> >> something similar.
>> >
>> > Hmm... this appears doable... it will require that the properties
>> > be resolved by IntrospectionHelper instead of RuntimeConfigurable
>> > though, which could require the usual backwards-compatibility
>> > acrobatics.
>>
>> Do we really need to resolve that in IntrospectionHelper? Why?
>
> What's the alternative? setResource(String) (after
> which every implementor has to call resolution code)?
I guess I need to re-read the code, its been a long time. IIUC you
think we need to modify IntrospectionHelper so that the correct object
type can be created right there, correct?
OK, I see the problem now. PropertyHelper - or the way we use it -
isn't really suited for property expansions that yield something other
than a String.
It's probably easier to have some kind of ResourceFactory that
returned Resource instances (or subclasses thereof) based on Strings
and explicitly code support for this into IntrospectionHelper (much
like the special cases for boolean or File). Your original idea,
isn't it?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 2 Nov 2005, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@apache.org> wrote:
>
> >> Hmm, I'd prefer (ab?)using PropertyHelpers for
> this
> >> instead of adding
> >> new helpers.
> >>
> >> <copy resource="${resource:url:someurl}"/> or
> >> something similar.
> >
> > Hmm... this appears doable... it will require that
> the
> > properties be resolved by IntrospectionHelper
> instead
> > of RuntimeConfigurable though, which could require
> the
> > usual backwards-compatibility acrobatics.
>
> Do we really need to resolve that in
> IntrospectionHelper? Why?
What's the alternative? setResource(String) (after
which every implementor has to call resolution code)?
How else other than monkeying with IH can we keep our
API pretty and still get the Resources resolved?
[SNIP]
>
> >> You have no idea what type of odd ideas I have
> for resource
> >> collections 8-)
> >
> > Please, go ahead. Scare me!
>
> Something I've been meaning to propose for two years
> but never had the
> time to fully think through. Allow each task to
> take input in form of
> a ResourceCollection and to declare its output as a
> ResourceCollection
> as well.
>
> Using this, provide a <pipe> task that chains the
> output of task n to
> the input of task n+1, something like
>
> <pipe>
> <javac .../>
> <jar .../>
> </pipe>
>
> where jar would update an archive with the output of
> the javac task
> (no idea whether this is useful).
>
> More interesting, make targets have input and output
> - the input is
> passed to the first task, the output provided by the
> last task in the
> target. Extend this to a whole project as well.
>
> With this, <ant buildfile="projectA.xml"/> would
> provide the build
> artifacts of projectA as outputs. Let's say
> projectA creates a jar
> that my current project depends on, then I can add
> the <ant> task's
> output to a path to use it in <classpath> settings,
> or I can copy it
> around.
>
> My main goal here is to make projects less strongly
> coupled, I only
> need to know that I need the jar created by
> projectA, I don't need to
> know where it ends up or how it is called.
pipes...! did I mention that I had pipes working using
<redirector> but windows JDKs had some threading issue
so that my pipes worked on Unix systems but deadlocked
on Windows all the time? I'm still mad about that...
>:(
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 2 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>> Hmm, I'd prefer (ab?)using PropertyHelpers for this
>> instead of adding
>> new helpers.
>>
>> <copy resource="${resource:url:someurl}"/> or
>> something similar.
>
> Hmm... this appears doable... it will require that the
> properties be resolved by IntrospectionHelper instead
> of RuntimeConfigurable though, which could require the
> usual backwards-compatibility acrobatics.
Do we really need to resolve that in IntrospectionHelper? Why?
> The resource-aware PropertyHelper would become part of the default
> PropertyHelper chain then as well?
Yes.
> Speaking of which we still need to make adding
> PropertyHelpers to the chain more (at all)
> user-friendly, but that's (yet) another discussion.
I agree, maybe providing a task that does (same for InputHelper or the
Executor).
>> You have no idea what type of odd ideas I have for resource
>> collections 8-)
>
> Please, go ahead. Scare me!
Something I've been meaning to propose for two years but never had the
time to fully think through. Allow each task to take input in form of
a ResourceCollection and to declare its output as a ResourceCollection
as well.
Using this, provide a <pipe> task that chains the output of task n to
the input of task n+1, something like
<pipe>
<javac .../>
<jar .../>
</pipe>
where jar would update an archive with the output of the javac task
(no idea whether this is useful).
More interesting, make targets have input and output - the input is
passed to the first task, the output provided by the last task in the
target. Extend this to a whole project as well.
With this, <ant buildfile="projectA.xml"/> would provide the build
artifacts of projectA as outputs. Let's say projectA creates a jar
that my current project depends on, then I can add the <ant> task's
output to a path to use it in <classpath> settings, or I can copy it
around.
My main goal here is to make projects less strongly coupled, I only
need to know that I need the jar created by projectA, I don't need to
know where it ends up or how it is called.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: XmlProperty
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 2 Nov 2005, Matt Benson
> <gu...@yahoo.com> wrote:
>
> > To make sure we understand each other, what I mean
> > here is to allow e.g.:
> > <copy resource="url:someurl" tofile="foo" />
> > or something similar, IH would pass "url:someurl"
> to a
> > ResourceHelper class or some such that would
> attempt
> > to locate a Resource type defined as "url" and
> call a
> > String constructor with "someurl".
>
> Hmm, I'd prefer (ab?)using PropertyHelpers for this
> instead of adding
> new helpers.
>
> <copy resource="${resource:url:someurl}"/> or
> something similar.
Hmm... this appears doable... it will require that the
properties be resolved by IntrospectionHelper instead
of RuntimeConfigurable though, which could require the
usual backwards-compatibility acrobatics. Then the
internally used interface (abstract class)
AttributeSetter of IH would have to be changed to take
an Object value instead of a String, just to have the
opportunity to use the Object value PropertyHelper is
capable of returning (Project isn't). The
resource-aware PropertyHelper would become part of the
default PropertyHelper chain then as well?
Speaking of which we still need to make adding
PropertyHelpers to the chain more (at all)
user-friendly, but that's (yet) another discussion.
>
> > This is more useful for specifying resources for
> > output than for input.
>
> Agreed.
>
> > This has been another of my
> so-odd-as-to-likely-be-unpopular ideas,
>
> You have no idea what type of odd ideas I have for
> resource
> collections 8-)
Please, go ahead. Scare me!
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org