You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2003/09/26 17:44:48 UTC
GUI/Stats/Gumping stuff (was Stefan's comments)
> The single most important feature for me is that it can run at night
> from cron with nobody around - and I love the timeout feature at least
> available on Linux that can kill hanging Axis or Cactus or
> Tomcat-Connector builds.
I have the same use case, and I thought I wouldn't like the GUI. Then I
tried it, and I really liked the way it allowed my to introspect the
metadata. I think there is great potential there. Again, I will likely never
run builds from the GUI, but I like the options it provides for tools for
basic users. I'd like to see the GUI (1) have a wizard for creating new
project metadata (2) allow "create me a profile that would build me X,Y and
Z from bottom up -- no extras". About 6 months ago I would've paid money (a
dirty set of words ;-) for (2).
Ok, where on earth is this timeout feature? I want it also, but I don't know
where to find it. Can you point me to it? Thanks.
> There may be a language problem here, I'm not sure. "concerned" was
> supposed have a negative connotation when I wrote it, sorry.
Nah, I probably just interpretted via what I wanted to read. Yes, there is
the potential for negative, but I'd like to have more faith in the
community, that they'd be used for posotive. If they happen, then time will
tell.
Statistics are not the goal, so sure -- fix things for other folks. If you
fix problems, you are part of the community. However, I was talking
primarily about code bugs (like one that has huanted me w/ VFS/HttpClient
for the last month).
Primarily, I think component re-use suffers from lack of trust amongst
developers. 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. [BTW: My interest in http://krysalis.org/version is
because I use stacks of code, and want it to work together, so maybe this is
my personal use case/bias.]
As such, I think statistics are mainly a good things for good projects, and
a gentle nudge for others.
> 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?
> 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?
We have some issues w/ tests projects right now, but in the main they work,
see Nick's custom gump:
http://gump.chalko.com/
So, is this centipede problem an environmental one on your system, or your
stack? Could you send me more information to help track it down? If you are
running latest Ant, and ant is about to be released, and centipede is
failing ... Krysalis folks really need to know, thanks.
regards,
Adam
Re: /k-* (was Stefan's comments)
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>On Tue, 30 Sep 2003, Nick Chalko <ni...@chalko.com> wrote:
>
>
>
>>krysalis-template-smoketest.
>>
>>
>
>After adding ant.home to the descriptor: <http://cvs.apache.org/~bodewig/gump/>
>
>
>
Strange that is not what I got from the command line
I will keep looking
Re: /k-* (was Stefan's comments)
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 30 Sep 2003, Nick Chalko <ni...@chalko.com> wrote:
> krysalis-template-smoketest.
After adding ant.home to the descriptor: <http://cvs.apache.org/~bodewig/gump/>
Stefan
Re: /k-* (was Stefan's comments)
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>I'll try to find some time and run a -debug build of one of the
>failing krysalis projects. Any suggestion which one I should try
>(they basically look like the same failure to me).
>
>
>
krysalis-template-smoketest.
But it seems to be turned off.
I will turn it back on.
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
Re: Gumping centipede
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
> Nick Chalko wrote:
>
> ...
>
>> BUILD FAILED
>> C:\krysalis\krysalis-template\smoketest\build.xml:9: import requires
>> support in ProjectHelper
>
>
> Seems like Eclipse is using it's own Ant. 1.5.4 doesn't indeed have
> support for import in ProjectHelper.
>
Perhaps.
I did some funky stuff and forced the imported file onto the importstack
and I got further but then had other problems.
I am still playing.
Re: Gumping centipede
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nick Chalko wrote:
...
> BUILD FAILED
> C:\krysalis\krysalis-template\smoketest\build.xml:9: import requires
> support in ProjectHelper
Seems like Eclipse is using it's own Ant. 1.5.4 doesn't indeed have
support for import in ProjectHelper.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Gumping centipede
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>I've updated the logs with last night's build (ant-contrib-tests has
>been hanging and I had to terminate it manually in case you're curious
>about the build times).
>
>See also <http://cvs.apache.org/~bodewig/gump/krysalis-version-debug.log>
>for a manual invocation with
>
>./build.sh krysalis-version dist-gump -debug -logfile /tmp/krysalis-version-debug.log
>
>
I am trying to replicate the problem in eclise (so I can step through
the code) but I get this
[centipede] set 'core.antlib.dir' to
'c:/tools/ant/tools/antlibs/core-0.0.1-dev.antlib'
[centipede] import file :
//c:/tools/ant/tools/antlibs/core-0.0.1-dev.antlib/xbuild.xml
BUILD FAILED
C:\krysalis\krysalis-template\smoketest\build.xml:9: import requires
support in ProjectHelper
at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:131)
at
org.krysalis.centipede.ant.ImportAntLibTask.execute(ImportAntLibTask.java:219)
at
org.krysalis.centipede.ant.CentipedeTask.importCoreXbuild(CentipedeTask.java:84)
at
org.krysalis.centipede.ant.CentipedeTask.execute(CentipedeTask.java:63)
at
org.apache.tools.ant.UnknownElement2.execute(UnknownElement2.java:205)
at org.apache.tools.ant.Task.perform(Task.java:401)
at org.apache.tools.ant.Target.execute(Target.java:338)
at
org.apache.tools.ant.helper.ProjectHelperImpl2.parse(ProjectHelperImpl2.java:148)
at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:126)
at org.apache.tools.ant.Main.runBuild(Main.java:653)
at org.apache.tools.ant.Main.startAnt(Main.java:220)
at org.apache.tools.ant.Main.start(Main.java:184)
at org.apache.tools.ant.Main.main(Main.java:267)
Total time: 1 minute 52 seconds
Still looking
Re: Gumping centipede
Posted by Nick Chalko <ni...@chalko.com>.
I confirmed this on my laptop at home last night using 9/28 CVS of ant
from the command line (not gump)
I will start debugging it tonihgt.
Stefan Bodewig wrote:
>I've updated the logs with last night's build (ant-contrib-tests has
>been hanging and I had to terminate it manually in case you're curious
>about the build times).
>
>See also <http://cvs.apache.org/~bodewig/gump/krysalis-version-debug.log>
>for a manual invocation with
>
>./build.sh krysalis-version dist-gump -debug -logfile /tmp/krysalis-version-debug.log
>
>and an empty CLASSPATH (using JDK 1.4.2).
>
>When you try to parse this, you should know that
>/home/bodewig/dev/gump is a symlink to /javastuff/gump.
>
>On Mon, 29 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
>
>
>
>>It isn't a property but a static variable we test (I forget why we
>>stopped using a property).
>>
>>
>
>Sounds like a potential classloader problem then. If centipede's
>classes get loaded twice via different class loaders, you'll get two
>instances of the same class that don't share the same static
>variables.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
Re: Gumping centipede
Posted by Stefan Bodewig <bo...@apache.org>.
I've updated the logs with last night's build (ant-contrib-tests has
been hanging and I had to terminate it manually in case you're curious
about the build times).
See also <http://cvs.apache.org/~bodewig/gump/krysalis-version-debug.log>
for a manual invocation with
./build.sh krysalis-version dist-gump -debug -logfile /tmp/krysalis-version-debug.log
and an empty CLASSPATH (using JDK 1.4.2).
When you try to parse this, you should know that
/home/bodewig/dev/gump is a symlink to /javastuff/gump.
On Mon, 29 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> It isn't a property but a static variable we test (I forget why we
> stopped using a property).
Sounds like a potential classloader problem then. If centipede's
classes get loaded twice via different class loaders, you'll get two
instances of the same class that don't share the same static
variables.
> This time it is me that does not follow, 'cos (1) POI is nothing to
> do with me (2) POI gave up on centipede long ago, and uses plain
> ant.
My only exposure to a build using centipede has been when I tried to
debug a problem with POI's builds in Gump some months ago when they
still used centipede. And at that time I found the nested <ant>
invocations incredibly difficult to follow, in particular since a
bunch of <antcall>s could have been depends attributes on targets as
well. Things may have changed since then.
Stefan
Gumping centipede
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Which variable in which log?
Looking at this:
http://cvs.apache.org/~bodewig/gump/krysalis-version.html
(Which incidently works on Chalko.com w/ a canned Ant from a few weeks ago)
http://gump.chalko.com/krysalis-version.html
I see:
Buildfile: centibuild.xml
[centipede] Initializing Centipede [org.krysalis.centipede version
1.0.0-beta6-10001]...
which shows centipede is included/run.
It isn't a property but a static variable we test (I forget why we stopped
using a property).
Anyway, some sort of exception must be occuring and not logged (or
something) for that variable not to run.
This is *IMNSHO* quite possible 'cos between that log line and setting the
variable is some reasonably significant stuff, including files, registers
ant property handlers, etc. I'm not sure why an exception is not logged
though.
> If you can tell me what property you expect to get where, I may have a
> chance. I haven't looked at the krysalis builds yet, but when I tried
> to debug a POI problem several weeks ago you simply lost me with your
> multiple nested levels of <ant> and <antcall>.
This time it is me that does not follow, 'cos (1) POI is nothing to do with
me (2) POI gave up on centipede long ago, and uses plain ant.
> I'll try to find some time and run a -debug build of one of the
> failing krysalis projects. Any suggestion which one I should try
> (they basically look like the same failure to me).
Yes please. Krysalis-version please, 'cos we see that runs on chalko.com w/
older ant.
regards,
Adam
Re: /k-* (was Stefan's comments)
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 29 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> Annoying that this must've started happening about when nags
> stopped,
I'm not sure, but I think I've even seen them before that.
> What is so interesting is that it is complaining about a static
> variable that one ant task sets (and I see it called in the logs)
> that another tests.
Which variable in which log?
> Any chance you could think of anything that has changed within Ant,
a lot, sorry. We've been rather busy as we want to release 1.6beta
soon (errm, tomorrow IIRC).
> to do with including ant taks
including in what way?
> and such, that might (possible) give us a starting point?
If you can tell me what property you expect to get where, I may have a
chance. I haven't looked at the krysalis builds yet, but when I tried
to debug a POI problem several weeks ago you simply lost me with your
multiple nested levels of <ant> and <antcall>.
I'll try to find some time and run a -debug build of one of the
failing krysalis projects. Any suggestion which one I should try
(they basically look like the same failure to me).
Stefan
Re: /k-* (was Stefan's comments)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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 ...
No. As I said, I'd just like to try to swing the balance a bit closer to
re-use through good clean communications (including statistics).
Maybe I am more trying to help folk prior ro making the build/borrow
decision. If a team is trying to make a decision to use (say) some XML bean
thingie, and some members of the team argue aginst re-use 'cos XYZ isn't
blah, it'd be nice to have some facts to make a proper decision upon. For
example -- N folks are already using it, it has M stability/maturity, etc.
Getting developers to use one's toothbrush will still be easier than getting
them to use one's software, but perhaps we can get it to rank above
flossing. ;-)
> 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.
Maybe, at the level of the examples you've given.
I'm working with others to re-write Ruper making commons VFS (cool, but
perhaps overkill) an optional component. The final straw was an ongoing gump
issue [making all ruper dependees crash horribly] that saw no action for way
too long. I'm not saying it is easy, but it is an option and some times it
is mandatory.
Gump helps demonstrate divergences, and having statistics/communications
that clearly document 'recent history' (saving humans from using gut
feelings alone) have potential to be a good thing (IMHO).
> >> Are you aware that almost all krysalis-* projects fail every night
> >> "because Centipede has not been not initialized"? 8-)
> 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.
I looked into to the problem (thanks for the posting it). Annoying that this
must've started happening about when nags stopped, and that Nick's gump (he
didn't have resources to build the ant stack) -- or perhaps when Ruper and
above was a mess due to VFS/HttpClient. I was thinking it was environmental
on your machine, but no, it is (as you say) on Covalent also.
What is so interesting is that it is complaining about a static variable
that one ant task sets (and I see it called in the logs) that another tests.
For that variable not to be set, an exception would have to occur (at best)
but I see nothing from ant on that, so maybe there is something deeper. Any
chance you could think of anything that has changed within Ant, to do with
including ant taks and such, that might (possible) give us a starting point?
> > If you are running latest Ant,
>
> You are joking, right? ;-)
> Sometimes it is more recent than CVS HEAD.
No, just demonstrating that the contents of my e-mails are sometimes more
recent than the contents in my HEAD. ;-)
regards
Adam
Re: GUI/Stats/Gumping stuff (was Stefan's comments)
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 26 Sep 2003, Adam R. B. Jack <aj...@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