Dear Gumpmeisters,
The following 7 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: Module xdoclet success, but with warnings.
[EMAIL PROTECTED]: Module icu4j failed
[EMAIL PROTECTED]: Project jdtcore (in module
Yup, it was this commit, I fell into this circular loop trap -- Jaxen -
XOM - Jaxen. I guess that is something to fix (in either Gump2 or Gump3).
[It is funny how you never give the commits mail list much attention, until
it is so helpful as to tell you the only possible cause that occurred on
Peter wrote:
I discovered in last night's local Gump run that XML Commons has been
updated to require JAXP 1.3, which I didn't have installed locally (just
the
java-xml-pack as suggested by xml-commons.xml). Brutus doesn't seem to
run
at all since Wednesday, but I think it's going to get
On 06-04-2005 17:25, Adam Jack [EMAIL PROTECTED] wrote:
1) External PlugIns
I'd really like to hear design/implementation ideas about
discovery/life-cycle of plug-ins to Gump3.
My initial idea number one: don't design ahead of need.
I hear ya, but we've heard the need for this
Issue Subscription
Filter: open gump issues (69 issues)
Subscriber: gump@jakarta.apache.org
Project: Gump
Resolution: Unresolved
Key Summary
GUMP-116Promote using html in description/ fields
http://issues.apache.org/jira/browse/GUMP-116
GUMP-115Make gump result pages
Why are CvsUpdater, SvnUpdater pre-process plug-ins, not 'process' visitors?
Clearly (as of now) it make little difference, I'm just trying to
understand.
I'm not sure I'm comfortable with the three pre-process/process/post-process
walks. Is this a Gump2 hold over that we want in Gump3? I'm not
