ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [Vote] ProjectBuilder abstraction
Date Mon, 14 May 2001 13:08:47 GMT
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?

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?

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.

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.


Jose Alberto

> From: Siberski, Wolf []
> Peter Donald wrote:
> > At 07:34  13/5/01 +1000, Conor MacNeill wrote:
> > >OK,
> > >
> > >-1.
> > >
> > >I don't see the need to abstract this into an interface.
> >
> > How do you propose to do xslt/css/velocity/other sources to build
> projects?
> > DO you think that we should allow people to do this sort of
> thing? If not
> > why not? If so - how do you propose we do it in a clean manner?
> >
> > > The proposal in myrmidon has a Project builder interface
> with one method
> > >
> > >build(File)
> > >
> > >I'm not sure builds will be coming from a File. They may
> be from a URL, a
> > >GUIProjectModel, JackSprattProjectRepository, who knows?
> Why not just say
> > >the execution engine operates on a Project instance and
> how that project
> > >instance is created is outside the scope of the execution
> engine. It is
> the
> > >responsibility of the front-end.
> >
> > right - which is exactly what I am proposing - or at least
> thats what I
> > though ??? I am not proposing we use the interface in
> myrmidon but that we
> > do use the concept. (I think we could build in same way that JNDI
> > InitialContextFactorys work).
> >
> Is voting about such a design issue really the right approach?
> My suggestion would be to just wait and see where we need this
> plugin capability. For example, as Antidote will allow
> users not only to load, but also to change and save projects,
> a general ProjectBuilder interface probably won't be the right
> solution for this context. For a command line interface
> I can imagine it will make life easier.
> But as it isn't a lot of work to refactor this; therefore we can
> start simple and introduce it later when the need arises.
> [from another mail:]
> > Just reminding peeps that there is a few votes that didn't
> get discussed
> > ... I would like it if everyone gave their opinions on
> these before I
> added
> > new topics ;)
> >
> I think for most committers (and non-committers) it is much
> easier to argue about an implemented proposal than on a design
> idea. That may be the reason that some of Your other mails
> didn't get a lot of replies.
> Wolf

View raw message