Re: OS Independent file strings in resourcecollections
On 2009-09-17, Raja Nagendra Kumar nagendra.r...@tejasoft.com wrote:
Hi,
I am using ResourceCollections such as Union etc. However when ever I
iterate, I am seeing the file names be as per the OS conventions.
e.g if the file on windows matches to the collections and it is located in
f:\work\nag\test.txt
the the union iterator gives it as f:\work\nag\test.txt and not as
f:/work/nag/test.txt.
due to this my name matching , using restrict etc are failing. as my match
pattern uses / instead of \ for os independency.
In this context, is there a way to tell the ant to use always OS independent
file path separator..
I see what you mean. The filename fileselector takes care of the file
separator but the name resource selector does not. I'd suggest adding a
handleDirSep attribute like the one for globmapper to the name selector
for the next Ant release.
Could you please file a bugzilla issue for this?
As a workaround you can use ${file.separator} instead of / all over your
patterns (or if you are using them programmatically
java.io.File.separator[Char]).
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: OS Independent file strings in resourcecollections
Hi Stefan as suggested I have filed the issue and the same is found at https://issues.apache.org/bugzilla/show_bug.cgi?id=47858 Regards, Nagendra -- View this message in context: http://www.nabble.com/OS-Independent-file-strings-in-resourcecollections-tp25486284p25489409.html Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ResourceCollections
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 additional commands, e-mail: [EMAIL PROTECTED]
Re: copy + ResourceCollections
On Mon, 23 May 2005, Matt Benson [EMAIL PROTECTED] wrote: So by that token, you would similarly add a Deletable (?) interface for FileResource to implement. So then move could fail when encountering a Resource that does not implement Deletable... Let's turn this around. Do we really want to support deleting of files on a remote FTP server using delete or move? Or would we want users to stick to ftp fro this? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy + ResourceCollections
On Mon, 23 May 2005, Matt Benson [EMAIL PROTECTED] wrote: My proposal regarding copy is that any FileResource with a base directory is processed according to BC, +1 but any other Resource is copied with implicit flattening (and an appropriate warning message) unless a nested mapper element says otherwise. Sounds reasonable and easy to explain. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 think we need to provide, as far as you can without knowing what that information IS, anyway. ;) I also need to document that path can take any filesystem-only resourcecollection as a nested element. -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ResourceCollections WAS Re: AW: cvs commit: ant/src/testcases/org/apache/tools/ant/types/opti onal/depend ClassFileSetTest.java
--- [EMAIL PROTECTED] wrote: src/resources/org/apache/tools/ant/types/resources/selectors Do you mean, we have to rewrite our file-selectors? Any fileselector continues to work with fileset/dirset as well as files. Most fileselectors should still be relevant as resourceselectors, and in those cases it might be nice to delegate file selection to the corresponding resourceselector, just to decrease the number of places where an implementation of a check exists. I didn't attempt to create a resource version of modified because a) I don't understand it :) and b) I wasn't sure how to handle the properties file approach that exists w/ the file version. It is probably translatable, but I hoped maybe you could do it :) or help me to. -Matt Jan __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: ResourceCollections WAS Re: AW: cvs commit: ant/src/testcases /org/apache/tools/ant/types/opti onal/depend ClassFileSetTest.java
I think about that by myself :) You said that a Resource could could give Input/OutputStream. So it would be possible just to add another Cache implementiation based on that. I thought of implementing the ResourceSelector interface additionally ... Jan -Ursprüngliche Nachricht- Von: Matt Benson [mailto:[EMAIL PROTECTED] Gesendet am: Dienstag, 24. Mai 2005 17:43 An: Ant Developers List Betreff: ResourceCollections WAS Re: AW: cvs commit: ant/src/testcases/org/apache/tools/ant/types/opti onal/depend ClassFileSetTest.java --- [EMAIL PROTECTED] wrote:h src/resources/org/apache/tools/ant/types/resources/selectors Do you mean, we have to rewrite our file-selectors? Any fileselector continues to work with fileset/dirset as well as files. Most fileselectors should still be relevant as resourceselectors, and in those cases it might be nice to delegate file selection to the corresponding resourceselector, just to decrease the number of places where an implementation of a check exists. I didn't attempt to create a resource version of modified because a) I don't understand it :) and b) I wasn't sure how to handle the properties file approach that exists w/ the file version. It is probably translatable, but I hoped maybe you could do it :) or help me to. -Matt Jan __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ResourceCollections WAS Re: AW: cvs commit: ant/src/testcases /org/apache/tools/ant/types/opti onal/depend ClassFileSetTest.java
--- [EMAIL PROTECTED] wrote: I think about that by myself :) You said that a Resource could could give Input/OutputStream. So it would be possible just to add another Cache implementiation based on that. I thought of implementing the ResourceSelector interface additionally ... You could probably do that too. Just remember that the restrict collection is the only one that knows about ResourceSelectors and they must be typedef'd--most likely in antlib:org.apache.tools.ant.types.resources.selectors (vote ant:resourceselectors !) or else globally. -Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ResourceCollections
Here we go... __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
copy + ResourceCollections
Now that ResourceCollections have been added to CVS, I (and anyone who wants to help) need to add support for ResourceCollections anywhere that it makes sense to do so. As I have mentioned in some bugreps tasks that operate on paths and should only get real-filesystem-files should work by adding filesystem-only resource collections to paths. These are not terribly plentiful, however, so it's time to figure out sensible ways for tasks to work with resource collections. Anyone who cares to read this may have noticed that I have subclassed Resource, primarily for input/outputStream accessor implementations, but also for typing in the case of the most common Resource type: FileResources. These provide access to the underlying file and, optionally, a base directory. My proposal regarding copy is that any FileResource with a base directory is processed according to BC, but any other Resource is copied with implicit flattening (and an appropriate warning message) unless a nested mapper element says otherwise. Regarding the Move task, I don't see that we could move non-file resources in a predictable way so I would recommend failing on ResourceCollections that do not return true from isFilesystemOnly(). Thoughts? -Matt __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy + ResourceCollections
Can it be - copy+delete in that case? - Alexey. Matt Benson wrote: ... Regarding the Move task, I don't see that we could move non-file resources in a predictable way so I would recommend failing on ResourceCollections that do not return true from isFilesystemOnly(). Thoughts? -Matt -- / Alexey N. Solofnenko MDL Information Systems, Inc. work: 510-357-x1726 home: http://trelony.cjb.net/ / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy + ResourceCollections
--- Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Can it be - copy+delete in that case? Okay... here's what I did for preserving timestamps in FileUtils copy methods. I added a Touchable interface to the resources package. FileResource is (so far) the only Resource that uses it, but I was thinking along the lines of FTP/SCP Resources when I added it. So by that token, you would similarly add a Deletable (?) interface for FileResource to implement. So then move could fail when encountering a Resource that does not implement Deletable... that is the only sensible way that occurs to me to support Resource deletion. -Matt - Alexey. Matt Benson wrote: ... Regarding the Move task, I don't see that we could move non-file resources in a predictable way so I would recommend failing on ResourceCollections that do not return true from isFilesystemOnly(). Thoughts? -Matt __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy + ResourceCollections
Sounds great. Do you have also Movable interface? - Alexey. On 5/23/05, Matt Benson [EMAIL PROTECTED] wrote: --- Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Can it be - copy+delete in that case? Okay... here's what I did for preserving timestamps in FileUtils copy methods. I added a Touchable interface to the resources package. FileResource is (so far) the only Resource that uses it, but I was thinking along the lines of FTP/SCP Resources when I added it. So by that token, you would similarly add a Deletable (?) interface for FileResource to implement. So then move could fail when encountering a Resource that does not implement Deletable... that is the only sensible way that occurs to me to support Resource deletion. -Matt - Alexey. Matt Benson wrote: ... Regarding the Move task, I don't see that we could move non-file resources in a predictable way so I would recommend failing on ResourceCollections that do not return true from isFilesystemOnly(). Thoughts? -Matt -- Alexey N. Solofnenko trelony at gmail.com http://gmail.com home: http://trelony.cjb.net/ Pleasant Hill, CA (GMT-8 hours usually)
Re: copy + ResourceCollections
--- Alexey Solofnenko [EMAIL PROTECTED] wrote: Sounds great. Do you have also Movable interface? Not yet. Let's see if anyone else has anything to say about these concepts too. -Matt - Alexey. On 5/23/05, Matt Benson [EMAIL PROTECTED] wrote: --- Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Can it be - copy+delete in that case? Okay... here's what I did for preserving timestamps in FileUtils copy methods. I added a Touchable interface to the resources package. FileResource is (so far) the only Resource that uses it, but I was thinking along the lines of FTP/SCP Resources when I added it. So by that token, you would similarly add a Deletable (?) interface for FileResource to implement. So then move could fail when encountering a Resource that does not implement Deletable... that is the only sensible way that occurs to me to support Resource deletion. -Matt - Alexey. Matt Benson wrote: ... Regarding the Move task, I don't see that we could move non-file resources in a predictable way so I would recommend failing on ResourceCollections that do not return true from isFilesystemOnly(). Thoughts? -Matt -- Alexey N. Solofnenko trelony at gmail.com http://gmail.com home: http://trelony.cjb.net/ Pleasant Hill, CA (GMT-8 hours usually) __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
--- 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 was rejected. After thinking about this further, this would be okay for inline usage of duplicate names but is still inferior to using Antlibs for scoping in that types can stand alone at the project level (with id normally) in the latter scheme, and referenced later. A small distinction perhaps, but I like to be able to declare things I intend to reuse at a high level rather than naming them during their first use. -Matt __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 proposal/implementation of Roles that I made a long time ago and that was rejected. After thinking about this further, this would be okay for inline usage of duplicate names but is still inferior to using Antlibs for scoping in that types can stand alone at the project level (with id normally) in the latter scheme, and referenced later. A small distinction perhaps, but I like to be able to declare things I intend to reuse at a high level rather than naming them during their first use. I agree with you in principle. However, I do not think every little bit of XML is a good candidate for id'ing. You may ID a fileset or a resoursecollection but a mapper on its own makes less sense since you usually need to look at its meaning in the context of the usage. You can always find a counterexample of course but as a general rule... To me name overloading makes sense for a very limited number of very much used things and as for a condition or a selector, is a good example. I am sure others can come with other cases. Forcing usage of namespaces is the same as forcing new different names for everything. In particular in core. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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.
I can hardly remember it by now (or I may be reinventing it anew ;-) ),
but the key of the matter was the following (notice this was before
namespaces):
a) Roles are interfaces.
b) We have add(Interface) methods for the roles.
c) Introspection works as follows when looking at an XML element:
1) Look at ALL the classes using that name (e.g., all the classes
mapped to and)
2) Restrict this set to those classes implementing an interface for
which
there is an add(Interface) method.
3) If there is more than one class in the resulting set, this is a
disambiguation error.
d) If this unique class implements more than one Interface with an add()
in the context,
there is a disambiguation error. Since we do not know what method to
call.
e) Call the only method with the only class that matches.
This was before namespaces, so this may apply to the current core or
allow libraries to
use the same name for multiple things.
Now, in this situation, what would introspection need to be able to
solve ambiguities?
Example: Lets have the following definitions:
foo= ant.pack.Foo {
add(ant.Condition);
add(ant.Selector);
}
and=ant.pack.condition.And implements ant.Condition;
and=ant.pack.selector.And implements ant.Selector;
foo
and .../
/foo
This will give an error as it will not know which and to use (two
classes),
Somehow you need to say which class to use.
On the other hand, we could have:
or=ant.pack.ambiguous.Or implements ant.Condition, ant.Selector;
foo
or .../
/foo
This will give an error as it will not know which add() to call (two
methods, one class),
Somehow we need to say which role to use.
Using NS just means that you associate different names to different
elements. But that is
not the issue we have in core, they have the same element name. And if
core can do that,
I do not see why third party cannot do the same.
This looks to me as the need to have meta attributes that can be used 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
--- 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 partly what I was trying to avoid. Part of
the beauty, to me, of some of the latest introspection
code is the ability to use add() methods. It makes me
unhappy to have to specify element names in my
configuration methods where there is no ambiguity.
For example, if you have to add multiple elements of
the same type to be used for different purposes, then
okay, how else would you know which was which? But in
the case of the restrict ResourceCollection (which
is the context for ResourceSelectors), why should I
have to support addAnd(), addOr(), addNot(),
addNone(), addMajority, etc., etc., when I could code
add(ResourceSelector) and be done with it? That takes
us back to either forcing the explicit declaration at
all times or trying to code something that uses
context to decide which and the user means at
runtime... fine, but also complicated and, as Peter
pointed out, bound to encounter ambiguity errors.
[trying to snip as much as possible lest these become unmanageable]
-Matt
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 code needed to make such a thing work. I suppose if we introduced this it would be simplest to comma/space-delimit classnames in a task|typedef properties file; e.g.: and=org.apache.tools.ant.types.selectors.AndSelector, \ org.apache.tools.ant.types.resources.selectors.And -Matt __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 okay with me. My only concern was the complexity of the code needed to make such a thing work. I suppose if we introduced this it would be simplest to comma/space-delimit classnames in a task|typedef properties file; e.g.: and=org.apache.tools.ant.types.selectors.AndSelector, \ org.apache.tools.ant.types.resources.selectors.And The main reason for allowing multiple things with the same name is that they can be defined that way by different providers. You could have that if you load several 3rd party antlibs on the same namespace (which I think you can do by loading explicitly). One could think on adding all your antlibs explicitly to the ant:core and remove the usage of NS completely, but that would be a user choice. (this could be a way to deal in a BC way with optional stuff, I.e., put it in an antlib that loads into ant:core NS and hence uses default prefix). When you have more than one lib on the same NS you have the posibility of name clashes and hence the issues about role resolution. So it is not about one property file is about multiple sources of definintions. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 date=2005/04/15/
/and
/resourcecollection
/project
or would this mean that the resoursecollection must
be part of set itself?
As I understand it, yes, because the xmlns was
declared on the resourcecollection element. I am
having a hard time following your exact example here
because I'm not sure how you are imagining the
ResourceCollections to look, while I know what they
look like. :)
I'll use your example below to ask what will be (im)possible
I don't see that the ResourceCollections themselves
need a namespace.
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 declaration would work for the
entire nested set of elements, including the element itself.
I have modified FileSet and similar
existing types to implement ResourceCollection.
Really the whole problem goes back to and/or/not, etc.
The Princess and the Pea. Anyway, I translate your
example above as:
project xmlns:rs=ant:resourceselectors
restrict!-- ResourceCollection type --
!-- FileCollection aka files has no basedir --
files name=${basedir}/foo/**/*.java /
!-- haven't written this selector yet; here
mimicked date FileSelector --
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
Why would the date have the rs namespace and the files not, both are
used inside the resourcecollection?
Does that make sense?
-Matt
So now up to the alternatives using the names of above example (Same
letter means equivalent in XML):
A1 (shameless copy from above)
project xmlns:rs=ant:resourceselectors
restrict
files name=${basedir}/foo/**/*.java /
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
A2:
project
restrict
files name=${basedir}/foo/**/*.java /
date when=after datetime=2005/04/15
pattern=/MM/dd xmlns=ant:resourceselectors/
/restrict
/project
B1 (difference files allowed / mandated to be in rs namespace)
project xmlns:rs=ant:resourceselectors
restrict
rs:files name=${basedir}/foo/**/*.java /
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
B2:
project
restrict
files name=${basedir}/foo/**/*.java xmlns=ant:resourceselectors/
date when=after datetime=2005/04/15
pattern=/MM/dd xmlns=ant:resourceselectors/
/restrict
/project
C1 (difference now allos restric allowed / mandated to be in rs
namespace, maybe a better name would in that case be resourcecollections)
project xmlns:rs=ant:resourceselectors
rs:restrict
rs:files name=${basedir}/foo/**/*.java /
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/rs:restrict
/project
C2:
project
restrict xmlns=ant:resourceselectors
files name=${basedir}/foo/**/*.java /
date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
D: (no namespace at all, with the danger and problems of clashes,
extensively discuussed before.)
project
restrict
files name=${basedir}/foo/**/*.java /
date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
Are there any other variations possible, are variant A-D feasible, and
what is best. (I'd currently say B or C)
Martijn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 declaration
would work for the
entire nested set of elements, including the
element itself.
Why would the date have the rs namespace and the
files not, both are
used inside the resourcecollection?
Because the files are (will be) a core type, like
fileset. The selectors are where the name collisions
are, so they are what should be packaged.
So now up to the alternatives using the names of
above example (Same
letter means equivalent in XML):
A1 (shameless copy from above)
project xmlns:rs=ant:resourceselectors
restrict
files name=${basedir}/foo/**/*.java /
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
A2:
project
restrict
files name=${basedir}/foo/**/*.java /
date when=after datetime=2005/04/15
pattern=/MM/dd
xmlns=ant:resourceselectors/
/restrict
/project
Equivalent to above. In each example the restrict
collection is also part of core.
B1 (difference files allowed / mandated to be in rs
namespace)
project xmlns:rs=ant:resourceselectors
restrict
rs:files name=${basedir}/foo/**/*.java /
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
This says to me that files would be a duplicate
typedef in both core and ant:resourceselectors
namespaces.
B2:
project
restrict
files name=${basedir}/foo/**/*.java
xmlns=ant:resourceselectors/
date when=after datetime=2005/04/15
pattern=/MM/dd
xmlns=ant:resourceselectors/
/restrict
/project
Equivalent to above.
C1 (difference now allos restric allowed / mandated
to be in rs
namespace, maybe a better name would in that case be
resourcecollections)
I see where this is going. First, I don't know that
there is a reason to scope all (new)
ResourceCollections out of core, as long as their
names don't conflict with existing components.
project xmlns:rs=ant:resourceselectors
rs:restrict
rs:files name=${basedir}/foo/**/*.java /
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/rs:restrict
/project
C2:
project
restrict xmlns=ant:resourceselectors
files name=${basedir}/foo/**/*.java /
date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
The two above are similar, again. I see why you would
want C2, but I am fairly unwilling to have files
live in other than core, so I'm not sure how you could
achieve it (comfortably). C2 syntax is why you would
want restrict to live with the selectors. That is at
least sensible, since as I said, there should be
little (no) use for resourceselectors outside the
context of restrict. But if the files can't live in
the rs namespace, I'm guessing you'd have:
C3:
project
restrict xmlns=ant:resourceselectors
files name=${basedir}/foo/**/*.java xmlns= /
date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
But I don't know if that's any better, as you then
have to resolve the core type instead of the
selectors. As for C1, assuming files will be in
core, the only difference becomes the namespace on the
restrict element, which is just a little more
typing, then.
D: (no namespace at all, with the danger and
problems of clashes,
extensively discuussed before.)
AFAIK this would, at this point, take some good
guessing code in the core (!) or DynamicElement
processing.
project
restrict
files name=${basedir}/foo/**/*.java /
date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
Are there any other variations possible, are variant
A-D feasible, and
what is best. (I'd currently say B or C)
I never claim to know what's best (or at least I don't
think I do).
-Matt
Martijn
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 aspect! :) For the record, I'd like some explicit way to say this is the and usable as Condition in some way. Guess that makes me pro-roles. Thanks for speaking on the record. :) So roles must either come from some form of antlib (vote ant:role !) or... what? -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 interest in this aspect! :) For the record, I'd like some explicit way to say this is the and usable as Condition in some way. Guess that makes me pro-roles. Thanks for speaking on the record. :) So roles must either come from some form of antlib (vote ant:role !) or... what? -Matt At first I thought I understood the discussion, I am trying to catch up, but now I completely lost it. I am trying to imagine what it would mean in a trivial build file. Is this te direction we are going with roles: project name=foo default=bar xmlns:co=ant:condition xmlns:set=ant:set resourcecollection id=blah set:and set:files dir=foo name=**/*.java/ set:date select=newer date=2005/04/15/ /set:and /resourcecollection /project Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 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 interest in this aspect! :) For the record, I'd like some explicit way to say this is the and usable as Condition in some way. Guess that makes me pro-roles. Thanks for speaking on the record. :) So roles must either come from some form of antlib (vote ant:role !) or... what? -Matt At first I thought I understood the discussion, I am trying to catch up, but now I completely lost it. I am trying to imagine what it would mean in a trivial build file. Is this te direction we are going with roles: project name=foo default=bar xmlns:co=ant:condition xmlns:set=ant:set resourcecollection id=blah set:and set:files dir=foo name=**/*.java/ set:date select=newer date=2005/04/15/ /set:and /resourcecollection /project Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 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 / Is this te direction we are going with roles: project name=foo default=bar xmlns:co=ant:condition xmlns:set=ant:set resourcecollection id=blah set:and set:files dir=foo name=**/*.java/ set:date select=newer date=2005/04/15/ /set:and /resourcecollection /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 select=newer date=2005/04/15/ /set:and /resourcecollection /project Whao, I'm getting this email exchange out-of-order! Weird. 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: resourcecollection id=blah and files dir=foo name=**/*.java/ date select=newer date=2005/04/15/ /and /resourcecollection The NS prefix would be necessary only in 3rd party custom task that only have a add(ResourceSelector) method and none of the specialized add methods. And even then, the 3rd party can still decide to add the specialized adds. So really the need to NS prefix roles appears in specific cases only: 1) In build files where XML namespaces are used and 'welcome'. 2) When there's a possible ambiguity with another role, for example in a class with both a add(Condition) and a add(FileSelector). I want to stress that we're not forcing everyone to use XML namespaces if we create these role AntLibs. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 in in core ant. right, what I have been working with is to remove the restriction against ant:.* namespaces (from AntlibDefinition). The classes are as you guessed in the core. All this really is, is creating a shorthand for our own antlibs, for scoping. By role is just a convenient way to separate the overlapping component names, which cause the immediate need for something along these lines. So the easy rule is, in RE terms, ant:(.*) - load resource org.apache.tools.ant.\1.xml as an antlib. So far this seems to me to be a good solution in terms of simplicity of implementation, and probably as good as possible in terms of ease of use while achieving full qualification for overlapping component names. -Matt Martijn Matt Benson wrote: 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 / Is this te direction we are going with roles: project name=foo default=bar xmlns:co=ant:condition xmlns:set=ant:set resourcecollection id=blah set:and set:files dir=foo name=**/*.java/ set:date select=newer date=2005/04/15/ /set:and /resourcecollection /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
--- 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 partly what I was trying to avoid. Part of the beauty, to me, of some of the latest introspection code is the ability to use add() methods. It makes me unhappy to have to specify element names in my configuration methods where there is no ambiguity. For example, if you have to add multiple elements of the same type to be used for different purposes, then okay, how else would you know which was which? But in the case of the restrict ResourceCollection (which is the context for ResourceSelectors), why should I have to support addAnd(), addOr(), addNot(), addNone(), addMajority, etc., etc., when I could code add(ResourceSelector) and be done with it? That takes us back to either forcing the explicit declaration at all times or trying to code something that uses context to decide which and the user means at runtime... fine, but also complicated and, as Peter pointed out, bound to encounter ambiguity errors. [trying to snip as much as possible lest these become unmanageable] -Matt __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 namespaces 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). Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 name=foo default=bar resourcecollection id=blah xmlns=ant:set and files dir=foo name=**/*.java/ date select=newer date=2005/04/15/ /and /resourcecollection /project or would this mean that the resoursecollection must be part of set itself? ===A=== project name=foo default=bar xmlns:co=ant:condition xmlns:set=ant:set resourcecollection id=blah set:and set:files dir=foo name=**/*.java/ set:date select=newer date=2005/04/15/ /set:and /resourcecollection /project ===B=== and xmlns=ant:conditions / and xmlns=ant:fileselectors / and xmlns=ant:resourceselectors / date xmlns=ant:resourceselectors / date xmlns=ant:resourcecomparators / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 just: snip without namespaces 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). 'guess so. I'm just worried than forcing to use XML namespaces even for a built-in Ant type would generate some push-back... And to avoid using XML NS, we'd have to come up with a mechanism that puts in scope only names for the roles accepted by the current class/instance, which will also get push back it looks like. Which is why I was proposing to have both add(Type) and specialized addXyz(Type) in Ant itself, while I could use just add(Type) and XML NS on my end ;-) I guess I was kind of ignoring the burden that puts on the implementer in Ant itself... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 date=2005/04/15/
/and
/resourcecollection
/project
or would this mean that the resoursecollection must
be part of set itself?
As I understand it, yes, because the xmlns was
declared on the resourcecollection element. I am
having a hard time following your exact example here
because I'm not sure how you are imagining the
ResourceCollections to look, while I know what they
look like. :)
I don't see that the ResourceCollections themselves
need a namespace. I have modified FileSet and similar
existing types to implement ResourceCollection.
Really the whole problem goes back to and/or/not, etc.
The Princess and the Pea. Anyway, I translate your
example above as:
project xmlns:rs=ant:resourceselectors
restrict!-- ResourceCollection type --
!-- FileCollection aka files has no basedir --
files name=${basedir}/foo/**/*.java /
!-- haven't written this selector yet; here
mimicked date FileSelector --
rs:date when=after datetime=2005/04/15
pattern=/MM/dd /
/restrict
/project
Does that make sense?
-Matt
__
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 to say this is the and usable as Condition in some way. Guess that makes me pro-roles. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 particular more plaggable things where boolean combinations will make sense. An or that can be used as condition or selector simply won't scale here. What is the alternative to placing the typedefs corresponding to the different versions of or into separate antlibs? roles? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 'global' Ant namespace may not be desirable. Yes, it solves the problem I was describing of having to manually typedef them, but it does not solve the name-collisions, and it introduces a bunch of names in the 'global' Ant namespace. That itself is a problem IMHO, but also these roles are not real types, but some implementation of an interface to use in the contact of another task/type making use of that interface. Granted, it's not a big deal, and it may be too late to change that, but if we had roledefs, we could only consult these name/classname mappings in the context of add(Type) methods, and ignore them when mapping name to classname at the top-level, or inside targets/TaskContainers. Don't worry, I'll stop rambling on this topic ;-) --DD * for lack of a specific term for these types implementing a particular interface, I'm calling them role. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
--- 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 aspect! :) -Matt * for lack of a specific term for these types implementing a particular interface, I'm calling them role. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 only other question would be, what was the intent of reserving the ant:* namespace protocol in the first place? -Matt --- Dominique Devienne [EMAIL PROTECTED] wrote: 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 role.xml for ant:role is elegant enough, no? 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 XML uri identifications for their antlibs. As I wrote earlier I also like the antlib:package convention. That's what I proposed we used in the first place. But others think it's too verbose. Surely you can see where they're coming from Peter ;-) For core ant types, I do not think it is a good idea - the namespace syntax will get in the way. Not really. Within Ant itself, you would never need to specify NS for mappers, selectors, etc... Because Ant types using them, instead of having one elegant add(FileSelector) method, they have tons of addthis(FileSelector). The need for namespaced types arises for 3rd party which do use the more elegant and extensible add(Type) methods! Use a namespace is tons more elegant than having to explicitly typedef each one you want to use like I had to do. If you refuse to add role-specific antlibs, then I'll have to define them myself in my custom AntLib, which clearly breaks encapsulation. For about a year now, new mappers, conditions, selectors and filters have been added by making them typedefs. If so, why did I need to typedef the date and size selectors when I'm using Ant 1.6.2? We should be able to make all the current conditions, selectors and filters be typedefs. But then you're polluting the global namespace IMHO. Types where originally for elements that could stand on their own at the top level, or directly inside targets. All these new types you are defining in the global namespace OTOH are meant to be used only in a very narrow context, within another (real) type or task. There are only a few name over-laps: and, or, not (selectors and conditions) Of course this will change with the selectors for the new resource collections, - but it may be possible to be clever. Precisely. We already have name conflicts, and it will only get worse. Namespaces are meant to resolve name conflicts. Lets try to not get too clever trying to implement another mechanism for this. It is quite easy to write a type that is a container for selectors and conditions (attached) that will act as a container for selectors or for conditions. It's my turn to not like this. As you say, it's clever, but now you're writing code to disambiguate name clashes, and the more name clashes appear, the more you write code... So to summarize, you Peter don't need to use any namespace when using Ant roles, because you're likely to use then in the context of Ant types/tasks, which have specialized add or create method for them. I, otoh, but using the new flexible add(Type) method, have forced to use namespaced Ant roles (mapper, selector), and that's perfectly alright with me. It is my opinion that Ant roles should *NOT* be added as types (if some were, then for BC reason they can stay that way, but only if they appeared in an official release), to avoid polluting the global namespace. As a consequence, like I said in the first place, we need to define Role-specific AntLibs (and thus namespaces). And I personally don't care if we use ant:role or antlib:package. What I wanted in the first place, and still want obviously, is for these to be defined, so I don't have to explicitly typedef myself pre-defined Ant role impls in my build script. If somehow we go your proposed put-them-all-as-types route, then I also won't have to typedef them explicitly, which I like, but we haven't resolved the name conflicts at all. And your proposed clever solution to this is not an acceptable solution to me (at this point). The ideal solution would be in fact to allow registering several classes/types under the same name, and the Ant runtime to pick the one type for which isA(Type) is true, fort the Type at hand, failing with an Ambiguous error if more that one such type exists. This way, you could
Re: ResourceCollections
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 XML uri identifications for their antlibs. I like using antlibs for thirdparty drop-in jars - antcontrib, groovy, jware_antx, site specific types and tasks. For core ant types, I do not think it is a good idea - the namespace syntax will get in the way. For about a year now, new mappers, conditions, selectors and filters have been added by making them typedefs. We should be able to make all the current conditions, selectors and filters be typedefs. There are only a few name over-laps: and, or, not (selectors and conditions) Of course this will change with the selectors for the new resource collectoioons, - but it may be possible to be clever. It is quite easy to write a type that is a container for selectors and conditions (attached) that will act as a container for selectors or for conditions. And condition And selector Available condition Checksum condition ClassConstants filter Contains condition ContainsRegex filter ContainsRegexp selector Contains selector Custom selector Date selector DeleteCharacters filter Depend selector Depth selector Different selector Equals condition EscapeUnicode filter ExpandProperties filter Filename selector FilesMatch condition FilterReader filter HeadFilter filter Http condition IgnoreBlank filter IsFalse condition IsReference condition IsSet condition IsTrue condition LineContains filter LineContainsRegExp filter Majority selector Modified selector None selector Not condition Not selector Or condition Or selector Os condition PrefixLines filter Present selector ReplaceRegex filter ReplaceString filter ReplaceTokens filter Selector selector Size selector Socket condition StripJavaComments filter StripLineBreaks filter StripLineComments filter TabsToSpaces filter TailFilter filter TokenFilter filter Trim filter TypeFound condition Type selector Uptodate condition Peter Matt Benson wrote: --- 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 hear Peter's thoughts on this since AFAICT he added the restriction against ant: uris in AntlibDefinition. With that restriction lifted, I have working a system whereby ant:foo loads resource org/apache/tools/ant/foo.xml as an Antlib. -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ContainerConditionOrSelector.java Description: java/ MultiTypeOr.java Description: java/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 role.xml for ant:role is elegant enough, no? 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 XML uri identifications for their antlibs. As I wrote earlier I also like the antlib:package convention. That's what I proposed we used in the first place. But others think it's too verbose. Surely you can see where they're coming from Peter ;-) For core ant types, I do not think it is a good idea - the namespace syntax will get in the way. Not really. Within Ant itself, you would never need to specify NS for mappers, selectors, etc... Because Ant types using them, instead of having one elegant add(FileSelector) method, they have tons of addthis(FileSelector). The need for namespaced types arises for 3rd party which do use the more elegant and extensible add(Type) methods! Use a namespace is tons more elegant than having to explicitly typedef each one you want to use like I had to do. If you refuse to add role-specific antlibs, then I'll have to define them myself in my custom AntLib, which clearly breaks encapsulation. For about a year now, new mappers, conditions, selectors and filters have been added by making them typedefs. If so, why did I need to typedef the date and size selectors when I'm using Ant 1.6.2? We should be able to make all the current conditions, selectors and filters be typedefs. But then you're polluting the global namespace IMHO. Types where originally for elements that could stand on their own at the top level, or directly inside targets. All these new types you are defining in the global namespace OTOH are meant to be used only in a very narrow context, within another (real) type or task. There are only a few name over-laps: and, or, not (selectors and conditions) Of course this will change with the selectors for the new resource collections, - but it may be possible to be clever. Precisely. We already have name conflicts, and it will only get worse. Namespaces are meant to resolve name conflicts. Lets try to not get too clever trying to implement another mechanism for this. It is quite easy to write a type that is a container for selectors and conditions (attached) that will act as a container for selectors or for conditions. It's my turn to not like this. As you say, it's clever, but now you're writing code to disambiguate name clashes, and the more name clashes appear, the more you write code... So to summarize, you Peter don't need to use any namespace when using Ant roles, because you're likely to use then in the context of Ant types/tasks, which have specialized add or create method for them. I, otoh, but using the new flexible add(Type) method, have forced to use namespaced Ant roles (mapper, selector), and that's perfectly alright with me. It is my opinion that Ant roles should *NOT* be added as types (if some were, then for BC reason they can stay that way, but only if they appeared in an official release), to avoid polluting the global namespace. As a consequence, like I said in the first place, we need to define Role-specific AntLibs (and thus namespaces). And I personally don't care if we use ant:role or antlib:package. What I wanted in the first place, and still want obviously, is for these to be defined, so I don't have to explicitly typedef myself pre-defined Ant role impls in my build script. If somehow we go your proposed put-them-all-as-types route, then I also won't have to typedef them explicitly, which I like, but we haven't resolved the name conflicts at all. And your proposed clever solution to this is not an acceptable solution to me (at this point). The ideal solution would be in fact to allow registering several classes/types under the same name, and the Ant runtime to pick the one type for which isA(Type) is true, fort the Type at hand, failing with an Ambiguous error if more that one such type exists. This way, you could register AndSelector and AndCondition with and, and use the 1st in the context of add(FileSelector), and the 2nd when with an add(Condition). This doesn't eliminate all conflicts, as for example your ContainerConditionOrSelect has both, it would be Ambiguous still. To me, using role-specific AntLibs is simply the only foul proof solution to name conflicts, that fits the existing behavior of Ant. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 hear Peter's thoughts on this since AFAICT he added the restriction against ant: uris in AntlibDefinition. With that restriction lifted, I have working a system whereby ant:foo loads resource org/apache/tools/ant/foo.xml as an Antlib. -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 xmlns:fs=antlib:org.apache.tools.ant.types.selectors xmlns:rs=antlib:org.apache.tools.ant.types.resources.selectors xmlns:ac=antlib:net.sf.antcontrib It's just the package names are quite long. Could we auto-alias the uris so that the user setup might be like below? project name=foo default=bar xmlns:fs=ant.fileselectors xmlns:rs=ant.resourceselectors I'd prefer at least antlib:org.apache.ant.mappers 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 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 about that. I just think--with my user hat on--the shorter it is, the easier a feature is to use (and therefore more likely it will be used). Perhaps the use of a specific protocol would appease some of the concerns floating around, particularly Jesse's? -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 whatever we want it to, no? -Matt __ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 natural interpretation of XMLNS semantics) than they already are... -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org if I had known it was harmless I would have killed it myself - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
I believe that using an undeclared prefix doesn't make the XML not well-formed it makes the XML invalid (i.e. a validating parser will barf) [1]. I think well formed simply means all the right syntax (element and attribute declarations are correct, and are all correctly 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: 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 to use? The user must explicitly set them up. Right. NS prefixes are irrelevant really. The user picks whatever she likes. And you can't automagically assign them. Using an undeclared NS prefix makes the XML document not well-formed, AFAIK. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 think we should. If so, does this tip the scale in favor of one or more new types subpackages? Even without them I think a new package would be better. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 possibly create a new ResourceSelector interface. I think we should. This will be interesting. Guess we will have to mimic FileSelectors. If so, does this tip the scale in favor of one or more new types subpackages? Even without them I think a new package would be better. Wow, I've never made a new CVS directory before... :) -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 selectors / conditions / filterreaders / mappers, etc... Not too ago I wrote a task taking selectors using add(FileSelector), and I had to manually typedef the selectors I wanted to use. I'm bringing this up because if we're fixing this issue for ResourceSelector, we should fix it for all our 'role's. And to me to way to fix these is indeed thru AntLibs, not DynElem. I guess we'd need these antlib URIs: antlib:org.apache.tools.ant.types.selectors antlib:org.apache.tools.ant.types.mappers etc... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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: 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 selectors / conditions / filterreaders / mappers, etc... Not too ago I wrote a task taking selectors using add(FileSelector), and I had to manually typedef the selectors I wanted to use. I'm bringing this up because if we're fixing this issue for ResourceSelector, we should fix it for all our 'role's. And to me to way to fix these is indeed thru AntLibs, not DynElem. I guess we'd need these antlib URIs: antlib:org.apache.tools.ant.types.selectors antlib:org.apache.tools.ant.types.mappers etc... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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. Peter -Matt --- Dominique Devienne [EMAIL PROTECTED] wrote: 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 selectors / conditions / filterreaders / mappers, etc... Not too ago I wrote a task taking selectors using add(FileSelector), and I had to manually typedef the selectors I wanted to use. I'm bringing this up because if we're fixing this issue for ResourceSelector, we should fix it for all our 'role's. And to me to way to fix these is indeed thru AntLibs, not DynElem. I guess we'd need these antlib URIs: antlib:org.apache.tools.ant.types.selectors antlib:org.apache.tools.ant.types.mappers etc... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 to use? The user must explicitly set them up. Right. NS prefixes are irrelevant really. The user picks whatever she likes. And you can't automagically assign them. Using an undeclared NS prefix makes the XML document not well-formed, AFAIK. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 explicitly set them up. First, why so? (-- an honest question.) Next, DD answered my first question. :) -Matt __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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]
RE: ResourceCollections
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 that's just me. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ResourceCollections
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 xmlns:rs=antlib:org.apache.tools.ant.types.resources.selectors xmlns:ac=antlib:net.sf.antcontrib It's just the package names are quite long. Could we auto-alias the uris so that the user setup might be like below? project name=foo default=bar xmlns:fs=ant.fileselectors xmlns:rs=ant.resourceselectors I'd prefer at least antlib:org.apache.ant.mappers antlib:org.apache.ant.selectors antlib:org.apache.ant.rescources.selectors And we have the choice of (1) actually putting the antlib.xml files in these directories, or (2) create yet another mechanism to map an AntLib URI to its actual XML descriptor. (we have one already with typedef I think, but I'd prefer to stay with an automagic URI approach). I could leave with (1). For (2), we could use META-INF/services/antlibs.properties, which would contain a mapping URI (w/o antlib: prefix for example) to Descriptor Resource: org.apache.ant.selectors org/apache/tools/ant/types/selectors/antlib.xml (1) is simpler to put in place. (2) is more flexible, but may be a little too much indirection. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 modified AbstractFileSet or the individual subclasses? Hopefully nobody has any major issues with this but I suppose if they do now is the time to get them out. Agreed. 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? 2) should there be a reference-only (resources) type that can generically use a ResourceCollection of an unknown type? What would it be used for? Finally, I would like to reach a consensus on the approach I should take to adding this; dump it all into CVS HEAD or create a sandbox area? I'd go for CVS HEAD unless anybody else objects. If the latter, I am still a little unclear on what tricks could be used to make it easier to use modified core code in a sandbox and would appreciate advice from other committers. I once did so for the input proposal and I think the original antlib code did as well. Basically you add your versions of all classes that you need to modifiy to the sandbox and when you compile you make sure your versions are before Ant's classes in the CLASSPATH. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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? Union is everything in two sets minus duplicates right? And you want a name for everything in two bags (not sets) with duplicates. the operation would be something like concatenate, but the name for what it would produce [shrug] Union is a noun (a union of something and something-else) and a verb (to union), not sure you'll be able to get a nice noun/verb combination for what you're suggesting.../me goes off to look in a thesaurus ok how about... blend, noun a blend, and verb to blend or for the more l33t fusion for the pr0n crowd intercourse/coupling [snigger] rather boring suggestions... association syndicate compound http://thesaurus.reference.com/search?q=union Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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, dirset, filelist and path to implement ResourceCollection. 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 children so I implemented the new interface in FileSet and DirSet directly. Plus this gives us encapsulated behavior (for the first time) whereby a fileset consists of files and a dirset consists of directories. 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? Referencing Kev's followup, I actually chose concat as the first real task to adapt (I've actually already done length and pathconvert because they are invaluable testing aids), and this collection is one I wanted concat to use internally, but I thought it might be usable elsewhere. With Kev having mentioned concatenate but not having a name for the noun created by the verb... concatenation? It really stood out since that's what I wanted it for in the first place. Thanks Kev! 2) should there be a reference-only (resources) type that can generically use a ResourceCollection of an unknown type? What would it be used for? The idea of this task creates a ResourceCollection with the specified reference. Okay, I invoke the task, now I have a reference to an RC, but I don't know its type, thus resources refid=foo / Finally, I would like to reach a consensus on the approach I should take to adding this; dump it all into CVS HEAD or create a sandbox area? I'd go for CVS HEAD unless anybody else objects. Easier for me. :) If the latter, I am still a little unclear on what tricks could be used to make it easier to use modified core code in a sandbox and would appreciate advice from other committers. I once did so for the input proposal and I think the original antlib code did as well. Basically you add your versions of all classes that you need to modifiy to the sandbox and when you compile you make sure your versions are before Ant's classes in the CLASSPATH. That doesn't sound too bad. :) Thanks, Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 children so I implemented the new interface in FileSet and DirSet directly. So ZipFileSet and ClassFileSet are not ResourceCollections right now? There certainly may be AFS children that are no good candidates for ResourceCollections so your choice seems logical, still people may expect to have a ResourceCollection when they extend AFS. Could be a matter of clear documentation. On Wed, 30 Mar 2005, Matt Benson [EMAIL PROTECTED] wrote: 2) should there be a reference-only (resources) type that can generically use a ResourceCollection of an unknown type? What would it be used for? The idea of this task creates a ResourceCollection with the specified reference. Okay, I invoke the task, now I have a reference to an RC, but I don't know its type, thus resources refid=foo / I see. So to answer your original question, yes, I think there should be one. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 we had little control over what happens to AFS children so I implemented the new interface in FileSet and DirSet directly. So ZipFileSet and ClassFileSet are not ResourceCollections right now? Most *FileSet types actually extend FileSet. I forgot to include ZipFileSet in the list of existing classes I have updated, but I have and it is working as expected. ClassFileSet IIRC should cleanly inherit FileSet's ResourceCollection behavior based on my inspection of the code. I will try to add that to my unit tests. There certainly may be AFS children that are no good candidates for ResourceCollections so your choice seems logical, still people may expect to have a ResourceCollection when they extend AFS. Could be a matter of clear documentation. Possibly, although since the AFS javadoc already would NOT include ResourceCollection as an implemented interface I'm not sure what else we could do besides explicitly add a reminder of that fact. :) On Wed, 30 Mar 2005, Matt Benson [EMAIL PROTECTED] wrote: 2) should there be a reference-only (resources) type that can generically use a ResourceCollection of an unknown type? What would it be used for? The idea of this task creates a ResourceCollection with the specified reference. Okay, I invoke the task, now I have a reference to an RC, but I don't know its type, thus resources refid=foo / I see. So to answer your original question, yes, I think there should be one. Thanks again, Matt (back to work!) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 example... :) ? -Matt __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
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 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 example... :) ? -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
--- 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 ability to interact with Resources is limited. We could possibly create a new ResourceSelector interface. If so I'd like to get that nailed down before I drop this stuff into HEAD, since selectors are integral to the restrict ResourceCollection type. Do we think a ResourceSelector interface is necessary? If so, does this tip the scale in favor of one or more new types subpackages? Thanks, Matt 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 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 example... :) ? -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ResourceCollections
Update: I have been rolling this stuff around and I
am nearly ready to have something to show. In
general, and as the subject line suggests, I have
decided that implementing generic file collections as
resource collections may not be too difficult, and
could really open a lot of doors. Some highlights of
what I'm working on, some of which are direct results
of suggestions from others (Stefan, Alexey, et al):
Resource.getInputStream() returns an InputStream
interface ResourceCollection {
// for ease of use:
Iterator iterator();
// makes RC more like a Collection:
int size();
// to allow quick distinction for file-centric
tasks:
boolean isFilesystemOnly();
}
Some of the ResourceCollections I have implemented:
files (dir-less fileset)
union, difference, intersect (set operations)
sort (sort Resources before returning)
restrict (with selectors)
I have also modified fileset, dirset, filelist and
path to implement ResourceCollection. Hopefully
nobody has any major issues with this but I suppose if
they do now is the time to get them out.
I intend to be ready to unveil this stuff next week,
with a few tasks modified to use ResourceCollections
as a demo. In the meantime, I would welcome
suggestions regarding the following:
1) a name for a ResourceCollection that acts like a
Union without removing duplicates.
2) should there be a reference-only (resources) type
that can generically use a ResourceCollection of an
unknown type?
Finally, I would like to reach a consensus on the
approach I should take to adding this; dump it all
into CVS HEAD or create a sandbox area? If the
latter, I am still a little unclear on what tricks
could be used to make it easier to use modified core
code in a sandbox and would appreciate advice from
other committers.
Thanks,
Matt
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
