At 02:08 14/5/01 +0100, Jose Alberto Fernandez wrote: >There is one aspect of project building that really requires abstraction or >at least some consideration. How are the <ant*> family of tasks suppose to >get the project object they need to pass to the engine?
right. >The implementation I remembered (don't think any major changes have >occurred) assumed that the current projact as well as all subprojects where >in files in the file system and they all go and build it from there. In >particular in the case of <antcall> this means all tools need to maintaing a >saved file version of the project so that it can be reloaded. How are >xslt/css/etc. suppose to work on these context? the problem would of course be multiplied there. With N different pluggable project representations you would require N different pluggable <ant ../> tasks. Antcall is different because it will act only on in-memory version and thus never needs to build a project. >Moreover, if antidote where to be obliged to write to a file before >execution in order to support <antcall>, then the whole argument of building >the project object directly from antidote's internal representation looses >value. It would be much simpler for all front-ends to simple do the >equivalent of an <ant> task call. That would provide a consistent >programatic API for building projects. One that even the current Main should >be using. API and implementation are different things. I want a "consistent programatic API for building projects" which all frontents and <ant .../> use. However how it is implemented - ie whether it picks it up as XML file on filesystem, out of a DB, from a URL, out of a xslt+xml transform, out of a velocity + XML transform, out of a CSS + XML transform etc ... is largely irrelevent in my opinion - at least at this stage. When ant2 matures one of them will hopefully be dominant ... until then ;) >So, I do not know whether we need a project build abstraction or not. Unless >it takes into account thise kinds of issues, it seems that having the XML >file as the entry point for the engine is the way to go. Otherwise we will >need to rethink much much more than just ProjectBuilder. XML as an entry point is not really an option - in many cases we are not guarenteed a writable filesystem or having builders that produce XML. It could also sucky to have multiple stage building with sideeffects - it would mean that developers would not be able to share one filesystem hierarchy safely etc. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
