ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [Vote] ProjectBuilder abstraction
Date Wed, 16 May 2001 14:33:44 GMT
It took me a while to answer :-)

> From: Peter Donald [mailto:donaldp@apache.org]
>
> 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.
>

I think this is wrong. Are you saying that everytime a new model is added we
need to have a new version or flavor of these tasks? That makes extremely
little sense to me.
Remember, <ant*> are tasks just like any other. What if tomorrow someone
adds some new taks with simillar requirements (i.e., being able to find the
buildfile, or content)? Are we going to ask the developer to support N
flavors of it?

> >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 ;)
>

Well, certaintly the arguments for <ant> are not some meaningless abstract
name denoting some XML source of some type somewhere in hyperspace. The
parameter is a fileName, relative to the build directory (which is a
directory name). You may want to provide some  extended pluggable file
system abstraction, but that is a different topic altoguether. I do not see
my Java sources comming out of a DB any time soon, why would be the
buildfiles any different. (Of course as with the CVS tasks you acn always
extract them from the DB and then do whatever).

> >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.
>

Well, you may need to tell me about those cases. What is the meaning of a
build tool if we cannot save what we have build. How can we do dependency
analysis based on time stamps if we can never modify the times of anything?

What kind of sharing do you want them to have? Are you suggesting that
multiple developers build over the same file space? I doubt the compilers
will like or appreciate the result of two people building at the same time
the same file.

And remember, tool generated buildfiles do not need to be located on the
same place as the sources, you can locate them somewhere else and just set
the basedir appropriately.

And finally, everything that the ANT engine is able to understand must have
to be expressable using an ANT file. I am 100% against having some other
dialect or representation not expressable as one or more ANT files. We need
a common language or we will finish like NMake and make gmake and qmake and
tmake and zmake and wmake etc, etc.

Cheers,

Jose Alberto



Mime
View raw message