Leo (primarily)
Relaxed and refreshed after a week on the beach, I'm putting other concerns
aside and am taking a day for me, to tinker w/ Gump3. So, I'm digging into
the fresh code (and still consuming the rest of it.) Hopefully after today
I'll be "in the zone" w/ this stuff, and better able to dig in at will.
Interestingly, I find I'm going through some of the same 'groking pains' as
folks have felt with Gump2. (Kinda nice to be on the other side of the fence
for a change, getting to see inside somebody else's head, and liking the
view.) Despite this being 100% crisper, I still have some question...
I think in these (early days, maybe through-out the life of Gump3) the
toughest part is the "property messaging protocol(s)". Basically Gump3
internals are based upon trust & respect between plugins -- like a good OSS
project :-) -- but it doesn't (yet) have the internal equivalents of
communications forums of wikis/blogs/docs, nor the history of commit mails,
mail archives, nor SCMs. My main interest in Gump3's approach is if this can
fly, and scale. I feel yes, but I think we need tools (docs being just one).
I'd like to see how/if those tools fit. For example, [Question] I'd like to
know how a module/project status/failure/cause protocol gets agreed between
builder plugins and (core?) build algorithms? How do I dig into it?
For futures, what is the best way to "manage" that protocol, keeping it
clean/healthy -- and ensure we don't leak too much "plugin stuff into the
core" w/o noticing. As I see the code base the "theoretical aspects" are
coming to a close as more and more "practicalities" come into play.
Basically, on Cygwin, I see CVS updates for Ant occurring and the
bootstrap-ant script being called (albeit, in my environment, failing). I
want to get past there -- wiring in the Java Ant builder I've written, but
I'd also not like to miss out on a few more theoretical parts. I'd like to
see if there are ideas for managing these property messages before we write
much more.
I feel that as we develop more and more plugins I'd like to consider how we
'keep track' of the interactions, perhaps even the deltas or what properties
a plugin creates and/or tweaks, and perhaps even attribute ownership.
Perhaps have a known dictionary (on model objects) of plugins taking credit
for their efforts. I'm not trying to slow down progress, just curious about
exploring ideas to make plugin communications if not deterministic,
"trackable" & perhaps self-documenting.
Also, I suspect that in the real world (the full Gump run) we'll want a
Reaper plugin, that trims properties, perhaps based off a reap_me
dictionary. I'm not sure where/how this fits in, but I suspect it'll be
needed over time. Gump2 had to do a lot of cleanup in order not to bloat
it's Python runtime to a crawl. I feel Gump3 will push this far further, and
some properties will heavy yet 'used' after the build has occurs. Dependent
upon the run algorithm some properties can reside in memory long after they
are useful, and it'd be nice to abstract that 'gc' from the plugins. [I also
think we'll want to do property() calls to implement a load on demand of log
files, into strings in memory, rather than spew into memory. We'll see.]
Anyway, how might a Reaper fit in?
BTW: We need to add a test case like this, so Gump3 doesn't crash like Gump2
does. This (and usually a typo in packages) has been the primary cause for
run fall-overs in Gump2 recent memory. [Question] Where would I start to fix
this crash?
<project name="bogus5">
<module name="doesnotexist"/>
</project>
That all said, I back (for now) to looking at why bootstrap-ant gives me
this on Cygwin (despite the below) so I can attempt dist-ant using the
JavaAntBuilder.
... Bootstrapping Ant Distribution
JAVA_HOME=c:\j2sdk1.4.2_08
JAVA=c:\j2sdk1.4.2_08\bin\java
JAVAC=c:\j2sdk1.4.2_08\bin\javac
CLASSPATH=lib\optional\junit-3.8.1.jar;lib\xercesImpl.jar;lib\xml-apis.jar;b
uild
\classes;src\main;
... Compiling Ant Classes
The system cannot find the path specified.
---------------------------------------------------------------------------
-------
$ which java
/cygdrive/f/apps/javasoft/j2sdk1.4.2/bin/java
$ env | grep -i java
JAVA_HOME=/cygdrive/f/apps/javasoft/j2sdk1.4.2
---------------------------------------------------------------------------
-------
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
