ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Configure->Template->Build
Date Wed, 06 Jun 2001 10:39:22 GMT
At 09:59 AM 6/6/01 +0200, Stefan Bodewig wrote:
>>>The problem I have with this approach is, that whenever I ask for
>>>real world examples of large scale projects I don't get any
>>>responses.  Or if I get responses and manage to solve the problems
>>>without templates (the static kind) they get declared bad examples
>>>afterwards.

BTW it wasn't me who coined the term "dynamic" templates.

>> Could you give me a reference - I wasn't aware any examples have
>> been given.
>
>This is part one of my response ;-)
>
>I have taken your 17 projects with slightly different compile targets
>as an example - no other has been provided yet.

Okay the problem is that certain features occur in certain builds but not
in others. If they are included then they are present in very specific and
well known places in build file. The example given was rmic but in reality
it could be virtually anything. Lets call this feature F. Each F occurs in
a target T.

Your solution to this was to split T into T1, T2 and T3. You suggested
keeping T1 and T3 in the "template" project file (P2). T2 would be
replicated in each of these build files (P1) that need it.

You never specified how the dependency would be managed but there was two
methods that your explanation would suggest;
(A). the template file T1 is dependent on T2. This means every buildfile
has to have a T2 and it must depend on T3. For projects without F then T2
will be empty but still must be present.
(B). T1 does not have any dependencies. You create a dummy target in in P1
that depends on T1, T2 if necessary and T3. This would rely on serial
processing of dependencies.

Now lets assume that each project if it was not using templating would have
10 targets. Lets assume that we have 20 projects. In these 20 projects
there are variations, some use rmic, some obfusicate, some build ejb jars,
some build wars etc. Lets set the variation count at 10 (which I think is
an underestimating variation).

So moving to your templating solution we would have a template file (P2)
with 20 targets (10 + 10 x (3 - 1 - 1) :: base + variations x increase in
target count).

You also have 20 project files (P1). These 20 P1 would have at least 10
targets (1 per variation possibly 2 if use strategy B from above). To build
these 20 P1 you would need to have a fairly extensive knowledge of P2
because you have to link all dependencies together. There is not a chance
in hell that you could claim that this has simplified process for writing
P1 files as you still have to know all the uglies of P2 extensively.

So your solution would have actually increased the number of targets by at
least 10% (220+ vs 200). The average number of targets per project has
increased from 10 to 30. The thread of execution swaps between P1 and P2,
making it difficult to debug and understand. The developers of P1 don't get
any decrease in complexity because they still need to understand P2.

So overall if templating was implemented the way you describe then it would
be a bane not a boon. The level of difficuly has increased by at least a
factor of three (though I would say more due to interlaced dependencies).
It has not decreased maintanence cost (actually increased it).

The other solution you offered was that we mandate that any tasks that take
input will not operate if their input set is null or empty. This may work
for a subset of cases but there will still be tasks that don't take input
that are an F. Besides this means far too much maintanence work for us to
keep all tasks operating according to our 'golden' rules.

Another solution requested (and often denied) was some form of selection
task (if being most likely candidate). Thus we could wrap each F in an 'if'
task and achieve the same. This is faaaaaaaar more maintainable. It also
allows for nested Fs (something that your model does not). However this is
something that has been -1'ed so many times it is not worth attempting to
get in ;)

FWIW this is the same obstacle that many web "server page"/"scripting
page"/"templating" frameworks face. One of the biggest complaints against
JSP/xsp/other is that it allows logic in page which should only be in in
components. One reason why WebMacro/Velocity is superior is because it
mandates this. While XSP/JSP can be almost as nice by only using taglibs,
this isn't forced by language so it relies on good sense and knowledge of
developer (a bad idea IMO).

The other solution offered is what I have been pushing. Remembering that
the situations that mandate templates will generally also mandate the
presence of configuration/build engineers. While ant in it's current form
is suitable for small and simple projects, it doesn't scale well to these
sorts of situations. 

Ideally when you have access to build engineer, you may aswell make use of
them. In the ideal scenario the "build file" will be a set of properties
that are processed by "rules"/"templates" to generate instance. I have
shown you my GNUMake file that facilitates this and you would have to agree
that it is simpler to work with. In case you forgot, here is snippet from
input file again.

-----------------------------------------------------------------------------
###########################################################################
# Cross Platform library
###########################################################################
XP.NAME              = xp
XP.DESCRIPTION       = Cross Platform Services
XP.DEPEND            = 
XP.DEFINES           = -DXPAPI=EXPORT
XP.SRC               = $(wildcard $(SRCDIR)/sys/$(OS)/xp*.cpp )
XP.LIB.EXTRA         = $(LIB.XPSHLIB)

###########################################################################
# Standard Debugging library
###########################################################################
STDDBG.NAME          = stddbg
STDDBG.DESCRIPTION   = Standard Debugging library
STDDBG.DEPEND        = $(XP.NAME)
STDDBG.DEFINES       = -DDBGAPI=EXPORT
STDDBG.SRC           = $(wildcard $(SRCDIR)/dbg/*.cpp )
-----------------------------------------------------------------------------

Personally I could live with a simpler properties file input to ant
process. This is currently not possible. Sure more difficult for build
engineer (but it IS their job) but simple for build file writer. And even
better - EASY to maintain.

Heres a sample of input file I used to generate an avalon project file.

<asl:project name="LogKit" version="0.2" hierarchy="org.apache.log.*"
group="avalon">

  <asl:init>
    <filter token="year" value="${year}"/>
    <filter token="AVALON_BASE" value="http://jakarta.apache.org/avalon"/>
  </asl:init>

  <asl:resources>
    <check-class name="javax.servlet.ServletContext" set="servlet.present"/>
  </asl:resources>

  <asl:java-compile>
    <exclude name="org/apache/log/output/ServletOutputLogTarget.java"
unless="servlet.present"/>
  </asl:java-compile>

  <asl:style-book/>

</asl:project>

Admitedly theres some dodgy features of it (java-compile would be better
represented as instance of fileset) but overall it is far easier to
maintain than a 13KB build file.

>My build file - I have a single one - doesn't include a single ant or
>antcall task, and it is maintainable (at least by me).  It doesn't need
>a single feature that you want to solve with templating, that's why I
>assume that I don't have the experience necessary to understand the
>complex needs of large scale build systems.

I guess by large I assume complex, with java that is usually not the case
atm, in the future I see it becoming more of an issue as build environment
matures.


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


Mime
View raw message