On Tue, 24 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> Hmmm. I actually don't know what else to say beyond
> the updates to the manual under Concepts and Types,
> and the modified tasks: pathconvert, concat, length +
> resourcecount.
This answer is exactly what I needed.
Thanks
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Any chance for a quick start guide?
Hmmm. I actually don't know what else to say beyond
the updates to the manual under Concepts and Types,
and the modified tasks: pathconvert, concat, length +
resourcecount. Let me know what further information
yo
On Mon, 23 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> Whew!
Thanks. Now I need to find a few hours to see how it all works ;-)
Any chance for a quick start guide?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Whew!
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> Here we go...
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
>
-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
> > > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > >
> > > --- Jose Alberto Fernandez
> > <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > All this discussion about roles brings me back
>
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> >
> > --- Jose Alberto Fernandez
> <[EMAIL PROTECTED]>
> > wrote:
> >
> > > All this discussion about roles brings me back
> to
> > > the
> > > proposal/implementation
> > > of Roles that I ma
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
>
> > All this discussion about roles brings me back to
> > the
> > proposal/implementation
> > of Roles that I made a long time ago and that was
> > rejected.
>
> If it works and solves th
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> All this discussion about roles brings me back to
> the
> proposal/implementation
> of Roles that I made a long time ago and that was
> rejected.
If it works and solves this problem, it's okay with
me. My only concern was the complexity of
t;ant.Condition" or ant.class="ant.pack.selector.And"
which are used by Introspection in case of ambiguity.
Jose Alberto
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: 15 April 2005 22:22
> To: Ant Developers List
> Subject:
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> I'll use your example below to ask what will be
> (im)possible
>
> The question is not whether the resourcecollection
> themselve need a
> namespace, but if it would be allowed to address
> elements from the same
> namespace, so that the default
Matt Benson wrote:
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
[SNIP]
Apart from the variands A and B further below, would
the following also
work?
or would this mean that the resoursecollection must
be part of set itself?
As I understand it, yes, because the x
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> Apart from the variands A and B further below, would
> the following also
> work?
>
>
>
>
>
>
>
>
>
>
>
>
> or would this mean that the resoursecollection must
> be part of set itself?
As I understand it,
> From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
> >
> >Martijn, Matt, the example above would be necessary if and only
> >if only had a add(ResourceSelector). In
> >practice, we'll likely have specialized addAnd(ResourceSelector) and
co
> >so that if can be written just:
> >
> >
> >
>
> But
But wouldn't that defeat the whole purpose of the I thought the whole point was avoiding having addConcrete in
favour of having add(Role).
What basically is that what Matt just stated.
Apart from the variands A and B further below, would the following also
work?
or woul
Dominique Devienne wrote:
Martijn, Matt, the example above would be necessary if and only
if only had a add(ResourceSelector). In
practice, we'll likely have specialized addAnd(ResourceSelector) and co
so that if can be written just:
>
But wouldn't that defeat the whole purpose of the I thou
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> Martijn, Matt, the example above would be necessary
> if and only
> if only had a
> add(ResourceSelector). In
> practice, we'll likely have specialized
> addAnd(ResourceSelector) and co
> so that if can be written just:
oh, that's partly what I
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Well that would be up to the "user". Would it mean
> for us that the code
> must be in different libraries, or is it enough if
> the classes are
> defined in separate property files / marked with
> special values, while
> the classes can still be
> From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
> Is this te direction we are going with "roles":
>
> xmlns:co="ant:condition"
> xmlns:set="ant:resourceselector">
>
>
>
>
>
>
>
>
>
Whao, I'm getting this email exchange out-of-order! Weird.
Martijn, Mat
Well that would be up to the "user". Would it mean for us that the code
must be in different libraries, or is it enough if the classes are
defined in separate property files / marked with special values, while
the classes can still be blended in in core ant.
Martijn
Matt Benson wrote:
You are u
You are using my preferred syntax. Also available
would be, e.g.:
-Matt
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
>
> >--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> >
> >
> >>On Mon, 11 Apr 2005, Matt Benson
> >><[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>
Matt Benson wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Mon, 11 Apr 2005, Matt Benson
<[EMAIL PROTECTED]> wrote:
Please don't. If I'm going to dump this
ResourceCollection stuff into HEAD I'd rather have
this resolved first, and right now only five
committers have shown any int
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Apr 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > Please don't. If I'm going to dump this
> > ResourceCollection stuff into HEAD I'd rather have
> > this resolved first, and right now only five
> > committers have shown any intere
On Mon, 11 Apr 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> Please don't. If I'm going to dump this
> ResourceCollection stuff into HEAD I'd rather have
> this resolved first, and right now only five
> committers have shown any interest in this aspect! :)
For the record, I'd like some explici
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
[SNIP]
> Don't worry, I'll stop rambling on this topic ;-)
> --DD
>
Please don't. If I'm going to dump this
ResourceCollection stuff into HEAD I'd rather have
this resolved first, and right now only five
committers have shown any interest in this
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Thu, 07 Apr 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > We should be able to make all the current conditions, selectors and
> > filters be typedefs.
>
> +1
As I wrote on the same thread, I'm starting to think that adding roles*
as typede
On Thu, 07 Apr 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
> We should be able to make all the current conditions, selectors and
> filters be typedefs.
+1
> There are only a few name over-laps:
>and, or, not (selectors and conditions)
and we need to solve them - there will be more to com
This was so well put-together I have little to add,
though I will say that after having had time to absorb
Peter's proposed alternative container, I am probably
not as negative about about it as Dominique. The
point that this type of fix would require maintenance
however certainly seems valid. My
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> I do not like "ant:mappers", etc
I don't have much of a problem with it myself now.
It's been argued, winning me over, that the ant: prefix
is already reserved, and thus it's an acceptable solution
solution to this problem, and Matt idea of loading
I meant to reply earlier...
I do not like "ant:mappers", etc
This does not use the method "antlib:" that antlibs are meant
to be identified by. If "ant:" is used to identify
ant's antlibs', then
there is ample reason for thirdparty antlibs authors to ask for "easy to
use" XML uri identifications
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> IIRC we've reserved "ant" as "protocol" as well as
> "antlib", even
> though I can't find any reference to that in out
> manual. Using that
> we certainly could shorten things:
>
> ant:mappers
> ant:fileselectors
> ant:resourceselectors
> ant:condit
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> IIRC we've reserved "ant" as "protocol" as well as
> "antlib", even
> though I can't find any reference to that in out
> manual.
[SNIP]
ant:current is declared in oata.ProjectHelper , so
there's the precedent for the protocol and whatever
follows to
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> IIRC we've reserved "ant" as "protocol" as well as
> "antlib", even
> though I can't find any reference to that in out
> manual. Using that
> we certainly could shorten things:
>
> ant:mappers
> ant:fileselectors
> ant:resourceselectors
> ant:condit
On Fri, 1 Apr 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>> > What's difficult already?
>> > It's like a Java import basically.
>> > You declare what you're using. What's wrong with
>> > that? --DD
>>
>> hmm... using the project attributes:
>>
>> > xmlns:fs="antlib:org.apache.to
ctly closed/nested).
[1] http://java.sun.com/xml/jaxp/dist/1.1/docs/tutorial/glossary.html#wellFormed
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Fri 01/04/2005 20:11
To: Ant Developers List
Cc:
Subject: RE: ResourceCollections
> From:
Matt Benson wrote:
Could we
auto-alias the uris so that the user setup might be
like
?
-0.5 for anything which makes the XMLNS rules for Ant scripts more
complicated (and divergent from the natural interpretation of XMLNS
semantics) than they already are...
-J.
--
[EMAIL PROTECTED] x22801 n
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > It's just the package names are quite long. Could
> we
> > auto-alias the uris so that the user setup might
> be
> > like below?
> >
> > > xmlns:fs="ant.fileselectors"
> > xmlns:rs="ant.resourceselectors">
>
> I'd prefer a
> > What's difficult already?
> > It's like a Java import basically.
> > You declare what you're using. What's wrong with
> > that? --DD
>
> hmm... using the project attributes:
>
> xmlns:fs="antlib:org.apache.tools.ant.types.selectors"
>
xmlns:rs="antlib:org.apache.tools.ant.types.reso
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > assuming my concern that users wouldn't bother
> using
> > something that requires extra setup (per
> project!),
> > what other things could we do to increase
> > ease-of-setup for antlibs?
>
> What's difficult already?
> It's like a Java impor
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> >what other things could we do to increase
> >ease-of-setup for antlibs?
> >
> Not use xml namespaces ;-)
Jokes apart, is that possible or desirable?
Are you having second thoughts about their use Peter?
I'm using them extensively, and like them,
Matt Benson wrote:
what other things could we do to increase
ease-of-setup for antlibs?
Not use xml namespaces ;-)
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> First, why so? (<-- an honest question.)
I tink I answered that one ahead of time ;-)
> assuming my concern that users wouldn't bother using
> something that requires extra setup (per project!),
> what other things could we do to increase
> ease-of-setup for antlibs?
What's difficult already?
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Peter Reilly <[EMAIL PROTECTED]> wrote:
> > Matt Benson wrote:
> >
> > >I also like the idea of using antlibs, but do we
> > then
> > >indicate that the user must explicitly set up the
> > >namespace prefixes or do we assign them
> > automagically?
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
>
> >I also like the idea of using antlibs, but do we
> then
> >indicate that the user must explicitly set up the
> >namespace prefixes or do we assign them
> automagically?
> > If the former, will anybody use them? If the
> latter,
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> Matt Benson wrote:
> >I also like the idea of using antlibs, but do we then
> >indicate that the user must explicitly set up the
> >namespace prefixes or do we assign them automagically?
> > If the former, will anybody use them? If the latter,
> >wh
Matt Benson wrote:
I also like the idea of using antlibs, but do we then
indicate that the user must explicitly set up the
namespace prefixes or do we assign them automagically?
If the former, will anybody use them? If the latter,
what prefixes to use?
The user must explicitly set them up.
Pete
I also like the idea of using antlibs, but do we then
indicate that the user must explicitly set up the
namespace prefixes or do we assign them automagically?
If the former, will anybody use them? If the latter,
what prefixes to use?
-Matt
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > F
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> 3) I'd rather not hard-code selector types.
>
> what other options exist? A built-in Antlib for
> namespacing the ResourceSelector types? A
> DynamicElement ResourceSelectorContainer?
Yeah, I'm surprised we don't have these built-in AntLibs alread
If we are going to add a ResourceSelector,
1) the interface and implementations will primarily be
relevant only to the "restrict" ResourceCollection.
2) things like And, Or, Not will be needed.
3) I'd rather not hard-code selector types.
what other options exist? A built-in Antlib for
namespac
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Mar 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > We are adding getInputStream to Resource.
> However,
> > without changing the FileSelector interface (bad),
>
> more than bad.
>
> > its ability to interact with Resources is limi
On Thu, 31 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> We are adding getInputStream to Resource. However,
> without changing the FileSelector interface (bad),
more than bad.
> its ability to interact with Resources is limited. We could
> possibly create a new ResourceSelector interface.
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
> I find this interesting.
> I wonder whether resources should not provide an
> InputStream or something
> like that. Because of selectors.
We are adding getInputStream to Resource. However,
without changing the FileSelector interface (bad), its
I find this interesting.
I wonder whether resources should not provide an InputStream or something
like that. Because of selectors.
Cheers,
Antoine
>
> --- Matt Benson <[EMAIL PROTECTED]> wrote:
> > To stay on the same thread, I have been developing
> > in
> > oata.types . So far I have probably
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> To stay on the same thread, I have been developing
> in
> oata.types . So far I have probably about 15
> classes
> to add to this package. Any opinions on whether we
> need oata.types.resource ?
or more probably, "resources" so we don't freak out
Win
To stay on the same thread, I have been developing in
oata.types . So far I have probably about 15 classes
to add to this package. Any opinions on whether we
need oata.types.resource ?
-Matt
__
Do you Yahoo!?
Yahoo! Small Business - Try our n
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Mar 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>
> >> Have you modified AbstractFileSet or the
> individual
> >> subclasses?
> >
> > Good question; I almost answered it in the
> origin
On Thu, 31 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> Have you modified AbstractFileSet or the individual
>> subclasses?
>
> Good question; I almost answered it in the original
> mail. I figured we had little control over what
> happens to
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Mar 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > Update: I have been rolling this stuff around and
> I
> > am nearly ready to have something to show.
>
> I really like what you've described.
well, hey! :)
>
> > I have also modi
1) a name for a ResourceCollection that acts like a
Union without removing duplicates.
What would it be used for? It is not a set operation that way and I'm
not familiar enough (at least the english terms of) with list theory
(if there is something like that at all). append? join?
Un
On Wed, 30 Mar 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> Update: I have been rolling this stuff around and I
> am nearly ready to have something to show.
I really like what you've described.
> I have also modified fileset, dirset, filelist and
> path to implement ResourceCollection.
Have
59 matches
Mail list logo
