Very good observation abount Ant asking the IDE for FileSets. Basically, I should focus on creating a FileSet derivitive that is produced by the IDE. I'll have to ponder that one for a while.
Thanks for the feedback. jim ----- Original Message ----- From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 15, 2000 3:55 PM Subject: RE: Ant 2.0 Consideration > > From: James Cook [mailto:[EMAIL PROTECTED] > > > > > -----Original Message----- > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > > > > 3. The reason I think File discovery is so important comes back to > > > > the fact that these IDEs utilitize a package/file structure. In > > > > order for Ant to be fully integrated, I need to be able > > to ask each > > > > Task if a particular file is affected by the Task. > > > > > > How would this apply to echo/sql/property ...? > > > > Tasks that do not deal with Filesets would return false when > > asked about a > > particular file. > > > > > > For example, given a particular File object, I should be > > able to ask > > > > a Copy Task if it will include this task. Since the Copy > > Task does > > > > not extend MatchingTask, this becomes impossible. > > > > > > Why? Or better, why would this be possible if Copy extended > > > MatchingTask? > > > > Because MatchingTask (or FileSet) can (or could) answer the > > question, "Is > > this file included/excluded from your scope?" > > > > How do you know such task is required for the build? Are you planning to do > the dependency analysis before running ANT to know which targets > will be actually used? How are you planning to dealt with > dependencies that only appear as a result of the action of other tasks? > Foe example: <update> which may set a property if the file needs updating > and that may trigger certain <target> to get called or not. > > How about <ant> or <antcall>? > > > > Could you please expand a little on how an IDE would benefit if it > > > knew whether a given task in a given buildfile would > > actually affect a > > > given file? > > > > Ant works on a concept of projects/targets/tasks, while a > > Java IDE manages > > files based on projects/packages/files. While it is possible > > to stick Ant > > directly into an IDE and have the person work against the Ant > > build script > > directly, this breaks the IDE's paradigm. It would be akin to sticking > > Antidote directly in the IDE. It would work, but it would > > never be truly > > integrated. > > > > I envision a system where the developer can assign a task at > > a high level, > > perhaps the project or package level. Then the developer can > > select which > > files will participate in the task. Maybe when a file is > > selected, it is > > shown all of the tasks that have been declared "above" it. > > The developer > > could then check off which tasks that file will or won't > > participate in. The > > methods that I mentioned previously would help faciliate > > keeping track of > > which tasks a particular file is participating in. > > > > Well this certaintly looks like an entire different insect, > based on ANT (I grant you that) :-) Perhaps, termite is a good name. > > But seriously, IMHO for ANT to be ANT, whatever we define as a build > using some build building tools (e.g., IDE) needs to be representable > as a proper ANT file, that can be exported and used by others not > using such an IDE. Otherwise, the whole point of portable builds is lost. > > Now as for your problem, I think that you are looking at the problem > in the wrong direction. Intead of the IDE asking ANT what it may be > interested in, I could see ANT asking the IDE about files it needs to know > during execution. So rather than MatchingTask or FileSet going to the > disk, or using java.io.File directly, we should have a registration > mechanism > that allows the IDE to intercept this questions and respond appropriately. > > This can be done by registering a factory that is used by the ProjectHelper > to create these new File objects and those objects will do the right thing > with respect to IDEs or something else. > > Maybe something to consider, > > Jose Alberto > > > jim > > >
