On Wed, 3 Nov 2004 19:59:14 +0000, Steve Loughran <[EMAIL PROTECTED]> wrote: > script breaking is always an issue; ant core cannot not break stuff, > especially as we are so very ignorant of so many uses. Note that you > can declare tasks and types into a namespace, though I usually just > declare stuff with a hyphen 'sf-deploy', 'axis-wsdl2java' to namespace > stuff. No clashes yet. > > If not <dependencies>, then <libraries>, perhaps. Easier to spell.
Fine. Then I can still agitate for my approach via other means :) > I did add the ability to set the classpath, so it is more declarative. > I left off fileset as it is a more troublesome beast. The uses which I have found for this task include the ability to copy the selected dependencies into a single directory (while optionally removing the version suffixes). This is very useful for binary releases, which tend to ship their dependencies. You sort of need the fileset for that. Otherwise, it is simpler to run from the cached files. > I chose not to explicitly use a central repository, because of the > extra complexity of cross-project implications, such as race > conditions and versions. I like my isolation. On a big project you can > and should declare a central home for stuff. I agree that it is a problem, and that declaring a central home is a good idea. And having the ability to redefine the layout of the repository is very good - I happen to have a case where that is important for internal dependencies. I would like to understand better how your approach helps with cross-project issues. > Now, you can add support for the repository stuff in your task, just > add the relevant setter. Once I add security it will be useful. Yup. > I had a look at the depot stuff in the apache incubator incidentally; > if you haven't you should. Its a very ambitious project as it actually > wanted to solve the versioning problem properly. I did look at it after submitting my task to that group. Their approach seemed to be essentially the same as mine, although slightly less well developed. Of course, I might have missed something - the project was never very active in the time I was subscribed to the list. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
