Re: Draft Message to PMCs
Stefan, It seems to me that the first data point to gather is if there is general interest in Gump as an ongoing service. If not we have our answer. If yes, then we need to figure out how to resource it if the level of interest extends to maintaining bits of it. As for your letter, I like it. Perhaps add a paragraph as to why Gump does it's builds? Something like: Apache Gump builds the full stack of the latest commits of software in order to ensure integrity over releases. Build failures surface API discontinuities between projects before they impact releases, and Gump's e-mail notifications promote the conversations between teams to resolve those discontinuities. regards Adam Adam R. B. Jack adam.j...@gmail.com http://neukadye.com On Jun 11, 2013, at 7:57 AM, Stefan Bodewig bode...@apache.org wrote: Hi all, I'd like to reach out to the PMCs that in some way seem to have used Gump - for some of them it is quite possible they haven't added their projects themselves. In a first step I'd like to gauge interest, I'm a bit unsure whether I should point out they'd need to help out if they intend to keep Gump running at this point. The PMCs to contact would be APR ActiveMQ Ant Camel Cocoon Commons Creadur Directory Forrest HTTP Components HTTPd JMeter James Lenya Logging Lucene POI Portals Tapestry Tika Tomcat Turbine Velocity Webservices XML Graphics Xalan Xerces here is a quick draft of what I'd send out: Dear FOO PMC Apache Gump builds some of your projects and it is quite possible you don't know or have by now forgotten about it. More than half a year ago a technical problem has forced us to turn off emails on build failures as we would have been sending out lots of false alarms. Before we re-enable emails we'd like to know whether you are still interested in the service Gump provides, so please tell us. :-) Metadata for many projects have been neglected for a long time and it is quite possible they'd need some love for results to be meaningful. All Apache committers have write access to Gump's metadata. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Where to go with Gump?
Stefan et al, I hesitate to reply since I've not contributed in quite some time (and yes, that is some *significant* British understatement. ;-) As somebody who found them self sucked away from Gump, I want to express my appreciation (and admiration) for all the Gump efforts over the years. There may be no direct uses of Gump but every issue resolved early is a valuable contribution to the full stack of projects hove there, with countless hours saved from fighting incompatibilities, and OSS productivity gains. That said, the fact that the burden of metadata maintenance has been on Gump committers speaks volumes (either to it's usability or it's acceptance.) Perhaps the value that Gump provides (i.e. early warning of backwards compatibility issues) is just too far removed from those working on projects to be anything more than a nagging annoyance. It is a voice for the user of a library, but few seemed to appreciate it as such. Maybe if it only built stacks of pre-release candidates to ensure that releases were compatible (or at least discontinuities were accounted for) it would get more respect. Not sure. I definitely believe that Gump committers alone should NOT do the bulk of the metadata maintenance and issue resolving, however I wonder if it is the type of services that won't be missed until it is gone, and if this discussion should be put to a wider community (once fully discussed here.) regards, Adam Adam R. B. Jack adam.j...@gmail.com http://neukadye.com On May 20, 2013, at 4:27 AM, Stefan Bodewig bode...@apache.org wrote: On 2013-05-19, Sander Temme wrote: Yes, this makes it seem that we are performing a thankless task. Perhaps the right question to ask is who here at the Gump PMC is using its facilities to good effect, since we constitute the minimum viable community to keep it going. It's not easy for me to admit that, but currently I mainly look after Gump because it's there. At one point in time I took every non-trivial build failure as a reason to contact the involved parties but have been worn out by now. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Tomcat SVN migration
I've changed the metadata so that the jakarta-tomcat and jakarta-tomcat-4.0 modules are now looking in the SVN repository. I need somebody to wipe out the old working copies on vmgump so that the update won't fail. Thanks for making the update Bill. [EMAIL PROTECTED]:/usr/local/gump/public/workspace/cvs$ rm -rf jakarta-tomcat jakarta-tomcat-4.0/ I'll do similarly in the JDK1.5 tree. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat SVN migration
On Sun, 18 Sep 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote: I'll do similarly in the JDK1.5 tree. We have one? Wishful thinking and me being out of the loop too long. ;-) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: latest gump fails: Indentation error
File /udd001/hoops/gump/python/gump/core/build/maven.py, line 191 except Exception, details: ^ IndentationError: unindent does not match any outer indentation level Process Exit Code : 1 -- Gump Version: 2.0.2-alpha-0003 Anyone know what this error means? Python is an indentation based language (rather than using curly braces.) It means I ought probably give up on trying to write Python in Eclipse w/ a plug-in and use Wing IDE. [I was trying to keep a visibly separate environment between Gump2 and Gump3, but it isn't worth it any longer.] Not sure how this got past my test, but that is another story (I likely over rushed it, as usual.) Give it another shot now, I see Leo has fixed it. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: svn commit: r216136 - /gump/metadata/project/xml-batik.xml
Any ideas why we are getting an unknown Author? Author: (unknown) regards Adam - Original Message - From: [EMAIL PROTECTED] To: commits@gump.apache.org Sent: Wednesday, July 13, 2005 4:45 AM Subject: svn commit: r216136 - /gump/metadata/project/xml-batik.xml Author: (unknown) Date: Wed Jul 13 03:45:51 2005 New Revision: 216136 URL: http://svn.apache.org/viewcvs?rev=216136view=rev Log: Try upgrading xml-apis Modified: gump/metadata/project/xml-batik.xml Modified: gump/metadata/project/xml-batik.xml URL: http://svn.apache.org/viewcvs/gump/metadata/project/xml-batik.xml?rev=216136r1=216135r2=216136view=diff == --- gump/metadata/project/xml-batik.xml (original) +++ gump/metadata/project/xml-batik.xml Wed Jul 13 03:45:51 2005 @@ -31,8 +31,7 @@ /ant depend project=dist-ant inherit=runtime/ -depend project=jaxp ids=sax jaxp-api/ -depend project=xml-apis-12/ +depend project=xml-apis/ depend project=xml-xerces/ depend project=rhino/ depend project=xml-stylebook2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
No. Gump2 does not set the process group id. Gump3 calls setpgrp (man setpgrp :-)). Note there isn't a whole lot of software out there that make setpgrp calls... Yes Leo, it does. Recall I implemented a scheme right before you got input on how to do it (we even discussed if my approach would work, or not. :-) The code is messy (for historical reasons, and 'cos it was tryign to do sometihng on M$) but it is here. https://svn.apache.org/repos/asf/gump/trunk/python/gump/util/process/launcher.py BTW: A month or so ago I notice Gump2 hanging, when I ran it from command line, and it seemed to improve if I passed it /dev/null. I kinda figured something had changed in Ant, or in one of the Ant scripts, that was blocking on input. That said, I never tracked anything down I don't know if it is still happening. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oucchhh!!!
I let a SPAM thorugh the moderation... So, sorry! Any we need to do about it ?? Funny, I haven't seen it on list. Maybe Stefan or I moderated it out first. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 is slowly becoming useful
Yay! :-) This is awesome! Having some 'live' data is exactly what we need to make this move forward fast. Thank you. You have *no* idea how hard that was (well, actually, I guess at least adam does :-)). Actually, I suspect we all have an idea about how much it takes, and all you've put in. Along those lines ... I feel we all appreciate how ASF you've handled this project. You really have set the example for how to work openly, with a full archive of history. I feel I've learned a lot from your approach and your efforts here, and I know we'll all look back with gratitude at how you've kicked off this effort. I'm proud to be associated with Gump/Gump3, and I know this is great for the Gump Community. Thank you. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-test (in module jakarta-commons-sandbox) failed
Seem like this information failed to get into the projects error information. It will after I fix the message. Next I need to figure out if this is as simple as ensuring the directory gets made automatically, or if we add a mkdir to the metadata. I lean towards automatically creating directories, if referenced in any Gump metadata, and (if I had my way) eventually getting rid of mkdir. Build Project: #[(333, 839)] : commons-test : [state:Unset] Generate Maven Properties Failed Traceback (most recent call last): File /x1/gump/public/gump/python/gump/core/build/maven.py, line 181, in performPreBuild propertiesFile=self.generateMavenProperties(project,languageHelper) File /x1/gump/public/gump/python/gump/core/build/maven.py, line 212, in generateMavenProperties props=open(propertiesFile,'w') IOError: [Errno 2] No such file or directory: '/usr/local/gump/public/workspace/jakarta-commons-sandbox/test/build.propert ies' regards Adam - Original Message - From: Gump Integration Service general@gump.apache.org To: general@gump.apache.org Sent: Sunday, July 10, 2005 2:57 AM Subject: [EMAIL PROTECTED]: Project commons-test (in module jakarta-commons-sandbox) 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 the folk at [EMAIL PROTECTED] Project commons-test has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Pre-Build Failed'. For reference only, the following projects are affected by this: - apache-ldapber-provider : Apache Directory Project - apacheds-core : Apache Directory Server - apacheds-main : Apache Directory Server - asn1-ber : Apache ASN.1 Tools - commons-test : Commons Test Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-test-10072005.jar] identifier set to project name -INFO- Failed with reason pre-build failed -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-test/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 4910072005, vmgump.apache.org:vmgump-public:4910072005 Gump E-mail Identifier (unique within run) #15. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange gump warning for ./configure
The following annotations (debug/informational/warning/error messages) were provided: -ERROR- Unhandled Property: --enable-libxml2 on: Configure on Project:monaco-xml-configure It seems that gump is not happy with the --enable-libxml2 option to configure, although it does work. Reading your use case and this: http://gump.apache.org/metadata/builder.html#property%2Farg it sure seems like a bug in Gump. We were trying to help out folks who had (say) mistakenly typo'd the attribute name ended up disallowing an optional/missing field. See if the change I just commit fixes it. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynagumper is alive!
so I figured we'd need to get Thomas some more data. Rather than invent it by hand, I figured I'd fix up the dynagumper plugin to work properly. See Cool, that is what I've been trying to do with Gump3 on VmGump: Oh, and you're now greeted with 100s of lines of error messages if you don't have a db connection or a messed up database :-). Like this? ;-) http://vmgump.apache.org/gump/gump3/run.log Adam, perhaps you could take a pass through the code and point your finger at stuff that's messed up or which doesn't make sense? Also, one todo that'd be nice to have when building dynagump is to actually have long logs stored in the DB. I know you've spent a lot of time on the builder plugins. For some reason no build_log properties are being set. Could you try and get that running? Sure. In return, could you look into the problem above seeking to understand why these failures cause Gump to fall off IRC, not exit? Are certain plugins not getting called when another fails? I'm never quite sure how Gump3 copes with errors. BTW: Can we fix the schema, or do we need to re-instantiate it? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration of metadata
I'm halfway torn between throwing history away and simply importing CVS HEAD manually and doing a trunk-only conversion. Well, not really true, I'd probably prefer keeping the history, but could live without it. What's your preference? +1 for keep the history. The second question is, where should our metadata end up in SVN? Probably in http://svn.apache.org/repos/asf/gump/metadata/trunk - I envision metadata branches for Gump3 later, so I'd be against a flat structure like site currently has. +1 in theory, 'cos looking at our SVN tree we do seem to use /gump/X/trunk when we have a sub-project X, but see below. Since today folks (1) checkout Gump from SVN and (2) checkout metadata from CVS into ./metadata, I don't see a hardship of having two places. That said, will SVN allow us to do this w/o pain? Can we have an empty /repos/asf/gump/trunk/metadata become a local working directory, and then checkout /repos/asf/gump/metadata/trunk into it? I suspect not. I think we got away with it because we were using two separate SCMs. Something will have to give, I'm just not sure what, i.e. (1) no empty ./metadata w/ a FILLME.txt (2) ../metadata not ./metadata (3) not separate SVN trees. Thoughts? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting gump to send email
What in addition to this do I need to configure to get gump to send emails? I'd add a nag/ to the workspace to get success/failure e-mails, and run with --official (to get the nightly reminders.) http://gump.apache.org/metadata/workspace.html#nag I'd also add an administrator to the workspace, to get overall success/failure messages. workspace ... administrator=general@gump.apache.org regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting gump to send email
Unable to mail failure report : [u'192.168.1.24', 25, '', u'[EMAIL PROTECTED]'] This needs a better error message, please add a JIRA entry. This is 'cos there was no 'administrator' setting in the workspace (hence the empty third entry, the 'to'.) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump presentation SoC
Thomas, Adam you talked about implementing it with python, it will take me a lot of time since i haven't used python before so I rather do it in Java. But if you whant it in python fine I'll take the time and sit to to learn python. Final result will take abit longer with python thats all. I mentioned that Leo was looking at a mod_python implementation, and liking what he saw. I was just floating the idea, to see how interested you are. Basically, we want this project to succeed, but success in OSS comes in many colours. ;) What we mean is that sometimes learning something new, and making an ok attempt at it is better for the community than doing something perfect, yet rote. (Some folks say the best OSS project is the great idea w/ the poor implementation, 'cos it attracts more community.) Would a mod_python plug-in be more fun? Maybe, that depends upon your interests. Would it have more bugs? Certainly, the framework is much younger. Which would be better for the Gump community, or ASF community, or you? Who knows, only time would tell. Sorry, I guess we are seeing that I'm going to be one of those mentors that poses more questions than answers. ;-) That all said, I'm really not pushing either approach. The Java appoach is good, and since it is easier (on you), it might dig deeper into how we can extract data from the Gump results. Basically, I'm (1) open to ideas from other Gumpers (2) willing to let you pick what you are most comfortable with. Finally, don't feel pressure on this ... we aren't looking for some fixed result, some perfectly polished webapp, we are all looking to learn from this endeavour see where it leads us all. BTW: (all) I've also mentioned that Cocoon was likely not our favoured approach, since we don't have cycles to help you with it. The choice of language allso depends on what server we have. We have access to a number, and folks run Gump on whatever servers they like. What do you have locally to work on? Me, I use W2K others use Linux or Mac, etc. So whats next? I think I need a push in the back to get started so just hit me and we'r off. What exactly do I need to get started, do i need svn or can I get the code through cvs? I have never used svn before so a short introduction would be nice. ASF is migrating from CVS to SVN. Some Gump metadata remains in CVS, but won't for much longer. As such, please learn/use SVN. Using the client against ASF code (to get a local copy you can't commit back) is easy [V1]. To learn more about SVN, should you need/want, try [V2]. The Gump3 code is here [V3]. [V1]http://www.apache.org/dev/version-control.html [V2]http://svnbook.red-bean.com/ [V3]http://svn.apache.org/repos/asf/gump/branches/Gump3/ how much of the Gump code do I need to know to do my task, Is it enough to know what the database contains or do I need to integrate with the rest of the program. Is the presentation a standalone webapplication? If that is the case then I should only need to focus on the databasecontent and the mening of it. As it is now I don't realy know what you whant me to do and from reading some oldposts from the mailing list you don't realy know either. We'd like you to focus on the database content, not how it gets populated, because one of the main thrusts behind Gump3 is to leverage the DB separation. Gump2 produce static HTML as it runs, and hence during a run (for many hours) the output is inconsistent (part last run, part this run.) We want to be able to query the data at any time, getting consistent results. There will be different use cases for the data, and although we can't predict them all, we can some. Some folks just want to know why their project broke, to fix it. Some will want to know about projects stability (over time) so do some historical data mining. Some will want to know about interactions between projects, who uses my project, etc. We might want to list these use cases plan for them. We will be improving the database schema with feedback from you, as you show us what is possible with what is there. What is there is pretty simple, but the main 'players' are in the database, so you can list projects, dependencies, and so forth. There is plenty to get started with. I'm sure you'll learn some of how Gump3 works from running it, and you'll want to run it locally so it produces a local DB of data for you to work on. You'll want Apache HTTPD v2 [R2], I'm sure. Getting things started will take a little time in itself, so do start that. [R1]http://wiki.apache.org/gump/GumpThree [R2] http://httpd.apache.org/ Please look at the static HTML pages that Gump2 generates [H1], specifically the statistics [H2] and [H3] cross reference pages and collect your thoughts on how a dynamic approach (data mining verse data overload) would be better. Having smaller/tighter pages (not pages stuffed w/ extra info) is the first win. Being able to calculate (query) a lot of the stats/cross-references is another win.
Re: GSoC Gump-related project breakdown
Stefano, I would like to know who is working on what, who is the mentor and what their plans are. When I sent the list of the two to the Gump PMC list, I failed to recall that the URLs were protected. You e-mail is a timely reminder to 'speak' to those who got accepted, and those who did not. Apache recieved over 700 applicants for eventually 38 projects (a number we did not know until a day before deadline day) so unfortunately there were was a lot of disappointment, for ASFers included. To those of you who applied for a Gump project, but failed to be accepted, please accept our thanks for your interest our shared disappointment in not being able to proceed. The reasons for acceptance/rejection were many, and varied, although one prime motivator was how 'interesting' the project was to the ASF community as a whole, not individual projects/mentors, etc. As such, if your project was not accepted, please don't read too much into it. With OSS one needs one's own sense of purpose and some thick skin. Please utilize it now. The two accepted for Gump (see [1]) are: Project: gump-and-maven Title Make gump 3 bootstrap and integrate maven and maven 2 Mentor: Scott Sanders Participant: Justin Merz Project: gump-presentation Title Provide a web interface to the gump 3 database Mentor: Adam Jack Participant: Thomas Hedin For both, plans are still developing... No applications were accepted for: Project: gump-doap Title Make gump 3 integrate Description of a Project (DOAP) Mentor: Adam Jack regards, Adam [1] http://wiki.apache.org/general/SummerOfCode2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remoting
Mind filing this via JIRA, so we don't forget it [like I have]? regards, Adam - Original Message - From: Bill Barker [EMAIL PROTECTED] To: general@gump.apache.org Sent: Tuesday, June 28, 2005 8:14 PM Subject: JMX Remoting Tomcat now requires JMX Remoting to build. I've changed the descriptor to use the version from mx4j. However, I'd really rather use the RI in Gump (it uses the RI for all of the other JMX stuff), but that would require some nice person to download it and set it up as an installed package. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
GNU make ( was Re: gump.zones.apache.org )
Bill, you asked about GNU make on Solaris. According to [1] it is called 'gmake', and (FWIIW) gmake happens to be on the path. Anybody have thoughts on if we ought (1) always use gmake not make on solaris, (2) make it configurable somehow (2) do a hack on this box? Preferences? regards Adam [1] http://www.ibiblio.org/pub/packages/solaris/sparc/html/GNUmake.3.78.1.html - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Apache Gump general@gump.apache.org Sent: Thursday, June 30, 2005 3:18 PM Subject: Re: gump.zones.apache.org With a little more help from Leo, and some from folks at #asfinfra, we have cron running Gump2 on the Gump Solaris zone. There was a need for more fixes to the gump.sh, and some more stuff to the $path, but it is running. [FWIIW: sendmail on that machine is hosed/dorked, but we may not need it/care, since Gump2 uses SMTP to mail.apache.org we aren't sending mail anyway.] Anyway, this ought get updated daily now (or more if we want to chew more shared cycles.): http://gump.zones.apache.org/gump/test/buildLog.html regards, Adam - Original Message - From: Adam Jack [EMAIL PROTECTED] To: Apache Gump general@gump.apache.org Sent: Friday, June 24, 2005 9:43 AM Subject: gump.zones.apache.org Folks, Somebody (not me) seems to have most/all of a test Gump install on our solaris zone. Thanks!!! I simply (after some poking around) had to re-create /var/run/apache2 and start the HTTPD, and we get these pages. I've just kicked off a test run. http://gump.zones.apache.org/gump/test/buildLog.html and we are already getting out update failures. ;-) http://gump.zones.apache.org/gump/test/jakarta-velocity/index.html BTW: Having read this, I still need to figure out how to get the RC scripts for HTTPD installed. Pointers appreciated. http://www.apache.org/dev/solaris-zones.html regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump3 Presentation -- choice of technology
Thomas et al, We need to pick a technology to use to display the contents of a database via a webapp. We are in the fortunate position of having more technologies available to use than we could wave a stick at. Clearly we could do the job with all of them. Let's explore them and come to a mechanism for you to decide which you want to use. I won't determine how you evaluate the 'best' choice, that will be your choice. At the end of the day much of OSS comes down to scratch what itches which is often translated to you do what you want, how you want, when you want 'cos nobody is paying you/tellign you what to do. I know this Google SoC case is slightly different, but the effective is there. Some *personal* thoughts that might factor into things are (1) which would you find the most fun (2) which would you learn the most doing (3) which would you benefit the most from learnng (4) which would you think you'd like to use again after this project. Added to that (1) which is the best fit to the requirements (2) which is the best fit to the community (Gump/ASF) (3) which is most likely to be maintained when you stop working on it [there is life after any committer] (4) what is the best fit for users (least resistence to install/use.) Again, we aren't trying to to be too academic -- we do want deliverable results -- but much at ASF (and especially Gump) is about the long haul, with the focus being on the community to support the code, not the code alone. To my knowledge here are the best known candiates (plus some others I've heard discussed.) - Java JSP/Struts. - Cocoon (Stefano has spent significant time on this, he feels it is worth evaluating.) - mod_python (Leo has spent some time on this, he feels it is worth evaluating.) - PHP (why not?) Clearly each of these (and there are plenty others) have strengths/weaknesses, and I don't profess to know them all. To help you make some determinations, here are some known requirements/thoughts for your project. - Gump3 presentation is simply about getting the data from the database onto the screen. That said, there are lofty goals for it (and Stefano has great insights here) that might lead to charting and/or graphics/graphs. Visualizing data isn't about dumping tables to the screen, but allowing a humans to easily navigate an interpret. (Do yourself a favour and search the archives for things marked [RT] in the subject). So, I suspect the technology will want good visualization support. - I could see the Gump3 webapp becoming a first point of contact w/ users, so I could see it becoming much more than presenation. For example it might need to go get output files for folks (for folks who don't have disk space to store these in the DB.) Heck, it might become a front end for folks to schedule runs/builds and/or kick of metadata parse checks. So, I suspect the technology needs to be easily integrated. - I could see this output of the webapp being data to reference (real-time and historically) with URLs having a permanance to them. I could see us generating RSS/Atom feeds from the webapp. I could see projects referencing their Gump Info on their home page, and/or behind a logo. As such, I think the technology needs full control over it's URL space. That all said, I know this is needs to be focused project, with fixed time allocated to it. As such, these last two thoughts are probably overkill. Getting the data presented to the users is the only (first) goal. Folks, please feel free to chip in your comments/reservations and perspectives on all of these to help Thomas decide. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spikesource, Gump3 Presentation
They have a web interface to the current build state here: http://spikesource.com/spikewatch/ Just thought people might be interested... To me, it looks pretty laughable compared to gump... what am I missing? Perhaps the charts and/or historical data? Some seems to be there just because the could, not sure why you'd care (e.g. individual committer activity), but they are worth a look. That said, thy seem to by Gump2-like -- i.e. static pages w/ lots of information and not the focused queries we'd like. Maybe they need to do that for some of the more complex calculations though, for resource reasons. Thanks for the link Simon. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 and IRC
bash gump run [EMAIL PROTECTED]/#asfgump Ok, that needs quoting, i.e. --irc='[EMAIL PROTECTED]/#asfgump' which is what I just added to gump3 on VmGump. If we find it too chatty we could move it to #asfgumprun or something like that. Which remind me. Folks who want to, ought add this to their channels list. irc://irc.freenode.net/#asfgump It would be good to get a few more folks in there more often. The plugin uses: http://sourceforge.net/projects/irclib/ Nope, the correct URL is: http://sourceforge.net/projects/python-irclib for which I did 'python setup.py install' and 'python2.4 setup.py install' on vmgump. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google SoC
Justin, welcome! It's a pleasure to have you on board. Yup, welcome congratulations. :-) I would suggest you to start from Gump 3, which is a little cleaner and less complex and has a more modular architecture. What do others think? Gump2 has an integration with Maven, albeit at the runtime interface (Gump2 can launch Maven) but not the metadata level, i.e. the Maven project descriptor. This means that Gump2 processes it's own (Gump) metadata format [1] to understand how interact with Maven, and not Maven's native version [2], which contain the same information. This duplication makes it harder for Maven projects to exist in Gump, even though a tool exists [4] that maps the formats. The truism if data exists in two places one of them is wrong holds, and often the Gump metadata is out of date/wrong. We are looking for Gump3 to consume a Maven project descriptors [2] directly. Also, one thing we wish to resolve is [3]. As such, the Gump3 code is in SVN, at [5], although we'll figure out a better way for you to access it. Justin, please collect your thoughts on all this while we get the logistics sorted out send you details. Feel free to post ideas/questions here -- and/or update your own page on the Gump wiki (see [3]). First though, you ought read [6] and [7] and get your ASF CLA [8] sorted ASAP. Please get to this ASAP, so the CLA doesn't become a bottleneck. regards, Adam [1]http://gump.apache.org/metadata/index.html [2] http://www.jajakarta.org/turbine/en/turbine/maven/reference/project-descriptor.html [3]http://wiki.apache.org/gump/MavenId [4]http://maven.apache.org/reference/plugins/gump/ [5]http://svn.apache.org/repos/asf/gump/branches/Gump3/ [6]http://www.apache.org/foundation/how-it-works.html [7]http://www.apache.org/dev/ [8]http://www.apache.org/licenses/#clas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 and IRC
Adam Jack wrote: I've been tinkering with an IRC plug-in for Gump3 that allows it to interact with an IRC channel. Whoah! Cool! Is this up and working on any of our servers atm? Can we fix up a cronjob somewhere to enable this? I'm not able to get my SSH tunnel to work right now (since the upgrade perhaps?), so mail access will be hampered. I'm on IRC if you want me through. ;-) If VmGump were up we ought be able to add [EMAIL PROTECTED]/#asfgump to there. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Does anyone ever do anything with the content of these messages? Yes, I look for module failures and even worse for module success but with warnings. The later usually means stuff has been moved in svn, we are now unable to check it out, but Gump doesn't consider it a failure. Want this to go away now that SF.net have their CVS act together we are doing a lot of SVN migrations? As I know you'll recall, this was due to cvs updates from SF.net working/failing/working/failing ... and with junit at that repository a failure was causing huge parts of the tree not to be built. If currently says if I have a copy and an update fails I'll simple warn it is stale not set it as failed. Want this to be fail is fail -- or configurable on the module/repository? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r201624 - in /gump/trunk/python/gump/core/update: cvs.py p4.py svn.py
The commit itself made me itch to spend more time on Python, the exact same code-change in three different files. Yeah, bad copy-n-paste on my part (ok, 1 of the 2 copies). The more I look at Gump2 these days, the more I feel I need to spend time on Gump3 see if I can do Python right these days. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
I also use it as you use it, a sanity check that it ran (and these days -- on vmgump -- didn't stall.) That said, I also often eyeball it for candidates that I can go bug. When Gump is stable, sending notifications as needed, it annoys me if ASF projects don't accept notification. I also go and (politely) as other projects if they'll accept notification. That, I could do that w/ or w/o this e-mail. The other one like this (i.e. failed to send, not nowhere to send) is more interesting, e.g. when the host (vmgump) isn't allowed to relay: http://issues.apache.org/jira/browse/INFRA-365 regards, Adam - Original Message - From: Leo Simons [EMAIL PROTECTED] To: Gump code and data general@gump.apache.org Sent: Thursday, June 23, 2005 1:26 PM Subject: Re: BATCH: All dressed up, with nowhere to go... Hi gang, Does anyone ever do anything with the content of these messages? I tend to use them as a gauge of gump ran and it sent e-mail, but as the actual content I would much rather have something like a list of failures/successes, i.e. a condensed version of log.html. Do you agree? Just planning for the future here... Cheers, LSD On 23-06-2005 12:57, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 7 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. [EMAIL PROTECTED]: Project nant (in module nant) failed [EMAIL PROTECTED]: Module jaxen success, but with warnings. [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. [EMAIL PROTECTED]: Project httpunit (in module httpunit) failed [EMAIL PROTECTED]: Project derby-split-2 (in module db-derby) failed [EMAIL PROTECTED]: Project jaxen (in module jaxen) failed *** G U M P [EMAIL PROTECTED]: Module castor 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 the folk at [EMAIL PROTECTED] Module castor contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/castor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/castor/gump_work/update_castor.html Work Name: update_castor (Type: Update) Work ended in a state of : Failed Elapsed: 11 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:/scm/castor update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/castor] - cvs server: failed to create lock directory for `/scm/castor/castor/lib/tests' (/home/projects/castor/haus.d/lock/cvs/castor/lib/tests/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/scm/castor/castor/lib/tests' cvs [server aborted]: read lock failed - giving up - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/castor/rss.xml - Atom: http://vmgump.apache.org/gump/public/castor/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2323062005, vmgump.apache.org:vmgump-public:2323062005 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project nant (in module nant) 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 the folk at [EMAIL PROTECTED] Project nant has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - nant : NAnt is a free .NET build tool. In theory it is kind of like... Full details are available at: http://vmgump.apache.org/gump/public/nant/nant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/nant/nant/gump_work/build_nant_nant.html Work Name: build_nant_nant (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs
Re: Killed Gump, removed locks
Did this stabilize since I set the number of background updaters to 0? If so, we could think about trying 5 (which is what Brutus had). Or, ought we just leave well alone for now? regards Adam - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: general@gump.apache.org Sent: Monday, June 20, 2005 8:46 AM Subject: Re: Killed Gump, removed locks On Mon, 20 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote: Sorry, can you be more explicit? What sort of locks? gump.lock was present, and belonged to the Gump instance from Sunday noon. Inside of workspace/cvs there have been ten .lock files all dated between 0 and 1am Sunday morning. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killed Gump, removed locks
Sorry, can you be more explicit? What sort of locks? BTW: We can limit the number of background threads (to none, if needed) for updates by editing the workspace definition. regards Adam - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: general@gump.apache.org Sent: Monday, June 20, 2005 1:00 AM Subject: Killed Gump, removed locks Hi all, logfiles are in ~gump/20050619. This time it looks as if the midnight run Sunday morning died during updates or syncs and didn't clean up after itself. The noon run then made it into the updates and starved because of the locks left over from midnight. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (GUMP-138) Modules dropped (due to missing Repository) causes a crash.
Actually, the workspace is in Gump3/metadata (not Gump3/fixture/metadata). Once SVN is back up I'll commit my improved fix. Where is the correct place for the workspace? I'd like to get VmGump building it, and us growing it (with properties, etc.) on an as needed basis. I'm game to either build the metadata from scratch [project by project], or try to use some or all of what you have built already. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-bsf.xml jakarta-ecs.xml jakarta-hivemind.xml
This will require us to remove the checked out source trees. I'll do so once the current run has come past the three directories. I had to manually kill a bunch of processes and remove lock files since the 6pm run didn't kill all childs, or so it seemed. There have been five lock files and about 10 python processes I had to remove in order to get the 0am Gump run unstuck. Lock files? As in SVN lock, or Gump lock??? I tell ya, this area is bugging me right now. I swear we seemed stable on Brutus, which was also SMP, right? Any thoughts from folks as to what is going on? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: test ( was Re: [Gump Wiki] Update of VmgumpConfig by AdamJack )
Insufficient disk space. Removed 'TEST' (the transient data) for now. [EMAIL PROTECTED]:/usr/local/gump/test$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 135468 56853 71388 45% / tmpfs 1034864 4 1034860 1% /dev/shm /dev/sda7 369000 8604340736 3% /tmp /dev/sda5 4807056683168 3879704 15% /usr /dev/sda6 2885780596388 2142804 22% /var /dev/sda9 21520948 20177800249928 99% /x1 [EMAIL PROTECTED]:/usr/local/gump/test$ rm -rf jars/ results/ workspace/ [EMAIL PROTECTED]:/usr/local/gump/test$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 135468 56853 71388 45% / tmpfs 1034864 4 1034860 1% /dev/shm /dev/sda7 369000 8604340736 3% /tmp /dev/sda5 4807056683168 3879704 15% /usr /dev/sda6 2885780596924 2142268 22% /var /dev/sda9 21520948 11041700 9386028 55% /x1 Gone fishing^H^H^H^H^H^Hcamping... regards Adam - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Apache Gump general@gump.apache.org Sent: Wednesday, June 08, 2005 2:41 PM Subject: test ( was Re: [Gump Wiki] Update of VmgumpConfig by AdamJack ) + test -- against SVN /trunk, manual runs. Often cleaned out to save disk space. I added test to vmgump, against /trunk, so I could test out the circular dependency detection code -- against the live metadata -- prior to releasing it. This will push our disk space usage close to the max, so (1) I'm not running it from cron (2) I'll clean-up after any run. Please feel free to do anything you like to this flavour, should more resources become required. Once the run completes (if disk space allows) the output will be here: http://vmgump.apache.org/gump/test/ regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump runs stopped?
On Mon, 6 Jun 2005, Bill Barker [EMAIL PROTECTED] wrote: According to http://vmgump.apache.org/gump/public/index.html, Gump hasn't run since Midnite last Friday. Is is down for a reason? There was a hanging Gump instance from June 5th, I've killed that and asserted that no lock files have been kept. I hope it is going to come back to live soon. Me too. I can't think of a good reason why it ought hang, and I couldn't find a cause when I last saw a hang (just before). I fear this might be happening every time. Amazing how the move from Brutus to VmGump has been so 'uncomfortable'. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump runs stopped?
Me too. I can't think of a good reason why it ought hang, and I couldn't find a cause when I last saw a hang (just before). I fear this might be happening every time. Ok, the what-is-becoming usual, i.e. circular dependency in the metadata (dom4j/jaxen, I believe). Clearly given the complexities of project interactions (and circular dependencies in the real OSS world, not just Gump metadata) this is something Gump needs to handle a lot nicer. I've promoted my checks for that (and tested/fixed them for this case) and hope we stay a little healthier w.r.t metadata errors. Gump3 is a little cleaner w.r.t these issues, but since it is nowhere near ready for prime time, that is somewhat moot. That, and we really need a simply tool for validating metadata, so we don't have to debug/guess when Gump runs fail. Anyway, there is a new run going, hopefully it'll keep going this week (as I head off for a long weekend camping at the Great Sand Dunes, Colorado's beach.) regards, Adam P.S. This (clearly) was nothing to do with the VmGump move, it is just coincidental timing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump runs stopped?
. Adam, could you give some pointers (filenames and linenumbers) where you think the insertion point for a cyclic dependency checker should be in gump3? I think Gump3 has some such code in there already. What I think is missing is an (equally supported) use case of check metadata that is as well used/supported as build or update and build. Basically we need a code path (and/or algorithm/set of plugins) that verifies the metadata (perhaps) notifies and/or 'documents' (to DB?). The main reason I added --do-builds (to match --do-updates) -- so when neither is specified it does a verify. I was to use what is there for this purpose. Trouble is, that fails to publish this information to the masses. It'll do for now, but it needs a re-think. Gump2 fell down here 'cos it tried to objectify all the metadata, and then annotate it with errors (e.g. circular dependency here.) This meant the object tree was untrustworthy, containing bogus references/object, hence the crashes and hacks. Gump3's approach to drop bad things makes the tree trustworthy, but lacking in this bad information, so Gump3 can't use it's plug-ins to publish. In short, no quick fix comes to me. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump runs stopped?
Gak, damn. Bad to worse. Working on it... Adam - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: general@gump.apache.org Sent: Tuesday, June 07, 2005 2:57 PM Subject: Re: Gump runs stopped? On Tue, 7 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote: In short, no quick fix comes to me. Could you please revert your last commit? It has created tons of false nag mails because Gump now thinks there'd be circular dependencies where none are there. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r189466 - in /gump/live: python/gump/actor/document/xdocs/ python/gump/actor/mysql/ python/gump/actor/notify/ python/gump/actor/syndication/ python/gump/core/build/ python/gump/core/model/ python/gump/core/run/ python/gump/core/runner/ pyth
Ok, I believe I have rolled back the last update of LIVE from TRUNK. I
didn't remove the work from TRUNK 'cos I'd like to test it/fix it. Please
let me know if you see anything wrong w/ these SVN steps. (I did a merge w/
last but one release, then re-commit.)
BTW: Gump nagging is off for a short while on vmgump until we can be certain
no more embarrassments like that. Since I'll not be around after tomorrow,
that'll be until next week, or whenever somebody else decides. [I changed
nag to nonag in the workspace.]
regards,
Adam
- Original Message -
From: [EMAIL PROTECTED]
To: commits@gump.apache.org
Sent: Tuesday, June 07, 2005 4:44 PM
Subject: svn commit: r189466 - in /gump/live:
python/gump/actor/document/xdocs/ python/gump/actor/mysql/
python/gump/actor/notify/ python/gump/actor/syndication/
python/gump/core/build/ python/gump/core/model/ python/gump/core/run/
python/gump/core/runner/ python/gump/test/resources/full1/ python/gump/util/
src/documentation/ src/documentation/content/xdocs/
Author: ajack
Date: Tue Jun 7 15:44:55 2005
New Revision: 189466
URL: http://svn.apache.org/viewcvs?rev=189466view=rev
Log:
Reverted the premature (read: broken) changes that the last
update of LIVE from TRUNK moved in, primarily the 'circular
dependencies' check.
Removed:
gump/live/python/gump/test/resources/full1/module6.xml
gump/live/python/gump/test/resources/full1/module7.xml
Modified:
gump/live/python/gump/actor/document/xdocs/documenter.py
gump/live/python/gump/actor/mysql/dynagumper.py
gump/live/python/gump/actor/notify/notifier.py
gump/live/python/gump/actor/syndication/syndicator.py
gump/live/python/gump/core/build/builder.py
gump/live/python/gump/core/model/depend.py
gump/live/python/gump/core/model/project.py
gump/live/python/gump/core/model/workspace.py
gump/live/python/gump/core/run/actor.py
gump/live/python/gump/core/runner/demand.py
gump/live/python/gump/core/runner/runner.py
gump/live/python/gump/test/resources/full1/profile.xml
gump/live/python/gump/util/mysql.py
gump/live/src/documentation/content/xdocs/index.xml
gump/live/src/documentation/skinconf.xml
Modified: gump/live/python/gump/actor/document/xdocs/documenter.py
URL:
http://svn.apache.org/viewcvs/gump/live/python/gump/actor/document/xdocs/documenter.py?rev=189466r1=189465r2=189466view=diff
==
--- gump/live/python/gump/actor/document/xdocs/documenter.py (original)
+++ gump/live/python/gump/actor/document/xdocs/documenter.py Tue Jun 7
15:44:55 2005
@@ -81,7 +81,6 @@
self.syncObject(module)
def processProject(self,project):
-
verbose=self.run.getOptions().isVerbose()
debug=self.run.getOptions().isDebug()
self.documentProject(project,True)
@@ -809,9 +808,6 @@
projectsTable=projectsSection.createTable(['Index','Time','Name','State','Du
ration\nin state','Last Modified','Notes'])
pcount=0
for project in self.gumpSet.getCompletedProjects():
-
-# Hack for bad data.
-if not project.inModule(): continue
#if realTime and \
#(project.getState()==STATE_FAILED or \
@@ -987,9 +983,6 @@
depOrder=createOrderedList(sortedProjectList,compareProjectsByFullDependeeCo
unt)
for project in depOrder:
-# Hack for bad data
-if not project.inModule(): continue
-
if not self.gumpSet.inProjectSequence(project): continue
if not project.getState()==STATE_FAILED:
@@ -1049,9 +1042,6 @@
'Dependees','Project State','Duration\nin state'])
pcount=0
for project in sortedProjectList:
-# Hack for bad data
-if not project.inModule(): continue
-# Filter
if not self.gumpSet.inProjectSequence(project): continue
if not project.getState()==STATE_SUCCESS or \
@@ -1098,9 +1088,6 @@
'Depends','Not-Built Depends','Project
State','Duration\nin state'])
pcount=0
for project in sortedProjectList:
-# Hack for bad data
-if not project.inModule(): continue
-# Filter
if not self.gumpSet.inProjectSequence(project): continue
if not project.getState()==STATE_PREREQ_FAILED:
@@ -1691,10 +1678,6 @@
#endXDoc(x)
def documentProject(self,project,realTime=False):
-
-# Hack for bad data. Gump3 won't let it get this
-# far.
-if not project.inModule(): return
spec=self.resolver.getFileSpec(project)
document=XDocDocument('Project : ' + project.getName(),
Modified: gump/live/python/gump/actor/mysql/dynagumper.py
URL:
http://svn.apache.org/viewcvs/gump/live/python/gump/actor/mysql/dynagumper.py?rev=189466r1=189465r2=189466view=diff
==
---
Re: svn commit: r180173 - in /gump/branches/Gump3
On 06-06-2005 01:22, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 1) added -b --do-builds (defaults to FALSE, like --do-updates, for initial devel) Do you think we should have a stage abstraction or something like that, ie, will there be many more --do-blah-blah? If so, we might want to have this Like you, I expect more, but I figure we let the number get to 3 (semi-arbitrary, just the first real 'N') before we did anything. I do think we need (desperately need, not just want) to be able to quickly parse/validate the metadata and/or display it (before a commit, etc.) [We've experienced a few metadata errors recently, and we ought have helped the users through those.] This is only one example, and as such I think configuring the plug-in selections/algorythms based of user choices (e.g these or --debug) will likely become key. For Gump2 we attempted separate scripts bin/build.py, bin/update.py, bin/check.py and so forth. This was in part to emulate Gump1, in part to allow separate comand lines per 'task'. I don't want to return to this approach, just reminding of it. We probably have too many possible permutations for simple combo-options like run-build. For now, I say keep tinkering w/ options until we know better. 3) Avoid floating point crash when no statistics to display That's a great example of something that I hacked together too quickly and should've tested more properly. While I appreciate you cleaning up some of my mess, you can also just slap me on the fingers :-) Leo, bugs happen -- even to you. ;-) No finger slapping coming. Sometimes the best ideas come from a good idea w/ a poor implementation (again, something I've heard folks say about OSS projects :-). I say we don't get anal about every line of code being great, just about having great ideas. Modified: gump/branches/Gump3/pygump/python/gump/engine/__init__.py +import pprint +pprint.pprint(domtree) I'm guessing you didn't mean to commit that. Nope. Heck, I even do the svn diff religiously before commits, but missed this. Oh well, thanks for catching it. Gone (for next commit). regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I've made the workspace independent of building Jaxen
I hope the next public build on vmgump will be a full one, not an Axis-only one, so that we can crawl back to normal operations. Sorry about that, I was trying to debug why mail wasn't going out (yesterday morning) and just selected an AXIS one 'cos I knew a nag ought go. I ran a full build right afterwards, but for some inexplicable reason it hung, hence no more Gump builds. I've killed that, and hope the next run starts soon. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I've made the workspace independent of building Jaxen
Sorry about that, I was trying to debug why mail wasn't going out (yesterday morning) and just selected an AXIS one 'cos I knew a nag ought go. I ran a full build right afterwards, but for some inexplicable reason it hung, hence no more Gump builds. I've killed that, and hope the next run starts soon. Ok, the usual: Traceback (most recent call last): File bin/integrate.py, line 113, in ? irun() File bin/integrate.py, line 90, in irun result = getRunner(run).perform() File /x1/gump/public/gump/python/gump/core/runner/runner.py, line 249, in perform return self.performRun() File /x1/gump/public/gump/python/gump/core/runner/demand.py, line 182, in performRun module=project.getModule() File /x1/gump/public/gump/python/gump/core/model/project.py, line 696, in getModule if not self.inModule(): raise RuntimeError, 'Project [' + self.name + '] not in a module.]' RuntimeError: Project [saxpath] not in a module.] Process Exit Code : 1 I've not (yet) taught vmgump to complain when it exits. I started (a week ago) trying to make Gump2 not die in this case, it is too annoying. Unfortunately I'm not quite there. Gump3 was smart enough to catch such things earlier (or most, so far) but I'm close to patching Gump2 until Gump3 grows wings and flies. I'll get back to that to commit a fix. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mutliple gump workspaces on VMs
I'm not going to be of much help until Sunday. I've set up accounts on captainfantastic, all that remains to be done is to copy .ssh/authorized_keys into the right homedirs (which are under /Users on the mac). Ie along the lines of: scp -r minotaur.apache.org:~bodewig/.ssh \ captainfantastic.osuosl.org:~bodewig I've logged in and poked around, but I'm too OSX illiterate to even know how to install packages. I'll help out where I can, but I'm not likely to get up to speed on this any time soon. Hopefully others have the knowledge. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffe on vmgump
I suspect Leo is either (1) swamped or (2) practicing I'm only one Gumper, not the oracle, so figuring it out as a group is best or (3) both. As such, I say go for it, and we'll try to compress disk requirements to fit. I suspect we'll fit two (just) and I'm game for the second to be Kaffe. [We can ask #INFRA for a tad more disk on this VM if we get squeezed too tight, but it'd be a new location/drive (since I don't believe VMWare ESX allows us to grow disks).] Or, if you are more patient than I ;-), wait and see what Leo was thinking when he chatted to #infra folks about vmgump. regards, Adam - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: Gump code and data general@gump.apache.org Sent: Tuesday, May 31, 2005 10:49 AM Subject: kaffe on vmgump Leo, So what's the latest situation on vmgump? are the results published yet? (jdk1.4?) Can we set up an instance that runs on kaffe? (Adam created my id, so i can help). thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn: Working copy 'muse' locked
It seems we have a bunch of these. - svn: Working copy 'muse' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) - Ought we consider an 'svn cleanup' before each 'svn update'? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump notifications ... are they getting through?
I think it comes down to relaying. Brutus was allowed to, VmGump not. I've entered this: http://issues.apache.org/jira/browse/INFRA-365 regards Adam - Original Message - From: sebb [EMAIL PROTECTED] To: Gump code and data general@gump.apache.org Sent: Wednesday, June 01, 2005 5:44 PM Subject: Re: Gump notifications ... are they getting through? On 6/1/05, Adam Jack [EMAIL PROTECTED] wrote: I am frustrated trying to debug vmgump, and e-mail notifications. I just don't know if they are getting through, or not. Heck, for the longest time I I've seen a fair few Gump e-mails on commons-dev over the past few days. Two examples today: Adam - commons-id dIon - configuration10 and email I can forward them directly if you want. HTH S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffe on vmgump
So what's the latest situation on vmgump? are the results published yet? (jdk1.4?) http://vmgump.apache.org/gump/public/ regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: vmgump official w/ notification
I've enabled public on vmgump [1] to (1) do an official build each day and (2) deliver notifications via e-mail when it does. With Brutus gone, it seems time. I just burned more time than I wanted spend tracking down why vmgump was not sending notification e-mails. It logged that the Notifier actor (plugin) was not being loaded, but the reason for that eluded me. After a lot of code scanning, and trial-and-error, and head scratching ... I finally went in to hack some debug into the running code. I found that somebody had (on vmgump) commented out the add notifier section! Since the edit was local (not checked in) the svn update, that Gump does on itself, was not finding/correct this. 1) Please let's no do this again. Now that vmgump is the livest thing we have, let's treat it as production. 2) One can disable notifications simply by removing nag/ from the workspace. If there were more problems than this, perhaps log a JIRA entry. 3) I deleted public/gump an re-checked out from http://svn.apache.org/repos/asf/gump/live/ not TRUNK. 4) Any thoughts on if/how we stop this happening to us (unnoticed) again? Can we (if official) do an SVN forced sync? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r170842 - in /gump/branches/Gump3
1) Removed Homedir, since home isn't an output. Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of native code projects find each other via a prefix directory. Step out of the confines of the java world :-) I'm not thinking Java, I'm thinking Gump.[1] What you are describing is done via properties [2]. That said, I'm game to come up with new ideas. With Gump2 I chose to emulate behaviours, to fit with existing, not re-design. Heck, there was no real expectation that Gump2 would live, let alone go TLP, so I hardly wanted to freak out any commiters by changing all the metadata. That said, I'd like to re-do the metadata for Gump3, and take whatever time we need on it. 2) Added WorkItem and ResolvablePath. 3) Added project.homedir - a ResolvablePath. 4) Resolve outputs relative to the homedir. 5) Zapped some tests. WHAT?!? Without reading on and knowing what this about (I see it has to do with removing Homedir), you really scared me :). We need more tests not less, and test removal really should be motivated well :-) The tests (based upon mock objects, or where a project is a 'string') are incredibly simple to write when Gump3 is simple, but as it gets fleshed out the tests are less and less practical. I did some DynaGumper work yesterday, but stumbled 'cos the tests could no longer be made to work 'cos they passed in a string for a project, not an object. Basically, the unit test's simplicity is in the way. With Gump2 I had unit tests running models I loaded from pre-defined test workspaces. That worked, but it made things more like an integration test, not a unit test. I think we need to make a whole mock model (irrespective of XML format) and have the unit tests be able to tap into these. I'd appreciate some help here. I removed those tests (and I sent an e-mail saying why, I thought) 'cos they tested output objects that no longer existed as such. Also, I want to do small/incremental commits, so we can view as we go. If that sometimes breaks unit tests, and forces a discussion, thatis fine by me. Modified: gump/branches/Gump3/pygump/python/gump/engine/objectifier.py ... from gump.model import * +from gump.model.util import * We need to get rid of '*' imports. I just wish there was a tool in python to automate clean up imports. I know, I'm not a fan either. I took a liberty and copied what was there. +def _extract_relative_item(project, element): + Extract directory relative to module or project, based +upon which attribute (parent or nested) is present. IMHO this is a piece of logic that doesn't belong in the objectifier. I guess that I believe the current gump object model has thoroughly messed up directory management. I want to rethink it. I mean, +parent=element.getAttribute(parent) +nested=element.getAttribute(nested) + +if parent: +rel_item=RelativePath(project.module,parent) +elif nested: +rel_item=RelativePath(project,nested) +else: +raise Error, Unknown relative path entry (no parent or nested): %s % (element) That's just ugly, right? Do I have to mark #UGLY to let you know I know? ;-) +# Work Items +works = project_definition.getElementsByTagName(work) +for work in works: Similarly, work/ is harmful and should be superfluous (we have it because java will barf in the case of nonexistent directories on the classpath or remove them from the path permanently. The place to fix that is very close to the code that interfaces us to java, not in the model). Yup, on platforms/builders (Ant on Solaris, I thinkl) we ought automatically create work directories for the user/metadata, there ought not be an element called work/. All this has nothing to do with the code you wrote, I'm just clearly realizing it now :) :-) Modified: gump/branches/Gump3/pygump/python/gump/model/__init__.py ... +- homedir -- None or a ResolvablePath (outputs are relative to this) See how confusing that is? At least it is to me! And to me. Please do read [1] below, as it might explain how it came into existence. ... +class WorkItem(ModelObject): +Model a directory containing stuff that can be used by other projects. ... If its used by other projects then its an Output. Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py ... +# Any internal build artifacts +for work in project.workitems: +self.classpath += ArtifactPath(work.name,output.path.resolve(self.workdir)) It really is a mess. We need to get rid of work/, home/, etc. What would make sense is something like repository name=ant module name=ant project name=ant ant classpath directory=build/classes /classpath /ant /project /module /repository I do like the idea of classpath (for one, we'd know this was a Java Ant project not another Ant project)
Re: svn commit: r170825 - in /gump/branches/Gump3
1) Added to the tsws1.xml workspace: Which is? That info should not be in the commit but rather in the xml comments for the workspace. It is a hostname I've used for a couple of years. It is just like giraffe.xml, I assume, although I suspected that was some new Python module (like cheetah ;-) for a while. :-) 2) Worked on the AntBuilder. Seems closer to providing the needs of the Ant commandline. Still need to add work items to the Gump3 model complete the CLASSPATH. I can see what you worked /on/ from easily enough. But what's the work that you /did/? Sorry, I thoguht that was what the code diff was for, so I summarized. I made the Ant commandline/environment match what was needed. I added CLASSPATH and an environment variable, I added -X bootclasspath/p for boot classpath, I call java (searching on the $PATH, not fixing it), I added -buildfile and The biggest work was to make classpath entries relative to the home/ element's nested or parent path, releative to the project directory. This mean resolving all such entries at time of use, since the model was pure of the root workdir. Trust me, it wasn't fun, but I'm not 100% certain it is all wrong. Maybe this is something we can discuss on irc://irc.freenode.net/#asfgump some time. I'd love for Stefan to be there, 'cos he knows the metadata (use cases) the best. Other than that, I'm open to ideas on how to resolve things. +self.method(project, command) +except Exception: [...] +self.log.exception(Command %s Failed... % (command)) +command.build_exit_status=1 + You're swallowing an exception here. Don't ever swallow exceptions. I think we had a thread on that already recently. Who knows, it might be changed again already :-) I was trying to follow the protocol at the highest point I could do it. This was the only place that was (1) build related (2) able to catch exceptions. If you've pushed this into some algorythm, then great, but I guess that assumes that all exceptions thrown from project visits are build related, right? That seems off. ... Modified: gump/branches/Gump3/pygump/python/gump/plugins/java/builder.py ... -class BuilderPlugin(AbstractPlugin): ... Hey, where'd that go? We had two, with little/no specializations, I returned them one. I'm guessing that what makes this so painful (besides the classpath problems being painful in general) is the use of intelligent objects. You'll note that so far the objects I've put into the gump model are very dumb. I.e. The javabeans pattern is avoided. I don't know who thought of javabeans, but they were wrong. Does this hark back to your small classes, many functions e-mail? If so, I'll re-read that. +# Clone the environment, so we can squirt CLASSPATH into it. +self.tmp_env = dict(os.environ) I don't get it. Why is this done here? The problem with the above is that the plugin suddenly has a tmp_env variable, and when and how will that be cleaned up? I believe you could ultimately even consider How is this different from DynaGumper holding a log variable, or a db variable, or whatever. Plugins re-use things over and over again, when not store them? Sicne we don't ahve a 'reaper' it could be cleaned up either (1) on exit [like most of our stuff] or (2) in _finalize. Thanks for taking time to review this. I do appreciate the input/different perspective, even if the volume of it is hard to accept at times. ;-) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
Could we get back to this thread above (using http://tinyurl.com/4qt9a to
get to the attachment) and see where we want to take it? I see that Gump3
has a schema that does not include some of the additions mentioned in the
thread.
Also, I'm trying to flesh out DynaGumper (the Gump3 DB plugin) and I'd like
to populate the run/build information. I think I need project_version ids,
but I can't figure out how do calculate them. Do I simply use
http://www.apache.org/projects/{projectname}#20050526 or #HEAD or #gump or
something? Further, ought project dependencies (in project_dependencies) be
between project versions not projects?
Finally, is anybody able to take on the DynaGump Cocoon webapp? I think we'd
all benefit from seeing inside the database as we populate it.
regards,
Adam
- Original Message -
From: Stefano Mazzocchi [EMAIL PROTECTED]
To: Gump general@gump.apache.org
Sent: Wednesday, December 08, 2004 6:32 PM
Subject: [RT] Gump 3.0 - Database Model
Since I received no pushback on my proposal, let's move on discussing
the database model.
I think the first step is to identify the entities that we want to
model, their relationships and their respective cardinality.
Here is what Leo and I came up with so far (attached as PDF).
Comments/criticism/questions appreciated.
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump failed: build timed out
Is there an option within gump that sets the time gump is willing to wait for the build to finish? Graham Did you not notice this response to your previous mail, or did it not help? http://marc.theaimsgroup.com/?l=gumpm=111620403011709w=2 regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move public onto JDK 1.5?
On Sun, 22 May 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote:
Does it make sense to move public (with nagging) to JDK 1.5?
Not yet, IMHO.
Ok. I just didn't want us to give up on all the Gump flavours w/o having
asked the question.
Given that we can't support all configurations, and given the level
of turmoil the JAXP 1.3 seems to be causing, ought we not just dive
in w/ both feet embrace change?
I find this time quite interesting since we see projects embrace JAXP
1.3 and in particular DOM3 at very different paces.
Yeah, in fact, I think it is one of the biggest deals in my memory of Gump.
It has started to make me realize that the 'events' such as this, big
discontinuities/big disruptions, are truely newsworthy ... and perhaps ought
be publicized. Gump 'represents'a reasonable chunk of base Java code,
classes that are (no doubt) underneath a lot of Java applications, and if
this base suffers badly from a change, that will ripple significantly.
I know you blogged about this Stefan [1], but I wonder if we ought have
brought it up to the ASF board, and if the ASF board ought consider taking
action based of the findings. I don't know what could (or should) be done,
but I wonder if we need to be more vocal about the findings. It seems that
without nagging Gump is a passive observer, and -- like the tree falling in
the woods w/ nobody to see it -- did it happen?
[I know I'm overlooking the human factor here, the people who read the
output, but I think this is far fewer than the data could interest (we need
to market this information source).]
Since (I believe) JDK ought be compile compatible w/ older JDKs,
Do you really belive this was true? Or is this just what you whish
would be true? ;-)
Yup, bad wording. I don't beleive it ('cos I've learned that much from Gump
interacting w/ JDKs, from over the years) but I sure do wish it were true.
Gump has taught me that discontinuities happen -- even in the best
maintained projects, with the best intentions -- they have to be allowed
for progress. That said, unintentional discontinuities are the pits, a
waste for everybody involved that slows progress, and I feel Gump needs to
help spotlight any such things. Who knows, maybe Sun would respond to ASF
highlighting a bunch of discontinuities. Maybe a dialogue ought occur.
Seems relatively healthy, and not too painful. That said, I'm not
expert, I'm just asking a question.
I thought about this (unfortunately) right after Brutus went down, so I
couldn't check what I was hoping. Kinda sad how the data disappears so
quickly. I figured a few nags might cause a few enums to be renamed, and
add some value speeding up the conversion. I'd not considered the nagatives
that you see. Time might help there, like you said, and we can give a little
to see if it does. Perhaps we ought nag (once a week/month) from a JDK 1.5
run.
All in all, I find the handling of the discontinuities -- the recording of
them, the bringing things to light -- the primary role of Gump, and I sure
wish we had a better way of documenting it/publicizing it. I think
individual failures in Gump (once stable in itself) ought generate a JIRA
entry (or database record) that gets worked/tracked to resolution. With some
level of consistency Gump's information would accumulate, not be lost, and
as a whole would be far more effective/valuable.
I think there is a lot to explore here, a lot to discuss, I just have a day
on diaper duty and breakfast to attend to [hence the no doubt
distracted/incomplete sentances].
regards,
Adam
[1] http://stefanbodewig.blogger.de/stories/167334/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 ideas/questions
Adam, I had discussions like this for years and years over in avalon land. Enuf said! ;-) I was thinking of the update build document[to DB] chain (say) for ant. Once done, are all the details of the build, that documentation used, still needed? Once done, don't we just exit the gump run? If the algorythm (which Gump2's became) is: update module A, build project A, document (to DB) A, notify A. update module B, build project B, document (to DB) B, notify B. .. and you have hundreds of projects, there is a lot of time/accumulation before the exit. Folks want this type of algorythm (than update A,B... build A/B... doc ... notify ...) otherwise the window between problem notification and next update is too small. As such, the first algorythm make module/project A reapable early. I meant reaping to death, not paging out. We'll see if it is needed, but somehow the algorythm would need to know when a model is used for this run, and/or the Reaper plugin would and/or we'd need a special plugin the algoruthm understood. Plugin writing would be a lot easier if you wouldn't have to worry about data that was there before not being there at a later point. Clearly. As such, I'm game to wait and see if we get the need. Alternatively we could (again, if needed) try your page out idea and then if a plugin was re-used (for some odd reason) the data wouldn't be gone. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 ideas/questions
I think in these (early days, maybe through-out the life of Gump3) the toughest part is the property messaging protocol(s). Basically Gump3 internals are based upon trust respect between plugins -- like a good OSS project :-) -- but it doesn't (yet) have the internal equivalents of communications forums of wikis/blogs/docs, nor the history of commit mails, mail archives, nor SCMs. I love that description. Nope, we don't have that. But we can reuse all those tools just by localizing the trust and respect into an explicit file! We need Funny how I wrote it w/o quite making the leap of using them exactly, I was expecting analogous components in Gump3. Could be interesting. gump/model/propertymessaging.py This module contains *all* the getters/setters that plugins use for adding data to the model or getting it from the model. Yup, I like it. I think we'll need a few such protocols -- i.e. the build/status as one protocol, with artifacts (classpaths, reposities, generating) perhaps another. I'm sure there will be many. We get SCM/commit mails you get by the file being in SVN. We also get versioning of the protocol that way: just tag revisions of the file: svn cp https://svn.apache.org/repos/asf/gump/branches/Gump3/pygump/gump/model/propertymessaging.py https://svn.apache.org/repos/asf/gump/tags/Gump3-propertymessage-protocol-3.0 Yes, interesting. That said, I was actually refering to plugins sharing the model (as developers share the code, via SCM) and how one plugin's efforts, setting properties, might (in plugin's real time) communicate. Just as we trust each other to move things towards a common goal, and respect each others changes (even reversions), and communicate via lists/blogs/SCMs -- I wonder if plugins could. Perhaps some named dictionaries on model objects, that allow plugins to say (I created x/y/z -- and modified a/b/c). I could see the core (algorythm/walker) being able to do some nifty/helpful tracing/debugging with that. If Gump3 ever gets so big (flexible) that it loads plugins on the fly, from developers whove never spoken, I could see this being very useful. For now, it is just a wild fancy. :-) I've actually been changing that a little (make sure you svn upped everything :-D). From memory, Yup, always do. I (eventually) stumbled on the in code docs for your changes also, so got an understanding. Thanks. Plugins should make an attempt to handle an expected failure, ie they should try and continue processing, and set the failed property on the model element that failed. They should raise exceptions on unexpected failure. They don't do anything else. The Builder nor the Walker nor any of the core code have anything to do with this, *except* the algorithm (in algorithm.py). All decisions about what should happen on a failure, all intelligence on what a failure *means* or what *consequences* a failure should have (for example, if you can't check out a module no use trying to build it) are made by the algorithm. Ok, then time for me to fess up. One thing I did was (in BuilderPlugin) was setting the status to failed (using your protocol setter) if an exception was thrown. I wondered (and added a #TODO) if we needed a BuilderErrorHandler for that instead. I now see you have a third alternative, and maybe we take the exception catch of out BuilderPlugin all together. I'll be frank: I don't think so. I think that if properties become too big, they should be turned into functionality to access properties. For example, instead of keeping logs in the model, you store them on disk or in a database, and you load them into the plugin space (instead of onto the model) as you need them: This is exacly the example I think of where we might want to use the property(get,set,del,'doc string') capability. I know I'm a little enamoured w/ this beastie, but as we use properties more and more, I could see it be interesting for a plugin to annotate a model object with both data and the getter/setter/delete/docs logic behind it (e.g. to read from file on demand). Other users don't need to know the implementation details, just that it provides/consumes a string. Hmm. While typing that, I realized that you can actually build a reaper that way, and its just a plugin that looks for the big chunks of memory, writes them to your object db of choice (ie python's shelf module or whatever), then adds an accessor to load them back into memory. I think we will want a Reaper, not so much 'cos of the size of properties (as discussed above) but the shear volume of them. Gump2 slowed to mollasses as it grew, before I spent a month or so fighting it, and being careful to assit GC. Python's runtime gets clogged with a few hundred thousand objects, and (especially when Gump2 creates DOM trees for documentation during the build) we were easily hitting that. Python GC is quite the magic I'd wish it to be. However, one wonders if this is really more efficient than
Re: Problem running Apache Gump [brutus-public]
I suspect we have a circular dependency in the metadata (that isn't
detected) but I don't have time to investigate tonight/tomorrow morning.
Since there were only two metadata changes today, it ought be easy to undo.
regards
Adam
- Original Message -
From: [EMAIL PROTECTED]
To: general@gump.apache.org
Sent: Friday, May 20, 2005 3:23 AM
Subject: Problem running Apache Gump [brutus-public]
There is a problem with run 'brutus-public' (19052005_180001), location :
http://brutus.apache.org/gump/public
The log ought be at:
http://brutus.apache.org/gump/public/gump_log.txt
The last (up to) 50 lines of the log are :
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
570, in complete
depProject.complete(workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/project.py, line
562, in complete
[b.expand(self, workspace) for b in self.builder]
File
/home/gump/workspaces2/public/gump/python/gump/core/model/builder.py, line
63, in expand
self.expandDomProperties(project,workspace)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/builder.py, line
118, in expandDomProperties
self.importProperty(pdom)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/property.py,
line 249, in importProperty
self.properties.importProperty(domproperty)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/property.py,
line 206, in importProperty
property=Property(name,pdom,self.getOwner())
File
/home/gump/workspaces2/public/gump/python/gump/core/model/property.py,
line 29, in __init__
NamedModelObject.__init__(self,name,dom,parent)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/object.py, line
288, in __init__
ModelObject.__init__(self,dom,owner)
File
/home/gump/workspaces2/public/gump/python/gump/core/model/object.py, line
44, in __init__
Workable.__init__(self)
File /home/gump/workspaces2/public/gump/python/gump/util/work.py, line
264, in __init__
self.worklist=WorkList(self)
File /home/gump/workspaces2/public/gump/python/gump/util/work.py, line
177, in __init__
self.times=TimeStampSet('Named Work')
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py,
line 336, in __init__
if not start:start=TimeStamp('Start of ' + name)
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py,
line 236, in __init__
stamp=getLocalNow()
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py,
line 95, in getLocalNow
return datetime.datetime.now(LOCAL_TIMEZONE_INFO)
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py,
line 69, in utcoffset
if self._isdst(dt):
RuntimeError: maximum recursion depth exceeded
Process Exit Code : 1
--
Gump Version: 2.0.2-alpha-0003
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brutus going down
Brutus will be going down somewhere today or tomorrow. It will be wiped to start hosting Apache's SVN install. For somebody trying to play catch-up, where are the alternative places to run a Gump instance? I'd like to be able tinker with a Gump3 on some *nix type platform, and I could perhaps help a little w/ any Gump2 re-installs. Thanks in advance for any pointers to wiki pages (and/or ways I can find where/how I need to log in.) Also, a random observation. It is interesting that we aren't wanting to save the database of 'historical information' that we've accumulated (in MySQL, or DBM). Sure, few really know it is there (given we don't have a presentation interface into it) but I also wonder at it's value. Is historical information really important to Gump's contributions, or is it more in the here an now? That, or if it isn't in a form that aggregators/index engines can consume, it doesn't fit today's world. I wonder if there is something in either of these. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brutus going down
DON'T KILL THE LOGS! Would that they'd be logs. We never had space (or haven't optimized sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a lot, but exist, if wanted. I hope we give good consideration to 'Net history (and access for external services, e.g. google) with Gump3. Adam, can you give us (or leo) pointers to where is all the data that gump saves so that we can restore it on the new installation? Basically there is the MySQL database, and a DBM file (at /usr/local/gump/public/gump/work/stats.db). These contain what history we have. [Same DBM exists for Kaffe, JDK1.5, etc.] BTW: Are we saving the crontab and any scripts in ~gump, Leo? Could be valuable. Where ought we put these to be moved, into Gump SVN? BTW: I hope '/usr/local/gump/packages' is being moved across. That'd remove a huge chunk of the pain of a fresh install. Also, if we kept '/usr/local/gump/staging' (along w/ timestamps) then Gump might continue to accurately records how long since a code update (on more stale projects.) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failed with reason build timed out
Is there a way to increase this timeout, or remove it altogether?
I see this in the code:
TIMEOUT=60*60 # 60 minutes (in seconds)
if os.environ.has_key('GUMP_TIMEOUT'):
TIMEOUT = string.atoi(os.environ['GUMP_TIMEOUT'])
Setting to 0 will (I believe) remove it. The JIRA entry still stands though,
it needs documentation the error message ought explain it. Personal I
think we need per project configurable timeouts, not server wide. I'll add
that to the JIRA entry sometime.
regards
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fancy CLI and stoof
Lemme know what you think! I love the concept. Unfortunately, on Cygwin, I see this below. I get pretty much the same whatever Gump command I try. Adam $ bash gump kill 1152 [main] bash 3292 fork_parent: child 4012 died waiting for longjmp before initialization gump: fork: No such file or directory 1484 [main] bash 4100 fork_parent: child 3440 died waiting for longjmp before initialization gump: fork: No such file or directory 4974 [main] bash 3444 fork_parent: child 3440 died waiting for longjmp before initialization gump: fork: No such file or directory 5021 [main] bash 4136 fork_parent: child 4012 died waiting for longjmp before initialization gump: fork: No such file or directory 2124 [main] bash 3440 fork_parent: child 4012 died waiting for longjmp before initialization gump: fork: No such file or directory 200 [main] bash 3348 fork_parent: child 4012 died waiting for longjmp before initialization gump: fork: No such file or directory 15534 [main] bash 3600 fork_parent: child 4184 died waiting for longjmp before initialization gump: fork: Bad file descriptor gump: Fatal error! Process ID specified in Pygump lockfile not found, no process to kill! [EMAIL PROTECTED] /cygdrive/f/data/Python/Gump3-SVN $ ps: unknown option -- o Usage: ps [-aefls] [-u UID] Report process status -a, --all show processes of all users -e, --everyone show processes of all users -f, --full show process uids, ppids -h, --help output usage information and exit -l, --long show process uids, ppids, pgids, winpids -s, --summary show process summary -u, --user list processes owned by UID -v, --version output version information and exit -W, --windows show windows as well as cygwin processes With no options, ps outputs the long format by default - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Xerces trouble
I guess this has to be expected - and it will extend beyond Xerces and to Xalan sooner or later as well. Makes me wonder if we want a disclaimer (general message) ability that get's sent out w/ each Gump notification. i.e. Caution : Work in progress on migration to JAXP 1.3. Since I'll be offline for a few days, please keep an eye on it and start adding xml-apis dependencies if it works. If not, we may need to throw in dependencies on jaxp and select sax.jar exclusively. I'll be offline from Saturday to Saturday (hence I've been too swamped to play w/ Gump3 like I wanted to.) We are going to find out what the sea look like again, after years as a land-lock Coloradoan. :-) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r165133
I fixed it. Please try to run ./gump test before every commit, and make sure it completes without errors. I will. (Further, I'll even add some test sooner or later, not just dilute the code to test ratio. Promise. :-) Since I'm trying to grab precious minutes of time here and there, the problem will be me being in a big rush and forgetting. Sometimes I wish this was something we could build into a script (tied into SVN, or wrapped around) so we could make it an easy habit to adhere to. Further, what I tried doing (before) was have gumptest be an entry that gump runs, that is a script that do: 1) Run unit tests 2) Runs PyChecker [ http://pychecker.sourceforge.net/ ] (although I had troubles figuring out how to dynamically find/pass modules as it wanted them) 2) Exercises some command lines (e.g. bash gump test). I'd really appreciate completing the Gump3 workspace on Brutus (or wherever) so we could have this working. It is gump-like to do this, and I'd like this to be a first milestone in getting Gump3 working for folks. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r164531 - in /gump/branches/Gump3/pygump: gump.log.config python/gump/config.py python/gump/engine/modeller.py python/gump/engine/walker.py python/gump/model/__init__.py python/gump/plugins/__init__.py python/gump/plugins/builder.py python/
Thanks Leo/Stefan. With WingIDE not adding files/directories when SVN brings them down anew, and with me having manually add things w/ SVN, refactoring is a pain. I was putting them into the plugin/builder.py file until I re-read the JIRA entry on what was requested of me. I quickly moved things, tested them, and did the commit. Hence the lack of files. I think you forgot to svn add gump/branches/Gump3/pygump/python/gump/plugins/java.py FWIIW: gump/branches/Gump3/pygump/python/gump/plugins/java/ BTWL When I added this it also added al lthe .pyc files, which I then manually deleted. Any way to have directories inherit an ignore of these? One thing to get used to with svn is doing a whole lot of svn status (often accompanied by svn diff since you wonder what it was you changed). That is what I do all the time. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
OTOH, debug statements have also worked reasonably for ages. Simplest thing, simplest thing ;) Yup, I'm there for now, however I was thinking about communication between two separate developers of plugins, perhaps the latter not being able to hack debug statements into the former. Still, right now that isn't the case. Still, if plugin developers can log (perhaps at end of the piece of code) the main attributes they publish, that'd be helpful. Perhaps we somehow need to have plugins document themselves (just like you have the list of attributes on the model.) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Has the Kaffe Gump run died?
Could it be that the new Kill prcess group stuff is killing too many
processes, taking the main Gump process down with it?
I don't think it is the new stuff, per-se, but the fact that some old
slipped in with the new. The old killed the Gump process 'cos it was
running within a standalone process, a copy ('cos M$ doesn't have fork).
Inside the new, I suspect that the fork still sees 'the Gump process' as the
original. Poorly coded, and when mixed with a coincident bug, perhaps fatal.
I would've expected to see a log warning line (that I don't see in your
output) but since this possibility exists, and fits the experience we have,
I'm inclined to blame it. I'll fix it and commit.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Last Gump runs were using libgcj
The problem must have been some apt-get installation that added a
symlink to gij into /usr/bin/java. Obviously Gump still doesn't use
$JAVA_HOME.
Much as my read of the code would hope to differ, my read of the log say
that Gump (despite efforts) isn't defaulting to $JAVA_HOME/bin/java, but
still using java. See Properties and Annotations here:
http://brutus.apache.org/gump/public/index.html
Ok, much as I hate fixing something I don't understand as broken, I've move
this code to be with the rest (that seems to work).
# Default to $JAVA_HOME/bin/java, can be overridden with
$JAVA_CMD.
if os.environ.has_key('JAVA_HOME'):
self.javaCommand =
os.path.join(os.environ['JAVA_HOME'],'bin',self.javaCommand)
self.addInfo('javaCommand set to $JAVA_HOME/bin/java = ' +
self.javaCommand )
I'll check out the output from the next new run.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - -
Gak, hold one .. commit to trunk, run from live ... I wonder if this was
working, we've just not 'release' recently. Hmm, I wonder if we ought be
running an 'svn info' as part of the start-up of the run, to see what we are
working with (and from where).
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Has the Kaffe Gump run died?
thanks adam. i was looking into the code myself when i saw ur email :) will wait for ur patch (both trunk and live...right?) Nice to have company in there dims. :-) Let's do a test run, see if things are working (if we can be certain) and then do a release. http://wiki.apache.org/gump/GumpBranches regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3:Dependency.dependencyInfo[]
I've been wondering whether its a smart idea to change a whole lot of this now. I think the Normalizer code and friends shows we can keep the model the same for now yet develop most of our code the way we see fit. The new model will fall out, and we'll immediately know what the transformation steps are: the Normalizer ends up being the conversion step between the old GOM and the new GOM. Does that make sense to you? It can wait. Of course, I'm now seeing that this is very bad communication-wise, since you'll have to understand all that ugly xml code in order to understand what the code does. Hmm. Maybe we should take it further. I'm thinking here that we should forget about the xml there and build the example model completely in code. Sounds good for a test model we can write unit tests against. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Has the Kaffe Gump run died?
This looks 'interesting' :
Kill process group (anything launched by PID 21107)
Kill process group 18226 (anything launched by PID 21107) [from 21109]
for:
pgrpID=os.getpgid(pid)
log.warn('Kill process group %s (anything launched by PID %s) [from
%s]' \
% (pgrpID, pid, os.getpid()))
It is unlikely that 21109 is the 'parent' of 21107. (Even Brutus isn't that
busy :-) Hmm, maybe it is that the timer is running in a sub-process (some
Python impl detail?), and the main process was 18226. That might be
possible, seeing as the lock file contains 18231.
Mind you, this leads to ...
Looking at the code, I see no 'setpgid', which is disturbing (to say the
least). The logic of this kill means the forked child needs to place itself
into it's own process group. Without that, the parent (main Gump) is likely
a equal target for termination. I (now) suspect that is the problem. I
certainly makes sense w/ the output we see.
[BTW: Somehow when I ported from the test script, python/misc/pgrp.py I lost
this 'minor' detail. Hopefully with Gump3 we all have better luck w/
repeatably unit testing integration code.]
regards
Adam
- Original Message -
From: Davanum Srinivas [EMAIL PROTECTED]
To: Adam R. B. Jack [EMAIL PROTECTED]
Cc: Gump code and data general@gump.apache.org
Sent: Tuesday, April 26, 2005 1:56 PM
Subject: Re: Has the Kaffe Gump run died?
no luck :( kaffe run still dies.
-- dims
On 4/26/05, Adam R. B. Jack [EMAIL PROTECTED] wrote:
oops...i already merged your patch to live :(
I doubt they are harmful, I just wasn't 100% certain they were sure fixes.
regards
Adam
--
Davanum Srinivas - http://webservices.apache.org/~dims/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Has the Kaffe Gump run died?
Hey Leo, thanks for taking a peek @ this... Looking at the code, I see no 'setpgid', which is disturbing (to say the least). Well, there is a setpgrp. That's setpgid(0,0), or something. Sorry, typo, I meant : os.setpgrp(). The logic of this kill means the forked child needs to place itself into it's own process group. That can never work properly. No, let's be clear: 1) Main Gump Python process forks 2) Forked child (now) sets it's self as a process group leader [protecting main Gump], and goes off to run children. 3) Main Gump sets a timer (for 1 hour) to do the call to os.killpg(os.getpgid(forkedPid),signal.SIGKILL) IMHO this works. Sorry if I didn't explain it clearly. The code in Gump3 responsible for all this is much much simpler, because: 1) it uses the subprocess module which simplifies things like error code handling 2) it uses a single global process group for all of gump instead of one for each command 3) it doesn't use timeouts or any kind of multithreading but only kills processes before system exit 4) it doesn't bother writing exec files 5) it does one thing only (we hope it does it well :-D) The Gump3 start is nicer than Gump2's, I agree. Unfortunately I don't was to give up on Python 2.3 nor Microsoft (non-Cygwin), and the Process Group stuff is Posix (not even sure if it works on Cygwin). Hence those lines of ugly code are not yet removable. Further, we need to make Gump3 start to kill sub-processes after a timeout (say on a spinning Ant build), or at least (1) not hang on them indefinately (2) stop them burning CPU if spinning. Basically, I'm in a mindset of (1) keep Gump2 working generating build results (even if not pretty) (2) developing Gump3 much more prettily. As such, I hope to (one of these days) take the subprocess stuff and do effectively what Gump2 has per child, in Gump3, but do it in a clean/subprocess/no-extra-fluff way. Feel free to beat me to it, and/or review what I submit. BTW: I merged this patch into LIVE and have a Kaffe run going on Brutus. It isn't happy about bootstrap-ant, so maybe we'll not see a rogue compile/test/build causing a (stray) kill to know if it is working. Hopefully we'll get that soon. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
Change config.py; configure the logging package by hand (I think that's called basicConfig()) instead of using a config file, and make it output everything to the screen. We can fix it later, and there's no test to look for the existence of log files so you're not breaking anything ;) Ok, got it. This LogReporter isn't a reporter to a log it is a reporter of logs. Since my workspace/environment had no Ant script to run (and had done no CVS|SVN updates to get one), I had no properties ending with _log, and (apparently) no exceptions. As such, no reporter output data. After (1) editing the gump.log.config and checking out oddities like args(stdout,) -- yup, odd but right (2) adding [logger_plugin_error-handler] -- nope, no new errors reported. (3) shutting down logging gracefully -- nope, nothing new (4) stopping the config level overriding the log file [I can restore this, but things are getting too verbose for me, given what I've added] (5) dotting lots of log messages -- yup, walking as intended ... I finally figured it out. The clue (staring us in the face) was that the same log was used for writing the initialisation message as the contents. I saw this message, so I ought have seen anything else. The main reason I was expecting more content was I was writing a pretty printer plug-in, when log reporter first came along, to see what attributes the various plugins left on the model. Since we are using the model as a message board that seems a key tool for newbies like me to get insights into the 'protocol' between plugins. I'll get back to writing it, now I know that LogReporter isn't that beastie. I'd half like to see a properties diff tool that runs in between plugins, to see what is changed each time a plugin runs. I could imaging plugins taking credit (say) for a property be updating a table. This is likely overkill for now though, and a dump (at the end) ought teach me what I need to know. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3:Dependency.dependencyInfo[]
If you think of a Project as a node, a Dependency as a vertex, then you
can
have an array of DependencyInfo as multiple vertex colorings. Was my
thinking.
I sorta got it, but I guess I was thinking based upon existing Gump
metadata/documentation. I had no metadata sample for Ant, so built it based
upon what I knew.
It doesn't make sense to do enumerations inside an xml attribute. It's
much
clearer to make enumerations by well, enumerating elements.
(...)
Anyway, I guess the code isn't as clear as I thought it was. Similarly I
couldn't quite figure out what you were trying to do in your commit,
further
indication that this really needs more change than you introduced :-D
Any suggestion on how to clean this up further?
We miscommunicated based of what I believed the XML to be, and applying my
read of the code to that input. I (honestly) can't tell you which form is
better ('ids' w/ N or N of depend 'id') but I lean towards yours. Let's
restore it to your way, and then create some good sample XML metadata. I
need a small stack of dependencies (up to an ant command, not a script
command ) to work on ClasspathPlugin and AntPlugin.
BTW: If we are changing metadata, let's fix it so that we know what is Ant
over Java not Ant over (say) C# or whatever.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3:Dependency.dependencyInfo[]
In fact, I'd much prefer the xml to be: [...] Or rather: project name=a depend project=b output type=jar id=basic runtime=true/ output type=jar id=extension1 runtime=true/ output type=native-lib id=fancy-feature optional=true/ /depend /project I'd go for this (although perhaps artifact not output) and maybe have more attributes on the depend element, to avoid repetition (e.g. have runtime setable there.) That said, I think it really comes down to how much complexity we want to allow here, or even ... how much is actually needed by users. Let's at least split out these sub-elements, and work on attributes in time. BTW: I suspect 'type' ought be on the declaration, not the dependency, right? No point duplicating that information, is there? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
I'm still finding it hard to make progress, 'cos I can't see log output. This (captured below) is all I see, and either there is a problem with logging on (Cygwin) or the Mutliplexer isn't dispatching, or something. Do we need to ask for non-buffered log files, or do some flushing prior to exit, or Any thoughts? regards Adam --- DEBUG: logdir is f:\data\Python\Gump3-SVN\pygump\work\log DEBUG: Pygump version 3.0-alpha-3 starting... DEBUG: (the detailed log is written to f:\data\Python\Gump3-SVN\pygump\work\log\gump_log_20050424_161931.txt) DEBUG: - hostname : tsws1 DEBUG: - homedir: f:\data\Python\Gump3-SVN DEBUG: - current time : 24 Apr 2005 16:19:31 DEBUG: - current time (UTC) : 24 Apr 2005 22:19:31 DEBUG: - python version : 2.4 (#60, Feb 9 2005, 19:03:27) [MSC v.1310 32 bit (Intel)] DEBUG: - python command : /cygdrive/c/Python24/python DEBUG: - environment variables: DEBUG: TMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: DEPOT_UPDATE_HOME=F:\data\OSS\depot-update DEBUG: COMPUTERNAME=TSWS1 DEBUG: USER=ajack DEBUG: USERDOMAIN=TSWS1 DEBUG: COMMONPROGRAMFILES=C:\Program Files\Common Files DEBUG: PROCESSOR_IDENTIFIER=x86 Family 6 Model 8 Stepping 3, GenuineIntel DEBUG: CVS_RSH=/bin/ssh DEBUG: PROGRAMFILES=C:\Program Files DEBUG: PROCESSOR_REVISION=0803 DEBUG: HOME=c:\ DEBUG: SYSTEMROOT=C:\WINNT DEBUG: CATALINA_HOME=F:\apps\Apache\jakarta-tomcat-5.0.19 DEBUG: MA_AGENT=c:\PROGRA~1\sybase\MANAGE~1\rstate.exe DEBUG: INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info :/usr/autotool/stable/info: DEBUG: GUMP_HOME=f:\data\Python\Gump3-SVN DEBUG: PRINTER=HP OfficeJet DEBUG: TEMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: SHLVL=2 DEBUG: PROCESSOR_ARCHITECTURE=x86 DEBUG: J2EE_HOME=F:\apps\j2sdkee1.3.1 DEBUG: APR_ICONV_PATH=F:\apps\Subversion\iconv DEBUG: ALLUSERSPROFILE=C:\Documents and Settings\All Users DEBUG: ROOTDIR=F:/apps/mks DEBUG: BPE_HOME=F:\apps\Sybase\bpee DEBUG: _=/cygdrive/c/Python24/python DEBUG: MANPATH=/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man: DEBUG: HOMEPATH=\Documents and Settings\ajack DEBUG: GUMP_HOSTNAME=tsws1 DEBUG: GUMP_WORKDIR=f:\data\Python\Gump3-SVN\pygump\work DEBUG: JAVA_HOME=c:\j2sdk1.4.2_08 DEBUG: USERNAME=ajack DEBUG: LOGONSERVER=\\TSWS1 DEBUG: PROMPT=$P$G DEBUG: COMSPEC=C:\WINNT\system32\cmd.exe DEBUG: MAKE_MODE=unix DEBUG: PYTHONPATH=f:\data\Python\Gump3-SVN\pygump\python;f:\data\Python\Gump3-SVN\ pygump DEBUG: XINDICE_HOME=F:\data\OSS\xml-xindice DEBUG: TERM=cygwin DEBUG: PATH=C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R 6\bin;c:\Python24\;f:\apps\Sybase\Shared\ASA802\win32;c:\Python23\;c:\Python 23\Scripts;f:\apps\javasoft\j2sdk1.4.2\bin;f:\Perl\bin\;f:\apps\mks\mksnt;c: \WINNT\system32;c:\WINNT;c:\WINNT\System32\Wbem;f:\apps\Subversion\bin;f:\ap ps\Sybase\SQL Anywhere 9\drivers;f:\apps\Sybase\Shared\Sybase Central 4.3\win32;c:\PROGRA~1\COMMON~1\MGISHA~1\Video;c:\Program Files\Common Files\Adaptec Shared\System;c:\PROGRA~1\COMMON~1\MGISHA~1\Video;f:\apps\mysql\bin DEBUG: SHELL=F:/apps/mks/mksnt/sh.exe DEBUG: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw ;.pys DEBUG: TMPDIR=c:\WINNT\TEMP DEBUG: WINDIR=C:\WINNT DEBUG: SVN_EDITOR=vi DEBUG: JAGUAR=F:\apps\Sybase\EAServer DEBUG: HOMEDRIVE=C: DEBUG: APPDATA=C:\Documents and Settings\ajack\Application Data DEBUG: GUMP_ENV_FILE=/cygdrive/f/data/Python/Gump3-SVN/tsws1-settings.sh DEBUG: OLDPWD=/cygdrive/f/data/Python/Gump3-SVN DEBUG: HOSTNAME=tsws1 DEBUG: NUMBER_OF_PROCESSORS=1 DEBUG: GUMP_CYGWIN=yes DEBUG: PWD=/cygdrive/f/data/Python/Gump3-SVN/pygump DEBUG: GUMP_PYTHON=/cygdrive/c/Python24/python DEBUG: PROCESSOR_LEVEL=6 DEBUG: OS2LIBPATH=C:\WINNT\system32\os2\dll; DEBUG: OS=Windows_NT DEBUG: SYSTEMDRIVE=C: DEBUG: USERPROFILE=C:\Documents and Settings\ajack DEBUG: DEBUG: - command line arguments: DEBUG: ['-c', '--debug'] DEBUG: No projects to build set, defaulting to 'all' _ | __|_ Apache_ ___ | | | | | | . | |_|___|_|_|_| _| |_| ~ v. 3.0-alpha-3 ~ DEBUG - Preprocessor : gump.plugins.instrumentation.TimerPlugin instance at 0x00A82238 DEBUG - Processor: gump.plugins.dirbuilder.RmdirBuilderPlugin instance at 0x00A8CEB8 DEBUG - Processor: gump.plugins.dirbuilder.MkdirBuilderPlugin instance at 0x00A8CEE0 DEBUG - Processor: gump.plugins.builder.ScriptBuilderPlugin instance at 0x00A8CF08 DEBUG - Processor: gump.plugins.builder.AntBuilderAttributePlugin instance at 0x00A922D8 DEBUG - Processor:
Re: svn commit: r164483 - /gump/branches/Gump3/pygump/python/gump/plugins/builder.py
Leo wrote: * pygump/python/gump/plugins/builder.py: commenting out this existence test makes the associated testcase fail under posix. Error log: Sorry, I should've run/fixed the test case. I suspect that failure to find a script file is not more severe an error than failure to execute one, or it failing to execute, so (1) I wonder why we special case it and (2) I don't think we ought exit the plugin on that eventuality. Surely we ought continue and set appropriate properties, with failure to run just being one. No? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help on Gump install
self.rssFile=self.run.getOptions().getResolver().getFile(self.workspace,'rss
','.xml',1)
File C:\gump\python\gump\actor\document\text\resolver.py, line 64,
in getFile
raise RuntimeError, 'Not Implemented on ' + self.__class__.__name__
+ ': getFile.'
RuntimeError: Not Implemented on TextResolver: getFile.
I feel quite dumb at this point I have no idea what to do :) Your help
would be appreciated.
I wouldn't, it is basically 'cos you've got a text-based run going and there
is a bug in Gump. Gump asks the document resolver where to put files ('cos
XDOCs/Forrest output put files in special places) but this simple document
just doesn't know what to do. With Python it is hard to trap such runtime
errors until they occur, and you got landed with it. Now all I need to
figure out is why you have a text-based run and not a XHTML-based one, which
has more of a clue.
regards
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help on Gump install
C:\gump\pythonpython ..\bin\build.py -w ..\metadata\workspace.xml all Oops, staring me in the face I didn't see it. Those direct commands (update/build/etc.) attempt to do a quick semi-interactive text based run, hence the code path that causes the problem. :( I don't have time to look into this now, but please look at running the gump script in the cron directory. That does a full (XHTML) based run, and ought get you further. Good luck w/ this. I'll keep an eye on this list today in case you hit further problems. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need testers for gump3 branch + windows
I just committed some updates to the gump3 branch that on my machine, allow me to run on cygwin+winxp+python2.4-win32. Could some people try and follow Some cygwin testing: $ bash gump webgump hostname: invalid option -- s Try `hostname --help' for more information. ./bin/debug: line 24: /cygdrive/f/data/Python/Gump3-SVN/webgump/lib/apache2-inst all/current/bin/httpd: No such file or directory $ bash gump kill ps: unknown option -- o Usage: ps [-aefls] [-u UID] Report process status -a, --all show processes of all users -e, --everyone show processes of all users -f, --full show process uids, ppids -h, --help output usage information and exit -l, --long show process uids, ppids, pgids, winpids -s, --summary show process summary -u, --user list processes owned by UID -v, --version output version information and exit -W, --windows show windows as well as cygwin processes With no options, ps outputs the long format by default gump: Fatal error! Process ID specified in Pygump lockfile not found, no process to kill! BTW: On posix I was able to lock the pid file and test if that file was still locked, i.e. the process was running. For cron based automatic runs I think that is nicer than requiring a manual kill. Something (IMHO) to add to the wish list sometime. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More jira cleanup!!
(I hope the links all work, you never really know with jira ;) At least for me they didn't 8-) Nor I. I'll poke around when attempting to use JIRA stops giving me 502 Proxy Error status. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r161906 - in gump/branches/Gump3: ./ gump pygump/main.py pygump/python/gump/config.py pygump/python/gump/plugins/builder.py
Propchange: gump/branches/Gump3/
('svn:ignore' removed)
I tried setting svn:ignore on my Gump.wpr file, and couldn't since it isn't
under version control. As such, I tried setting it, for this file, for the
directory -- which seems right, but almost seemed to be ignoring the
directory. I'll fix it next time I get time.
regards
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
I dunno. Could be. Could you be a little more specific about what you're seeing and when what pauses? On every 'run' invocation the 'gump' shell scripts removes *.pyc then recompiles and re-imports, that's part of the delay. It seems like the program runs, and only once done I see output. Basically I get a long wait, and then a super fast spew of output, and it is done. 2) Why do some things (like DEBUG - Outputting all log data (a lot)...) come out to the console, but not the rest of the logging information? That's configured in the log config, console and file use slightly different formatters. What do you think it should be? I thought this was a line from within plugin, which ought run within the 'proper' logging. I thought what was coming to the screen was the gump bash script output (and the 'proper' to the log file) and I didn't understand why this'd be in there. Perhaps I just have that backwards. [I see that rather than fork another process for the pygump engine run we import and run it. I assume that and SVN run (updating the pygump/.../*.py file) ought not be imported at that point, but I feel like I'm seeing what feels like a log 'bleed' that suggests otherwise.] I don't get the above. What? Gump2 did the main checks, did the SVN update, and then launched Python again (in the hope of ensuring that no *.pyc was cached frmo prior to a *.py SVN update.) I see Gump3 isn't doing that. I was wondering if somehow the two logs were bleeding into each other, via the shared Python runtime. Eh, no. Could you send run.log and gump_log_xxx along with console output? I've got a feeling you're not seeing the same thing I'm seeing... In doing this, I realize that the gap before the Gump banner, combined with the quick spew, combined with the size of my terminal window, meant I was only really noticing what was after the banner. Still it seems to be missing some nice details. Also, I've attach the contents of the work/log directory below the asterisk line. $ bash gump run --debug DEBUG: logdir is f:\data\Python\Gump3-SVN\pygump\work\log DEBUG: Pygump version 3.0-alpha-3 starting... DEBUG: (the detailed log is written to f:\data\Python\Gump3-SVN\pygump\work\lo g\gump_log_20050419_132247.txt) DEBUG: - hostname : tsws1 DEBUG: - homedir: f:\data\Python\Gump3-SVN DEBUG: - current time : 19 Apr 2005 13:22:47 DEBUG: - current time (UTC) : 19 Apr 2005 19:22:47 DEBUG: - python version : 2.4 (#60, Feb 9 2005, 19:03:27) [MSC v.1310 32 bit (Intel)] DEBUG: - python command : /cygdrive/c/Python24/python DEBUG: - environment variables: DEBUG: TMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: DEPOT_UPDATE_HOME=F:\data\OSS\depot-update DEBUG: COMPUTERNAME=TSWS1 DEBUG: USER=ajack DEBUG: USERDOMAIN=TSWS1 DEBUG: COMMONPROGRAMFILES=C:\Program Files\Common Files DEBUG: PROCESSOR_IDENTIFIER=x86 Family 6 Model 8 Stepping 3, GenuineIntel DEBUG: CVS_RSH=/bin/ssh DEBUG: PROGRAMFILES=C:\Program Files DEBUG: PROCESSOR_REVISION=0803 DEBUG: HOME=c:\ DEBUG: SYSTEMROOT=C:\WINNT DEBUG: CATALINA_HOME=F:\apps\Apache\jakarta-tomcat-5.0.19 DEBUG: MA_AGENT=c:\PROGRA~1\sybase\MANAGE~1\rstate.exe DEBUG: INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/d evel/info:/usr/autotool/stable/info: DEBUG: GUMP_HOME=f:\data\Python\Gump3-SVN DEBUG: PRINTER=HP OfficeJet DEBUG: TEMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: SHLVL=2 DEBUG: PROCESSOR_ARCHITECTURE=x86 DEBUG: J2EE_HOME=F:\apps\j2sdkee1.3.1 DEBUG: APR_ICONV_PATH=F:\apps\Subversion\iconv DEBUG: ALLUSERSPROFILE=C:\Documents and Settings\All Users DEBUG: ROOTDIR=F:/apps/mks DEBUG: BPE_HOME=F:\apps\Sybase\bpee DEBUG: _=/cygdrive/c/Python24/python DEBUG: MANPATH=/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel /man: DEBUG: HOMEPATH=\Documents and Settings\ajack DEBUG: GUMP_HOSTNAME=tsws1 DEBUG: GUMP_WORKDIR=f:\data\Python\Gump3-SVN\pygump\work DEBUG: JAVA_HOME=c:\j2sdk1.4.2_08 DEBUG: USERNAME=ajack DEBUG: LOGONSERVER=\\TSWS1 DEBUG: PROMPT=$P$G DEBUG: COMSPEC=C:\WINNT\system32\cmd.exe DEBUG: MAKE_MODE=unix DEBUG: PYTHONPATH=f:\data\Python\Gump3-SVN\pygump\python;f:\data\Python\G ump3-SVN\pygump DEBUG: XINDICE_HOME=F:\data\OSS\xml-xindice DEBUG: TERM=cygwin DEBUG: PATH=C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin \usr\X11R6\bin;c:\Python24\;f:\apps\Sybase\Shared\ASA802\win32;c:\Python23\; c:\P ython23\Scripts;f:\apps\javasoft\j2sdk1.4.2\bin;f:\Perl\bin\;f:\apps\mks\mks nt;c :\WINNT\system32;c:\WINNT;c:\WINNT\System32\Wbem;f:\apps\Subversion\bin;f:\a pps\ Sybase\SQL Anywhere 9\drivers;f:\apps\Sybase\Shared\Sybase Central 4.3\win32;c:\ PROGRA~1\COMMON~1\MGISHA~1\Video;c:\Program Files\Common Files\Adaptec Shared\Sy stem;c:\PROGRA~1\COMMON~1\MGISHA~1\Video;f:\apps\mysql\bin DEBUG:
Re: [RT] module, project, target = repository, module, project...
I'm tempted to do a radical remodelling of our metadata structure to remove this kind of ambiguity, even going as far as having conventions like project-name-is-file-name be gently enforced. We are rebuilding Gump from the bottom up, so why not do the same with the metadata? I'm game for it. I say we create a Gump3 workspace on Brutus to run the minimum (e.g. up to Ant) and we work and re-work it until we like it. We can throw in all the rotton test cases we like, like Jakarata Commons and so forth. Once we like it we can migrate the whole set of metadata, which we could likely script (for 80+%). Oh, ehm, I was even briefly tempted to turn our model into RDF but there ain't that many good tools for RDF editing :-D I'm repeating what Iv'e written before, but for my tuppence ... I think folks are most comfortable with XML, even if RDF good sense as a set of statements about a module/project/artifact. I say we stick w/ XML, have us generate RDF triples to match the metadata, and (eventually) allow RDF for input (when we allow Maven descriptors, etc.) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar required.
Aruna wrote: I'm in need of the rhino jar. Can you pls send it to me. I don't know the current version of the jar I've been using, but its reporting error in optimizer and regexp packages. I would be of great help if you could mail me the latest jar. Jars built/used by Gump are not suitable for general consumption. I believe that you ought be able to get what you want from here: http://www.mozilla.org/rhino/. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 inter-component orchestration/communications
I'm not wanting us to design a generic mechanism, just solve our problem, but is the approach the right one? Why are these three walks better than (say) putting Updates/Builders/Databasers(DynaGumper) in sequence inside one mutlicast plugin? Do you think we could do without multiple stages completely? I think it just comes down to order. The walker logic I've preferred most is the one that iterates through projects, visiting modules (and repositiories and workspaces, etc.) on demand (for those projects) and visiting each plug-in in sequence. A sequence of (1) start time stamp (2) build (3) end time stamp (4) DB update (5) notify -- seems fine w/o need for pre or post processing. So, I guess (as of my view right now) yes, maybe. That said, I've not thought throguh some of the more intelligent behaviours we'd like, such as aggregations (so we don't spam folks w/ e-mails or RSS/Atom feeds, etc.) One side effect of the current approach is that (during a long slow build) we'll only update the database at the end of the run, after all modules have been updated and all projects have been built. This was something we found unpleasant w/ Gump2, 'cos folks want more instant gratification. Really? I've always found it really annoying to want to debug something and then seeing that a build is in progress meaning part of that tree is from the run before and part of it is new. Very confusing... Yup, agreed, but that is something I hope we can fix with the Gump3 separation of run from presentation, via DB. Given that we'll uniquely identify DB updates per run, they ought be able to be made any time, and the presentation still show last complete run w/o confusion. This all said, I'm in no hurry to redesign things and remove the three phase, I was just wondering. Time will tell. BTW: One last thought property bloat leading to memory bloat. I've found with Python (for Gump2) that object/property bloat can really clog things up. Sure, a lot of it was the DOM tree (and those are being pruned) but I do think we'll hit this later, with full runs. I'm not saying we ought think about this now (I just have scars from months of fighting performance, so can't forget) but we might want some sort of Reaper plug-in that keeps us lean. That'd need to run after all plug-ins for a project. Again, time will tell... regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xml-apis updated
I've updated the metadata to place over JAXP 1.2 for now. regards Adam - Original Message - From: Maarten Coene [EMAIL PROTECTED] To: Gump code and data general@gump.apache.org Sent: Tuesday, April 12, 2005 12:03 PM Subject: Re: xml-apis updated dom4j seems to have problems with the new xml-apis as well... http://brutus.apache.org/gump/public/dom4j/dom4j/index.html regards, Maarten Stefan Bodewig wrote: On Sun, 10 Apr 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote: Looking at the run I've set off some things are not happy, e.g XALAN: This is to be expected - and this is why we had to play with xml-apis and bootclasspath and build.sysclasspath in order to get everything built under JDK 1.5 or Kaffe (which contain JAXP 1.3 in their version of the classlib already). We probably should add an xml-apis-12 project (either the one from the XML pack or the tck-jaxp-1_2_0 branch in xml-commons) and provide this to Xalan, Xerces and any other project we detect which won't build with JAXP 1.3 yet. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xml-apis updated
This is to be expected - and this is why we had to play with xml-apis and bootclasspath and build.sysclasspath in order to get everything built under JDK 1.5 or Kaffe (which contain JAXP 1.3 in their version of the classlib already). We probably should add an xml-apis-12 project (either the one from the XML pack or the tck-jaxp-1_2_0 branch in xml-commons) and provide this to Xalan, Xerces and any other project we detect which won't build with JAXP 1.3 yet. Thanks for doing this (I see the commits). Is there a way we could duplicate the Xalan project and have one build on 1.2 (that others depend upon) but have another build upon 1.3 (for reference as folks migrate?) [Or, do we merely need to use JDK1.5 or Kaffe for that?] BTW: Were the JAXP interface changes really 'necessary discontinuities'? Or, is it just too late for such a discussion topic? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project xom.xml
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 that date. :-) ] regards Adam - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 09, 2005 7:22 PM Subject: cvs commit: gump/project xom.xml ajack 2005/04/09 18:22:08 Modified:project xom.xml Log: Undo the only real thing that occured on the 6th. See if this is causing Gump to spin. Revision ChangesPath 1.11 +2 -1 gump/project/xom.xml Index: xom.xml === RCS file: /home/cvs/gump/project/xom.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- xom.xml 6 Apr 2005 11:54:55 - 1.10 +++ xom.xml 10 Apr 2005 01:22:08 - 1.11 @@ -25,8 +25,9 @@ packagenu.xom/package ant target=jar property name=version value=@@DATE@@/ - + !-- property name=jaxen.jar reference=jar project=jaxen/ +-- /ant depend project=ant/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xml-apis updated
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 bitten pretty severely the next time it does since xml-apis is a prereq for Ant. Thanks for the two heads up Peter, the Brutus Gump down and this. Ok, so perhaps stepping in where angles fear to tread ... I installed JAXP-1_3 as a package, and edited the jaxp project (in xml-commons), along with the package declaration in the gump profile, to reference these new guys. I'm not comfortable about mixing them in with the rest of the XML pack, but I guess I'll learn from it. Looking at the run I've set off some things are not happy, e.g XALAN: http://brutus.apache.org/gump/public/xml-xalan/xalan/gump_work/build_xml-xalan_xalan.html but I'm not sure if this is a legit (changed interface) problem, or if I ought be looking for other updates (to add along with JAXP 1.3). I'll look into it as I get time. Amazingly my WISP link is coping w/ the two foot of snow we have up here this morning, but I'm not sure how long that'll last (or when it'll stop snowing :-). If I get cut off for a while, and others can figure out what is occurring, please do help out. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Random Gump3 questions
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 expressed (over and over) by folks w.r.t Gump2. Given that one main reason for Gump3 is to get community developers involved, and since allowing them to write simple plug-ins is a good way to empower external developers, I'd like to have this ability. I'd prefer having it as a small one by leveraging python's features for this kind of stuff as much as possible :-D. What do you think of the idea above? I like the concept of what you said, and agree to leveraging Python to keep it simple. I'm kinda surprized there isn't some plug model or module pre-existing, but I'm not good at search the net for things like that. For a home grown solution, I'm not so sure about editing a file, I might prefer us simply placing python scripts in a certain plug-ins directory, finding them, loading them, and calling a pre-defined 'insert yourself into me' method. Again, before anything is implemented, I think I ought do some web searching though. 2) OnDemand Metadata Loading Ok, so I'll just start w/ a simple/small profile for my 'live' testing. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need testers for gump3 branch + windows
http://wiki.apache.org/gump/GumpThree And let me know where it breaks? I'm new to Cygwin, so probably failed to install things exactly as you specified (a problem for later stages, I suspect), however, I can't seem to get past the mysql step. $ bash gump test gump: line 1: /cygdrive/f/data/Python/Gump3-SVN/bin/PrintPath: No such file or d irectory gump: Fatal error! Cannot find mysql. Please retrieve it from http://www.mysql.com/ and install it. If it is already installed, modify your $PATH variable to point to it. You can customize the $PATH variable inside a file named /cygdrive/f/data/Python/Gump3-SVN/tsws1-settings.sh if you wish. [EMAIL PROTECTED] /cygdrive/f/data/Python/Gump3-SVN $ which mysql /cygdrive/f/apps/mysql/bin/mysql regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need testers for gump3 branch + windows
For those reading along, Adam and I find out on ICQ that his bin subdirectory was in some way wrong containing entirely different cruft. Hence, he was missing PrintPath and testrunner.py Yeah, I think I must've used an old old SVN client that (due to some change in the repository) completely dork the directory. I assume it failed to follow a move or something. If other see python and such under bin, look to your SVN client... regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Walking around gump code (svn commit: r160101...)
Quick Q: how do you find the location to make small changes like this when you fire up your development environment, and how do you test to make sure its the only thing to change? In this case, I guess I believed I knew it, based on prior knowledge of the code, i.e that all things to do with environment checking are in that location. That said, I pretty much do a text search through the code. [Given I reverted to Eclipse, Wings still is a bit flaky for me and I haven't found a Python IDE I like, I don't have a better solution. Do you? I'd like to find one.] How do you test a simple change like this works? I run gump in the cron directory, and my local environment has: GUMP_NO_CVS_UPDATE=true GUMP_NO_SVN_UPDATE=true GUMP_WORKSPACE=python\gump\test\resources\full1\tsws1 this causes a run of the test workspace data. Unfortunately (as your mail made me realize) this isn't as good a test as I'd like. This is fine for a lot of the 'mechanics' but not for a true full run. Basically, the data in that workspace does not cover enough codepaths. [Clearly this has been noticed w/ my 'multiple commits', so I can test on TEST.] I've always struggled with testing Gump 'cos I don't have the most conducive environment (no Linux, slow link, etc.) That said, I think I need to make a better effort, and make a small workspace I can really work on. BTW: This brings me back to the point you made about me not using unit test. Interestingly, I consider myself a reasonably test infected kinda guy, but you aren't wrong ... I'm not using them aggressively for Gump any more. I've tried to consider why, and lack of IDE/(Pant = PyAnt ;-)scriptability and all are factors. That said, I did really try. Python needs code coverage or it is a walking time bomb of runtime errors, so I really wanted to... I added the gump unit tests to the workspace, I added a script to try to run tests, to run pychecker, etc. I suspect I simply stretched myself too thin, and didn't get things right, but one big factor was 'environment'. There is something (IMHO wrong) about Python launching other Python scripts, and not using the PYTHONPATH for it, but having to know the path to the main script. That caused some of these things to be harder than they ought be, and hence fall by the wayside. [Take for example the fact of how nobody seems to have a decent Gump command line interface. It isn't just us, the 4 or more people who have tried, there is something (IMHO) hard about doing this right in Python. If I could put my finger on it I'd blog about it in detail looking for assistance, or better yet ... fixed it! ;-)] Also, I think Gump problems always seemed to show up in runs, due to metadata or environment or something, and not in simple Python code (other than time bombs). I wrote unit tests, I wrote test environments, but I always had a gap between this coverage and live. Even when Gump passed it's unit tests, it still failed in runs. Perhaps the implementation was too shallow, or something, but I found it too hard to write unit test for the main/core parts. [One of the reason I went to runners/actors/etc. was to see if I could get inside this aspect.] Perhaps I needed integration tests, but those ended up best being the TEST environment. In short think it is part Python, and part Gump's functionality, and part individuals/time/focus as to why unit testing isn't playing a bigger role. Basically, I love testing, I believe it is more critical for Python than anything else, and I'm game to give it another shot. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: [Gump Wiki] Update of GumpThree by LeoSimons
This came to the Gump mailing list, but says it is going to itself. Is this
something we need to configure on our wiki? [My e-mail tool didn't put this
into my Gump list for this reason.]
regards
Adam
- Original Message -
From: Apache Wiki [EMAIL PROTECTED]
To: Apache Wiki [EMAIL PROTECTED]
Sent: Tuesday, April 05, 2005 4:35 PM
Subject: [Gump Wiki] Update of GumpThree by LeoSimons
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Gump Wiki for
change notification.
The following page has been changed by LeoSimons:
http://wiki.apache.org/gump/GumpThree
The comment on the change is:
instructions in windows/cygwin with Gump3 branch
New page:
Gump3 is a substantial rewrite effort for gump. This is a collection of
semi-random notes. If you're not a gump developer, you're not interested :-D
= Gump3 on windows =
You need at least:
* [http://www.cygwin.com/ Cygwin]. Make sure to get at least the base
and development packages sort-of completely; without the which and
hostname commands you'll be in trouble for sure. Probably a good idea to
add C:\cygwin\bin and C:\cygwin\sbin to your PATH, which you can do via
right clicking My Computer Properties Advanced Environment Variables
* [http://www.python.org/ Python]. You need version 2.4 or later. Make
sure to add the location you installed it (usually C:\Python24) to your PATH
*before* the cygwin paths, or otherwise make sure you don't install the
cygwin versions of python.
* [http://subversion.tigris.org/ Subversion client]. I recommend the
latest stable version. The installer modifies your PATH for you.
* [http://www.mysql.com/ MySQL]. I recommend the latest stable version.
* [http://java.sun.com/ Java]. I recommend the latest version in the
1.4.x series. Set JAVA_HOME to point to wherever you install it
Fire up a command window. Do something like:
{{{
rem or wherever you do your development...
cd c:\
mkdir svn
cd svn
rem this will take long, Gump is a big download!
svn co https://svn.apache.org/repos/asf/gump/branches/Gump3 gump3
cd gump3
rem ...this should show some useful help output...
bash gump help
rem ...this will show you prerequisite failures...
bash gump test
rem ...this will show database errors...
bash gump run
rem so lets install a database
cd gumpdb/src/sql
rem create a gump user with permissions to the gump database first,
then
mysql -u root -p gump gump3-database-definition.sql
rem cross your fingers! It might work...
bash gump run
}}}
There is some more stuff you need in addition to bash, python and svn. The
script will attempt to inform you about that. Try and do what it says. Once
you get stuck (no doubt there'll be unixisms), let us know!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: Project dumbster (in module dumbster) failed
So why does Gump think there is a problem here ? It is something to do with the tests failing. Does Dumpster open some ports and try to connect to it? [Or, is it all in memory?] http://brutus.apache.org/gump/public/dumbster/dumbster/gump_work/build_dumbster_dumbster.html test: [junit] Running com.dumbster.smtp.AllTests [junit] Tests run: 16, Failures: 0, Errors: 5, Time elapsed: 0.444 sec BUILD FAILED /home/gump/workspaces2/public/workspace/dumbster/build.xml:89: Test com.dumbster.smtp.AllTests failed If needs be we can turn on capturing/publishing of junit unit test output, if that'd help.regards,Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Last public Gump runs used Kaffe
Why? Likely 'cos way back when I wrote this, I didn't know that (cross platforms) this was a standard location. It isn't, but I thought it was Gump's standard location. After all we are setting JAVA_HOME in each of our workspaces. Maybe for Ant's boot, I vaguely recall something like that? Most likely, just a guess on my part. I'm game to code it to $JAVA_HOME/bin/java and allow folks to override it via $JAVA_CMD. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Not building src-apache?
Dear Sir/Madam, I was taking a quick look into why this build [1] for XSDLIB [2] started failing on Apache Gump [3]. (It is a project with a lot of dependees, see [4]) It seems that this class (amongst, perhaps others) is not being built, or not being placed on the classpath. [EMAIL PROTECTED] /usr/local/gump/public/workspace/msv/xsdlib $ find . -name RegularEx\* -print ./src-apache/com/sun/msv/datatype/regexp/RegularExpression.java giving: /home/gump/workspaces2/public/workspace/msv/xsdlib/dist/src/com/sun/msv/data type/xsd/regex/REUtil.java:286: cannot resolve symbol [javac] symbol : class RegularExpression [javac] location: class com.sun.msv.datatype.xsd.regex.REUtil [javac] static final RegularExpression[] regexCache = new RegularExpression[CACHESIZE]; [javac] ^ Is it possible that the apache-src set of code is not being built, or that (perhaps) it is being built into a directory that Gump isn't adding to the classpath? Would you mind investigating (and the is a lot of build information at [2]) and reporting back here? If there is a Gump descriptor mismatch we'll help fix it. Thanks in advance for your consideration. regards Adam [1] http://brutus.apache.org/gump/public/msv/xsdlib/gump_work/build_msv_xsdlib.html [2] http://brutus.apache.org/gump/public/msv/xsdlib/index.html [3] http://gump.apache.org [4] http://brutus.apache.org/gump/public/project_todos.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Last public Gump runs used Kaffe
* why does Gump use /usr/bin/java instead of $JAVA_HOME/bin/java at all?
Why? Likely 'cos way back when I wrote this, I didn't know that (cross
platforms) this was a standard location. As such , I kinda relied upon the
path.
self.javaCommand = 'java'
That said, we do have the ability to set this in (say) the gump.sh (if
hacking the Python isn't a preferred idea.)
# JAVA_CMD can be set (perhaps for JRE verse JDK)
if os.environ.has_key('JAVA_CMD'):
self.javaCommand = os.environ['JAVA_CMD']
self.addInfo('JAVA_CMD environmental variable setting java command
to ' + self.javaCommand )
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Moving to python 2.4 for Gump3
I propose we start requiring Python 2.4 for Gump3. Stefan's concerns outstanding, I'm ok with this. Motivation: 1) the subprocess module described in PEP 324 finally properly solves running processes within python using a decent interface. It's new in python 2.4. Needless to say, we run a lot of subprocesses! Good find, looks nice. It does seem to have the abilities I've been seeking, including passing environments in a thread safe manner. I suspect, however, we'd still want to (on posix) set the process group leadership prior to invoking the subprocess, and later (if needed) killing the process group. [Almost seemed we could use the preexec_fn to do this, but I suspect we'd still need to fork (to get the child pid/group id).] This won't be available to us on Windows, but then we are no worse off than today. Maybe we'll pickup some (small) mileage from being able to close the processes stdout/stderr. I assume we'd close stdin from the start. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump [brutus-public]
On Wed, 30 Mar 2005, Stefan Bodewig [EMAIL PROTECTED] wrote: On 30 Mar 2005, [EMAIL PROTECTED] wrote: 'MySQL server has gone away' I've upgraded MySQL on brutus as part of an overall upgrade today, I didn't see any messages about problems during the upgrade. This was around 5:30 local time on Brutus I logged off 5:50 local time. The public gump run (last night) failed due to SVN issues. I started the job again (eager to see if I'd truly fixed the XALAN sync problem.) Ok, we can either re-restart or I can wait patiently. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump [brutus-public]
Hmm, shouldn't the Kaffe run have picked it up as well (the sync changes)? Only since I did the migration of TRUNK to LIVE. Hmm, for some reason java_cup is fine for Kaffe and the run claims it had been fine for 17 runs. Oddly TEST seemed to be working also, back when PUBLIC wasn't. I don't get it. The only difference ought be that those two use the new shared staging area, but heck -- the sync part ought be used anyway. The files are there in both the shared staging and the Kaffe area. Maybe (somehow I don't quite get) in those runs (due to differences in the workspace) we had a plain string, not a Unicode string, as the module path. That is a wild guess/long long shot... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brutus may have more downtime
The mailserver (hermes) has been flaky since we did the colo move. Some bits of brutus may be required to fix it, which means we may have more downtime. Sorry :/ Are there any backups/snapshots of Brutus (configurations, installs, whatever) that we can/should take in case we end up loosing something significant? I believe I've seen that Brutus has given up a power supply, what else is likely to be taken? Memory? CPUs? Disk? Just curious (I do understand the priority towards mail.) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump dependancy on MySQL - is this necessary?
Is there a way to avoid the dependancy on mysql in gump? Yeah, it is an optional dependency. Ought cope gracefully if the Python MySQL driver isn't there, and/or if the workspace doesn't give DB details. That said, what are you seeing? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
