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
--- 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
you
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
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
-
--- 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 made a long time ago and that
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
to
the
to
disambiguate:
ant:role=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: RE: ResourceCollections
--- 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 the
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 this problem, it's
Matt Benson wrote:
--- Martijn Kruithof [EMAIL PROTECTED] wrote:
[SNIP]
Apart from the variands A and B further below, would
the following also
work?
project name=foo default=bar
resourcecollection id=blah xmlns=ant:set
and
files dir=foo name=**/*.java/
date select=newer
--- 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 namespace
--- 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 interest in this
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
You are using my preferred syntax. Also available
would be, e.g.:
and xmlns=ant:conditions /
and xmlns=ant:fileselectors /
and xmlns=ant:resourceselectors /
date xmlns=ant:resourceselectors /
date xmlns=ant:resourcecomparators /
-Matt
--- Martijn Kruithof [EMAIL PROTECTED] wrote:
Matt Benson
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
From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
Is this te direction we are going with roles:
project name=foo default=bar
xmlns:co=ant:condition
xmlns:set=ant:resourceselector
resourcecollection id=blah
set:and
set:files dir=foo name=**/*.java/
set:date
--- 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 blended
--- Dominique Devienne [EMAIL PROTECTED] wrote:
Martijn, Matt, the example above would be necessary
if and only
if resourcecollection 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
Dominique Devienne wrote:
snip with namespaces
Martijn, Matt, the example above would be necessary if and only
if resourcecollection only had a add(ResourceSelector). In
practice, we'll likely have specialized addAnd(ResourceSelector) and co
so that if can be written just:
snip without
But wouldn't that defeat the whole purpose of the fill in role-type
here 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?
project
From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
snip with namespaces
Martijn, Matt, the example above would be necessary if and only
if resourcecollection only had a add(ResourceSelector). In
practice, we'll likely have specialized addAnd(ResourceSelector) and
co
so that if can be written
--- Martijn Kruithof [EMAIL PROTECTED] wrote:
[SNIP]
Apart from the variands A and B further below, would
the following also
work?
project name=foo default=bar
resourcecollection id=blah xmlns=ant:set
and
files dir=foo name=**/*.java/
date select=newer
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 explicit way
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 come, in
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 typedefs in the
--- 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
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.
I meant to reply earlier...
I do not like ant:mappers, etc
This does not use the method antlib:package name that antlibs are meant
to be identified by. If ant:whatever core wants is used to identify
ant's antlibs', then
there is ample reason for thirdparty antlibs authors to ask for easy to
use
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
--- 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:conditions
I'd like to
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:
project name=foo default=bar
--- 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:conditions
I wondered
--- 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 mean
Matt Benson wrote:
Could we
auto-alias the uris so that the user setup might be
like
project name=foo default=bar
xmlns:fs=ant.fileselectors
xmlns:rs=ant.resourceselectors
?
-0.5 for anything which makes the XMLNS rules for Ant scripts more
complicated (and divergent from the
] 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: Peter Reilly [mailto:[EMAIL
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.
I
--- 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 limited.
We could
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 already for
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:
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.
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,
what prefixes
--- 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?
The user must
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]
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, maybe
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:
project name=foo default=bar
xmlns:fs=antlib:org.apache.tools.ant.types.selectors
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 you
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?
--- 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 modified fileset,
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 AFS
--- 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
original
mail. I figured
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
--- 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
Windows for
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 about 15
--- 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
54 matches
Mail list logo
