[GUMP@brutus]: gump/gump-test failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project gump-test has an issue affecting its community integration, and has been outstanding for 9L runs. Project State : 'Failed' Full details are available at: http://brutus.apache.org/gump/public/gump/gump-test/index.html That said, some snippets follow: The following annotations were provided: -INFO- Failed with reason synchronize failed To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org/gump/public/gump/gump-test/rss.xml Atom: http://brutus.apache.org/gump/public/gump/gump-test/atom.xml -- Gump E-mail Identifier (within run) #3. Produced by Gump 2.1.0-alpha-0003. [Run (4203102004, brutus:brutus-public:4203102004)] http://brutus.apache.org/gump/public/index.html http://brutus.apache.org/gump/public/options.html -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] fixing gump
Stefano Mazzocchi wrote: This is not a rant, but constructive criticism. 1) as I mentioned already, I think that having gump (or forrest or whatever) generate static HTML pages creates more problems than it solves. I think we should move the architecture with something like this metadata - gump - database - jenny - user I agree. Keep in mind that metadata - gump - database - jenny -\ ^ | | | \-- user / it's worth thinking about workflow if you split things up, before you split things up. It could be that you want to have a Jane besides Jenny, where Jane is used for modification of the metadata and execution of complex workflow activity. Or whatever. Another minor comment: let's make sure we *brand* the whole thing as gump, not just a part of it. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
/usr nearly full
Hi gang, [EMAIL PROTECTED]:/usr/local/gump$ df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 7.4G 1.4G 5.7G 19% / tmpfs1011M 0 1011M 0% /dev/shm /dev/sda6 25G 2.1G 21G 9% /home /dev/sdb6 32G 26G 3.9G 87% /usr /usr/local/gump is kinda full, especially as it grows during gump runs (ie it was /dev/sdb6 32G 29G 1.1G 97% /usr a while ago). Something's gotta give. Or something has to move from /usr/local/gump to /home/gump. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rant] I hate this gump
On Sunday 03 October 2004 07:34, Scott Sanders wrote: it's going to be the simplest thing (for me!) that can possibly work. which is probably going to be cocoon ;-) That's a HUGE hammer, I hope you're pounding some big nails :) http://www.ibiblio.org/Dave/Dr-Fun/df200210/df20021030.jpg -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 10 notifys should have been sent *** G U M P [EMAIL PROTECTED]: gump failed [EMAIL PROTECTED]: cocoon-2.1/deli failed [EMAIL PROTECTED]: smartfrog success, but with warnings. [EMAIL PROTECTED]: xom failed [EMAIL PROTECTED]: jakarta-servletapi-5/txt2html-task success, but with warnings. [EMAIL PROTECTED]: jrefactory/jrefactory-pretty failed [EMAIL PROTECTED]: werkz success, but with warnings. [EMAIL PROTECTED]: easymock/easymock failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed [EMAIL PROTECTED]: jetty/jetty-plus failed *** G U M P [EMAIL PROTECTED]: gump failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Module gump has an issue affecting its community integration, and has been outstanding for 9L runs. Module State : 'Failed' Full details are available at: http://brutus.apache.org/gump/public/gump/index.html That said, some snippets follow: The following annotations were provided: -INFO- Failed with reason synchronize failed The following work was performed: http://brutus.apache.org/gump/public/gump/gump_work/update_gump.html Work Name: update_gump (Type: Update) State: Success Elapsed: 1 min 12 secs Command Line: svn --quiet checkout http://svn.apache.org/repos/asf/gump/trunk/ --non-interactive [Working Directory: /usr/local/gump/public/workspace/cvs] - No output - To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org/gump/public/gump/rss.xml Atom: http://brutus.apache.org/gump/public/gump/atom.xml -- Gump E-mail Identifier (within run) #1. Produced by Gump 2.1.0-alpha-0003. [Run (4203102004, brutus:brutus-public:4203102004)] http://brutus.apache.org/gump/public/index.html http://brutus.apache.org/gump/public/options.html *** G U M P [EMAIL PROTECTED]: cocoon-2.1/deli failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project deli has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 9L runs. Project State : 'Failed' The following are affected: - cocoon-block-deli : Java XML Framework - deli : Delivery context library Full details are available at: http://brutus.apache.org/gump/public/cocoon-2.1/deli/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole output [deli-0.9.8.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon-2.1/src/blocks/deli/lib/deli-0.9.8.jar -ERROR- See Directory Listing Work for Missing Outputs -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org/gump/public/cocoon-2.1/deli/rss.xml Atom: http://brutus.apache.org/gump/public/cocoon-2.1/deli/atom.xml -- Gump E-mail Identifier (within run) #2. Produced by Gump 2.1.0-alpha-0003. [Run (4203102004, brutus:brutus-public:4203102004)] http://brutus.apache.org/gump/public/index.html http://brutus.apache.org/gump/public/options.html *** G U M P [EMAIL PROTECTED]: smartfrog success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Module smartfrog contains errors. Module State : 'Success', Reason '' Full details are available at: http://brutus.apache.org/gump/public/smartfrog/index.html That said, some snippets follow: The following annotations were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/smartfrog/gump_work/update_smartfrog.html Work Name: update_smartfrog (Type: Update) State: Failed Elapsed: 3 mins 17 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvsroot/smartfrog update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/smartfrog] - cvs [update aborted]: writing to server: Broken pipe - To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org/gump/public/smartfrog/rss.xml Atom: http://brutus.apache.org/gump/public/smartfrog/atom.xml --
BATCH: Unable to send...
Dear Gumpmeisters, The following 1 notifys should have been sent *** G U M P [EMAIL PROTECTED]: cocoon-lenya/cocoon-lenya failed *** G U M P [EMAIL PROTECTED]: cocoon-lenya/cocoon-lenya failed Failed with to: [EMAIL PROTECTED] from: [Gump] Failed to send notify e-mail: (450, 'FQDN required in the envelope sender', 'Gump') To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project cocoon-lenya has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 50L runs. Project State : 'Failed' The following are affected: - cocoon-lenya : Content Management System Full details are available at: http://brutus.apache.org/gump/public/cocoon-lenya/cocoon-lenya/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole output [cocoon.jar] identifier set to project name -ERROR- No such project [dist-avalon-logkit] for property. -ERROR- No such project [avalon] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [avalon] -ERROR- Unhandled Property: avalonapi.jar on: Ant on Project:cocoon-lenya -ERROR- Cannot resolve output/outputpath of *unknown* [dist-avalon-logkit] -ERROR- Unhandled Property: logkit.jar on: Ant on Project:cocoon-lenya -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/cocoon-lenya/cocoon-lenya/gump_work/build_cocoon-lenya_cocoon-lenya.html Work Name: build_cocoon-lenya_cocoon-lenya (Type: Build) State: Failed Elapsed: 1 sec Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=*Unset* -Dlogkit.jar=*Unset* -Dversion=03102004 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon-lenya] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/cocoon-lenya/build/lenya-03102004/classes:/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-03102004/cocoon.jar:/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-03102004/cocoon-tests.jar:/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-03102004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/excalibur/deprecated/event/api/target/excalibur-event-api-2.0.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03102004/checkstyle-03102004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03102004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03102004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03102004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03102004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03102004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03102004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/excalibur/deprecated/event/impl/target/excalibur-event-impl-03102004.jar- Buildfile: build.xml BUILD FAILED Target `gump-core' does not exist in this project. Total time: 1 second - To subscribe to this information via syndicated feeds: RSS:
Re: /usr nearly full
Leo Simons wrote: Hi gang, [EMAIL PROTECTED]:/usr/local/gump$ df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 7.4G 1.4G 5.7G 19% / tmpfs1011M 0 1011M 0% /dev/shm /dev/sda6 25G 2.1G 21G 9% /home /dev/sdb6 32G 26G 3.9G 87% /usr /usr/local/gump is kinda full, especially as it grows during gump runs (ie it was /dev/sdb6 32G 29G 1.1G 97% /usr a while ago). Something's gotta give. Or something has to move from /usr/local/gump to /home/gump. Some directories like /usr/local/gump/public/jars seem to only grow. A cron job such as the following would remove files that are older than a week: find /usr/local/gump/public/jars -ctime +6 | xargs -r rm - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: /usr nearly full
Sam Ruby wrote: Leo Simons wrote: Hi gang, [EMAIL PROTECTED]:/usr/local/gump$ df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 7.4G 1.4G 5.7G 19% / tmpfs1011M 0 1011M 0% /dev/shm /dev/sda6 25G 2.1G 21G 9% /home /dev/sdb6 32G 26G 3.9G 87% /usr /usr/local/gump is kinda full, especially as it grows during gump runs (ie it was /dev/sdb6 32G 29G 1.1G 97% /usr a while ago). Something's gotta give. Or something has to move from /usr/local/gump to /home/gump. Some directories like /usr/local/gump/public/jars seem to only grow. yep, that jar archive is getting bigger for no reason. A cron job such as the following would remove files that are older than a week: find /usr/local/gump/public/jars -ctime +6 | xargs -r rm +1 great idea. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] fixing gump
Leo Simons wrote: Stefano Mazzocchi wrote: This is not a rant, but constructive criticism. 1) as I mentioned already, I think that having gump (or forrest or whatever) generate static HTML pages creates more problems than it solves. I think we should move the architecture with something like this metadata - gump - database - jenny - user I agree. Keep in mind that metadata - gump - database - jenny -\ ^ | | | \-- user / Yes, I thought about it and it might require some thinking overhere too. First of all: for that to work, all gump metadata must reside in the same repository... or, even better, not reside in a repository at all but just reside in a database. Cocoon build system, for example, depends directly on the gump module file and it's very unlikely for that to change any time soon. At the same time, if gump gave the same XML file from a URL, we could simply download it at build time and it would not be such a big issue (cocoon needs it for the blocks not for its core). So, what do you guys think: should gump metadata still reside in xml files or should it reside in a database and we have a web application on top that takes care of managing it? it's worth thinking about workflow if you split things up, before you split things up. True. It could be that you want to have a Jane besides Jenny, where Jane is used for modification of the metadata and execution of complex workflow activity. Or whatever. Another minor comment: let's make sure we *brand* the whole thing as gump, not just a part of it. All right forget about gump/jenny, it was just an example. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] fixing gump
On Monday 04 October 2004 01:29, Stefano Mazzocchi wrote: So, what do you guys think: should gump metadata still reside in xml files or should it reside in a database and we have a web application on top that takes care of managing it? What is known as Magic, an Ant 1.6 extension system with a strong project model similar to Maven, generates the current Gump XML from the project definition. Currently, this generation has to be run whenever the model changes (which sometimes is forgotten), instead of just handing Gump the model on demand. What would be really cool, is that Gump could query each module for the meta data somehow, so that in case of Magicthe 'intermediary' step of creating the xml of today could be skipped. That would also mean that the current xml, new DB way, Magic, Maven and possibly other ways can co-exist. In effect, it could be a 'pre-stage' to the 'build-stage' and that a DB connection is handed over to some generator/updater. My RM0.076 Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] fixing gump
Stefano Mazzocchi wrote: So, what do you guys think: should gump metadata still reside in xml files or should it reside in a database and we have a web application on top that takes care of managing it? If we move, which is probably a good idea, I'd suggest moving over gradually. Create a webapp that can read and write xml (should be easy with cocoon, no?). That way we don't impact projects that depend on having a gump descriptor available. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to reproduce a gump failure
Hi, Adam, Since it is a class not found, my guess is you might need a new work entry: http://gump.apache.org/metadata/project.html#work I'll keep that in mind, thank you. Anyway, you ought be able to run: python gump.py -w metadata/gump.xml ws-jaxme --debug I tried that, but the process terminated with the error message below. (In essence, it's permission to /data denied. Of course, I can create such a directory, but I have some doubts, that this is intended. :-) That said, I doubt it'll tell you much more than you see on the website. It will help for a start. :-) Regards, Jochen P.S: Is it possible to run gump without updating itself and its metadata? I understand why the update happens, but it slows down debugging quite a lot. Traceback (most recent call last): File bin/integrate.py, line 109, in ? irun() File bin/integrate.py, line 71, in irun workspace=WorkspaceLoader(False).load(ws) File /home/jwi/gump/python/gump/loader/loader.py, line 275, in load return self.loadFile(file,Workspace) File /home/jwi/gump/python/gump/loader/loader.py, line 202, in loadFile return self.postProcess(cls) File /home/jwi/gump/python/gump/loader/loader.py, line 255, in postProcess rootObject.complete() File /home/jwi/gump/python/gump/model/workspace.py, line 313, in complete if not os.path.exists(self.tmpdir): os.makedirs(self.tmpdir) File /usr/lib/python2.3/os.py, line 153, in makedirs makedirs(head, mode) File /usr/lib/python2.3/os.py, line 153, in makedirs makedirs(head, mode) File /usr/lib/python2.3/os.py, line 154, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/data' Process Exit Code : 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump misbehaves
On Monday 04 October 2004 07:02, Stefano Mazzocchi wrote: now it says that cocoon-block-asciiart didn't build because XOM didn't build. problem is that that block *DOES NOT* depend on XOM. This is starting to make me kinda concern. the old gump was a pain, but at least was working as expected damn. investigating some more.. The chain that I can find is; cocoon-block-asciiart -- cocoon -- excalibur-xmlutil -- jaxen -- xom ( -- == dependsOn ) i.e. jaxen has compile errors where nu.xom is listed in compile errors output. So, yes there is a root cause of xom involved. A bigger problem is that the 'output' of Gump (IMHO) is very hard to follow, added to the fact that it seems to be 'inconsistent' during an 'in-progress' execution, and executions are going on most of the time... I.e. there is a very short window when all the output is consistent and all there. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump misbehaves
Niclas Hedhman wrote: On Monday 04 October 2004 07:02, Stefano Mazzocchi wrote: now it says that cocoon-block-asciiart didn't build because XOM didn't build. problem is that that block *DOES NOT* depend on XOM. This is starting to make me kinda concern. the old gump was a pain, but at least was working as expected damn. investigating some more.. The chain that I can find is; cocoon-block-asciiart -- cocoon -- excalibur-xmlutil -- jaxen -- xom ( -- == dependsOn ) D'oh! you are right, I totally missed that. i.e. jaxen has compile errors where nu.xom is listed in compile errors output. So, yes there is a root cause of xom involved. ok, cool, I'm feeling better now ;-) A bigger problem is that the 'output' of Gump (IMHO) is very hard to follow, added to the fact that it seems to be 'inconsistent' during an 'in-progress' execution, and executions are going on most of the time... I.e. there is a very short window when all the output is consistent and all there. yes, agreed, but this is what I'm working on. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [rant] I hate this gump
Example: http://brutus.apache.org/gump/public/cocoon-2.1/index.html look at what it says: SUCCESS success at what? at finding problems? then it says overall project success 18%. WTF? what is the measure of success for gump, anything higher than zero? True, likely misleading. This is a module and it checked out so it is success at the module level. So, we clearly have a problem and I try to fix it. I take the 'cocoon' module because is the root of the dependencies (obviously *I* know that, stupid gump doesn't tell me that, even if it knows) http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/index.html no such project avalon-framework. What? It has been there *FOREVER*... oh, yeah, it's the we love our users anthem we hear from avalon every day [we are fixing that one in another area, but it should be fixed soon] I think It got renamed w/o some alias. Yeah, kinda tough on dependees. So, I go looking for the new name of the avalon framework... hmmm... where do I go? I look up: run? no workspace? yeah, that shoudl have it... no, it's useless crap, back, where is the list of the goddamn projects... hmmm, maybe log? all right Oh *fuck* gump is currently building, blah blah blah Yup, that has been pissing me off big time recently. But, I've come to agree ... I'd hate to write yet another static page, they have to go. Boy, this gump sucks. Gump needs to be a two tier system: one system drives the build and generates data, pumps it into a database and another tier (possibly a webapp) drives the presentation layer accessing that data. You and I stated this on an IM once. I agree completely. I also can't stand the static pages, and I wrote them. The static pages were there because of Forrest, partly historically, and that just slipped into XHTML, and stayed there. As you've stated, they try to tell you everything, and there is simply no intelligence. To attempt to be complete they overload the user with data [that is, at times, misleading], and as such the obscure the important facts. I'd love to see you go for this. Gump writes to MySQL, the data is there (albeit in somewhat ugly/simplistic a schema) so feel free to dig into it. Let me know if you need anything else. [BTW: Did Leo give you the PHP MySQL admin pages/login?] I half wonder if we could also write some information into an RDF tuple database for a webapp to query/display, but that can be a phase two (if needed). Yes, I'm going to do something about it myself and you can bet your ass that the webapp will *NOT* be written in python. No complaints from me. Python is a fine language, but I think: (1) the Gump code uses (for want of a better word) fragmented classes which are hard to form a mental picture from. I was trying to employ multiple inheritance and re-use, but think I unintentionally obscured. (2) I don't think Python is giving us the benefit it could, not necessarily 'cos of the language, more 'cos of the IDEs. I think Gump is large enough that folks can't navigate around it, so get lost, when really the core (wherever that is) is tiny and simple. I do hope to keep finding ways to simplify Gump's code so that Python is not a barrier to entry, but I'm more than happy to help work with alternatives. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] fixing gump
This is not a rant, but constructive criticism. 1) as I mentioned already, I think that having gump (or forrest or whatever) generate static HTML pages creates more problems than it solves. I think we should move the architecture with something like this metadata - gump - database - jenny - user 'jenny' is the codename of the web application that will present the gump-generated data to the user. +1. 2) not only the information presented is misleading but I think Gump simply operates wrong. take a look at http://brutus.apache.org/gump/test/project_todos.html look at the cocoon project. it says that it has 1 affected and 54 dependees, then the deli project (which is a package that the cocoon module exposes) has 2 affected and 1 dependee. Either there is something wrong or i don't understand what is an affected project and what is a dependee. Hmmm. And again ... Hmmm. I had bad math once before, but I swear I fixed it. Basically of the N dependees that a project could dork up, M (M=N) dependees could be affected by that project's failure (with N - M being dorked up by some earlier dependency). Do *not* ask me how we get 2 and 1. Some optimization perhaps (this determination once cost far too many cycles). This ought be added to JIRA. Moreover, right below cocoon there is cocoon-block-asciiart. Now, this project depends directly on cocoon, but instead of being yellow, it's red. This is just wrong. I think this is a result of trying to build everything every night ... i.e. it is trying to build off a cocoon in the repository. [Once we tried this I knew things got pretty 'fuzzy'.] Scroll down, there are *a ton* of cocoon blocks that should *NOT* have been built because their major dependency was missing. I wonder what's going on. add cocoon-lenya and xml-forrest to the list too. See above. Let's keep going: 3) xom does not have any affected project but has 137 dependees. but then http://brutus.apache.org/gump/test/dom4j/dom4j/index.html tell me that dom4j hasn't been built because of XOM failing. Color me surprised, I guess DOM4j was effected by this xom not building. Again, see above. Clearly there is work to do, or I ought back this out until we have a clear plan. Do we try to build all, or not? If we do, and I think we want to, how do we cope with states when parents are failing, but we have older versions pre-built in the repository. But let's look at XOM http://brutus.apache.org/gump/test/xom/index.html State: Failed Reason: Synchronize Failed The update was done ok, so what is this supposed to mean? When we update we checkout to a staging area. We then syncronize that to a working area (historical, but folks like it) and that synchronize failed. I had that with gump-test, the SVN checkout completed, but to an incorrect location -- so the sync then failed. I think I just fixed that, I'll look here at this. 4) another thing, the excalibur issue http://brutus.apache.org/gump/test/excalibur/excalibur-pool-api/gump_work/build_excalibur_excalibur-pool-api.html look at the build dump: maven-1.0-beta-10.jar (no download url specified) we have serious issues with gump/maven integration, we should try a little harder on this one. If folks use the Maven gump goal (to generate the Gump descriptor) dependencies ought be correct. That said, this looks like some sort of Maven internal thing. I'm not sure why it is needed. We could post it to JIRA, and see if we could get Brett to help us. Note: here the problem is that since this failed, cocoon shouldn't have been built since it directly depends on this! [so there are *three* level of building that failed because of gump not recognizing dependencies properly] It used to, but now it tries not to. 5) what is this supposed to be? http://brutus.apache.org/gump/test/gump/gump-test/gump_work/buildscript_gump_gump-test.html Some unit tests Gump runs on itself. enough for now. I'm diving in the code now, hopefully you'll see patches flying too. :-) Biggest help is folks looking at the outputs and scrutinizing them, it is the only way Gump improves. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: /usr nearly full
A cron job such as the following would remove files that are older than a week: find /usr/local/gump/public/jars -ctime +6 | xargs -r rm Ok, now our cron cleanup is: # Clean up after POI... 0 0 * * * /bin/rm -f /tmp/*.xls # Clean up older artifacts 0 0 * * * /usr/bin/find /usr/local/gump/*/jars -type f -ctime +6 | /usr/bin/xargs -r /bin/rm find /usr/local/gump/*/jars -type f -ctime +6 | xargs -r rm Tweaks: 1) Do all Gump flavours. 2) Just attempt to delete files (not directories) 3) Full paths -- in the cron script, if not cut-n-paste here -- just in case. What is interesting about this simplistic date-based clean-up is that we'll remove artifacts after 6 days, whether we have new artifacts or not. This will mean we can only 'build from repository' for a week. Maybe that is a good thing, i.e. we smooth issues we don't hide them forever. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] fixing gump
On Monday 04 October 2004 06:04, Stefano Mazzocchi wrote: well, I'm sorry but I don't get it. Gump *is* querying the metadata for each module. If you choose to encode your data in a different way and need to transform it to the gump markup format, that's your problem. AFAIU, Gump doesn't tell my module; Hey, I am about to start a build, please get your metadata in order. Meaning to say, currently the query is a passive read of a file that is expected to be up-to-date. I was looking for some more 'active' mechanism. In effect, it could be a 'pre-stage' to the 'build-stage' and that a DB connection is handed over to some generator/updater. say more, I'm not sure I follow you entirely. As I mentioned above, I think I would like to have an 'active query instance' instead of a 'passive read of file' as the metadata gathering. Stephen and I was actually considering making a servlet generate the metadata out of Magic's project model on a http request basis, and have the Gump module to point there, but it seemed like more maintainance overhead than it is worth. I think a better way would be that I can specify a script to execute for each module, before the projects are read from the XML. The discussion actually led to an additional observation; * Why does Gump build periodically ? Shouldn't a project only be scheduled to build when there is a change, where change is either source change, depenency build or meta data change. Another 'fantasy' we have been toying with is that taking the above paragraph, and saying Gump is a build engine, now let us make it into a distributed build farm. What I have in mind is that it would be possible to let anyone be part of the entire Gump exercise in exchange for providing build power. Imagine that you had a few hundred servers attached to the Gump Federation, and whenever there is a change, the build jobs resulting from the dependency graph is distributed and scheduled on these servers. Large projects can potentially be built quickly. These are very random thoughts on the subject, but they are fun... :o) Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FYI] gadget dumps of the gump metadata
part of my day job is to deal with tons crappy XML, described by some even crappier XMLSchema/DTD (most often not in synch!) and try to make sense of it enough to transform it into RDF. Since the above pattern can be applied to basically any XML dataset that grew overtime, it applies very well to gump too :-) So, here are the gadget dumps of the gump metadata (gadget is an xml inspector tool that I wrote, for more info see http://simile.mit.edu/gadget/) I'm trying to get the DTDs up to date, but this might help others figuring out what gump deals with. NOTE: I definately inclined in transforming everything into RDF and work from there... RDF is sooo much nicer (and easy to use if we use N3 instead of that stupid RDF/XML syntax) than this crappy XML markup we have. Anyway, enjoy. -- Stefano. repository/ @compress/ 2 1 50% @name/ 38 38 100% @type/ 38 2 5% cvsweb/36 25 69% home-page/ 38 34 89% root/ hostname/ 29 19 65% method/ 29 1 3% password/ 22 5 22% path/ 29 12 41% user/ 29 5 17% title/ 38 36 94% url/9 9 100% web/1 1 100% module/ @fullname/ 3 3 100% @name/209 208 99% @tag/ 5 5 100% @verbose/ 1 1 100% credits/ credit/ 1 1 100% cvs/ @dir/ 45 41 91% @host-prefix/ 2 2 100% @module/ 37 35 94% @repository/ 147 23 15% @tag/ 5 5 100% description/ 204 182 89% detailed/ 2 2 100% licence/1 1 100% @legal/ 1 1 100% @name/ 1 1 100% nag/ @from/ 1 1 100% @to/1 1 100% note/ 1 1 100% package/3 3 100% project/ @debug/ 1 1 100% @fullname/ 19 16 84% @language/ 1 1 100% @name/655 614 93% ant/ @basedir/ 363 310 85% @buildfile/66 21 31% @debug/ 3 1 33% @target/ 323 59 18% @vm/ 15 1 6% depend/ @id/ 159 30 18% @name/ 16 13 81% @project/ 855 90 10% @property/ 837 142 16% @reference/ 2 1 50% @runtime/ 30 1 3% jvmarg/ @value/ 1 1 100% mkdir/ @dir/18 6 33% property/ 1 1 100% @id/ 15 7 46% @name/ 909 143 15% @path/86 28 32% @project/284 43 15% @reference/ 267 4 1% @value/ 556 102 18% sysproperty/ @name/ 21 2 9% @value/21 2 9% barcode/ @fix/ 1 1 100% @major/ 1 1 100% @minor/ 1 1 100% @tag/ 1 1 100% code/ @dir/ 2 2 100% @type/ 2 2 100% delete/ @dir/3 2 66% deliver/ @fromdir/ 3 2 66% @todir/ 3 1 33% @tosite/3 1 33% depend/ @id/46 17 36% @ids/8 8 100% @inherit/ 579 4 0% @project/ 4166 396 9% @property/ 30 20 66% @runtime/
