xml-apis updated
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. The new version is available for download for pre-J2SE5.0 at URI:https://jaxp.dev.java.net/. Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: help please with Gump Forrest
Stefan Bodewig wrote: On Wed, 09 Feb 2005, Peter Janes [EMAIL PROTECTED] wrote: The way to fix the build is to use namespacing, one way, not *the* way. The other way is to use the xml descriptor instead of the properties file as resource in the taskdef. Ah, I should have left it to the Ant master instead of being all clever-like. :) A one-line fix is definitely easier than a maze of twisty little namespace prefixes. In my defense, the usage you presented isn't really made clear in the Ant docs for taskdef/, typedef/ or antlib/--in the first two the examples use .properties files, and I found the latter confusing--and the ant-contrib website doesn't mention that it can be used as an antlib at all. For what it's worth, I like the namespace version: it clearly defines what is Ant and what isn't. Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: help please with Gump Forrest
We do have a depend entry for ant-contrib which provides that for task, but Gump does not seem to pick it up. Is our descriptor missing something, e.g. a nested entry for the ant or something? Sorry, i cannot figure it out. ant-contrib recently removed the for task from the antcontrib.properties file, so the only way to get it is via antlib. for depends on Ant 1.6, which also introduced antlibs, so it's a way to enforce that version. There were several messages on their cvs list that said this will break a lot of builds, but when I last looked they seemed fine with that. The way to fix the build is to use namespacing, which is also part of 1.6. First, remove the taskdef/ that loads the properties file. Then add a namespace definition to your project/ tag... project ... xmlns:antcontrib=antlib:net.sf.antcontrib and then use that namespace to prefix all of your ant-contrib tasks... antcontrib:for param=foo ... /antcontrib:for Hope this helps, Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: kaffee local-env-brutus.sh on brutus
Dalibor Topic wrote: Traceback (most recent call last): File gump.py, line 118, in ? main(sys.argv) File gump.py, line 108, in main getattr(command, process)(options,arguments) File /var/tmp/topic/gump/python/gump/commands/build.py, line 41, in process workspace = WorkspaceLoader(options.isCache()).load(ws) any idea what's going on? That looks like the same problem I just had, although I was running the gump.py in the root directory rather than the cron directory. I believe you need to run gump.sh from within the cron directory (cd cron ./gump.sh) since it uses the gump.py in the current directory. Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: Problems running gump (both trunk and live)
Gareth Webbley wrote: The way I got around this problem was to cd to the cron directory and either run gump.sh in that directory or python gump.py. There is another copy of gump.py in the cron directory which works differently to the one in the root directory. I think this is the one used in the official runs. That seems to do it, thanks. Oddly, the getting started page gives instructions on installing and configuring Gump, but stops just short of actually *running* it. :) -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: Problems running gump (both trunk and live)
Stefano Mazzocchi wrote: The status of the gump.py file in the root is *up in the air* at best and totally untested for a lot of things. In short, it's a mess. [...] So, for now, use the cron script or you can help me out and fix the bugs :-) Love to, but I think I've exhausted my Python knowledge. If I get a chance I'll submit a patch for the getting started page though. :) -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Problems running gump (both trunk and live)
I've recently synced both the trunk and live branch of Gump (which are identical as of revision 56892) and have a problem running both of them. If I execute python2.3 gump.py build I get the following traceback: Traceback (most recent call last): File gump.py, line 118, in ? main(sys.argv) File gump.py, line 108, in main getattr(command, process)(options,arguments) File /home/pjanes/devel/tempo/thirdparty/gump-live/python/gump/commands/build.py, line 41, in process workspace = WorkspaceLoader(options.isCache()).load(ws) AttributeError: 'list' object has no attribute 'isCache' I think it's a scope problem--gump.core.run.options is imported, but the process() method takes an argument named options--but I'm at a loss to explain why my version doesn't run and the Apache one does. Any takers? Also, I notice that http://gump.apache.org/gettingstarted.html directs new users to check out the trunk (i.e. potentially unstable) version instead of the live branch. Would it be more appropriate to send them to live instead? Thanks, Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems running gump (both trunk and live)
I've recently synced both the trunk and live branch of Gump (which are identical as of revision 56892) and have a problem running both of them. If I execute python2.3 gump.py build I get the following traceback: Traceback (most recent call last): File gump.py, line 118, in ? main(sys.argv) File gump.py, line 108, in main getattr(command, process)(options,arguments) File /home/pjanes/devel/tempo/thirdparty/gump-live/python/gump/commands/build.py, line 41, in process workspace = WorkspaceLoader(options.isCache()).load(ws) AttributeError: 'list' object has no attribute 'isCache' I think it's a scope problem--gump.core.run.options is imported, but the process() method takes an argument named options--but I'm at a loss to explain why my version doesn't run and the Apache one does. Any takers? Also, I notice that http://gump.apache.org/gettingstarted.html directs new users to check out the trunk (i.e. potentially unstable) version instead of the live branch. Would it be more appropriate to send them to live instead? Thanks, Peter J. -- Fighting a war is easy. Destroying is easy. Building a new world out of what's left of the old, that is what's hard. -- J. Michael Straczynski Lenni Jabour and The Third Floor - http://peterjanes.ca/LenniFan/ Petroglyphs - http://peterjanes.ca/blog/ Sirens - http://www.sirens3.com/ smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
Gump wrote: Dear Gumpmeisters, The following 1 notifys should have been sent Sorry folks, this run got away on me. Please go about your business, nothing to see here. :) -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: maven, gump, developer effort
Leo Simons wrote: I will assert that the most serious concern with gump is that it is too hard to use, understand or improve for non-gump-gurus. If this were a componay and I were the boss, the first thing I would tell people to work on is a much more readable and enticing website. Ie What is Gump? Gump is a social experiment. is not very successful marketing-wise. For what it's worth, I don't think it's too hard to use or understand. (Times below are approximate because I've been doing this as a side project for work whenever I've had a few free cycles.) I had my very first experience setting up classic XSLT Gump just before it was removed from CVS, based only on the GOM docs on the website and the existing metadata files. Within a couple of days I'd extended it to perform Perforce-based checkouts. I used a half-dozen of the official metadata modules but the vast majority are homegrown. Migrating the classic install to Python Gump, sans Perforce support, was a snap. Adding Perforce took a little while longer--about a week--but that was mostly due to my unfamiliarity with Python and the structure of the code. There are certainly things to be improved, most of which are being discussed in other threads right now. Of greatest importance (to me, at least) are reporting and nagging, both of which are pretty heavyweight: the classic versions were much friendlier. It would also be nice to achieve parity with classic Gump, specifically supporting the javadoc/ element. The internals aren't the easiest thing to dive into to make changes, or I'd probably have added support for publishing Javadocs to the artifacts repository myself. All in all, I don't think Gump for users is as horrendous a beast as you've made it sound. I don't consider myself a gump-guru in any sense, but I've had more trouble getting Ant to run some of our less trivial builds than I had installing, configuring and running Gump to build the 60-odd projects we have in-house. I don't understand Maven *at all*, and I've tried a couple of times. The second thing I would have my team do is to get in place a double-click (and/or configure; make; make install) installer. Which would do what exactly, other than unzip the distribution into a directory? I'm just curious--other than getting SVN, Java and the right version of Python onto a new machine, it took me all of 5 minutes to completely reinstall my entire Gump setup, so I don't understand why an installer would be worth the effort. (Unless you're talking about rolling out Gump to every person on a team... in which case my question would be why?) Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project ant.xml barcode4j.xml depot.xml excalibur.xml gump.xml j2ee-connector.xml jaas.xml jakarta-cactus.xml jakarta-velocity.xml jstl-jsp-12.xml jts.xml jython.xml mx4j.xml scarab.xml ws-axis.xml ws-juddi.xml wss4j.xml xml-xalan.xml
Adam R. B. Jack wrote: All builders (Ant|Maven|NAnt) and updaters (CVS|SVN|P4 -- I think) support: debug=true|false verbose=true|false I didn't include anything specifically for debug/verbose in the P4 updater, so it probably ignores those attributes. There's not much extra info that it can give anyway, so I think it's okay to have them as no-ops. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Perforce for Python Gump?
I've written some basic Perforce support for Traditional Gump, based very much on the cvs repository support. However, since Trad Gump is in the process of being replaced by Python Gump, I'd like to migrate the Perforce support as well. Would anyone be able to provide pointers on what parts I should be looking at, and/or answer some followup questions (off-list)? So far I've figured out how to add a repository of type p4, and I think I'll have to add a P4Updater in python/gump/update, but I'm not clear on whether this will be sufficient. Thanks, Peter J. -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
