--On Monday, September 12, 2005 11:24 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
I agree with the current problems with Hackystat's Ant Build process.
I've just done some Ant hacking for some other complicated projects and
thought I could base it on Hackystat's build. However, because of the
dependency problems I felt that Hackystat's build.xmls were pretty messy
and pretty hard to understand (for newbies).
There is some inherent complexity in the Hackystat system which will always
necessitate a sophisticated build.xml. On the other hand, I am sure we can
make it more understandable than it is now. My proposed improvement
actually makes things a little more complicated from the readability
standpoint, but the benefit is that it makes the system more modular and
extensible.
I like the idea of the definition file. But, how would the generated file
know which module to build first? One would think that hackyKernel
should go first, then followed by hackyInstaller, hackyStatistics,
hackyReport, etc. Would we be able to determine the order of the modules
from the definition file?
Yes, and this is the key insight. The generated file determines
dependencies exactly the way we do it now, which is by exploiting Ant's
dependency resolving mechanism. Each individual "doInternal_<module>" task
defines what modules each <module> depends upon in the build. The set of
all doInternal_<module> tasks together defines a dependency graph.
Right now, we have to hardwire the set of doInternal_<module> tasks into
build.xml. In my proposal, we will automatically generate the set of
doInternal_<module> tasks via a preprocessor. Ant's dependency mechanism
takes care of the rest.
Not to mention, I just seen that the checkModuleAvailability needs to
execute the checks in alphabetical order according to the comment..
"Modules in dailybuild. Keep in alphabetical order, please!" on line 125.
Actually, that isn't needed once the set of modules is generated
automatically.
(I'm just thinking out loud here. Feel free to stop reading).
Not sure if I like the idea of the generated build.xml file. Would that
be hard to debug? I say that because, we would need to make sure that
the generated file works and that the generator works too.
This is actually a feature of the generated build.xml file: it's easier to
debug because it's just Ant code! And, since it should end up looking
pretty much like the current build.xml, and is invoked the same way, when
things fail it should be relatively easy to debug.
Option 2: I'm not sure we would even need to have a generated
checkModuleAvailability, doInternal, doUtil, etc. It seems to me that if
we can generate a list of modules in the order that it should be built,
based on the definition files, then we should also be able to write
targets that dynamically calls each module.
This is actually much harder---now we have to roll our own dependency
resolving mechanism instead of simply using the one that's already
available in Ant. Now we have to debug and maintain a bunch of custom Java
code.
Option 3: use includes, macrodef, and subant.. see
<http://ant.apache.org/manual/CoreTasks/subant.html>.
I agree that these could be useful. One approach is to apply these
constructs to the current build.xml file first to see if we can make it
more simple and readable. Once we have them correctly implemented, we
design the preprocessor to generate the build.xml using these constructs.
One last thing, there seems to be a need for module specific targets like
installEclipseSensor (although this might be removed) and
installInstaller.
Hopefully, installEclipseSensor should go. installInstaller may need to
stick around, but since it is required by every configuration, it's not too
much of a problem.
Cheers,
Philip
