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: OS Independent file strings in resourcecollections
On 2009-09-17, Raja Nagendra Kumar 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 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
OS Independent file strings in resourcecollections
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.. Regards, Nagendra www.tejasoft.com -- View this message in context: http://www.nabble.com/OS-Independent-file-strings-in-resourcecollections-tp25486284p25486284.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
ResourceCollections support nested FilterChain's
While reading the thread "Expanding ALL properties manually" [1] on the user list I got an idea: could a ResourceCollection support filterchains for its own? In consequence all tasks "just" supporting RCs would also support filterchains as well. The main idea is that RC iterates over the nested resources. Filterchains only are important if you access the content - via input/output streams. So the actual use wouldnt make any difference. When you add a filterchain the 'resources' would wrap the nested resources, so that the streams are passed through the filterchain. 'resources' would be modified in the base class BaseResourceCollectionContainer. The 'chaining' could be done via ResourceUtils.copyResource(). Consequence: the task couldnt do an 'instanceof' comparison (e.g. for type casting) because it only holds the wrapper. Mmh - not nice... What do you think? Jan [1] http://marc.theaimsgroup.com/?l=ant-user&m=113449879022522&w=2 - 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 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]
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 . 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 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] >
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 . 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 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: 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]
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 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: 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: 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 or ? Or would we want users to stick to fro this? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
--- 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: 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 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
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]
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: 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]
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
> 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 or a but a 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 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
--- 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: > > > 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
--- 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
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 )
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;
This will give an error as it will not know which 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;
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 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 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
--- 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) > > > > > pattern="/MM/dd" /> > > > > A2: > > > > > pattern="/MM/dd" > xmlns="ant:resourceselectors"/> > > > Equivalent to above. In each example the collection is also part of core. > B1 (difference files allowed / mandated to be in rs > namespace) > > > > > pattern="/MM/dd" /> > > > This says to me that files would be a duplicate typedef in both core and ant:resourceselectors namespaces. > B2: > > > > xmlns="ant:resourceselectors"/> > pattern="/MM/dd" > xmlns="ant:resourceselectors"/> > > 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. > > > > > pattern="/MM/dd" /> > > > > C2: > > > > > pattern="/MM/dd" /> > > > The two above are similar, again. I see why you would want C2, but I am fairly unwilling to have 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 . But if the files can't live in the rs namespace, I'm guessing you'd have: C3: 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 will be in core, the only difference becomes the namespace on the 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. > > > > pattern="/MM/dd" /> > > > > 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
Matt Benson wrote: --- Martijn Kruithof <[EMAIL PROTECTED]> wrote: [SNIP] Apart from the variands A and B further below, would the following also work? or would this mean that the resoursecollection must be part of set itself? As I understand it, yes, because the 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: 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) A2: B1 (difference files allowed / mandated to be in rs namespace) B2: C1 (difference now allos restric allowed / mandated to be in rs namespace, maybe a better name would in that case be resourcecollections) C2: D: (no namespace at all, with the danger and problems of clashes, extensively discuussed before.) 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: [SNIP] > > Apart from the variands A and B further below, would > the following also > work? > > > > > > > > > > > > > or would this mean that the resoursecollection must > be part of set itself? As I understand it, yes, because the 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: 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
> From: Martijn Kruithof [mailto:[EMAIL PROTECTED] > > > >Martijn, Matt, the example above would be necessary if and only > >if only had a add(ResourceSelector). In > >practice, we'll likely have specialized addAnd(ResourceSelector) and co > >so that if can be written just: > > > > > > > > But wouldn't that defeat the whole purpose of the 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
But wouldn't that defeat the whole purpose of the I thought the whole point was avoiding having addConcrete in favour of having add(Role). What basically is that what Matt just stated. Apart from the variands A and B further below, would the following also work? or would this mean that the resoursecollection must be part of set itself? ===A=== ===B=== - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ResourceCollections
Dominique Devienne wrote: Martijn, Matt, the example above would be necessary if and only if only had a add(ResourceSelector). In practice, we'll likely have specialized addAnd(ResourceSelector) and co so that if can be written just: > But wouldn't that defeat the whole purpose of the I 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
--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > Martijn, Matt, the example above would be necessary > if and only > if only had a > add(ResourceSelector). In > practice, we'll likely have specialized > addAnd(ResourceSelector) and co > so that if can be written just: oh, that's partly what I 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 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
--- 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.: > > > > > > > > > > > > > > > > > >>Is this te direction we are going with "roles": > >> > >> >> xmlns:co="ant:condition" > >>xmlns:set="ant:set"> > >> > >> > >> > >> > >> date="2005/04/15"/> > >> > >> > >> > >> > >> > >> > > > - > 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
> From: Martijn Kruithof [mailto:[EMAIL PROTECTED] > Is this te direction we are going with "roles": > > xmlns:co="ant:condition" > xmlns:set="ant:resourceselector"> > > > > > > > > > Whao, I'm getting this email exchange out-of-order! Weird. Martijn, Matt, the example above would be necessary if and only if only had a add(ResourceSelector). In practice, we'll likely have specialized addAnd(ResourceSelector) and co so that if can be written just: > > > > > > 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
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.: Is this te direction we are going with "roles": - 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.: -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 > >>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": > > xmlns:co="ant:condition" > xmlns:set="ant:set"> > > > > > > > > > > > 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
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 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": Martijn - 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 > 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
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 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
--- 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
> 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
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 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 into separate antlibs? roles? Stefan - 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: is elegant enough, no? > > > This does not use the method "antlib: name>" that antlibs > > are meant to be identified by. If "ant: 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: > 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 add(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: or > antlib:. > 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
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: is elegant enough, no? > This does not use the method "antlib:" that antlibs > are meant to be identified by. If "ant:" is > used to identify ant's antlibs', then there is ample reason for > thirdparty antlibs authors to ask for "easy to use" XML uri > identifications for their antlibs. As I wrote earlier I also like the antlib: 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 add(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: or antlib:. 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 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
I meant to reply earlier... I do not like "ant:mappers", etc This does not use the method "antlib:" that antlibs are meant to be identified by. If "ant:" is used to identify ant's antlibs', then there is ample reason for thirdparty antlibs authors to ask for "easy to use" XML uri identifications 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
--- 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
--- 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
--- 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
On Fri, 1 Apr 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: >> > What's difficult already? >> > It's like a Java import basically. >> > You declare what you're using. What's wrong with >> > that? --DD >> >> hmm... using the project attributes: >> >> > xmlns:fs="antlib:org.apache.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? >> >> > 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
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
Matt Benson wrote: Could we auto-alias the uris so that the user setup might be like ? -0.5 for anything which makes the XMLNS rules for Ant scripts more complicated (and divergent from the natural interpretation of XMLNS semantics) than they already are... -J. -- [EMAIL PROTECTED] x22801 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
--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > It's just the package names are quite long. Could > we > > auto-alias the uris so that the user setup might > be > > like below? > > > > > xmlns:fs="ant.fileselectors" > > xmlns:rs="ant.resourceselectors"> > > I'd prefer 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 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. If we choose (1), maybe we should create a new directory src/resources (Java, not Ant) for those non-Java config files that are supposed to live in ant.jar . This way we don't pollute the codebase in such a confusing manner. -Matt > > --DD > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest - 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: > > 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? > > 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 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
--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > assuming my concern that users wouldn't bother > using > > something that requires extra setup (per > project!), > > what other things could we do to increase > > ease-of-setup for antlibs? > > What's difficult already? > It's like a Java import basically. > You declare what you're using. What's wrong with > that? --DD hmm... using the project attributes: It's just the package names are quite long. Could we auto-alias the uris so that the user setup might be like ? same thing for using the other URI approaches... -Matt > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - 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
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
> First, why so? (<-- an honest question.) I tink I answered that one ahead of time ;-) > assuming my concern that users wouldn't bother using > something that requires extra setup (per project!), > what other things could we do to increase > ease-of-setup for antlibs? What's difficult already? It's like a Java import basically. You declare what you're using. What's wrong with that? --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
--- Peter Reilly <[EMAIL PROTECTED]> wrote: > Matt Benson wrote: > > >I also like the idea of using antlibs, but do we > then > >indicate that the user must explicitly set up the > >namespace prefixes or do we assign them > automagically? > > If the former, will anybody use them? If the > latter, > >what prefixes to use? > > > > > The user must explicitly set them up. > First, why so? (<-- an honest question.) Next, assuming my concern that users wouldn't bother using something that requires extra setup (per project!), what other things could we do to increase ease-of-setup for antlibs? -Matt > 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] > > __ 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: 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 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
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
> 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
If we are going to add a ResourceSelector, 1) the interface and implementations will primarily be relevant only to the "restrict" ResourceCollection. 2) things like And, Or, Not will be needed. 3) I'd rather not hard-code selector types. what other options exist? A built-in Antlib for namespacing the ResourceSelector types? A DynamicElement ResourceSelectorContainer? Thanks for any thoughts, Matt --- Matt Benson <[EMAIL PROTECTED]> wrote: > --- 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] > > __ 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
--- 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
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
--- 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 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]
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
--- 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
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
--- 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 > > 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
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 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 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 > > > 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
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
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]
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]
