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, 06 Jun 2001 12:22:20 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
> 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.
>

My problem is with applying the term to <projectref> not with the existance
of it.

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

(C) Use "if" attribute on the predefined target. Just covering all possible
solutions.

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

Or you could just have knowledge about the properties in the "if"s and just
pass that info to the <projectref> in the instantiation. There, your outside
projects know hardly anything about what is going on. No need to know the
"uglyness" as you call it.

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

What is this extra maintenance work? Aren't tasks suppose to work as
adverticed? If I publish develop a task and say it does nothing when no
input is given, then it should keep on doing that on future revisions, the
same why it is suppose to keep on doing whatever it is that is suppose to
do.

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

Yes, we have been against "if"s at task level, but not at target level. I
actually would like them strengthen. With <projectref> you only have one
instance of the features to maintain. You can add more, features have
default values for the features, etc.

Before you get into what we can do or not, can you tell me what you mean by
nested Fs? Fs are tasks, so are you talking about some new nested task
concept or something?

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

This is what I call embeded job security ;-)
We can't make the build tools too easy to use, those programmer may start
writing their own build files.

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

As I told you in the past, you are just trying to impose on ANT those
patterns developed for MAKE. For example:

	$(wildcard $(SRCDIR)/dbg/*.cpp )

when were you goint to come and ask for $function-call notation for ANT so
you can give input lists explicitly? without that you cannot just write your
buils as a property file. I was wondering how were you planning to pass all
the different filesets and such for your expanded templates/configuration.
Well, OK I give you the benefit of the doubt, you were planning to implement
this functionality in your JavaScript/JPYTHON Configuration stage. ;-)

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

Althogh you can achieve this with the <configure> task we have already
mentioned and maybe even with the <style> or <anakia> tasks that exists
today. I still think this is just advocating for having dialects in ANT,
each project its own. No common IDE is possible because there is no common
language for buildfiles.

How do you debug a builfile in this macro language? You do not even know
what is this suppose to expand to until you execute. Or learn XSLT as to
understand the templates.

Jose Alberto


Mime
View raw message