Hi,
I just wanted to report where Loom currently is, for everyone's infor-
mation:
First of all, it still just can build HelloWorld. But it can do it in a
much nicer way that it could a few days ago.
I added a configuration subsystem, so the basic infrastructure for this
is there. I decided on an open system there, ProjectBuilders (AKA
ConfigurationConsumers) are contributed to the ProjectManager using an
entry in hivemodule.xml. As soon as they do so, they'll get their
chance to install their defaults into the project, and later to handle
their XML configuration fragments. It's basically exactly the same as
the WorkingMemoryBuilders, which populate the WorkingMemory with facts,
globals and other things. I decided to pass just a org.dom.Node, so no
further dependencies are introduced at this point and plugin
implementors have the complete freedom, to use whatever they want to
handle 'their' fragment of configuration. I personally prefer digester,
but I didn't want to force anyone to use anything specific. To make
life a bit easier, there's an abstract default implementation of the
ProjectBuilder interface that 'converts' that DOM node back to SAX (for
Digester, xpp3, whatever), implementors just have to provide a
ContentHandler.
When I started to add JavaDocs, I changed the Ant interface quite a lot.
But actually, these were mainly renames, the concepts stayed the same.
I think, it's good like that, there are certainly some quirks in the
implementation, but the API looks good to me. It's just a few lines of
code to execute some Ant tasks -- it's even less typing than writing
Ant build files. :)
The most interesting changes, however, are in the java plugin, esp. in
compile.drl. compile.drl now shows how a rule based system will decide
what to do and when to do it. There's also an example in this file
which shows how a single line of code in some consequence will fire up
the Java plugin and cause it to compile some Java sources. Try it with
/path/to/loom/bin/loom test
The goal 'test' specified on the command line will cause a Goal object
with the name 'test' to be asserted into the working memory, which
causes the rule 'java:compile:test' to fire after the main sources have
been compiled (i.e. after the path with the role 'java:classes:main'
has been flagged with 'java:upToDate'). The consequence is to assert a
new CompilationUnit to the working memory => the paths with the
roles 'java:sources:test' and 'java:classes:test' are asserted
(rules 'java:populate:sources' and 'java:populate:classes'), then the
rule 'java:compile' fires, because there's a CompilationUnit, where the
corresponding output path is not flagged as up-to-date. So, those
sources will be compiled causing the path 'java:classes:test' to be
flagged as 'java:upToDate' => the rule 'java:compile:test:run' fires,
which would run the unit tests. Of course, the two last rules in that
file (the 'test' ones) shouldn't be part of the java plugin, they're
now just there for demonstration. It wouldn't make any difference, if
these two rules were in another DRL file of some other plugin.
I think, I'm on the right track there. I'm aware that there's a great
lack of documentation and I'm working on that. But I'm sure you all
know that coding is much more fun than documenting, so, please, bear
with me ... ;) If anyone wants to take a look and needs help to get
into the concepts or to find the right starting points, feel free to
contact me by mail, instant messaging or the list (ICQ #67961355, the
other contact info is in my signature).
Generally, some tips for starters:
1. 'ant docs': This will create JavaDocs and HiveDocs. Esp. the HiveDocs
should give quite a good overview, I think.
2. The '-d' option ('loom -h' works, BTW): This will cause debug logging
to build.log. LOTS of debug logging. :) It might be helpful to under-
stand, what that thing's doing.
I'll start a Wiki page/section on all that.
cu,
Raffi
--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.
[EMAIL PROTECTED] · Jabber: [EMAIL PROTECTED] · PGP Key 5D1FF5F4
_______________________________________________
general mailing list
[EMAIL PROTECTED]
http://lists.ops4j.org/mailman/listinfo/general
