[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gump
Subject:    Re: GUI/Stats/Gumping stuff (was Stefan's comments)
From:       Stefan Bodewig <bodewig () apache ! org>
Date:       2003-09-29 7:18:34
[Download RAW message or body]

On Fri, 26 Sep 2003, Adam R. B. Jack <ajack@trysybase.com> wrote:

>> The single most important feature for me is that it can run at
>> night from cron with nobody around
> 
> I have the same use case, and I thought I wouldn't like the
> GUI.

"wouldn't like" is not exactly true.  It's a nice to have, but not
important to me.  Being able to run stuff without the GUI is
important.

> Ok, where on earth is this timeout feature?

Sam posted a Linux executable named timeout here, I'm not sure where
he found it.  Running strings on it didn't reveal anything useful,
sorry.

My cron job does

bash gen.sh -cp "/usr/local/bin/timeout 1200"

which prefixes all executions in update.sh and build.sh with the
timeout invocation.  It is supposed to kill any process that runs
longer than 20 minutes and works quite well in most cases - but
sometimes fails if the java process forks a new VM like during Cactus
builds.

> I beleive that many developers don't like to rely upon others, so
> don't re-use if they can avoid it, I've seen it even on
> Jakarta. With commons/sandbox and even incubator I feel there is the
> chance for lots of non-cooperating projects, and I don't like
> that. I am not naive enough to think that all software can/ought
> work together, but I'd like to see Gump help shift the
> balance.

As long as you don't believe you could solve the social problem of
"don't like to rely on others" via a technical solution ...

>> Very unlikely, even for projects that consider themselves "friends
>> of Gump".  When has Gump tried to build Cocoon or Forrest the last
>> time?
> 
> But shouldn't it? Couldn't it? Why not - resources? complexity?

We could go by them case by case, but I don't think thta is necessary.

You said that projects could switch components they rely upon if those
components would consistently fail to build with Gump and I said that
would be unlikely.

Cocoon doesn't get built because of missing pre-reqs coming from
Avalon, mostly.  Last night it has been xmlutil and store.

If you follow the dependency chain, you'll see that the reason that
excalibur-store doesn't build is that it relies on the qdox definition
inside of cocoon's own descriptor which is broken.(it should be
qdox-1.2.jar istead of 1.1).

This means Cocoon doesn't build since many weeks, partly because its
descriptor is broken and nobody cared enough to fix it.  Unfortunately
I can't fix it since I don't have commit access to the descriptor
itself.  I didn't investigate why Cocoon's build was broken until just
now, that's why I haven't send a patch, yet.

Forrest obviously can't drop its Coccon dependency easily, that's the
original point I was trying to make.

>> Are you aware that almost all krysalis-* projects fail every night
>> "because Centipede has not been not initialized"? 8-)
> 
> No, not at all. I monitor them, as do others, and they work. I've
> not seen nags to this effect, have you?

Every night.  You don't see them as nagging doesn't work at all (the
one from Sam's machine) as nightly Gumps are broken, currently.  Maybe
I should publish my nightly results until Sam's builds are up again.

But then again, you should be able to see the failures un
gump.covalent.net as well.

> If you are running latest Ant,

You are joking, right?  ;-)

Sometimes it is more recent than CVS HEAD.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
For additional commands, e-mail: gump-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]