[jira] [Assigned] (GUMP-148) Clean up entire codebase and add documentation
[ https://issues.apache.org/jira/browse/GUMP-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leo Simons reassigned GUMP-148: --- Assignee: (was: Leo Simons) Clean up entire codebase and add documentation -- Key: GUMP-148 URL: https://issues.apache.org/jira/browse/GUMP-148 Project: Gump Issue Type: Task Components: Python-based Gump Affects Versions: Gump3-alpha-7 Reporter: Leo Simons Fix For: Gump3-alpha-7 It'd be nice if the gump codebase could get some time to stabilize after this milestone. To be confident we don't get too much bit rot, its important to take a big stroll through the codebase, adding javadocs, rolling up unrolled algorithms, getting rid of code duplication, standardizing method names, etc etc. Let's use this issue for code review reporting. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: vmgump2
Hey guys, On 8/9/10 5:17 AM, Stefan Bodewig wrote: On 2010-08-08, Stefan Bodewig wrote: vmgump2 sends nag emails to me right now, but if the current run works like I expect it to, I'll enable nagging there and turn off nagging on vmgump. Done now. Starting midnight GMT vmgump2 will take over as the official machine. Just checking in after ignoring my e-mail for some 2 months (*). Sorry I missed all the fun! Awesome work, though! Are you guys all up and running again now or is there anything more that needs attention? For example did you figure out the wonders of mysql to the degree you wanted to? Let me know. cheers, Leo (*) I can totally recommend it ;) - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Parallelism (was Re: A Few Plans)
On 6/21/10 5:34 AM, Stefan Bodewig wrote: This would allow for a little more concurrency than we can do on the Zone or VM... of course we'd have to be able to address all of those cores. Wonder whether Python has glue for Grand Central Dispatch? Most of the weight in gump runs is inside the java processes; the other half of the latency is svn checkouts/updates. For the former, you'd need (a) the JVM to hook up GCD (which is for apple to do) and (b) maven to do more stuff in parallel (which is on the charts for maven 3 I think). For the latter, IIRC we have code to run more checkouts in parallel, but the code is buggy in gump2; and would mean a load increase on the svn server which may not be a good thing? If you log into one of the machines while Gump is running, the system feels sluggish and any opration that hits the file system takes ages which makes me fear we are I/O bound rather than CPU bound - making those cores do more may not help too much in that case. I can certainly be wrong. You're absolutely right. Builds are almost always I/O bound and you'll see a lot of CPU is actually iowait -- so the numbers in top are usually misleading and most of CPU busy-ness is due to overhead of waiting for IO. IIRC Gump's trunk supports parallel SCM checkouts but we've restricted it to a maximum of one updater because Adam saw problems - it's been a long time. Oh, eh, yep, so that's what I remember too :) In any case to take advantage of multicores it'd be good to re-implement parallelism using python's multiprocess module. Currently we don't support building things in parallel at all. Starting several Ant or make builds in parallel would likely do what you expect, but I don't know how mvn would deal with multiple processes accessing the same local repository (and writing to it) in parallel. I don't think there's any special code for it in maven, but nevertheless I've never really seen an issue with that. A common hudson deployment is to run 4-5 builds in parallel using a 'hudson' user that has one local repository. cheers, Leo PS: no I'm not dead just persistently e-mail overloaded :) - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: How to depend on legacy projects?
Hey sebb, On Sat, Sep 19, 2009 at 10:50 AM, sebb seb...@gmail.com wrote: JMeter currently depends on some legacy Excalibur modules: excalibur-datasource-1.1.1.jar excalibur-i18n-1.1.jar excalibur-instrument-1.0.jar excalibur-logger-1.1.jar excalibur-pool-1.2.jar Are you sure it really needs those specific versions? Modulo various small build system / packaging differences, the excalibur codebase has not changed significantly in many many years; I would kind-of expect JMeter to work with current excalibur trunk... ciao, - Leo - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: validate script and Maven 2
Hi Roland, Patch applied, thanks! (I also added some attributes for nant/ while I was there.) cheers, - Leo On Dec 30, 2007, at 9:25 AM, Roland Weber wrote: Index: dtd/project.dtd === --- dtd/project.dtd (revision 607521) +++ dtd/project.dtd (working copy) @@ -22,10 +22,11 @@ +-- !ELEMENT module ( url | description | nag | cvs | svn | p4 | redistributable | project )* -!ELEMENT project ( ant | maven | nant | script | configure | make +!ELEMENT project ( ant | maven | mvn | nant | script | configure | make | package | mkdir | depend | option | home | jar | delete | description | work | license | nag | url | javadoc | junitreport | redistributable | xmlreport )* !ELEMENT ant ( property | depend | sysproperty | mkdir | jvmarg )* !ELEMENT maven ( property | depend )* +!ELEMENT mvn ( property | depend )* !ELEMENT nag ( regexp )* !ELEMENT javadoc ( description )* !ELEMENT junitreport ( description )* @@ -81,6 +82,11 @@ basedir CDATA #IMPLIED goal CDATA #IMPLIED +!ATTLIST mvn + buildfile CDATA #IMPLIED + basedir CDATA #IMPLIED + goal CDATA #IMPLIED + !ATTLIST script name CDATA #IMPLIED basedir CDATA #IMPLIED @@ -94,6 +100,8 @@ basedir CDATA #IMPLIED !ATTLIST depend + artifactId CDATA #IMPLIED + groupIdCDATA #IMPLIED idCDATA #IMPLIED ids CDATA #IMPLIED inherit CDATA #IMPLIED Index: dtd/project.dtd === --- dtd/project.dtd (revision 607521) +++ dtd/project.dtd (working copy) @@ -22,10 +22,11 @@ +-- !ELEMENT module ( url | description | nag | cvs | svn | p4 | redistributable | project )* -!ELEMENT project ( ant | maven | nant | script | configure | make +!ELEMENT project ( ant | maven | mvn | nant | script | configure | make | package | mkdir | depend | option | home | jar | delete | description | work | license | nag | url | javadoc | junitreport | redistributable | xmlreport )* !ELEMENT ant ( property | depend | sysproperty | mkdir | jvmarg )* !ELEMENT maven ( property | depend )* +!ELEMENT mvn ( property | depend )* !ELEMENT nag ( regexp )* !ELEMENT javadoc ( description )* !ELEMENT junitreport ( description )* @@ -81,6 +82,11 @@ basedir CDATA #IMPLIED goal CDATA #IMPLIED +!ATTLIST mvn + buildfile CDATA #IMPLIED + basedir CDATA #IMPLIED + goal CDATA #IMPLIED + !ATTLIST script name CDATA #IMPLIED basedir CDATA #IMPLIED @@ -94,6 +100,8 @@ basedir CDATA #IMPLIED !ATTLIST depend + artifactId CDATA #IMPLIED + groupIdCDATA #IMPLIED idCDATA #IMPLIED ids CDATA #IMPLIED inherit CDATA #IMPLIED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r572412 - /gump/trunk/python/gump/core/build/mvn.py
On Sep 3, 2007, at 10:01 PM, [EMAIL PROTECTED] wrote: Author: bodewig Date: Mon Sep 3 13:01:46 2007 New Revision: 572412 URL: http://svn.apache.org/viewvc?rev=572412view=rev Log: Make each mvn build use a local repository of its own really? Wow! That's a lot of extra downloading. What problem does this solve? cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: village and town?
and then magically, this appeared in my inbox... Begin forwarded message: From: Jean T. Anderson [EMAIL PROTECTED] Date: July 9, 2007 4:22:28 AM GMT+02:00 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Village contribution to Torque Reply-To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Jon Scott Stevens offered the Village code to Torque [1]. Apparently Jon is not expected to file a software grant. See the [EMAIL PROTECTED] thread starting with msg id [EMAIL PROTECTED] posted on July 8. Would the Incubator PMC be willing to accept Jon's post [1] in lieu of the software grant? regards, -jean [1] http://mail-archives.apache.org/mod_mbox/db-torque-dev/200705.mbox/% [EMAIL PROTECTED] cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
gump has moved! (was: Re: gump is moving!)
On Jul 8, 2007, at 6:55 PM, Leo Simons wrote: On Jul 8, 2007, at 3:42 PM, Leo Simons wrote: * moved to use JDK 1.6 (!!!), though we can switch back to 1.5 easily enough I guess that broke a few things, so I'm switching this back... Which worked out well AFAICS. Justin is updating the DNS so that vmgump.apache.org will now point to the new machine, and I've enabled the cronjob. The DNS propagation will take a while. The new machine should send out its first batch of emails within about 20 hours. cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
size of java cache dirs - .ivy is huge!
Of interest: [EMAIL PROTECTED]:/home/gump# cd ~gump [EMAIL PROTECTED]:/home/gump# du -hs .ivy 1.2G.ivy [EMAIL PROTECTED]:/home/gump# du -hs .maven 41M .maven [EMAIL PROTECTED]:/home/gump# du -hs .m2 791M.m2 While we have a bunch of different stuff in .maven and .m2, almost all of the stuff in ~gump/.ivy is smartfrog artifacts, going back months and months and months. There's no reason for gump to keep months of generated jars. I'd argue that either * there must be a way to configure ivy to do a SNAPSHOT thingie or * we must erase ~/.ivy after every run opinions? Actually, I guess we could also just erase .maven and .m2, once a week, too. cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump [vmgump-public]
this was me.
On Jul 8, 2007, at 2:55 AM, [EMAIL PROTECTED] wrote:
There is a problem with run 'vmgump-public' (07072007_160002),
location : http://vmgump.apache.org/gump/public
The log ought be at:
http://vmgump.apache.org/gump/public/gump_log.txt
The last (up to) 50 lines of the log are :
-- Extracted (fallback) artifacts from Repository : jakarta-
turbine-2
Perform Update on #[(291, 291)] : portals-jetspeed-1
Perform SVN Update on #[(291, 291)] : portals-jetspeed-1
Build Project: #[(696, 696)] : portals-jetspeed-1 :
[state:Prerequisite Failed]
SQL Warning:_mysql_exceptions.OperationalError:(2002, Can't
connect to local MySQL server through socket '/var/run/mysqld/
mysqld.sock' (2))
SQL Warning:_mysql_exceptions.OperationalError:(2002, Can't
connect to local MySQL server through socket '/var/run/mysqld/
mysqld.sock' (2))
SQL Error on [SELECT * FROM gump_public.gump_workspace_stats WHERE
workspace_name='vmgump-public'] : (2002, Can't connect to local
MySQL server through socket '/var/run/mysqld/mysqld.sock' (2))
Traceback (most recent call last):
File /x1/gump/public/gump/python/gump/util/mysql.py, line 145,
in select
affected=cursor.execute(statement)
File /var/lib/python-support/python2.4/MySQLdb/cursors.py, line
166, in execute
self.errorhandler(self, exc, value)
File /var/lib/python-support/python2.4/MySQLdb/connections.py,
line 35, in defaulterrorhandler
raise errorclass, errorvalue
OperationalError: (2002, Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2))
Traceback (most recent call last):
File bin/integrate.py, line 114, in ?
irun()
File bin/integrate.py, line 91, in irun
result = getRunner(run).perform()
File /x1/gump/public/gump/python/gump/core/runner/runner.py,
line 254, in perform
return self.performRun()
File /x1/gump/public/gump/python/gump/core/runner/demand.py,
line 215, in performRun
self.finalize()
File /x1/gump/public/gump/python/gump/core/runner/runner.py,
line 232, in finalize
self.run._dispatchEvent(FinalizeRunEvent(self.run))
File /x1/gump/public/gump/python/gump/core/run/gumprun.py, line
186, in _dispatchEvent
actor._processEvent(event)
File /x1/gump/public/gump/python/gump/core/run/actor.py, line
83, in _processEvent
self.processEvent(event)
File /x1/gump/public/gump/python/gump/core/run/actor.py, line
127, in processEvent
self._processOtherEvent(event)
File /x1/gump/public/gump/python/gump/core/run/actor.py, line
184, in _processOtherEvent
self.processOtherEvent(event)
File /x1/gump/public/gump/python/gump/actor/stats/
statistician.py, line 66, in processOtherEvent
self.updateStatistics()
File /x1/gump/public/gump/python/gump/actor/stats/
statistician.py, line 113, in updateStatistics
ws=self.db.getWorkspaceStats(self.workspace.getName())
File /x1/gump/public/gump/python/gump/actor/stats/mysql/
statsdb.py, line 87, in getWorkspaceStats
self._getStats
('gump_workspace_stats','workspace_name',workspaceName,stats)
File /x1/gump/public/gump/python/gump/actor/stats/mysql/
statsdb.py, line 163, in _getStats
StatisticsDB.ATTR_COLUMN_MAP.values())
File /x1/gump/public/gump/python/gump/util/mysql.py, line 145,
in select
affected=cursor.execute(statement)
File /var/lib/python-support/python2.4/MySQLdb/cursors.py, line
166, in execute
self.errorhandler(self, exc, value)
File /var/lib/python-support/python2.4/MySQLdb/connections.py,
line 35, in defaulterrorhandler
raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (2002, Can't connect to local
MySQL server through socket '/var/run/mysqld/mysqld.sock' (2))
Process Exit Code : 1
--
Gump Version: 2.0.2-alpha-0003
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
regards,
Leo Simons
--
[EMAIL PROTECTED] / +31616471562
Joost Technologies B.V.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
gump is moving!
Hi everyone, The infrastructure team has set up the gump team with a new, beefier, virtual machine (100GB space, 1.5GB memory, 2 processors) to replace vmgump. I've been busy setting it up: http://wiki.apache.org/gump/NewVmgumpConfig Doing the setup took me about 3 hours (less than I expected), with most of the time spent on keeping detailed notes and triple-checking I wasn't losing key data, and because I took the time to clean up a bunch of things. What's interesting about this wiki page is that, since we kept a detailed install log when we went from brutus to the current vmgump, between this one and the previous one, it now clearly shows all the steps you need to take when migrating an installation. Some of the changes include: * using Ubuntu Feisty instead of Debian Testing * gump goes under /srv/gump instead of /usr/local * mono upgraded to 1.2.4 * moved to use JDK 1.6 (!!!), though we can switch back to 1.5 easily enough * didn't bother installing the gump3 bits * removing artifacts from ~/.ivy, ~/.maven, ~/.m2 that are over a week old To avoid confusion that we'd get with DNS switchover and the like, I've already disabled the gump run on the current vmgump machine. This means there will be no gump notifications for a day or two. I just kicked off a test run; hopefully you will be able to see results in a few hours at http://140.211.11.135/gump/public/ (right now it's still displaying reports copied over from the old vmgump). This first run will take quite a bit of time since I didn't sync over CVS/SVN checkouts. If the run completes successfully, we can switch over DNS/IP to the new vm, and I'll be enabling the cronjob so we have 'official' runs again. cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mono broken on new vmgump?
Hi all, See http://140.211.11.135/gump/public/nant/nant/gump_work/ build_nant_nant.html Who knows something about mono? What's broken? Any volunteer to fix it? cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump is moving!
On Jul 8, 2007, at 3:42 PM, Leo Simons wrote: * moved to use JDK 1.6 (!!!), though we can switch back to 1.5 easily enough I guess that broke a few things, so I'm switching this back... java:compile: [echo] Compiling to /srv/gump/public/workspace/excalibur/ containerkit/logkit/target/classes [echo] == NOTE: Targetting JVM 1.6, classes will not run on earlier JVMs == [javac] Compiling 61 source files to /srv/gump/public/workspace/ excalibur/containerkit/logkit/target/classes /srv/gump/public/workspace/excalibur/containerkit/logkit/src/java/org/ apache/log/output/db/DefaultDataSource.java:33: org.apache.log.output.db.DefaultDataSource is not abstract and does not override abstract method isWrapperFor(java.lang.Class?) in java.sql.Wrapper public class DefaultDataSource ^ Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 error BUILD FAILED File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly Element... ant:javac Line.. 63 Column 48 Compile failed; see the compiler error output for details. Total time: 5 seconds Finished at: Sun Jul 08 06:45:33 GMT-08:00 2007 cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
village and town?
These seem to be rather old database access APIs that have all but dissapeared from the web a while ago. Anyone know more about them, like what happened to them? cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fixing the jUDDI gump build
On Jun 15, 2007, at 5:20 PM, Kurt T Stam wrote: Yeah I did: commit -m Adding axis2 dependency C:/cygwin/home/kstam/dev/gump/metadata/project/ws-juddi.xml Sendingdev/gump/metadata/project/ws-juddi.xml RA layer request failed svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/451115/gump/metadata/project/ws-juddi.xml': 403 Forbidden (https://svn.apache.org) A C:/cygwin/home/kstam/dev/gump/metadata/project/excalibur.xml That's a really weird error to get. I just checked the SVN config and you *should* have access. The problem must be elsewhere. In bash under cygwin, doing cd ~/dev/ svn co https://svn.apache.org/repos/asf/gump/metadata/ gump-metadata cd gump-metadata echo 'test' test.txt svn add test.txt svn commit -m Testing write access, please ignore test.txt should normally work. could you run `svn status` and `svn info` on the top of your checkout and send it to us? thanks, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: advice for fixing commons-email breakage
On Jun 16, 2007, at 7:35 AM, Ben Speakmon wrote: commons-email now depends on two things not in gump. The new dependencies are only used during test runs (they simulate an SMTP server) and are NOT required for clients. After reading the docs it seems straightforward enough to build them, but there are a few problems: 1) I want only a specific version of the test dependencies and don't really care if upstream changes break my code (and users won't care either) Ok. In that case you can opt to have an 'installed binary'. Simply put the jar/artifact/whatever somewhere in your SVN and define it in gump, but then don't specify the build for it. There's many examples for how to do this, at random for example, look at how xstream refers to woodstox: http://svn.apache.org/repos/asf/gump/metadata/project/xstream.xml 2) the build system for commons-email is maven 2, but using it in gump seems unsupported Maven2 builds are sort-of second class citizens in gump, since gump cannot control the maven2 dependency management the way we'd like to. But it is supported these days; see https://svn.apache.org/repos/asf/gump/metadata/project/jakarta- bcel.xml for an example descriptor. 3) the build for my new dependencies is compiled under 1.5 and then translated using retroweaver to produce 1.4-compatible jars; commons-email only requires 1.4 to build Ah, that could be a tricky one. But gump builds are all using java 5 now though, http://vmgump.apache.org/gump/public/index.html so if you have a java-5-only build that doesn't use retroweaver you could make gump use that one. Alternatively, follow the approach explained above and have the retroweaved binaries in SVN. Given that commons-email is going to be maven 2 from here on out, the maven 1 file will likely go away soon since it seems silly to maintain ant, m1, and m2. Sounds like you want to move to use mvn in the gump descriptor. How would you recommend I proceed given these issues? I hope this helps! cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 builds
On May 4, 2007, at 8:40 AM, Stefan Bodewig wrote: we've successfully built bcel on vmgump last night! w00t! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apachecon
On Apr 26, 2007, at 8:05 AM, Sander Temme wrote: On Apr 23, 2007, at 11:37 PM, Martin van den Bemt wrote: Maybe nice opportunity to have a Gump meeting at the hackathon ? +1 +1 I expect to arrive at the Mövenpick mid-morning on May 1. Me too probably. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status?
Hey Mark! On Mar 2, 2007, at 9:10 PM, [EMAIL PROTECTED] wrote: I've been doing requirements and design for a build system and continuous integration setup for our in-house software and on the build side I have made the rounds from Maven2+Ant to Ivy+Ant to commercial systems to a home-brew system. Currently we use a lot of Ant and make, and some other stuff. In the process of all this I looked at Gump briefly and moved on. Now that I am thinking more about how I would design a system to build all of our projects (using Ant) it was starting to slightly resemble Gump and its approach using modules and projects. I am now looking at it again in more detail and I like what I see so far (and I love Python so that rocks too). I was wondering what the current status of the project is. I see stuff about Gump3 in development and I am intrigued. If I wanted to start using it is Gump3 ready for primetime? I find surprisingly little info on the project in terms of other people using it outside of Apache. I was wondering if that meant it was relatively dead, or it just works so well that nobody talks about it? ;o) Any advice would be most welcome. Thanks for your interest. I would say Gump3 is currently in hybernation, unfortunately. Not dead, since I do still plan to return to work on it at some point in the future, but right now it is just not functionally complete nor ready for real use. Gump2 is still running at apache and elsewhere though, and working just fine, even if its not seeing that much active development either right now. Unless you want to dive in and hack Gump3 into something production-ready yourself, I'd suggest starting off from the gump2 configuration in use at apache and customizing it for your own use. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cron [EMAIL PROTECTED] cd /usr/local/gump/gump3/Gump3/; /bin/bash gump run --do-updates --do-builds --fill-database --databasename=gump3 --databasepassword=gump --irc='[EMAIL PROTECTED]/#asfgump
Hey everyone! I seem to have misplaced my password for vmgump. Could someone re-set the password for leosimons and let me know? ([EMAIL PROTECTED], or www.leosimons.com on skype) Alternatively, could someone remove the line from the gump@ crontab that tries to run gump3? Thanks! - Leo On Feb 22, 2007, at 6:00 PM, Cron Daemon wrote: gump: Fatal error! Pygump lock file /usr/local/gump/gump3/Gump3/pygump/pygump.pid already exists. Run gump kill to stop the current pygump un. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [gump] Gump running on Harmony!!
On Nov 15, 2006, at 5:27 PM, Stefano Mazzocchi wrote: Great news everyone, I've finally managed to get Gump running with Harmony. sweet! Find it at (the semipermanent URL of Geir's server) http://67.86.14.213:1/gump/ and the 'list of todos' with importance priority can be found at http://67.86.14.213:1/gump/project_todos.html The first problem is the lack of javac that bootstrap-ant requires. Do we have a solution for that? How about installing jikes? And doing an 'alias'? LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important Change | Re: BATCH: All dressed up, with nowhere to go...
Gotta love this response: -[99ABF8] Leo Simons, Your ticket concerning 'Ticket: aanval.com mailconfig' has a new response. Message: System is operating as intended. Loop was already in place and prevented further damage past 10 messages. Ticket closed. --- Instruction: To respond, simply use the reply button within your email client. --- Ticket ID: 99ABF8 Email: [EMAIL PROTECTED] -- Aanval Product Support -- I might dedicate a blog entry to it :) LSD On Sun, Jul 30, 2006 at 01:42:48PM -0700, [EMAIL PROTECTED] wrote: This message is for all users sending submissions to [EMAIL PROTECTED]; ** This address is no longer receiving support or assistance submissions. ** Aanval now requires all support and assistance requests to be entered into our new form based support ticket system. To submit for support or request assistance, please visit: http://www.aanval.com/?op=pub_ticketForm or http://www.aanval.com/?op=pub_support This new system takes effect on 06/24/06 and should be used until further notice. Thank you, -- Your original message was not forwarded to support and has been deleted. You will be required to use the new form based ticket submission system. Do not reply to this email address. - 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: Metadata for Cocoon not correct anymore
Hi Reinhard! look for all nag/ tags and comment them out, and that will stop the flow of e-mail. Note it isn't quite spamming -- cocoon requested these e-mails, really! Please don't simply remove the files, they contain valuable gems of info! To work with the 2.1.x branch, if the build definitions that are currently in place for that branch are still correct (I suspect they might be, largely), you need to look for the svn URL in module.xml and change it, and then we need to manually get rid of existing checkouts. Alternatively, you could duplicate the module.xml tree with a 2.x addition in there names (eg change names like cocoon-flow to cocoon-flow-2.x) to try and build both the 2.1 and trunk trees. Regarding the second question, I'm not sure of the maven 2 integration status; someone else will have to answer that... cheers, Leo On Wed, Apr 19, 2006 at 09:55:13AM +0200, Reinhard Poetz wrote: Some time ago the Cocoon community decided to use Maven 2 as build system. We also changed the directory structure and made our Ant build obsolete. Because of this the Gump build has stopped to work and is spamming our mailing list with failure reports every day. What do we need to do to disable the Gump build for now? Is removing module.xml enough? What would we have to do to make the Gump build for our 2.1.x branch working instead? (... though I'm not sure if there are any volunteers on our side as we hope that the Maven 2 integration is coming soon). -- Reinhard P?tz Independent Consultant, Trainer (IT)-Coach - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0 support status update?
Hey Brett, Just wondering... ...is there a system-wide continuum installation at apache yet? Is it stable enough yet to support getting lots of apache people logins to do their nightly builds using it? I've been using continuum at work and its really a lot easier to understand for people who just want a nightly build, dammit. Historically people have looked to gump to do that, and also historically, that has never been a good idea (I'm willing to bet there's still people out there using gump- built jar files on production machines). Its not that gump can't be stable and secure and used for regular builds, its just that we, well, don't, really :-). On and off I've looked at perhaps having such a more trustable gump in place (with lots of installed packages) but when I heard about continuum I figured that it would probably serve this need a whole lot better...so I'm kinda hoping at some point some people set that up and maintain it LSD On Tue, Mar 28, 2006 at 09:58:28AM +1100, Brett Porter wrote: The work for this is still on my todo list. I haven't had any spare time to look at it over the last couple of months, but I'm happy to direct anyone that wants to look into it. Some other projects at Apache are using Continuum (http://maven.apache.org/continuum) for builds. I believe other CI systems have also added m2 support. These systems in some ways take a different approach than Gump, focusing on the success of your particular builds, rather than the builds of the latest in the whole ecosystem. Cheers, Brett On 3/28/06, Rick Rineholt [EMAIL PROTECTED] wrote: Hello, New to Gump and just from looking through the mailing list it appears that Gump 2.0 does not support Maven 2.0 I'm looking to add nightly build support for the Tuscany incubator project and was hoping Gump would do it for me. What I did pick up is that Gump 3.0 will do this; is that there yet? Is the infrastructure in Apache there to support nightly (periodic) builds? If this is not the case can someone provide some advise on how I could achieve regular builds for a Maven 2.0 based project ? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0 support status update?
On Wed, Mar 29, 2006 at 04:35:38AM +1100, Brett Porter wrote: On 3/28/06, Leo Simons [EMAIL PROTECTED] wrote: ...is there a system-wide continuum installation at apache yet? No. The situation seems to be that the load on the zones is too high so I can't set it up there, and the new machine designed for Gump and Continuum seems to have stalled. So, instead, each PMC is setting up their own zone, with their own Continuum, increasing the load on the machine :) I took Maven's to a separate machine. Heh. Infra@ needs more active pro java server admins. Is it stable enough yet to support getting lots of apache people logins to do their nightly builds using it? Stable, yes - at least that's what I believe. I've had no complaints, and people don't usually hesitate to complain :) In that case I'll go compile a list. Like, its a huge resource hog :-) But there's no sandboxes for individual projects if that was a concern to people running inside one instance. [snip bits I totally agree with] so I'm kinda hoping at some point some people set that up and maintain it I've volunteered, but I'm a bit unsure how to move it forward. See infra@, [EMAIL PROTECTED], from Jan 06. I might resend that to the other infra list that I've discovered and try and get some feedback. It would be good to trial it for a bit and gather up any areas it is lacking to ensure the 1.1 release is capable of doing this. I suggest sending Berin Lautenbach and Noel Bergman a direct e-mail asking whether they could set up another host on loki (which runs vmgump). There's a disk array accessible there so plenty of space. Or try IRC. I *think* I have access to set up things on that machine but I'm not keeping up with infra@ dealings these days so I'm not gonna go and do that without knowing what is going on. Would be especially good for a trial -- get a good idea of what such an install would need. I just learned there may be room for more (new) boxes around July/August or so, so if by then its clear what is needed that would probably be a Good Thing. Anyway. Firmly off-topic for this list isn't it. Is there a continuum mailing list yet? Nevermind, I'll go look. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [gump3] stuck on getting gump3 off the ground
On Sat, Mar 18, 2006 at 09:21:12PM -0800, Stefano Mazzocchi wrote: So, here I am, trying to get Gump3 off the ground again. Kewl. I've installed all the requisites on my machine (macosx 10.4.5, python 2.4.2, mysql 4.1.10) and followed the instructions on the README.txt and on the wiki and I get that far. I have no idea why the rsync help shows up. I suspect that the sync code (I would suspect the file is gump/util/sync.py or something) detects that you have a version of rsync, and then tries to use it, but that the rsync you have does not support the same command line as the rsync I have, or that there is some bug somewhere that cause a crappy kind of command line to be generated. Help? IIRC (I don't have a checkout handy atm), sync.py uses gump.util.executor, which can be configured to do logging of all the commands. This is probably easiest to enable by setting the debug variable in config.py by hand or something like that, or looking for the log.debug() statements and changing them to print statements or whatever. And there's always the debugger (do you have Wing IDE installed yet? Its wonderful...) I'm sorry for messing things up. I had a code sprint in December for which I figured I'd commit at least some of the stuff, but I must've run out of steam before getting everything cleaned up. I still have a bunch of uncommitted patches somewhere on a CD I think. I would love to find some time to hack on this right now, but I think I won't have any till about april 6. cheers! LSD -- Stefano. [EMAIL PROTECTED] ~/Code/src/gump/gump3 $ ./gump test rsync version 2.6.2 protocol version 28 Copyright (C) 1996-2004 by Andrew Tridgell and others http://rsync.samba.org/ Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, IPv6, 32-bit system inums, 64-bit internal inums rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. rsync is a file transfer program capable of efficient remote update via a fast differencing algorithm. Usage: rsync [OPTION]... SRC [SRC]... [EMAIL PROTECTED]:DEST or rsync [OPTION]... [EMAIL PROTECTED]:SRC DEST or rsync [OPTION]... SRC [SRC]... DEST or rsync [OPTION]... [EMAIL PROTECTED]::SRC [DEST] or rsync [OPTION]... SRC [SRC]... [EMAIL PROTECTED]::DEST or rsync [OPTION]... rsync://[EMAIL PROTECTED]:PORT]/SRC [DEST] or rsync [OPTION]... SRC [SRC]... rsync://[EMAIL PROTECTED]:PORT]/DEST SRC on single-colon remote HOST will be expanded by remote shell SRC on server remote HOST may contain shell wildcards or multiple sources separated by space as long as they have same top-level Options -v, --verbose increase verbosity -q, --quiet decrease verbosity -c, --checksum always checksum -a, --archive archive mode, equivalent to -rlptgoD -r, --recursive recurse into directories -R, --relative use relative path names --no-relative turn off --relative --no-implied-dirs don't send implied dirs with -R -b, --backupmake backups (see --suffix --backup-dir) --backup-dirmake backups into this directory --suffix=SUFFIX backup suffix (default ~ w/o --backup-dir) -u, --updateupdate only (don't overwrite newer files) -l, --links copy symlinks as symlinks -L, --copy-linkscopy the referent of all symlinks --copy-unsafe-links copy the referent of unsafe symlinks --safe-linksignore unsafe symlinks -H, --hard-linkspreserve hard links -p, --perms preserve permissions -o, --owner preserve owner (root only) -g, --group preserve group -D, --devices preserve devices (root only) -t, --times preserve times -S, --sparsehandle sparse files efficiently -n, --dry-run show what would have been transferred -W, --whole-filecopy whole files, no incremental checks --no-whole-file turn off --whole-file -x, --one-file-system don't cross filesystem boundaries -B, --block-size=SIZE checksum blocking size (default 700) -e, --rsh=COMMAND specify the remote shell --rsync-path=PATH specify path to rsync on the remote machine --existing only update files that already exist --ignore-existing ignore files that already exist on receiving side --deletedelete files that don't exist on the sending side --delete-excluded also delete excluded files on the receiving side --delete-after receiver deletes after transferring, not before --ignore-errors delete even if there are
Re: Gump @ AC EU 2006
On Tue, Feb 28, 2006 at 08:58:25PM +0100, Martin van den Bemt wrote: Where can I nick the slides ;) I think there's some in trunk/xdocs and some more on people.apache.org:~leosimons (using ssh on people and looking in ~leosimons might be easier). I don't know if the source format for my last one is there (its Apple Keynote I think). I can send that or put it somewhere if need be. Not sure if I will submit a talk though or for that matter even go (conference fee is kind of a problem, at least to finance privately). If you give a talk you normally get travel refunded, a hotel night or two, and the conference fee is waved. So hopefully my new employer thinks this is interesting enough to support me :) (starting at Ordina J-Technologies tomorrow btw). Have fun! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing up Gump on Java1.5
On Tue, Feb 21, 2006 at 01:42:33PM +, Steve Loughran wrote: Stefan Bodewig wrote: On Mon, 20 Feb 2006, Steve Loughran [EMAIL PROTECTED] wrote: I need to bring up Gump on Java1.5. You may have missed it, but vmgump is now running Java 5. 8-) I see now that that is the case. Me must be grateful for at least some benefit coming from JUnit 4.0 Expect some newly added smartfrog projects to start failing shortly. I have quite a complex little dependency graph to put together and it till take a while to stabilise I'm still interested in a vmware image with gump on though, if anyone does have one to hand. gump to go It should be easy enough to take the vmgump image. Some issue there with eg /etc/shadow and /etc/passwd. I think the people that can do that are me, Noel Bergman and Berin Lautenbach. I have -10hours of sleep a week at the moment so it'l be a while before I get to this... - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Upgraded vmgump to JDK 1.5
On Sun, Feb 19, 2006 at 10:37:37AM +0100, Stefan Bodewig wrote: On Sat, 18 Feb 2006, Leo Simons [EMAIL PROTECTED] wrote: This is to solve the junit stuff right? JUnit is the most prominent project to require Java 5 ATM, but hardly the only one. We've had other projects breaking for months now because we didn't provide a Java 5 environment. Oh. Do you have a (partial) list (in your head or elsewhere)? Are these projects leaf projects or core projects? I'm personally not happy with how effectively there's this one project run by a bunch of people who don't particulary understand enough about backwards compatibility I don't think you are fair here. JUnit 4 uses a completely different approach that has been enabled by annotations. I'm a happy NUnit user (.NET unit testing framework) and can tell you that using annotations really is a step forward over the JUnit 3.x approach. Right. The other big one is the template collections (whatever its called, the FooList stuff). I understand how cool and useful it is. I agree I wasn't fair, sorry. However, JUnit is one of the corest of core projects, much like Xerces and/or Ant. The ant project is an example of a project which is very aware of its role like that. Log4j is one where its lead to friction in the past but where gump in the end was used as a tool to have a net positive effect on e.g. migration strategies and backward compatibility and the like. I feel that gump is failing in that role with this jdk 1.4 - 1.5 stuff, and failing in a big way, and I find it frustrating that we're not able as a team to contribute a whole lot to easing this kind of thing and this kind of mess. Its my perception that the people working on JUnit 4 have decided to take a bite the bullet (or the sour apple) approach to this migration, and I think this is wrong, and I know there is no way I can help here or change it and I probably shouldn't try (well, of course I could go and try and change the java landscape by contributing to having open source and open style change management processes for the JDK...hey...ehm...), and I'm sorry for mentioning people instead of project and casting it as a personal thing. The big picture is just so ugly. And when it comes to backwards compatibility, it is very likely that all our JUnit 3.8 tests in Gump will work with JUnit 4 as well. It's simply that JUnit wants to use annotations and the only way forward was to require Java 5 at compile time. Yeah I know. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Re: Maven 2 (was Re: Maven 1.1)]
Brett's message from a while back which may be of interest to bill. There's more in this thread... LSD - Forwarded message from Brett Porter [EMAIL PROTECTED] - From: Brett Porter [EMAIL PROTECTED] Date: Wed, 16 Nov 2005 16:45:56 +1100 Subject: Re: Maven 2 (was Re: Maven 1.1) To: Gump code and data general@gump.apache.org Reply-To: Gump code and data general@gump.apache.org List-Id: Gump code and data general.gump.apache.org Ok, here's the opportunity for me to write the mail in my head. Aside from the non-existance of a gump machine right now, what is needed to use Maven 2, a) minimally b) ideally Because it has an even more online nature (plugins are not preinstalled), to use an installed version we'd again need to create a minimal local repository including those plugins, then use offline mode (-o), and ensure it can't get any internet access just to make sure. However, it should be pretty easy to step it up to the next level. Instead of a pre-installed repository, we can add a Gump artifact resolver. What I'd need to know is the best way to make that work. Can you verify that to resolve a JAR file in gump (assuming gump has already built it) I'd need to: * know the base working directory * know the location of the gump XML file * parse out project name and within that jar name * look in base/project_name/jar_name The resolver can also parse these files for depends. This would require knowing where everything is, so even better would be: * a list of directories creating gump descriptors * that all files in the descriptor are relative to that gump descriptor Is that how it is currently? We come back to the problem of aligning IDs. I think the best place to solve this is in the gump descriptors. Here is how I'd parse them out in order of preference: * GroupId: 1) project groupId= 2) module groupId= 3) module name= * Artifact ID: 1) jar artifactId= 2) jar id= 3) project artifactId= 4) project name= * Type: 1) jar type= / 2) jar / means jar 3) project type= / 4) how do you specify non-jar outputs? * Classifier: 1) jar classifier= / 2) project classifier= / 3) default is none If I start adding them, will it break anything? Now, the next issue comes when Gump3 parses multiple input formats. I don't want to duplicate information in Maven - can we get gump to pick a format and produce that as part of the build, regardless of its input? A POM would simplify things :) Ok, this would have a preinstalled Maven using some packaged plugins working offline without a manual repository setup. Next, to build Maven. We have a bootstrap that runs without any dependencies except Java that would produce the installation above - but it downloads the Maven dependencies on the way. We could have it resolve packaged versions of those by reusing the gump resolver. Alternatively, something we are doing so it can be packaged on unix is checking out the sources rather than relying on packaging, then building them, then building m2 (and those packages would later be rebuilt again using the new m2). Is that a better alternative to the above? - Brett On 11/16/05, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Nov 2005, Leo Simons [EMAIL PROTECTED] wrote: Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. Pluto's trunk has already jumped to Maven 2. We will need a maven2 builder, that's all. 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] - End forwarded message - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 support
On Mon, Jan 02, 2006 at 09:44:36AM +1100, Brett Porter wrote: I sent a lengthy proposal some time back - I don't have time to grab it right now but you might like to look at it. If you have any trouble let me know and I'll take a look. I'd really hoped to have time to work on this by now, but since I was told it wasn't going to be done until gump3, I've had an excuse not to :) :-). Heh. All I said was that *I* wasn't going to integrate this into the gump2 codebase. But by all means, feel more than free. The code repo is wide open, and if you need an account on vmgump or gump.zones, just holler and someone can set it up for you... /me wishes there was more time in a day happy new year! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (GUMP-157) Gump builds fail on Windows when projects include maven / tags
Bill, you're now part of gump-developers in jira so you can close stuff and the like. cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2
On Fri, Nov 18, 2005 at 12:20:39AM -0800, Bill Barker wrote:
Stefan Bodewig [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Wed, 16 Nov 2005, Leo Simons [EMAIL PROTECTED] wrote:
-- support for maven2 in gump2
-- I'm not going to work on it
I'd offer to do a monkey-see-monkey-do support if it is not too
different from maven 1 support. In general I agree that gump3 is the
way to go and that we should do it properly.
It depends on how quickly we are going to need it. As soon as
projects in our tree switch to Maven2 exclusively, we will at least
need that quick-hack version.
I believe that both the Maven1 and Maven2 scripts use $MAVEN_HOME, which is
the biggest problem with just creating a mvn/ tag for Gump2. There are
also problems with separating the local Maven repository between Gump1 and
Gump2. As much as I hate to admit it, having a mvn/ tag in Gump2 looks
like it will be a lot of work :(.
Do I understand correctly that the problem you see is that
- you need different values of MAVEN_HOME
- you need different contents of ~/.maven
if so, that isn't something you can't hack in there I think. Just create
~/.maven1
~/.maven2
prior to invoking maven1:
rm -f ~/.maven
ln -s ~/.maven1 ~/.maven
export MAVEN_HOME=foo
prior to invoking maven2:
rm -f ~/.maven
ln -s ~/.maven2 ~/.maven
export MAVEN_HOME=bar
the equivalents in python involve something like
os.unlink(fnmatch('~/.maven'))
os.symlink('~/.maven', '~/maven2')
os.environ[MAVE_HOME] = 'foo'
relevant docs at
http://docs.python.org/lib/module-os.html
LSD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
I missed a bit.. On Fri, Nov 18, 2005 at 10:27:53PM +1100, Brett Porter wrote: On 11/16/05, Leo Simons [EMAIL PROTECTED] wrote: I wrote an answer then deleted it. I got lost a little. Seperating concerns: -- support for maven2 in gump2 -- I'm not going to work on it Fine by me. I assume gump3 is not far off then? Heh, I wish :-). We don't have a working webapp nor do we have it sending out email. But there's a lot of the hard problems solved in there and for me its just a whole less painful to work with (I still get lost around the gump2 codebase all the time). I hope to find more time to hack on it. Its not far off in terms of man hours, I hope :-) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
On Fri, Nov 18, 2005 at 11:10:24PM +1100, Brett Porter wrote: Why do you keep referring to a something.xml? Is it going to be a lot easier to have the maven jar resolver read a something.xml rather than do something else (like, I dunno, a database, or an XML/RPC interface, or ...)? Just checking -- I think there's more assumptions in my head that might need to get out. No, we can read from any number of sources, nothing has to be XML. Like what you are saying - we just need to end up with a Maven POM in Java (where you need to end up with your Gump object model). All I'm saying is that both Maven and Gump shouldn't have to implement the same mechanism to read all the formats gump digests (and as Maven pulls dependencies, it will need to get that information). If Gump intends to do this, all it needs to do is output a file from the gump object model and Maven can read just one format (and if it outputs a POM, even better :) Of course, Maven *could* do all this, but either that's doubling up, or putting Maven at the centre of Gump, neither of which seem desirable :) Maven is in the center of the developers for a project (they type mvn and not gump) so what these people want to author is a POM. Gump should read that POM and understand it. Question: can gump get away with writing things like settings.xml and command line arguments and not touch any POM at all (eg maven just reads the normal pom.xml that's already there) yet change enough of maven's behaviour so that all the classworlds match up properly with the gump process? Maybe we should just try it and see how far we get. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
I wrote an answer then deleted it. I got lost a little. Seperating concerns: -- support for maven2 in gump2 -- I'm not going to work on it -- support for maven2 in gump3 -- pretty much like we did for maven1 + bootstrap -- doing it quickly -- not me -- doing it properly -- been thinking about that too So... -- how to properly support maven2 in gump3 Basically in the gump descriptors all we want to do is project name=pluto type=mvn href=http://svn.a.o/r/a/p/x/pom.xml/ and then gump fetches that xml file and merges it into the rest of the XML. We end up with lots of xml. Now we need -- a python function or two to work with that xml (while in DOM form) and help transform it into the python object model gump uses Then the gump engine at some point figures out it needs to boostrap mvn. The goal here is to use the actual bootstrap process used for mvn, I believe that involves an svn checkout followed by running a shell script followed by running a minimal mvn on itself. project name=mvn-bootstrap module name=mvn/ script name=bootstrap/ !-- .sh or .bat -- jar name=build/maven2-bootstrap.jar runtime=true/ /project project name=mvn module name=mvn/ depend name=maven2-bootstrap inherit=all/ mvn/ jar name=target/mvn.jar runtime=true/ /project eg, pretty much as we do for Ant. Next bit is -- a python plugin which can call Maven2 Ideally we can run mvn without using its shell scripts and just digest a command which starts with java, since that makes it easier to get things like the CLASSPATH right. In this case we don't have a local installation but one running straight from trunk (just like ant). Now, if we need some special bits like some java code to replace the repository management, we would have something like project name=mvn-gump-java-helper module name=gump3/ depend name=ant inherit=all/ depend name=mvn-bootstrap inherit=all/ ant/ jar name=target/mvn-gump-java-helper.jar/ /project project name=mvn !-- ... -- depend project=mvn-gump-java-helper runtime=true/ /project Now, as far as repository management, downloading, dependency resolution, any of that is concerned, what we want to do in this mvn-gump-java-helper is simply disable as much of those bits of maven2 as possible. Basically what we want to end up with is a gump-generated CLASSPATH (in some form) which maven just accepts as containing all the required dependencies. All those pom.xml files are still available and we can write bits of glue (in python) to expose info from them or for them up as much as needed. Eg Gump3 ends up doing something like for element in parsed.pom.xml.DOM: for (origname, replacement) in artifactmap: element.replaceall(origname, replacement) (...) CLASSPATH=$JAVA_HOME/tools.jar:$MVN_HOME/target/mvn.jar:$GUMP_HOME/target/mvn-gump-java-helper.jar: cd pluton/ java -cp $CLASSPATH org.apache.maven.Maven2.Main jar I hope all that made sense. Now, moving on to the first implementation details -- how to bootstrap maven2 On Wed, Nov 16, 2005 at 04:45:56PM +1100, Brett Porter wrote: Next, to build Maven. We have a bootstrap that runs without any dependencies except Java that would produce the installation above - but it downloads the Maven dependencies on the way. We could have it resolve packaged versions of those by reusing the gump resolver. Alternatively, something we are doing so it can be packaged on unix is checking out the sources rather than relying on packaging, then building them, then building m2 (and those packages would later be rebuilt again using the new m2). Is that a better alternative to the above? Downloading things from elsewhere is not a problem. The key bit is getting to a classpath when using maven to build stuff that contains only fresh built sources and none of the prepackaged bits (just like when you're bootstrapping GCC -- you download a binary GCC to build GCC, then you throw the binary away). If there is a procedure to get absolutely everything from source including all of mavens dependencies and build all of it properly (I really hope there is one now for maven 2) and dependably, lets use it. Key bit here is that what gump does for bootstrapping is the same as what the maven 2 people do for bootstrapping. It sounds like the one you use yourselves is the first option so lets roll with that. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
On Tue, Nov 15, 2005 at 06:28:28AM +0100, Stefan Bodewig wrote: On Mon, 14 Nov 2005, Brett Porter [EMAIL PROTECTED] wrote: We actually started validating the project.xml files. Some people have a lot of random content in there that was previously silenty ignored. Maybe its worth considering them a failed build for the purposes of Gump so that they update it? If it wasn't the excalibur project, maybe. You may not have noticed it, but before I destroyed vmgump the only project still depending on the old Avalon codebase was James - since I don't find a replacement for meta-tools in Excalibur. All other dependencies, in particular commons-logging's dependency on framework and logkit have been migrated to the Excalibur maintained versions. I'm sure the james people would love to hear about the stuff that's keeping them depending on the old avalon codebase. Either we migrate that to excalibur or into james or they stop using it :-) On the other hand - unless Leo jumps in - I'm afraid that the Excalibur community doesn't care about Gump that much and we'd be left with a build tree that is only building around 50% or even less just because Maven started to validate the descriptors. Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
On Mon, Nov 14, 2005 at 05:55:48AM +0100, Stefan Bodewig wrote: On Sun, 13 Nov 2005, Bill Barker [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The version of dom4j that Maven 1.0.2 uses is quite old - some prerelase of 1.4. Maybe we could upgrade to Maven 1.1? I just tried with Maven 1.1b2, and Maven chokes on the Excalibur project.xml long before getting to Struts. It looks like there isn't enough backwards compatibility in Maven to make it possible to upgrade the version that Gump is using. That's unfortunate. Thanks for checking. Heh. I'm sure maven would appreciate a bug report, so they can fix it :-) -LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump3 does last successful build
Hi gang, okay so I got the last two must have (IMHO) low-level features implemented over the weekend. Gump3 now saves the last successful build (and nothing else), and it now seperates the checkouts from the builds. The last build functionality works quite differently from gump2 -- rather than saving only declared outputs (eg, jars), we save absolutely everything. This makes it feasible to do the same for non-java builds. After studying the rsync sourcecode, the rsync.py source code, and the sync.py from gump2, I wrote a new piece of sync code that is supposedly considerably faster than anything we've used before. By using hardlinks combined with native rsync (if possible), its actually faster than just running native rsync by hand. Using hard links also means using 2-3 times less disk space. Yay! Now, I hope to find some time to get some form of web reporting out of all this. I'm still hoping that we can use dynagump or gump-presentation but if something doesn't change soon there I think I'll hack something up -- I want to be able to do a shiny demo at apachecon :-) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
On Mon, Nov 14, 2005 at 09:53:01PM +1100, Brett Porter wrote: We probably need a compatibility option, but it's listed on the known incompatibility pages. Aw, that sucks as a concept! I thought maven1 was going to stay compatible and there'd be painfulness only once (maven1 - maven2)? We actually started validating the project.xml files. Some people have a lot of random content in there that was previously silenty ignored. Grr. Very useful, that was. I know I did stuff like jsd custom-metadata-here/ /jsd :-) Maybe its worth considering them a failed build for the purposes of Gump so that they update it? IMHO maven is broken and its behaviour should change. Validate XML if there is a reference to a DTD or a schema or a pomVersion bigger than X, otherwise preserve the old behavior. Or something. If maven is not going to change, then yes, that would make sense, but I think some people are not going to be very happy. cheers! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (GUMP-146) Need to run each build against a fresh CVS/SVN tree
[ http://issues.apache.org/jira/browse/GUMP-146?page=all ] Leo Simons reassigned GUMP-146: --- Assign To: Leo Simons (was: Adam Jack) Need to run each build against a fresh CVS/SVN tree - Key: GUMP-146 URL: http://issues.apache.org/jira/browse/GUMP-146 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-5 Gump2 has synchronisation functionality where we do a cvs/svn checkout of a project, then copy over that dir into the work area for the actual build. This ensures the build outputs of the last run don't influence the current one. Gump3 needs that functionality as well, probably best implemented by modifying the CvsUpdater and SvnUpdater plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (GUMP-146) Need to run each build against a fresh CVS/SVN tree
[ http://issues.apache.org/jira/browse/GUMP-146?page=all ] Leo Simons resolved GUMP-146: - Resolution: Fixed Implemented in SVN revision 333089. Need to run each build against a fresh CVS/SVN tree - Key: GUMP-146 URL: http://issues.apache.org/jira/browse/GUMP-146 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-5 Gump2 has synchronisation functionality where we do a cvs/svn checkout of a project, then copy over that dir into the work area for the actual build. This ensures the build outputs of the last run don't influence the current one. Gump3 needs that functionality as well, probably best implemented by modifying the CvsUpdater and SvnUpdater plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (GUMP-82) Keep only the jars from the last successful build
[ http://issues.apache.org/jira/browse/GUMP-82?page=all ] Leo Simons resolved GUMP-82: Resolution: Fixed Assign To: Leo Simons Implemented as part of SVN revision 333089. Keep only the jars from the last successful build - Key: GUMP-82 URL: http://issues.apache.org/jira/browse/GUMP-82 Project: Gump Type: Improvement Components: Python-based Gump Versions: Gump2-2.4 Reporter: Stefano Mazzocchi Assignee: Leo Simons Fix For: Gump3-alpha-5 Currently, gump saves all jars and then a cron job removes them after a week. I think it's a waste of space since what we really need is just the latest one that was built. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (GUMP-105) design a way to build against the last-successful-dependency-build
[ http://issues.apache.org/jira/browse/GUMP-105?page=all ] Leo Simons resolved GUMP-105: - Resolution: Fixed Implemented fully after SVN revision 333089. Still a very experimental feature but it seems to be holding up in basic testing. Good enough for now. design a way to build against the last-successful-dependency-build -- Key: GUMP-105 URL: http://issues.apache.org/jira/browse/GUMP-105 Project: Gump Type: Task Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-5 The first algorithm to get right is GUMP-104, where we bail out of building at all if a dependency dies. The next step to tackle is to build against the last version of the dependency that /was/ built successfully. This requires gump to become time-aware beyond a single build run, saving off previous successes into a repository and knowing about them. It requires a significant extension of the model where, for example class BuildFailureRecoveryPlugin(AbstractPlugin): visit_project(p): if p.state = FAILED: successful_p = historyutil.lookup_last_successful_build(p) modelutil.replace(p, succesful_p) p.failed_project = p p.state == RECOVERED stages are inserted to keep most of the plugins blissfully unaware of the intelligence going on. If we get this right that'll be where the staged plugin model will really start to shine, as the graph theory people can design smart new algorithms (As long as they're compatible with the basic topsort we're doing in some way), and the build tool people can just, well, build stuff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GUMP-29) new user howto
[ http://issues.apache.org/jira/browse/GUMP-29?page=all ] Leo Simons updated GUMP-29: --- Fix Version: Gump3-alpha-6 (was: Gump3-alpha-5) Description: New users seem weary of editing gump descriptors (especially when they don't live in their own cvs module but they have to change things in the gump repository), and most of them are very sketchy as to the steps one takes to fix things. Niclas Hedhman' recent experience in getting some of avalon to build using gump and the talk resulting from it on avalon-dev and gump-general are a good example of a new user we need to talk through things. We need a howto. Not just the technical explanation, but some philosophy (Everyone is free to work on gump. Everyone. Stuff like that) intertwined. was: New users seem weary of editing gump descriptors (especially when they don't live in their own cvs module but they have to change things in the gump repository), and most of them are very sketchy as to the steps one takes to fix things. Niclas Hedhman' recent experience in getting some of avalon to build using gump and the talk resulting from it on avalon-dev and gump-general are a good example of a new user we need to talk through things. We need a howto. Not just the technical explanation, but some philosophy (Everyone is free to work on gump. Everyone. Stuff like that) intertwined. Version: Gump3-alpha-6 (was: Gump3-alpha-5) (was: Gump3-alpha-4) Environment: bump. new user howto -- Key: GUMP-29 URL: http://issues.apache.org/jira/browse/GUMP-29 Project: Gump Type: Improvement Components: Documentation Versions: Gump3-alpha-6 Reporter: Leo Simons Fix For: Gump3-alpha-6 New users seem weary of editing gump descriptors (especially when they don't live in their own cvs module but they have to change things in the gump repository), and most of them are very sketchy as to the steps one takes to fix things. Niclas Hedhman' recent experience in getting some of avalon to build using gump and the talk resulting from it on avalon-dev and gump-general are a good example of a new user we need to talk through things. We need a howto. Not just the technical explanation, but some philosophy (Everyone is free to work on gump. Everyone. Stuff like that) intertwined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-29) new user howto
[ http://issues.apache.org/jira/browse/GUMP-29?page=comments#action_12357532 ] Leo Simons commented on GUMP-29: Grr. This issue keeps lying around mostly because our doc editing / publishing process isn't good enough. We have a variety of tools at the ASF and all are either painful to use or buggy or have a variety of other limitations (like being a wiki). Bumping this up a version. new user howto -- Key: GUMP-29 URL: http://issues.apache.org/jira/browse/GUMP-29 Project: Gump Type: Improvement Components: Documentation Versions: Gump3-alpha-6 Reporter: Leo Simons Fix For: Gump3-alpha-6 New users seem weary of editing gump descriptors (especially when they don't live in their own cvs module but they have to change things in the gump repository), and most of them are very sketchy as to the steps one takes to fix things. Niclas Hedhman' recent experience in getting some of avalon to build using gump and the talk resulting from it on avalon-dev and gump-general are a good example of a new user we need to talk through things. We need a howto. Not just the technical explanation, but some philosophy (Everyone is free to work on gump. Everyone. Stuff like that) intertwined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-91) testcases for gump.engine.loader.Loader
[ http://issues.apache.org/jira/browse/GUMP-91?page=all ] Leo Simons closed GUMP-91: -- Resolution: Won't Fix I don't think it'll happen. testcases for gump.engine.loader.Loader --- Key: GUMP-91 URL: http://issues.apache.org/jira/browse/GUMP-91 Project: Gump Type: Sub-task Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-93) testcases for gump.engine.objectifier.Objectifier
[ http://issues.apache.org/jira/browse/GUMP-93?page=all ] Leo Simons closed GUMP-93: -- Resolution: Won't Fix I don't think it'll happen. testcases for gump.engine.objectifier.Objectifier - Key: GUMP-93 URL: http://issues.apache.org/jira/browse/GUMP-93 Project: Gump Type: Sub-task Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Fix For: Gump3-alpha-5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-92) testcases for gump.engine.normalizer.Normalizer
[ http://issues.apache.org/jira/browse/GUMP-92?page=all ] Leo Simons closed GUMP-92: -- Resolution: Won't Fix I don't think it'll happen. testcases for gump.engine.normalizer.Normalizer --- Key: GUMP-92 URL: http://issues.apache.org/jira/browse/GUMP-92 Project: Gump Type: Sub-task Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Fix For: Gump3-alpha-5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GUMP-31) cvs dirs should be cleaned every month (or so)
[ http://issues.apache.org/jira/browse/GUMP-31?page=all ] Leo Simons updated GUMP-31: --- Fix Version: Gump3-alpha-6 (was: Gump3-alpha-7) Description: cvs hackery corrupts cvs trees. We should shield gump against this: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=672035 was: cvs hackery corrupts cvs trees. We should shield gump against this: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=672035 Version: Gump3-alpha-6 (was: Gump3-alpha-7) Environment: Assign To: Leo Simons cvs dirs should be cleaned every month (or so) -- Key: GUMP-31 URL: http://issues.apache.org/jira/browse/GUMP-31 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-6 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-6 cvs hackery corrupts cvs trees. We should shield gump against this: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=672035 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-31) cvs dirs should be cleaned every month (or so)
[ http://issues.apache.org/jira/browse/GUMP-31?page=all ] Leo Simons closed GUMP-31: -- Resolution: Fixed cvs dirs should be cleaned every month (or so) -- Key: GUMP-31 URL: http://issues.apache.org/jira/browse/GUMP-31 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-6 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-6 cvs hackery corrupts cvs trees. We should shield gump against this: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=672035 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-31) cvs dirs should be cleaned every month (or so)
[ http://issues.apache.org/jira/browse/GUMP-31?page=comments#action_12357537 ] Leo Simons commented on GUMP-31: Detection of changes can now be done by introspecting three properties set on the model: module.update_log module.update_exit_status module.update_type these are set by updater.py. The new sync.py has support for cleaning out directories, and the updater now uses that support. By passing the '--do-repo-clean' commandline option, all the repositories and modules for the projects that are being built are cleaned out and a new checkout is done. Setting the cronjob to add that option every now and then should suffice. cvs dirs should be cleaned every month (or so) -- Key: GUMP-31 URL: http://issues.apache.org/jira/browse/GUMP-31 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-6 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-6 cvs hackery corrupts cvs trees. We should shield gump against this: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=672035 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-157) Gump builds fail on Windows when projects include maven / tags
[ http://issues.apache.org/jira/browse/GUMP-157?page=comments#action_12356952 ] Leo Simons commented on GUMP-157: - Hi bill! Patch looks fine. As an ASF committer you should have write access to the gump codebase. Feel free to commit the patch yourself! Gump builds fail on Windows when projects include maven / tags Key: GUMP-157 URL: http://issues.apache.org/jira/browse/GUMP-157 Project: Gump Type: Bug Components: Python-based Gump Environment: Windows Reporter: Bill Barker Priority: Minor Attachments: maven.diff Currently, any Gump project with a maven / tag fails when running on a Windows platform. The underlying reason is that Maven (or at least v1.0.2) is too brain-dead to parse 'project.properties' other than by using j.u.Properties. As a result, the standard Windows File.separator of \ is considered to be a quote character, and is dropped from the jarpath of the dependancies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation
On Fri, Oct 28, 2005 at 12:34:32AM +0200, Thomas wrote: Sorry haven't had much time lately. The school has started and it takes alot of my time at the moment. I have converted it back to 1.4.2 so thats done. Where's the code? What we have in SVN is 1.5 still... Also I'll make some scripts (.sh .bat) to build the aplication and give some more detaild instructions on how to deploy the .war. A clearer description of the folders and the content of them. More important than documentation is that it works! :-) On Mac OS X 10.4: [EMAIL PROTECTED] ant -f packaging-build.xml Buildfile: packaging-build.xml clean: [delete] Deleting directory /Users/lsimons/dev/asf/gump/Gump3/presentation/WEB-INF/class [mkdir] Created dir: /Users/lsimons/dev/asf/gump/Gump3/presentation/WEB-INF/class copy-resources: [copy] Copying 34 files to /Users/lsimons/dev/asf/gump/Gump3/presentation/WEB-INF/class compile: [javac] Compiling 33 source files to /Users/lsimons/dev/asf/gump/Gump3/presentation/WEB-INF/class BUILD FAILED /Users/lsimons/dev/asf/gump/Gump3/presentation/packaging-build.xml:22: /Users/lsimons/dev/asf/gump/Gump3/presentation/WEB-INF/lib not found. Total time: 6 seconds [EMAIL PROTECTED] svn info Path: . URL: https://svn.apache.org/repos/asf/gump/branches/Gump3/presentation Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 32 Node Kind: directory Schedule: normal Last Changed Author: ajack Last Changed Rev: 234419 Last Changed Date: 2005-08-22 04:31:37 +0200 (Mon, 22 Aug 2005) [EMAIL PROTECTED] pwd /Users/lsimons/dev/asf/gump/Gump3/presentation [EMAIL PROTECTED] which ant /opt/local/bin/ant [EMAIL PROTECTED] ant -version Apache Ant version 1.6.5 compiled on June 2 2005 [EMAIL PROTECTED] echo $JAVA_HOME tcsh: JAVA_HOME: Undefined variable. [EMAIL PROTECTED] which jav jav: Command not found. [EMAIL PROTECTED] which java /usr/bin/java [EMAIL PROTECTED] java -version java version 1.4.2_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232) Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode) This is my first real project with opensource so regarding the licens files, Do I need to unpack the licens files or is it enought to let them be in the jar files of the third party jars ?? they need to be in the source code tree somewhere like Stefano wrote. It isn't very important what is in the jar files as we aren't re-distributing anything. Also I have now added the Apache Lincens in the root directory of the project. I quess I'll have to include it in the war archive as well when they build it with ant. Please feel free to comment. I'm in this to learn and hope that you don't get sick of my stupidity and novice questions. Heh. Stop calling yourself stupid will you :-) When I get some free time I'll fix it. Hopefully there will be 2-3 hours a week. Wheehooh! - it still uses hibernate Ok... sound you don't like hibernate ? I'll update the SQL file so you can use both. Thats the point you can use SQL or hibernate your choice. Great. Please write a little readme on how to do that configuration. Its not that I don't like hibernate, its that hibernate is under the LGPL license which doesn't work so well with the Apache License / Apache License policies. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation
On Fri, Oct 28, 2005 at 11:49:35AM +0200, [EMAIL PROTECTED] wrote: Really, Leo? I thought LGPL is ok and GPL not. Ok - usually I try not to rely on non-ASF-licensed code. ONE license is the best (over a couple of). Heh. Don't ask me for authoritive details. Talk to Cliff Schmidt (our VP legal). Depending on your interpretation of the LGPL and the Apache License, code under these licenses can be used together without the AL code falling under the LGPL license. The ASF recently switched interpretation to one where this mixing and matching is possible for java code, too. However, the ASF doesn't like to ship software for which parts of that software which are needed for it to function are under terms more restrictive than the AL (which is the case when you have a non-optional LGPL dependency). So we have a policy in development (I don't think its ratified yet) to somewhat constrain such a thing. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation
Okay, I looked at this today, tried to get things to compile and hit many of the same problems as Stefano outlined. - some jars seem to be missing - docs in general, are missing, so I can't quite figure out what is happening where - its java 5 (ugh) - it still uses hibernate - legal/ info is still missing - I don't really get the build organisation, its kinda different from what you get using the maven-like structure (for want of a better term, eg having a src/java, src/htdocs, src/xxx and a build/classes, build/war, etc) and don't know where to start fixing things I think the below is the last email on this which was about two months ago. Thomas, are you going to address any of the bits you talk about below? Its not really possible to use this stuff right now. As it stands with the above issues, gump3-presentation would be a step backwards from dynagump. - LSD On Fri, Sep 02, 2005 at 01:05:32PM +0200, Thomas wrote: Stefano Mazzocchi wrote: Stefano Mazzocchi wrote: Thomas wrote: Hi ! I have now uploaded a working compy of the Gump3 pressentation. The webapplication is far from done. But it would be nice with some feedback. The code is a bit of a mess so refactoring is indeed needed. Mostly I would like idees on what functionality you would like to se in the application. Also a comment on the documentation/installation manual would be nice. My spelling isn't that good so, be nice ;) but don't keep quite either. (need to learn) So if you have the time please take a look. I'm on it. A few comments: 1) thanks for keeping the dynagump resources! 2) I never used struts but seems easy to learn by example, which is good for this (and probably much easier than cocoon for newbies) 3) I never ran a JSP on this machine (macosx) and I'm experiencing all sort of defective behaviors in jetty due to the jsp compiler trying to open a jni library as a zip file (???) ??? 4) the web application should *never* start with a directory listing, the index.jsp page should be in the root not in a folder that you have to guess where to go All java source files is in WEB-INF src and all the jsp,html,css and other sourcefiles for the webpages is in the map pages. 5) the tar.gz package should be a war and should contain the classes compiled into /WEB-INF/classes so that you can deploy-and-forget (or at least just change the JDBC parameters) If you unpack the tar.gz file and run the ant build file package-build.xml. The source will be compiled and a war-archive created. The structure of the war-archive should be: / |- index.jsp |- leftbar.inc |- META-INF/ | |- MANIFEST.MF |- WEB-INF/ | |- /* Config files for struts .xml and .tld */ | |- error/ | | |- /* error page can not be accessed manualy*/ | |- classes/ | | |- /* all the classes and packages */ | |- lib/ | | |-/* all the jar files */ | |- results/ ||- /* jsp pages for results that canot be accessed manualy*/ |- resources/ | |- /* resources for the application such as css, pictures etc. */ |- results/ | |- /* jsp pages for results that can be accessed manualy */ All pages Jsp pages that are in WEB-INF can't be accessed directly. To get to them you have to go through a Action servlet. There for I have put all the pages that needs some data (processed by an action class) in that folder or subfolders to WEB-INF. 6) the SQL data seems weird, but this is probably not your fault The SQL is not my strongest side. The idee is to use hibernate insted but since I hade some problems you can use either Hibernate or a pure jdbc connection against the database. Both are included. Althought to change from one to another check the file DBHandler and just change a text string. For mysql just use MySQL and for hibernate Hibernate. 7) java 1.5 is, IMNSHO, a little too bleeding edge (especially on a mac) and eclipse gives all sort of warnings. Not having used generics yet, I still have no clue of what they mean and how serious they are. You might want to look into that, though, code should not have warnings. All the wrnings comes from implementing hibenate. I haven't figured out how to write the code for hibernate with generics. It dosen't cause any troubles since I type cast it insted like you do in 1.4. I can change it back. The only thing that separetes my 1.5 code from a 1.4 code is the generics. 8) I have not looked into the code yet, as I still can't run JSP pages, but I will as soon as I can. 9) there should be a /legal folder that contains all the licenses of the libraries This is a good point :). 10) and would also be nice to have a file that depicts the dependencies between the libraries (so that we could have gump building dynagump) 11) you say the mysql jdbc driver is in /lib but
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
Hi andrew, Don't really understand the problem but I've put the db-derby dir from vmgump at http://vmgump.apache.org/derby-gump-snapshot.tgz please holler when we can remove it. cheers! Leo On Tue, Oct 25, 2005 at 03:11:01PM -0700, Andrew McIntyre wrote: Just noticed that this is still failing. I am unable to reproduce the problem. Please see my previous mail concerning this problem. It would appear on the surface to be an issue with how Ant generates the manifest file in the derbyjarwithoutosgi target. Is there any way that I can get access to the manifest file in the zone where gump is run to compare with a copy generated outside of the gump run? cheers, andrew On 10/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: *** G U M P ... [EMAIL PROTECTED]: Project derby (in module db-derby) failed ... snip other failures *** G U M P [EMAIL PROTECTED]: Project derby (in module db-derby) failed snip other targets derbyjarwithoutosgi: [jar] Building jar: /x1/gump/public/workspace/db-derby/jars/insane/derby.jar [jar] Manifest is invalid: Manifest sections should start with a Name attribute and not Sealed BUILD FAILED /x1/gump/public/workspace/db-derby/build.xml:775: The following error occurred while executing this line: /x1/gump/public/workspace/db-derby/build.xml:854: Invalid Manifest: /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf - 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: Final Tomcat SVN migration
On Fri, Oct 07, 2005 at 07:14:51PM -0700, Bill Barker wrote: Tomcat is now completely on SVN, so I should be able to stop bothering people about this :). The metadata for the move has been committed, and I need somebody to nuke the working directories on vmgump for the modules: jakarta-tomcat-jasper_tc5 jakarta-tomcat-jasper_tc4 jakarta-tomcat-connectors jakarta-tomcat-catalina jakarta-tomcat-5 [EMAIL PROTECTED]:/usr/local/gump/public/workspace$ ls -l jakarta-tomcat* ls: jakarta-tomcat*: No such file or directory should do it. cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Maven plugin update
On Thu, Sep 15, 2005 at 01:58:06PM -0700, Justin Merz wrote: I have started adding code to mavenizer to handle jar id created in the maven build. Have a couple things to work out still. Kewl. Also I have still not been successful in getting the existing bootstrap-maven project to work. I have attached the build output. Any thoughts? ... OSError: [Errno 2] No such file or directory Maybe there's a 'repository' or 'module' intermediate directory missing or something like that. I would look for code along the stack trace that does OS interaction and add some debug statements outlining what it tries to do and there should then be a clue about which operation is causing this failure. Most likely its bugs in code elsewhere in the system :/ cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error in gump test
On Wed, Sep 07, 2005 at 10:43:56PM +0200, Jochen Wiedmann wrote: I am attempting to set up gump3, Cool! following the instructions on http://wiki.apache.org/gump/Gump3Installation I am using a Fedora Core 4 system, the prerequisites should be installed. Additionally I have created a database gump and initialized it with the gump3-database-definition.sql script. However, when I run bash gump test, then I receive the following error message. What should I do? Fix something? Ignore the error? The below problem is caused by changing the actual vfs component we use but not updating the mock component used by a testcase. Obviously it should be fixed but you can ignore it for now and continue your install. This is a bug in the gump3 test cases. Thanks for reporting it! ERROR: test_loader_get_workspace_tree_simple self.get_as_stream, self.handle_error, self.vfs.filesystem_root) AttributeError: MockVFS instance has no attribute 'filesystem_root' cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Account created for Brett Porter on vmgump
Brett, dude, I've created an account for you on vmgump.apache.org. You have sudo. Please make sure to update http://wiki.apache.org/gump/VmgumpConfig When you change stuff. Please log in and update your password ASAP. Your password is in /home/brett/.vmgump On people.apache.org. (Also note the gump PMC unanimously voted to have you aboard; just waiting for the 72h after a board ACK I think. Make sure you subscribe yourself to [EMAIL PROTECTED] if you haven't already. I'd say welcome aboard but it feels like you've been around for a long time already so I'll just stick to carry on! Wootness!) Cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (GUMP-149) allow gump to bootstrap maven
whoohooh! A patch! Looks pretty sweet. Before we chuck it in, some comments... First of, I presume you have some tests (eg project.xml files and a sample workspace) against which you run this code. Could you submit those too? +def __init__(self, project, target, buildfile=maven.xml, basedir=None, properties=None): Isn't using 'maven.xml' mandatory? I think you can set the POM but not the buildfile... + #command line + args = [maven jar ] If I'm not mistaken args should be one-entry per array, eg [maven, jar] also, the target defined in the model as above is probably the maven goal to use instead of the hardcoded jar? Leo Simons wrote: Index: pygump/python/gump/engine/map.py could map.py go into gump/util or gump/plugins/java somewhere? Also, it'd be cool if this could be a config file of some sort that is read in, perhaps a format as simple as avalon-framework avalon-framework-api axis ws-axis Note that the 'gump' plugin for maven has many more of these mappings that would be nice to steal. Index: pygump/python/gump/engine/mavenizer.py === + if maven_node: + #parse DOM creating new gumped-maven file + #then return file location to be used instead + #of original maven file + gumped_maven_href = _parse_maven_file( maven_node, download_func, get_vfs ) + return gumped_maven_href + else: + return 'broken' you want to 'raise' an exception here. +def _parse_maven_file( project, download_func, get_vfs ): this looks pretty comprehensive! + mavenfile = open(%s\\%s % (home_dir, filename), w) ^^^ use os.path.seperator (or whatever its called) however, using the StringIO module would probably avoid the need for using a file at all, which would rock even more. Index: pygump/python/gump/config.py === --- pygump/python/gump/config.py (revision 233131) +++ pygump/python/gump/config.py (working copy) @@ -105,6 +105,7 @@ log.info(Not running updates! (pass --do-updates to enable them)) if config.do_build: + from gump.model import Maven from gump.model import Ant from gump.model import Script looks like a TAB character in there. Seems there's several more in your patch. Please get rid of those and just use spaces :) Index: pygump/python/gump/util/executor.py === --- pygump/python/gump/util/executor.py (revision 233131) +++ pygump/python/gump/util/executor.py (working copy) @@ -38,7 +38,7 @@ __copyright__ = Copyright (c) 2004-2005 The Apache Software Foundation __license__ = http://www.apache.org/licenses/LICENSE-2.0; -import sys +import sys, os huh, what? Why? Seems there's a few loose ends in the patch... Index: pygump/python/gump/util/io.py === --- pygump/python/gump/util/io.py (revision 233131) +++ pygump/python/gump/util/io.py (working copy) @@ -99,6 +99,9 @@ self.cachedir = os.path.normpath(os.path.abspath(cachedir)) else: self.cachedir = None + +def return_path(self): + return self.filesystem_root feel free to just use the property directly, eg replace calls to myvfs.return_path() with simply myvfs.filesystem_root instead of writing accessors. Sun did the world a lot of harm by inventing getters/setters for java. Python certainly doesn't need them. cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: temporarily disable nags for Directory in gump?
On 15-08-2005 01:09, Brett Porter [EMAIL PROTECTED] wrote: Having looked at the recent problems with Apache Directory, I can't immediately fix them. The checkout is locked and I don't have access to vmgump. I hadn't been tracking these since it moved from brutus. Would you like access? Heck, would you like to be on the Gump PMC? While you might want to look into automating svn cleanup on locked checkouts, Aye. [EMAIL PROTECTED]:/usr/local/gump/public/workspace/directory-naming$ svn cleanup svn: '' is not a working copy directory Could you be more specific? I'm proposing we disable the directory descriptors (or at least the nags) for now. There seem to be a steady flow of problems in the build that are not actually broken builds. If that's what you really want. Just comment out the nag/ elements in the descriptors and no e-mail will be sent. I'll point out that in general if your build keeps breaking (rather than being broken all the time) that's because it keeps changing in non-compatible ways. I know I've always have had loads of trouble getting it all to compile everytime I tried to look at it. Directory does have a problem there. Oh, and the second bit I'll mention is that it seems no-one ever pays attention to the builds for their project unless they get e-mail, so there'll probably be a 'hump' to get over once you get back to sending yourself e-mail :-) There's a few example of bigger maven-based builds (for example I know about Excalibur) that tend to build fine. This would just be until such time as: a) somebody else in the gump tree depends on directory libraries (at which point gump becomes useful as a regression test, and it is worth the effort to keep them up to date, but at the moment nothing does) b) gump3 goes live which should be able to read the maven descriptors directly which should just mean that nags are actually things broken, not gump integration issues Mind you -- that's still going to be a while. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump presentation
Thomas wrote: Hi ! Hi! I have made some progress and I'm wondering where to send my code is it ok to just add a sub catalog to the existing svn tree if so do I have permisson to do so and where should I put that folder if not. I guess that should be https://svn.apache.org/repos/asf/gump/branches/Gump3/name-for-your-code-here/ I say you get to pick a fancy name :-). One suggestion would be dynagump2, but feel free to be a little more creative. Where can I mail it? to this list? With a specifik format for the mail? Adam talked about [jira] but couldn't give me a good answer to that. Jira has a web interface. Don't send it email. I suggest: 1) go to http://issues.apache.org/jira/secure/Dashboard.jspa and create a user account for yourself. 2) go to http://issues.apache.org/jira/browse/GUMP click on Create a new issue in project Gump create a new issue (gump project, dynagump component) describing what it is your uploading (eg summarise your readme or whatever). Don't need to be verbose. 3) create a zipfile or tarball containing *all* your sources and project files but no binaries (eg if you have an ant script that can generate the stuff don't include it) or servlet engine. Do include eg the jars that you use like velocity.jar or whatever that are not provided by the servlet engine. The developer submitting your patch will probably not commit everything in the tarball, and that might be the best possible way to get this. 4) create a new attachment to the jira issue with your zipfile Someone'll take a look at your tarball and try and run it. People will add comments to the jira issue (maybe they have trouble getting your stuff to run on their systems or whatever). You can revise the attachment. Documentation on what jira is and how to use it is at http://www.atlassian.com/software/jira/docs/v3.2/issues.html I'm not sure whether we decided whether Gump SoC students get svn accounts yet or what the policy is. Two reasons for using jira: 1) there's a checkbox that says I submit this under my CLA 2) its how open source often works (eg you load your stuff into an issue tracker) Since this is my first commit to a openscource project I'm also interested in information of whats needed in my commit. Actually, what you're doing is submitting a patch. Committing means interacting with the CVS or subversion repository directly. There's lot of guidelines on how to submit patches for different projects: http://www.google.com/search?q=submit+patch+site%3Aapache.orgbtnG=Searchhl=enlr= a lot of the process is the same for different project. How to make commits is documented in many different places as well, eg http://svn.collab.net/repos/svn/trunk/www/hacking.html is a neat reference. Furthermore, it ain't that much of a patch (I assume you're not doing a 'diff' against the current source tree) as much as it is a new codebase. We just don't have slang for that ;) I know I need to have a README with installation and requirements. Also I need a TODO to describe what more I think can/should be done to the project. Don't worry too much about stuff like that at the moment. It doesn't need to be perfect. Just send what you have. We're pretty good at reading source code. We'll no doubt provide you with lots of feedback. The project is build by ant to a .war archive should I make some .sh and .bat files for the build part. nope. We've got ant :-) Should I have it as a .war or should I leav it as an open archive? I don't particularly care :-) (.war = web archive used to make the deployment on an application server easyer. packs the webapplication to one single file that you deploy) just eager to get my code out there and to get some responce and feedback on it. good! Just chuck whatever you have at the moment into jira. cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GUMP Comparisons
Hi Hal! Trask, Hal wrote: I am in the process of setting up an environment to do Continuous Integration. Lots of (non .Net code (C++)) and (.Net code) in the future, are and, will be involved.. I am looking at tools that will work with Subversion (source code repository), do scheduling (cron-like scheduling scripts for kicking off and managing builds and test), perform the automated builds, perform unit/performance/regression testing, etc. Gump does continuous integration and can fire off tools like make and other tools for eg running your tests. I think we have some support for NAnt but I don't know much about the whole .Net area (Adam, care to comment?). We actually *use* cron for scheduling gump runs. I am looking at products such as NAnt, NUnit, CruiseControl.Net, BuildRobot, and a couple others such as gump but can't seem to distinguish on which products are best. best is a complex word in this problem space :-). Depends on what you want to do... Can anybody comment on why I should use GUMP instead of any other products or comment on other product comparisons or comment on the NAnt and NUnit or BuildRobot products Heh. Gump is less of a product than CruiseControl.Net and more of a project. In many ways its apples and pears. I have some presentation slides at http://people.apache.org/~leosimons/presentations/apacheconeu2005/ which try and point out in some detail how gump is different from eg cruisecontrol (note I don't know much about the .Net variant there either). Better depends very much on what you want to do. If you want predictable builds gump is a nightmare, because we very much focus on the unpredictable problems and try and help with identifying those. I don't know what BuildRobot is, but I know NAnt and NUnit are clones of Ant and JUnit which are top-notch de-facto standards in the java space. Based on that I'd just go with NAnt :-) hope this helps... Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: [EMAIL PROTECTED]: Project jakarta-hivemind-library (in module jakarta-hivemind) failed
Howard Lewis Ship wrote: This has been failing for quite some time now. The errors indicate a problem compiling against some Spring code. The output shows the spring-core library on the classpath however. Any ideas how to fix this and get rid of these damn nag messages? Well, spring-core doesn't actually contain that missing BeanFactory. I think you need spring-beans.jar, which involves adding a depend tag to the hivemind project definition: https://svn.apache.org/repos/asf/gump/metadata/project/jakarta-hivemind.xml Looking at https://svn.apache.org/repos/asf/gump/metadata/project/spring.xml you need to change the line depend project=spring ids=spring-core/ to depend project=spring ids=spring-core, spring-beans/ or something similar. And yes, you do indeed have karma to fix that file yourself :-) cheers! Leo [javac] private BeanFactory _beanFactory; [javac] ^ [javac] /x1/gump/public/workspace/jakarta-hivemind/library/src/java/org/apache/hivemind/lib/impl/SpringBeanParameter.java:44: cannot resolve symbol [javac] symbol : class BeanFactory [javac] location: class org.apache.hivemind.lib.impl.SpringBeanParameter (...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 presentation
On 26-07-2005 12:00, Thomas [EMAIL PROTECTED] wrote: Hi ! Hi thomas! (this is a quick reply, I have limited connectivity atm) I also have one question regarding the database. The causes table lists the cause of a stalled package. The same information could be found by listing the dependencies tree from one faild build. If I got it right it's the same information on two places. The only thing that would make my statement wrong is if: package#1 depends on package#2 and package#1 can be build although package#2 faild. Another way my statement dosent work on is if. the causes table refer to somethig else then only dependencies. As I said before I don't know if got the causes table right need some clearance on that. A cause can also be failure to update from source control (eg CVS), a problem with the xml definitions, an internal error within gump, or something similar. There can be multiple causes (eg multiple failed dependencies). Think of this as a sort of lightweight exception stack trace. *but*, for now, it might indeed be a good idea to just look for one dependency that caused a problem and use that. It can be generalized later. Cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r219505 - /gump/branches/Gump3/bin/ssh-ap-adduser
Ehm, sorry. This was supposed to go into my private repo. On 18-07-2005 16:52, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: leosimons Date: Mon Jul 18 07:52:20 2005 New Revision: 219505 URL: http://svn.apache.org/viewcvs?rev=219505view=rev Log: Apache adduser cmd Added: gump/branches/Gump3/bin/ssh-ap-adduser Added: gump/branches/Gump3/bin/ssh-ap-adduser URL: http://svn.apache.org/viewcvs/gump/branches/Gump3/bin/ssh-ap-adduser?rev=21950 5view=auto == --- gump/branches/Gump3/bin/ssh-ap-adduser (added) +++ gump/branches/Gump3/bin/ssh-ap-adduser Mon Jul 18 07:52:20 2005 @@ -0,0 +1,6 @@ +echo ap-adduser calls sudo (first password) +echo ap-adduser then uses ssh to get into hermes (second password) +echo environment stuff can be a problem, so make sure it is relatively +echoclean and use tcsh (*not* bash) + +ssh -t minotaur.apache.org /bin/tcsh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation -- choice of technology
On 18-07-2005 15:33, Thomas [EMAIL PROTECTED] wrote: If I don't get around this cocoon problems I have I'll start a new presentation application (not dyngump) with J2EE and Struts. I'll chuck in 2 cents: I don't want J2EE. Servlets+Struts+other stuff like velocity is potentially nice, but please no EJB or JNDI or any of the other J2EE stack. Most of it is crap :-) like to hear what you have to say, if I missunderstud something with cocoon or if I'm just giving up to easy. But I want to get som results now and I feel that cocoon is one step to big to take at the moment to get where I whant. Ok. I'd appreciate if you could go into some more detail (and a little more concretely) on what you tried to do with dynagump that you were unable to get to, what you tried to get there, and how you figured out what to try, etc. That'll be very useful feedback to the cocoon people, and it means you won't have wasted your time :-) Cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: derby-split-2
Stefan Bodewig wrote: On Tue, 12 Jul 2005, Andrew McIntyre [EMAIL PROTECTED] wrote: Sorry for the delay here... I've been meaning to look into it myself but never found the time, sorry. However, the classpath reported by Gump doesn't appear to have any JDK 1.4 classes on it, besides tools.jar. Also, I had a script which emulates the Derby build in Gump by building with just one JDK on the classpath for each split, and this script still compiles Derby successfully. Is it possible that a change to Gump (or Ant) was made that is causing JDK 1.4 (or higher) classes to appear on the compilation classpath before the JDK 1.3 classes which are needed for this compile? IIRC it started to fail after the migration from brutus to vmgump, so maybe it really is more of an installation issue. Hmmm. Leo, where did you get the rt.jar that is being used as 1.3 runtime? Didn't remember, but I just checked, from http://wiki.apache.org/gump/VmgumpConfig: TODO: figure out which packages of the below on brutus is needed lrwxrwxrwx 1 root root35 Oct 6 2004 ant - /opt/__versions__/apache-ant-1.6.2/ lrwxrwxrwx 1 root root31 Jan 7 11:57 cocoon - /opt/__versions__/cocoon-trunk/ lrwxrwxrwx 1 root root32 Jan 7 11:57 forrest - /opt/__versions__/forrest-trunk/ lrwxrwxrwx 1 root root29 Jan 24 23:47 jdk1.3 - /opt/__versions__/jdk1.3.1_14 lrwxrwxrwx 1 root root27 Oct 6 2004 jdk1.5 - /opt/__versions__/jdk1.5.0/ lrwxrwxrwx 1 root root31 Oct 6 2004 jetty - /opt/__versions__/jetty-4.2.21/ lrwxrwxrwx 1 root root23 Oct 12 2004 kaffe - /opt/__versions__/kaffe lrwxrwxrwx 1 root root29 Oct 6 2004 loader - /opt/__versions__/loader-1.0/ lrwxrwxrwx 1 root root49 Oct 6 2004 mysql - /opt/__versions__/mysql-connector-java-3.0.15-ga/ lrwxrwxrwx 1 root root31 Oct 6 2004 rdflib - /opt/__versions__/rdflib-2.0.3/ lrwxrwxrwx 1 root root30 Oct 6 2004 servlet-api - /opt/__versions__/servlet-2.4/ lrwxrwxrwx 1 root root32 Oct 9 2004 webware - /opt/__versions__/Webware-0.8.1/ the TODO means I didn't think about it a whole lot and/or gave up. Further down it says # update /usr/local/gump/packages/java-runtime-1.3 to have working symlinks [EMAIL PROTECTED]:/usr/local/gump/packages/java-runtime-1.3$ rm LICENSE [EMAIL PROTECTED]:/usr/local/gump/packages/java-runtime-1.3$ rm rt.jar [EMAIL PROTECTED]:/usr/local/gump/packages/java-runtime-1.3$ ln -s /opt/jdk1.4/LICENSE [EMAIL PROTECTED]:/usr/local/gump/packages/java-runtime-1.3$ ln -s /opt/jdk1.4/jre/lib/rt.jar which obviously means that's the rt.jar from the 1.4 jre that I linked to, probably because I couldn't figure out some build failure. We don't have jdk 1.3 on vmgump at the moment I think. Everything on the classpath is jdk 1.4. Is it the one from brutus? Or maybe it is the jikes configuration? I vaguely recall we've been running our own version of Jikes on brutus while the one on vmgump is a stock debian installed one. I know I didn't install jikes. Nothing mentioned about it on http://wiki.apache.org/gump/VmgumpConfig. If we had a custom jikes on brutus it wasn't in /opt. What should happen now? Regardless of what you change, please update the wiki page :-) You may have noticed I'm working on some sane management of installed packages for gump3. Will make sure that this kind of thing is a lot easier to debug than it is now. cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: latest gump fails: Indentation error
Graham Leggett wrote: Hi all, After doing an svn update on my gump directory, gump now bombs out with an indentation error like so: Execute : /udd001/hoops/usr/bin/python2.3 bin/integrate.py -w /udd001/hoops/gump/metadata/fodev01.xml -d --official all out.txt 21 Traceback (most recent call last): File bin/integrate.py, line 40, in ? from gump.core.runner.runner import getRunner File /udd001/hoops/gump/python/gump/core/runner/runner.py, line 22, in ? from gump.core.build.builder import * File /udd001/hoops/gump/python/gump/core/build/builder.py, line 51, in ? from gump.core.build.maven import MavenBuilder 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? Precisely what it says. In python indentation is important. Someone committed a line that has a too much or a too little, so now python complains and exits. I'll go and fix it. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r210010 - /gump/trunk/python/gump/core/build/maven.py
[EMAIL PROTECTED] wrote:
Author: ajack
Date: Sun Jul 10 06:27:01 2005
New Revision: 210010
URL: http://svn.apache.org/viewcvs?rev=210010view=rev
Log:
Attempt to cope with the Maven properties file going into a directory that
does not yet exist.
Modified:
gump/trunk/python/gump/core/build/maven.py
Modified: gump/trunk/python/gump/core/build/maven.py
URL:
http://svn.apache.org/viewcvs/gump/trunk/python/gump/core/build/maven.py?rev=210010r1=210009r2=210010view=diff
==
--- gump/trunk/python/gump/core/build/maven.py (original)
+++ gump/trunk/python/gump/core/build/maven.py Sun Jul 10 06:27:01 2005
@@ -187,9 +187,11 @@
os.path.basename(propertiesFile))
except:
log.error('Display Properties [ ' + propertiesFile + ']
Failed', exc_info=1)
-
-except:
-log.error('Generate Maven Properties Failed', exc_info=1)
+
+ except Exception, details:
^^^ there's an indentation error here.
I'll fix it in a moment.
- Leo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
Stefan Bodewig wrote: does the same happen in Gump 2? So far I haven't seen a trace of stalled processes. 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... You said you had some smallish testcase, can we get access to that? Well, sure, but that one doesn't have this problem. Might be because of GC never kicking in or something similar. It looks as if I was too busy to spend considerable time on it right now, so I'll try to get ant-dev involved. Besides there are a few people on that list that are smarter than me 8-) Kewl. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump3 for bootstrapping your entire environment
Stefano Mazzocchi wrote: I wonder how long a 'gump world' of debian would take to run (and whether or not you can reach a 100% ;-) I have no doubt its totally impossible. Just think of all the different bdb versions you need to have lying around, or the mess that surrounds all the different lexing tools. Now, the biggest question of all: does gump3 implement fallback? Ah, getting impatient now, are we? :-) Working on it. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing the parameters for make - possible?
Graham Leggett wrote: Hi all, Hi Graham! While building C/C++ projects using make within gump, is there an option to add parameters to the make command? I don't think so (if there was it'd be an arg/ like for script/ elements). You *can* use a script/ to invoke make though in a custom fashion. Gump3 will have arg/ for make/. We would like to add the -j flag to do parallel builds on a large machine, but there doesn't seem to be an obvious way to do this. cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
Adam R. B. Jack wrote: 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. NooOOOhOOooohhoh! :-) WTF. Crap. So now I really have no clue where the problem is. We may have a python bug then. 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. And, more importantly, it works. Remember it took the python people a POpen, POpen2, POpen3, POpen4, POpen5 to get to subprocess.POpen, which as it turns out isn't all that perfect yet either. I just really really want to know *why* it works (or not). 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. Would you be able to figure out something more specific than A month ago? 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 think that might be worth it. I don't know if it is still happening. I suspect the important bit here is that gump2 does this: # Allow redirect cmd += ' ' + str(outputFile) + ' 21' # Run the command systemReturn = os.system(cmd) cuz otherwise most of the end results are the same, eg gump2 also does (childPID, waitcode) = os.waitpid(forkPID,0) and the like. However, subprocess.py uses os.execvp() or os.execvpe() and not os.system. I'll have to take a look at the source code of posix.system() (which powers os.system). There's definitely some file descriptor magic to fix, somewhere. cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
Stefano Mazzocchi wrote: do you think it's time to throw a python task force at it? what would you suggest? I'm sure the python community would be quite pleased to help us making the entire apache software (especially all the java stuff) with a python script. I think so too [1]. I hope the python community comes to ApacheCon :-) LSD [1] - http://jroller.com/page/lsd/20050530#hey_you_python_expert_apache - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-147) Complain if a project does not provide all the outputs it states
Complain if a project does not provide all the outputs it states Key: GUMP-147 URL: http://issues.apache.org/jira/browse/GUMP-147 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-6 Reporter: Leo Simons Fix For: Gump3-alpha-6 We should have a post-processing plugin (maybe one-per-output-type) that looks for successfully built projects, then goes and peeks if each and every of the outputs it specifies now actually exists (probably os.exists() and sometimes os.isfile() and os.isdir() if appropriate). If not, the plugin should mark the failure on the output. The logreporter should be modified to include this information with each project (this is probably a METADATA FAILURE), eg loop over all outputs for all projects and check_failure on each of them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-148) Clean up entire codebase and add documentation
Clean up entire codebase and add documentation -- Key: GUMP-148 URL: http://issues.apache.org/jira/browse/GUMP-148 Project: Gump Type: Task Components: Python-based Gump Versions: Gump3-alpha-6 Reporter: Leo Simons Assigned to: Leo Simons Fix For: Gump3-alpha-6 It'd be nice if the gump codebase could get some time to stabilize after this milestone. To be confident we don't get too much bit rot, its important to take a big stroll through the codebase, adding javadocs, rolling up unrolled algorithms, getting rid of code duplication, standardizing method names, etc etc. Let's use this issue for code review reporting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-84) Packages defined in built modules are shown as green but they should be blue
[ http://issues.apache.org/jira/browse/GUMP-84?page=all ] Leo Simons closed GUMP-84: -- Resolution: Fixed Assign To: Leo Simons Fixed in revision 215990. Packages defined in built modules are shown as green but they should be blue Key: GUMP-84 URL: http://issues.apache.org/jira/browse/GUMP-84 Project: Gump Type: Bug Components: Python-based Gump Versions: Gump2-2.4 Reporter: Stefano Mazzocchi Assignee: Leo Simons Fix For: Gump3-alpha-5 packages are colored blue when they are not built by gump. Modules are allowed to have their own internal packages, wrapping some of the jars they contain in their repository. Gump should treat those the same as packages, but currently it does not and it misleads the statistics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GUMP-36) Generate source diff report on build failure
[ http://issues.apache.org/jira/browse/GUMP-36?page=all ] Leo Simons updated GUMP-36: --- Fix Version: Gump3-alpha-6 (was: Gump3-alpha-5) Version: Gump3-alpha-6 (was: Gump2-2.4) Generate source diff report on build failure Key: GUMP-36 URL: http://issues.apache.org/jira/browse/GUMP-36 Project: Gump Type: New Feature Components: Dynagump Versions: Gump3-alpha-6 Reporter: Vincent Massol Fix For: Gump3-alpha-6 When a project fails to build, generate a report containing the following information: - CVS source diff on the project itself between the last success build and the current checked out sources - CVS source diffs on the project first level dependencies between the last success build and the current checked out sources - CVS source diff on Gump project files between the last success build and the current checked out sources. The idea is to help devlopers of the failed project in indentifying the reason of the failure. See http://blogs.codehaus.org/people/vmassol/archives/000644_diffing_continuous_build_results.html for more details. Thanks -Vincent -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-94) testcases for gump.engine.verifier.Verifier
[ http://issues.apache.org/jira/browse/GUMP-94?page=all ] Leo Simons closed GUMP-94: -- Resolution: Fixed Assign To: Leo Simons fixed in revision 216018 testcases for gump.engine.verifier.Verifier --- Key: GUMP-94 URL: http://issues.apache.org/jira/browse/GUMP-94 Project: Gump Type: Sub-task Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Assignee: Leo Simons Fix For: Gump3-alpha-5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Kaffe gump run
Guilhem Lavaux wrote: Hi, Hi Guilhem! I am one of the developers of the Kaffe.org VM. I would like to know if there is any chance to get back an automatic gump run on vmgump.apache.org. Not really :/. That machine is low on disk space so we can't run any more profiles there. We do have a Mac OS X box on which we'll be running gump as well as a Solaris zone. My intention has always been to get a kaffe run set up on one of these, but I've been kind-of busy with other stuff lately :-) That was pretty useful to test GNU Classpath Kaffe in interaction with the rest of the other java projects and to detect bugs. Thanks a lot for your job ! :-). You're welcome! We'll let you know when we have things working, but if I'm the one setting it up that'll be a while yet... cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Runtime.exec Ant Gump3 (was: Re: svn commit: r210128 - in /gump/branches/Gump3)
So, ehm,
I've had to learn a lot about process management in the last two days,
most importantly that java is *really* bad at doing it properly. If you
open
pygump/python/gump/plugins/java/builder.py
and edit the AntBuilderPlugin to have no_cleanup=False instead of
no_cleanup=True, then do a gump run using the vmgump.xml profile, the
run will usually stall trying to invoke java_cup.
The reason for this seems to be that java sometimes deadlocks when
forked from java. I built a trivial testcase (basically rewrote the
Execute.java from ant to manually run my demo program and wrote a simple
python wrapper to fire that up) and the problem does not occur there, so
I suspect (after stepping through both python and java debuggers for a
whole lot) that something like multi-threading or garbage collection is
in some way significant.
To be clear, this isn't a bug in gump or a bug in ant, but a bug in the
JDK in interaction with a very specific environment. It'll be
interesting to see if, for instance, the same mess doesn't occur when
using Kaffe. I suspect that using any JVM for which Ant's Execute takes
a different approach (ie not using Runtime.exec) makes the problem go
away.
We'll have to see if this becomes a problem or not (eg zombie
processes). I'll try hard to, if we run into issues, produce big and
scary stack traces. My hunch is that we'd have to implement a work
around in Ant...I doubt sun is going to fix their jdk...
cheers,
Leo
[EMAIL PROTECTED] wrote:
* disable process group management for running ant. See inside
gump.plugins.java.builder.AntPlugin for some details. This was a *huge*
pain to figure out. What triggered this is the invocation of java_cup
from the xalan build.xml file, which has a java fork=true.
...
project name=xalan
-module name=xml/
+module name=xml-xalan/
!-- commands --
ant basedir=java target=unbundledjar
@@ -252,6 +263,8 @@
/project
...
+def _do_run_command(self, command, args, workdir, shell=False,
no_cleanup=False):
+# see gump.plugins.java.builder.AntPlugin for information on the
+# no_cleanup flag
+
...
-cmd =
Popen(myargs,shell=False,cwd=workdir,stdout=outputfile,stderr=STDOUT,env=command.env)
+cmd =
Popen(myargs,shell=False,cwd=workdir,stdout=outputfile,stderr=STDOUT,env=command.env,
no_cleanup=no_cleanup)
...
-command.build_log = outputfile.read()
+# we need to avoid Unicode errors when people put in 'fancy
characters'
+# into build outputs
+command.build_log = unicode(outputfile.read(), 'iso-8859-1')
+import tempfile
...
-def _get_new_process_group():
-Get us an unused (or so we hope) process group.
-pid = os.fork()
-gid = pid # that *should* be correct. However, let's actually
- # create something in that group.
-if pid == 0:
-# Child
-
-# ensure a process group is created
-os.setpgrp()
-
-# sleep for ten days to keep the process group around
-# for a while
-import time
-time.sleep(10*24*60*60)
-os._exit(0)
-else:
-# Parent
-
-# wait for child a little so it can set its group
-import time
-time.sleep(1)
-
-# get the gid for the child
-gid = os.getpgid(pid)
-
-return gid
-
-# This is the group we chuck our children in. We don't just want to
-# use our own group since we don't want to kill ourselves prematurely!
-_our_process_group = _get_new_process_group()
+temp_dir = tempfile.mkdtemp(gump_util_executor)
+process_list_filename = os.path.join(temp_dir, processlist.pids)
+def savepgid(filename):
+Function called from Popen child process to create new process
groups.
+os.setpgrp()
+f = None
+try:
+grp = os.getpgrp()
+f = open(filename,'a+')
+f.write(%d % grp)
+f.write('\n')
+finally:
+if f:
+try: f.close()
+except: pass
+
class Popen(subprocess.Popen):
This is a thin wrapper around subprocess.Popen which handles
process group management. The gump.util.executor.clean_up_processes()
@@ -106,35 +109,67 @@
stdin=None, stdout=None, stderr=None,
preexec_fn=None, close_fds=False, shell=False,
cwd=None, env=None, universal_newlines=False,
- startupinfo=None, creationflags=0):
-Create a new Popen instance that delegates to the
-subprocess Popen.
-if not preexec_fn:
-# setpgid to the gump process group inside
[jira] Created: (GUMP-146) Need to run each build against a fresh CVS/SVN tree
Need to run each build against a fresh CVS/SVN tree - Key: GUMP-146 URL: http://issues.apache.org/jira/browse/GUMP-146 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Fix For: Gump3-alpha-5 Gump2 has synchronisation functionality where we do a cvs/svn checkout of a project, then copy over that dir into the work area for the actual build. This ensures the build outputs of the last run don't influence the current one. Gump3 needs that functionality as well, probably best implemented by modifying the CvsUpdater and SvnUpdater plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (GUMP-146) Need to run each build against a fresh CVS/SVN tree
[ http://issues.apache.org/jira/browse/GUMP-146?page=all ] Leo Simons reassigned GUMP-146: --- Assign To: Adam Jack Need to run each build against a fresh CVS/SVN tree - Key: GUMP-146 URL: http://issues.apache.org/jira/browse/GUMP-146 Project: Gump Type: New Feature Components: Python-based Gump Versions: Gump3-alpha-5 Reporter: Leo Simons Assignee: Adam Jack Fix For: Gump3-alpha-5 Gump2 has synchronisation functionality where we do a cvs/svn checkout of a project, then copy over that dir into the work area for the actual build. This ensures the build outputs of the last run don't influence the current one. Gump3 needs that functionality as well, probably best implemented by modifying the CvsUpdater and SvnUpdater plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
Stefan Bodewig wrote: On Mon, 11 Jul 2005, Leo Simons [EMAIL PROTECTED] wrote: I suspect that using any JVM for which Ant's Execute takes a different approach (ie not using Runtime.exec) makes the problem go away. Hmm, have you run your tests with the equivalent of exec's vmlauncher=false? I.e. force Execute to use the ShellLauncher even if it is on JDK 1.2? I have now. It doesn't help. But it does give a new bit of info -- the /bin/sh process created by the ShellLauncher stalls as well, before ever firing up a new java process. I.e. we never get beyond return Runtime.getRuntime().exec(cmd, env); on line 736 of Execute.java. My hunch is that we'd have to implement a work around in Ant... I can probably get away with yet another magic property if I know how to cure the problem ;-) It'd be nice to know :-) I've verified that the same problem occurs when running the xalan build through gump on vmgump, so if you want to have a go at figuring it out, that's all set to go :-) cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
Stefan Bodewig wrote: I have now. It doesn't help. But it does give a new bit of info -- the /bin/sh process created by the ShellLauncher stalls as well, Likely some thread waiting for the process to read or the process waiting for Ant to write something. There have been some process deadlocks due to streams getting read too early or written too late. Yeah its something I thought about. I've tried manually sending bits and bytes into some of the unix pipes that get created but without much understanding of all the custom pipe stuff its pretty much impossible to understand. You are certainly using Ant's CVS HEAD, aren't you? Yep. Have also tried using 1.6.2 with the same result. I've verified that the same problem occurs when running the xalan build through gump on vmgump, so if you want to have a go at figuring it out, that's all set to go :-) I'll try to free up some time, thanks. Kewl! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] Gump3 for bootstrapping your entire environment
Gang, ... 00:05:35 INFO Processing LocalRepository: DEFAULT_GUMP_LOCAL_REPOSITORY 00:05:35 INFO Processing LocalModule: gump3-packages 00:05:35 INFO Processing Project: jdk 00:05:35 INFO Processing Project: jaxp 00:05:35 INFO Processing CvsModule: xml-xalan 00:05:35 INFO Processing Project: java_cup 00:05:35 INFO Processing CvsRepository: ant 00:05:35 INFO Processing CvsModule: ant 00:05:35 INFO Processing Project: bootstrap-ant 00:05:35 DEBUG Perform Script:bootstrap,args=,shell=,basedir= on Project: bootstrap-ant 00:05:35 DEBUG Perform Script:bootstrap,args=,shell=,basedir= on Project: bootstrap-ant 00:05:35 INFO Executing command: '/usr/bin/env sh /home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/ant/ant/bootstrap.sh' in directory '/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/ant/ant' 00:06:09 INFO Processing CvsModule: xml-commons 00:06:09 INFO Processing Project: xml-apis 00:06:09 DEBUG Perform Ant:target=jar,buildfile=,basedir=java/external on Project: xml-apis 00:06:09 DEBUG Perform Ant:target=jar,buildfile=,basedir=java/external on Project: xml-apis 00:06:09 DEBUG Perform Ant:target=jar,buildfile=,basedir=java/external on Project: xml-apis 00:06:09 DEBUG CLASSPATH is '/usr/lib/j2se/1.5/lib/tools.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jdk/lib/tools.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/ant/ant/bootstrap/lib/ant.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/ant/ant/bootstrap/lib/ant-launcher.jar' 00:06:09 DEBUG PATH is '/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jdk/bin:/usr/lib/j2se/1.4/bin:/home/lsimons/bin:/home/lsimons/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11::/home/lsimons/svn/gump/branches/Gump3/' 00:06:09 INFO Executing command: 'java -Xbootclasspath/p:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jaxp-1_3-20050622-gump-20050710/jaxp-api.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jaxp-1_3-20050622-gump-20050710/dom.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jaxp-1_3-20050622-gump-20050710/sax.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jaxp-1_3-20050622-gump-20050710/xercesImpl.jar:/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/DEFAULT_GUMP_LOCAL_REPOSITORY/gump3-packages/jaxp-1_3-20050622-gump-20050710/xalan.jar org.apache.tools.ant.Main jar' in directory '/home/lsimons/svn/gump/branches/Gump3/pygump/work/gump3-test/xml/xml-commons/java/external' ... Freely translated, it took me about 20 minutes to make it possible to have gump compile binaries it can then use (by modifying the PATH in which subprocesses execute) for building other stuff. Theoretically, this shows that we could have gump compile a GCC to compile a linux environment to chroot in to compile a python to run gump. Practically, It's going to take a while to figure out how to do all that (and we don't want to be bootstrapping GCC, trust me), but this is encouraging. Another cool thin to think about is that if we get gump to build all its prerequisites installation could be made much easier :) cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting project file name from module
Hi Justin! Justin Merz wrote: Since gump3 does not recoginze maven project descriptor files I am trying to access the file name from the module descriptor file (/tag if in same file). Actually, I think that gump, in the form of the Loader component, manages to load the descriptor just fine. Eg it if you have workspace ... projects ... project href=somemavendescriptor.xml /project /projects ... /workspace then the Loader will get hold of somemavendescriptor.xml, and replace said project/ with the contents of that descriptor. But my memory is a bit sketchy, and that's probably not tested. Might be a good idea ;) I believe the project descriptor tag is removed from the module file and placed into a dropped_tags list. Hmm. I don't think so. I think after the loading stage is complete the descriptors are still in the workspace. Is there anyway to access this list ie functions already written Not really, but Engine._write_merge_files() does iterate over that list and writes a new xml file. You might find it helpful. And the other bits of gump.engine do a lot of xml manipulation to spy on. But no doubt you're still going to have to figure out loads of DOM stuff :-) See http://www.python.org/doc/current/lib/module-xml.dom.html or does anyone have a better idea how to access all of module's data by the time normalizer gets ahold of it? In the example above, maybe we could have workspace ... projects ... project type=maven href=somemavendescriptor.xml /project /projects ... /workspace And then you could build a Mavenizer component that does something like this projects = w.getElementsByTagName(project) for p in [p for p projects if p.getAttribute(type) == maven]: magic_goes_here() Or maybe there's a good way to detect that we're dealing with a maven definition (eg if all maven xml files always have a pomVersion or something). I dunno. If you do an 'svn log' on normalizer.py and/or look through the mailing list archives you might find ideas some of us had at some point. But I'd just do the thinking myself if I were you ;) PS. please let me know if you think i am going in the wrong direction on this! Nope, just keep going :-). Once you've got your first patch together I'll try and give you more feedback to shake a stick at :-) cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [howto] Debugging gump3
Leo Simons wrote: So, ehm, it is possible to run gump through pdb or another debugger (like wing), but I've found none of those are really of sufficient quality to be very productive. ye olde print statement works as well. So, ehm, *cough*, I actually found myself explaining to adam the other day how useful the Wing IDE debugger can be. I just committed some stuff that hopefully makes it real easy to use either wing or PDB for debugging. Let me know if it doesn't work. Justin, you might want to try this out. You can get a free license to Wing IDE for working on open source software (see http://wingware.com/store/prices#discounts). cheers, Leo Using a Real Debugger(tm) with Gump3 Running `./gump help` shows two debug-related command line options: debug -- run pygump in debug mode, attaching pdb debug-with-wing -- run pygump in debug mode, attaching the Wing IDE Which have docs: [EMAIL PROTECTED] ./gump help debug Run pygump in debug mode. Usage: ./gump debug [gump.py-args ...] This is not the same as executing the 'run' command with a '--debug' parameter. Using this command will actually start the command line debugger pdb to run gump in, whereas the '--debug' option customizes the log verbosity gump will use. This command otherwise accepts the same arguments as the 'run' command. [EMAIL PROTECTED] ./gump help debug-with-wing Gump3 Run pygump in debug mode. Usage: ./gump debug [gump.py-args ...] This is not the same as executing the 'run' command with a '--debug' parameter. Using this command will actually start the debug connector for the Wing IDE and attach it to the gump process, whereas the '--debug' option customizes the log verbosity gump will use. This command otherwise accepts the same arguments as the 'run' command. Usage is something like this: ./gump debug -w \ /home/lsimons/svn/gump/branches/Gump3/fixture/metadata/workspace.xml or for wing ide: export WINGHOME=path/to/wing/2 ./gump debug-with-wing -w \ /home/lsimons/svn/gump/branches/Gump3/fixture/metadata/workspace.xml If you've not worked with debuggers before, you should probably take some time to review the relevant documentation for your choice of - PDB: http://www.ferg.org/papers/debugging_in_python.html - Wing IDE: http://wingware.com/doc/debug/index - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-139) module project fails, it needs to be module project module
[ http://issues.apache.org/jira/browse/GUMP-139?page=all ] Leo Simons closed GUMP-139: --- Fix Version: Gump3-alpha-4 Resolution: Fixed module project fails, it needs to be module project module --- Key: GUMP-139 URL: http://issues.apache.org/jira/browse/GUMP-139 Project: Gump Type: Bug Components: Python-based Gump Versions: Gump3-alpha-3 Reporter: Adam Jack Assignee: Leo Simons Fix For: Gump3-alpha-4 This might be considered support for 0.4 metadata. Normalizer:_get_list_merged_by_name returns cloned nodes --- and those nodes are w/o a parent. As such Normalizer:_find_module_containing_node fails when looking for the parent module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-137) A missing href (e.g. typo of file/URL not found) causes Gump to crash
[ http://issues.apache.org/jira/browse/GUMP-137?page=all ] Leo Simons closed GUMP-137: --- Fix Version: Gump3-alpha-4 Resolution: Fixed Assign To: Leo Simons It seems this was fixed a while back but I forgot to close the issue. A missing href (e.g. typo of file/URL not found) causes Gump to crash - Key: GUMP-137 URL: http://issues.apache.org/jira/browse/GUMP-137 Project: Gump Type: Bug Components: Python-based Gump Versions: Gump3-alpha-3 Reporter: Adam Jack Assignee: Leo Simons Fix For: Gump3-alpha-4 A missing href (e.g. typo of file/URL not found) causes Gump to crash: Find module starting with DOM Element: module at 0x11c4120 Found! 16:44:13 WARNINGDropping module '' because of href resolution error! 16:44:13 ERROR Fatal error during run! Traceback (most recent call last): File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\__init__.py, line 21 4, in run (domtree, dropped_nodes) = self.workspace_loader.get_workspace_tree(self.wor kspace) File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\loader.py, line 186, in get_workspace_tree _resolve_hrefs_in_children(ws, dropped_nodes, [], self.get_as_stream, self.h andle_error) File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\loader.py, line 67, in _resolve_hrefs_in_children _resolve_hrefs_in_children(child, dropped_nodes, found_hrefs[:], download_fu nc, error_func) File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\loader.py, line 61, in _resolve_hrefs_in_children _resolve_href(child, dropped_nodes, found_hrefs, download_func, error_func) File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\loader.py, line 89, in _resolve_href error_func(href, node, dropped_nodes) File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\loader.py, line 225, in handle_error _do_drop(project, dropped_nodes) File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\modeller.py, line 47 , in _do_drop node_to_remove_element_from = to_remove.parentNode AttributeError: 'NoneType' object has no attribute 'parentNode' DEBUG: Run completed! DEBUG: Cleaning up child processes. This may take up to a little over 400 second s. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-138) Modules dropped (due to missing Repository) causes a crash.
[ http://issues.apache.org/jira/browse/GUMP-138?page=all ] Leo Simons closed GUMP-138: --- Fix Version: Gump3-alpha-4 (was: Gump3-alpha-3) Resolution: Fixed Modules dropped (due to missing Repository) causes a crash. --- Key: GUMP-138 URL: http://issues.apache.org/jira/browse/GUMP-138 Project: Gump Type: Bug Components: Python-based Gump Versions: Gump3-alpha-3 Reporter: Adam Jack Assignee: Leo Simons Fix For: Gump3-alpha-4 Module dropped due to missing repository (e.g. for packaged??) causes later crash. 16:53:43 DEBUG Converting project definition 'xml-xercesImpl' into objectorm. 16:53:43 ERROR Fatal error during run! Traceback (most recent call last): File f:\data\Python\Gump3-SVN\pygump\python\gump\engine\__init__.py, line 22 6, in run workspace = self.workspace_objectifier.get_workspace(domtree) File f:\data\Python\Gump3-SVN\gump\engine\objectifier.py, line 362, in get_w orkspace File f:\data\Python\Gump3-SVN\gump\engine\objectifier.py, line 403, in _crea te_projects File f:\data\Python\Gump3-SVN\gump\engine\objectifier.py, line 395, in _find _module_for_project KeyError: u'xml-xerces2' DEBUG: Run completed! DEBUG: Cleaning up child processes. This may take up to a little over 400 second s. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GUMP-131) Build fails with build timed out
[ http://issues.apache.org/jira/browse/GUMP-131?page=all ] Leo Simons updated GUMP-131: Fix Version: Gump2-2.4 Description: While compiling a make on a very large (compile time 2 hours or more) C/C++ project, the build is reported as failed with the reason build timed out. The build log shows that the build has been stopped half way through the build. There is no obvious evidence that the build has hung in any way. If an attempt is made to cd to the build directory and type make, the build completes normally. There is no obvious timeout setting that can change this - if there is can the build timed out message be replaced with a message that says build timed out - increase option ZZZ and try again. was: While compiling a make on a very large (compile time 2 hours or more) C/C++ project, the build is reported as failed with the reason build timed out. The build log shows that the build has been stopped half way through the build. There is no obvious evidence that the build has hung in any way. If an attempt is made to cd to the build directory and type make, the build completes normally. There is no obvious timeout setting that can change this - if there is can the build timed out message be replaced with a message that says build timed out - increase option ZZZ and try again. Version: Gump2-2.4 Assign To: Adam Jack Build fails with build timed out -- Key: GUMP-131 URL: http://issues.apache.org/jira/browse/GUMP-131 Project: Gump Type: Bug Components: Python-based Gump Versions: Gump2-2.4 Environment: Solaris v2.8, Gump SVN trunk (Python 2.4.1) Reporter: Graham Leggett Assignee: Adam Jack Fix For: Gump2-2.4 While compiling a make on a very large (compile time 2 hours or more) C/C++ project, the build is reported as failed with the reason build timed out. The build log shows that the build has been stopped half way through the build. There is no obvious evidence that the build has hung in any way. If an attempt is made to cd to the build directory and type make, the build completes normally. There is no obvious timeout setting that can change this - if there is can the build timed out message be replaced with a message that says build timed out - increase option ZZZ and try again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-132) http://vmgump.apache.org/ needs a landing page
[ http://issues.apache.org/jira/browse/GUMP-132?page=all ] Leo Simons closed GUMP-132: --- Resolution: Fixed Assign To: Adam Jack http://vmgump.apache.org/ needs a landing page -- Key: GUMP-132 URL: http://issues.apache.org/jira/browse/GUMP-132 Project: Gump Type: Task Components: Infrastructure Reporter: Adam Jack Assignee: Adam Jack Priority: Minor http://vmgump.apache.org/ needs a landing page, like Brutus used to have. Was that page saved? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GUMP-115) Make gump result pages link to LXR-generated content
[ http://issues.apache.org/jira/browse/GUMP-115?page=all ] Leo Simons updated GUMP-115: Component: Dynagump (was: Python-based Gump) Fix Version: Gump3-alpha-6 Version: Gump3-alpha-6 Environment: Make gump result pages link to LXR-generated content Key: GUMP-115 URL: http://issues.apache.org/jira/browse/GUMP-115 Project: Gump Type: New Feature Components: Dynagump Versions: Gump3-alpha-6 Reporter: Leo Simons Priority: Minor Fix For: Gump3-alpha-6 Once GUMP-114 is set up, we could provide links to the cross-referenced stuff from the gump build results pages. It would be esp. cool to parse build outputs for filenames and line numbers and transform those into links into the cross referenced source. This would mean that a whole lot of debugging could take place by clicking around the gump site, without developers having to check out the matching version of code they wish to examine from version control. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-113) Set up dynagump installation and proxypass from main gump site
[ http://issues.apache.org/jira/browse/GUMP-113?page=comments#action_12315261 ] Leo Simons commented on GUMP-113: - The new dynagump is at http://vmgump.apache.org:8080/ started from the crontab of the 'gump' user. Set up dynagump installation and proxypass from main gump site -- Key: GUMP-113 URL: http://issues.apache.org/jira/browse/GUMP-113 Project: Gump Type: Task Components: Infrastructure Versions: Gump3-alpha-4 Environment: brutus.apache.org, minotaur.apache.org, or perhaps a new vhost on loki or helios Reporter: Leo Simons Priority: Minor We should actively start using the cool new interface dynagump provides us for our documentation needs. This requires a webapp set up, and the gump.apache.org vhost should be proxypassing it for security, performance and url management reasons. For now I suggest we simply hide the actual dynagump features in development, and link only to the documentation that's in there. This should not be started before the whole infrastructure dust cloud settles a little and the plans for the apache hardware become more definitive. We should also take care not to confuse users; for now we don't want them doing anything with Gump3 whatsoever :-D -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump3 - error
Justin Merz wrote: I can't seem to trace error back. Any suggestions? Ignore the test failures for now. I broke some of them yesterday. cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynagumper is alive!
On 06-07-2005 13:51, Adam R. B. Jack [EMAIL PROTECTED] wrote: 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 Fancy! BTW: Can we fix the schema, or do we need to re-instantiate it? The latter. I'll try and take care of it tonight. 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? Huh? Ehm, will do. Are certain plugins not getting called when another fails? I'm never quite sure how Gump3 copes with errors. Its supposed to be pretty simple: all exceptions that occur inside a plugin bubble up to the algorithm that's being run. The idea is that you configure the ErrorHandler used with the Algorithm. Using the OptimisticLoggingErrorHandler swallows the exceptions that plugins raise, whereas the LoggingErrorHandler re-raises all of them. Maybe the post-processing plugins are configured with the LoggingErrorHandler or something. I'll check. Cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
