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: Configure->Template->Build
Date Wed, 30 May 2001 13:49:56 GMT
Peter,

This is a very interest discussion, in my opinion, I think my views has
evolved, if not changed ;-), as we have gone along. So here is how I stand
at this time:

- I continue to believe that ANT usage patterns, in general, do not require
the usage of a configuration stage. I think we agree on that as you state
that only very sophisticated users will require such feature.

- I actually have entrench(sp?) more in thinking that ANT's core, does not
need to be rearchitected to support a configuration stage. It may need to be
redesign to support other stuff, but not a configuration stage. This is a
change from before.

- The reason for the above, is that I now think your requirements can be
fulfilled by an optional task which can execute whatever software, this
sophisticated group wants, to generate their configured build files. I have
never being oppose to that since such task (or tasks) would be just a
regular task with no special behaviour with respect to ANT core. The
language, syntax and semantics for such a task are irrelevant from ANT's
point of view the same way ANTs do not care about what the <javacc> task
does or generates.

- This probably means I am advocating the usage of different pattern in
build files for people with your type of needs.

- My views on templates (XSLT and such) I think we can live aside for the
moment since you are right they are part of a different discussion.

Now with this as a basis, let me refer to just a few of the points below:

> From: Peter Donald [mailto:donaldp@apache.org]
>
> At 01:02 AM 5/30/01 +0100, Jose Alberto Fernandez wrote:
>
> >Now tell me, how do I know if my templates or autoConfig are
> >generating the right ANT buildfile? Since everyting is
> happening internally
> >and on the fly, how do I know? We will have to provide tools for that
> >(preprocess only), etc, etc. Sounds like a need for cpp.
>
> No idea what you are yammering about here. You will naturally have the
> ability to run single stages at a a time. I assume that was a given.
>

By having a task generate (on disk) the buildfile, I think this puts my
point to rest. People can look at it, tested separately, or whatever. No
need for special options or swithches in ANT itself.

>
> >Well, how do you feel about ANT2s proposed <projectref>. I
> guess your 17
> >files could just have something like:
> >
> ><project name="mymodule" default="mydflt">
> >	<property name="thismodule" value="......."/>
> >	<projectref name="environement" file=".../environemnt.xml" >
> >	  <param name="sourcedir" value="." />
> >	  <param name="destdir" value="${thismodule}/lib" />
> >	</projectref>
> >
> >	<!-- and then just add the user targets for easy to use -->
> >
> >	<target name="mydflt" depends="environment->default" />
> >	<target name="compile" depends="environment->compile" />
> >
> ></project>
> >
> >Something like this, looks that can solve quite cleanly the
> issue of the 17
> >identical buildfiles.
>
> If they were identical yes but they keys is *mostly*
> identical. It is the
> slight variations between them that becomes painful (besides
> which this
> layout assumes java is immature - hopefully that will soon
> not be the case).
>
> Because they have slight variations you end up with hariy
> build files or
> else use per task if attributes or implement an if task (like what was
> described recetly).
>

<projectref> is just like instantiating a library of targets. You can still
put on each one of the 17 buildfiles additional targets containing the
things that are different (those small things) and make the refered project
have dependencies on those targets. Without that I  think the whole idea of
<projectref> would be useless. So I expect the ability to do such things as
part of the final design for <projectref> in ANT2.

> >> I am sure if you ask the build engineers who have to maintain
> >> medium to
> >> large sized products they will complain most loudly about the
> >> loops they
> >> have to jump through ;)
> >>
> >
> >And I think we are trying to respond in ANT2, the point is
> how the response
> >looks like.
>
> right - and as far as I can tell you seem to be denying the need for
> scripting, or encouraging expanding ants core to add it. I propose the
> standard practice of breaking down complex problems into
> multiple smaller
> problems.
>

I think we are both advocating the same, is just a question of the thickness
of the slice. ;-)

> You want an example - take your own example from above as one then ;)
> Assume each project has slight variations and just try to
> write a clean
> build file for it all ;)
>

Of course the problem is what do we mean by "variations". Are we talking
about properties being set differently? Are we talking about them executing
different sets of tasks altoguether? Is it some other bizzare combination? I
am asking for a real world example so that we can stop the what-if game,
which is a never ending game.

> This does mean dealing with different locations of tools/jars. ie
> /usr/local/java/* for linux systems, /opt/java/* for some
> other unixes,
> /opt/* for other unixes and presumably a java standard for
> other platforms
> will eventually evolve. With tools like jjan/cjan on the
> horizon this is
> becoming more of an issue.
>

I still do not know how your scripting will deal with this issues. It looks
like you would need to provide a whole accompaning library of function that
provide OS independent means of finding this things out, just like the m4
libraries used by autoconfig. But hey if it is in an optional task, it is up
to the maintainers of it. ;-)

> >Can we achieve the same without it? I will say yes, because
> we can do the
> >same by just writing a <task>:
> >
> >	<target name="prepare" >
> >	  <configure template="myConfigurationLanguageScript.cfg"
> >	 		buildfile="TheconfiguredBuildFile.xml" >
> >		<param ..../>
> >		<param ..../>
> >	  </configure>
> >	</target>
> >
> >	<target name="compile" depends="prepare" >
> >	  <ant target="compile" file="TheConfiguredBuildFile.xml" />
> >	</target>
> >
> >and so on. So as long as someone provides a <task> defining
> the autoconfig
> >tool and languaje, you can use it in ant as is. So that
> people writing in
> >this large build environments can do their own thing is so they want.
>
> A while ago weren't you arguing against this? Yes most of the
> stuff could
> be done with tasks in one way or another but the question is
> whether it
> should be.
>

The difference here is this does not require any modification or intrusion
into CORE. This is a regular task that has its own inputs and outputs. I do
not think I have being against that, however as I ssaid at the begining I
have evolved.

Jose Alberto



Mime
View raw message