On Sat, 27 Mar 2004, Nick Chalko wrote:
> Here is an idea to let gump build 100% every time.
>
> Keep the jars from the last success full build of each project. Then a
> project fails it will not stop the rest of the tree from building.
I'm just a lurker here, but this seems to defeat the whole p
nickchalko2004/03/27 23:25:24
Modified:profile gump.xml
Log:
Adding antlets.
PR:
Obtained from:
Submitted by:
Reviewed by:
CVS: --
CVS: PR:
CVS: If this change addresses a PR in the problem
Here is an idea to let gump build 100% every time.
Keep the jars from the last success full build of each project. Then a
project fails it will not stop the rest of the tree from building.
Of course it becomse a little more complicated to know what jars were
used for what. But I think we coul
some snippets follow:
- - - - - -- -- G U M P
Gump provided these annotations:
- Info - Sole jar
[/data3/gump/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-20040327.jar]
identifier set to project name
- Error - Failed with reason build timed out
- Info - Enable "debug"
Adam R. B. Jack wrote:
BTW: I'm eager to see some graphics. If SVG can be written (in XML, viua
Python) can Forrest convert these to images (using Batik or somethough?)
I'll happily continue with Forrest if that is a good way to get images
rendered.
Yes
Just put foo.svg and then access it as f
> I'll certainly guilty of being away for a while, but
> gump.document.forrest is not a small thing, and to my eyes, not entirely
> obvious.
It is really just a lot of repetative simple code, building simple xdoc
pieces. It it's pretty, but it isn't that bad.
We have gump.document.text, and we co
Nick Chalko wrote:
Stefano Mazzocchi wrote:
\
.
Ok, I think that reducing complexity is critical for wider adoption.
+1 in removal of forrest and go plain XHTML + CSS. But please, let's
use a velocity-like approach, not a DOM like approach!
I am not sure how removing forrest reduces complexity
> Any suggestions?
>
Have you had chance to the thread with subject 'Enigma: build of xdoclet'?
There is a rogue build chewing cycles, and hence delaying yours beyond the
timeout.
regards
Adam
-
To unsubscribe, e-mail: [EMAIL
Dear Gumpmeisters,
The following 9 nags should have been sent
G U M P
[EMAIL PROTECTED]: webwork/webwork failed
[EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed
[EMAIL PROTECTED]: freemarker/freemarker failed
[EMAIL
Stefano Mazzocchi wrote:
\
.
Ok, I think that reducing complexity is critical for wider adoption.
+1 in removal of forrest and go plain XHTML + CSS. But please, let's
use a velocity-like approach, not a DOM like approach!
I am not sure how removing forrest reduces complexity.
It just means w
Leo Simons wrote:
in other words, do it incrementally.
Sorry, then I misunderstood you.
I just think that we should keep scratching our itches and stop doing
abstractions just because it's cool and elegant.
That's all.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Adam Jack wrote:
Unfortunately we are stuck with a recent CVS HEAD, if not latest, due to
some features in the skin. We can't go back to a release.
FWIIW: The release we have has been working for the last month or so,
something just changed and dorked it.
Ok, I think that reducing complexity is cri
rubys 2004/03/27 10:52:09
Modified:python/gump/output statsdb.py
Log:
Some implementations seem to freak out at simple strings encapsulated
in unicode objects.
Revision ChangesPath
1.18 +7 -13 gump/python/gump/output/statsdb.py
Index: statsdb.py
==
sebb2004/03/27 07:26:42
Modified:project jakarta-jmeter.xml
Log:
Add JMeter monitors to test classpath
Revision ChangesPath
1.93 +10 -9 gump/project/jakarta-jmeter.xml
Index: jakarta-jmeter.xml
=
Have been digging into the avalon-composition-impl project results from
earlier this morning which is failing with a "Build Timed Out".
http://lsd.student.utwente.nl/gump/avalon/avalon-composition-impl.html
Under "Project Level Work" I see that build is successful but that the
build itself took
Current status:
A minimal network install of Debian testing [1] was made on one of the
new IBM xSeries 345 machines. Being minimal, this kernel does not yet
recognize the second CPU or second Gig, but my first focus is to get the
box up and running. Once running, I plan to attempt to replicat
One thing that is possible to do in Python that would have been
difficult to do in shell script is to parallelize some of the processing.
In a daily build, there are three major components: cvs/svn update,
copy/rsync, and build. My recommendation would be to not overdesign
this (too many proce
17 matches
Mail list logo
