Re: AW: Fileset and Custom Fileset in Ant 1.7
I believe I do, but if you can prove me wrong, then I'd be delighted to go around custom files sets. I am trying to provide file selectors in svn-ant, which is an ant library that support subversion. Subversion keeps track of files that are deleted and missing. If I want to write an ant task where all missing files are restored, then the classic file set is not sufficient. I created a new file set that queries the subversion client for all files, regardless of whether they are present on the file system or not. Since there are already existing ant tasks based on file sets to perform restoring operations, using the custom file set allows re-using the same code but with the ability to specify files that are, as far as the file system is concerned, non-existent. I can not see a way around it, since the classic file set can not predict files that are not on the file system. I know that creating a custom file set that returns paths of non-existing files is a departure from what is generally accepted of a file set, however mis-use of the custom file set will result in a task failure. For example: will fail. But, this weird behaviour is just a nuisance compared to the great benefits of something like this: Tell me what you think. I am in the development stage for this feature, and I have yet to submit the patch to svn-ant. This is a good time to influence the design. JP [EMAIL PROTECTED] wrote: And you should ensure that you _really_ need a fileset. 2 years ago (or so) I wanted to write a new fileset and end on a selector. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
It certainly is an interesting idea. I think the main challenge in this endeavour is to figure out what is the common denominator between all the SCM systems and then assess if it is encompassing enough to warrant abstracting it out. I wish this effort will not be limited to tasks, but will also include file sets and file selectors, since I feel it is necessary in managing a source repository properly. For example, in svn-ant (the subversion ant lib), I implemented file selectors to discriminate files based on status such as: added, replaced, unversioned, ignored, etc. That, in itself, was not enough. I needed to also provide a file set, since subversion has a concept of "missing" and "deleted" files. Obviously, a classic file set can not predict files that are not present on the file system, so a custom file set had to be designed. While tasks might have to be limited to common functionality (why develop a script based on a task that keeps failing on a majority of SCM systems), file selectors can combine the richness of all SCM systems. If a SCM system does not support a concept, then the related file selector would never tag any file. Scripts based on those file selectors would be valid, regardless of the underlying SCM system. JP Kev Jackson wrote: Hi I've been playing with darcs recently and I've almost finished an antlib for it (though I keep being distracted, first Haskell, now Lisp). 'darcs get' is roughly similar to 'cvs checkout' or 'svn co' I was wondering if it would make sense to refactor the SCM tasks into an interface (scm) and have a set of antlibs that implement that interface in a vendor specific manner. Such that is handled appropriately by each SCM system in it's own way, whilst at the same time exposing a common API to simplify this (very common) set of tasks. I'm thinking it'd be similar to how the task simplifies compiling regardless of which compiler you want to use. Is this: a - a stupid idea and a colossal waste of time b - a not too stupid idea, but still a colossal waste of time c - not stupid, a colossal waste of time, but it'd be worth doing anyway d - none of the above Kev - 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]
Fileset and Custom Fileset in Ant 1.7
I am interested in developing a custom fileset. After reading the mail archives, it appears that much work is currently happening to allow custom file sets in 1.7. Looking at the trunk implementation, I see that this change will affect all fileset-based tasks. Can anyone comment on the impact of those changes as to the compatibility of fileset-based tasks between 1.6 and 1.7? After reviewing the code (without testing my assumptions), it looks like: 1. Fileset-based tasks written to take advantage of ResourceCollection instead of FileSet will not run in Ant prior to 1.7 2. Fileset-based tasks written prior to 1.7 (dependent on FileSet) will not be able to support custom file sets, even if running in 1.7 Are my assumptions right? JP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
