cvs commit: gump/profile gump.xml
bodewig 2004/07/09 00:27:53 Modified:profile gump.xml Log: drop removed servers from profile Revision ChangesPath 1.363 +2 -2 gump/profile/gump.xml Index: gump.xml === RCS file: /home/cvs/gump/profile/gump.xml,v retrieving revision 1.362 retrieving revision 1.363 diff -u -r1.362 -r1.363 --- gump.xml 6 Jul 2004 09:38:40 - 1.362 +++ gump.xml 9 Jul 2004 07:27:53 - 1.363 @@ -373,10 +373,10 @@ server href=server/brutus.xml/ server href=server/covalent.xml/ - server href=server/dotnot.xml/ + !--server href=server/dotnot.xml/ server href=server/hermes.xml/ server href=server/lsd.xml/ - server href=server/try.xml/ + server href=server/try.xml/-- !-- tracker definitions -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] fixed-version-dependency needet? (was: [GUMP@brutus]: commons-vfs/commons-vfs failed)
Hello! Since today vfs fails to build in gump due to an api change in commons-httpclient. I dont know why this happens today as this change is 11 month old and vfs itself uses this thing for a while. If i adapt vfs to make it compatible with the api change i will break the slide-webdavclient library. So i have to stick on httpclient-2.0. What to do next? Shall i ignore the error and wait until things settle together again - or should i add a fixed-version-dependency to vfs. If i should add a fixed-version-dependency: *) do i really have to add the httpclient-jar to vfs's cvs and add a description file as described on http://wiki.apache.org/gump/FrequentlyAskedQuestions or is there any other method available now? *) the description is an additional project entry that should be added to gump.xml - right? *) how should this line look option project=commons-httpclient/ after adding the description: (from guml.xml in vfs) Thanks! Mario To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project commons-vfs has an issue affecting its community integration. This issue affects 6 projects. Project State : 'Failed', Reason 'Build Failed' The following are affected: - antworks-importer-with-depot : Autodownload and import ant build.xml's. - depot-update : Depot -- repository tools and more... - depot-update-ant-sample-httpclient : Depot -- repository tools and more... - depot-update-ant-sample-jdk : Depot -- repository tools and more... - depot-update-ant-sample-vfs : Depot -- repository tools and more... - depot-update-test : Depot -- repository tools and more... Full details are available at: http://brutus.apache.org:8080/gump/commons-vfs/commons-vfs/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [commons-vfs-20040708.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. The following work was performed: http://brutus.apache.org:8080/gump/commons-vfs/commons-vfs/gump_work/build_commons-vfs_commons-vfs.html Work Name: build_commons-vfs_commons-vfs (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 4 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-vfs-20040708 -f build.xml dist [Working Directory: /usr/local/gump/public/workspace/commons-vfs] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/commons-vfs/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040708.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/target/commo ns-compress-0.1-dev.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/net/dist/commons-net-20040708.jar:/usr/local/gump/public/workspace/jakarta-slide/webdavclient/dist/lib/jakarta-slide-webdavlib-20040708.jar:/usr/local/gump/packages/jcifs/jcifs-0.8.1.jar:/usr/local/gump/packages/jsch-0.1.14/dist/lib/jsch-gump.jar- Buildfile: build.xml init: [mkdir] Created dir: /usr/local/gump/public/workspace/commons-vfs/target/lib get-deps: compile: [mkdir] Created dir: /usr/local/gump/public/workspace/commons-vfs/target/classes [javac] Compiling 150 source files to /usr/local/gump/public/workspace/commons-vfs/target/classes [javac] /usr/local/gump/public/workspace/commons-vfs/src/java/org/apache/commons/vfs/provider/http/HttpClientFactory.java:67: warning: setCredentials(java.lang.String,java.lang.String,org.apache.commons.httpclient.Credentials) in org.apache.commons.httpclient.HttpState has been deprecated [javac] client.getState().setCredentials(null, hostname, creds); [javac]^ [javac]
cvs commit: gump/project avalon-tools.xml
bodewig 2004/07/09 00:43:04 Modified:project avalon-tools.xml Log: Make unit tests work with 'plain' instead of 'black' magic Revision ChangesPath 1.22 +4 -1 gump/project/avalon-tools.xml Index: avalon-tools.xml === RCS file: /home/cvs/gump/project/avalon-tools.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- avalon-tools.xml 9 Jul 2004 05:19:48 - 1.21 +++ avalon-tools.xml 9 Jul 2004 07:43:04 - 1.22 @@ -45,11 +45,12 @@ project name=avalon-tools-magic license name=central/system/license/LICENSE.TXT/ +mkdir dir=tools/magic/target/classes/ +mkdir dir=tools/magic/target/test-classes/ ant basedir=tools/magic !-- for magic -- property name=magic.home reference=home project=magic/ property name=gump.signature value=@@DATE@@/ - property name=build.sysclasspath value=dark-arts-volume-one/ !-- external references -- depend property=gump.resource.ant project=ant id=ant/ depend property=gump.resource.junit project=junit/ @@ -58,6 +59,8 @@ !-- end for -- /ant depend project=magic runtime=true inherit=runtime/ +work nested=tools/magic/target/classes/ +work nested=tools/magic/target/test-classes/ home nested=tools/magic/target/deliverables/ jar name=jars/avalon-tools-magic-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] fixed-version-dependency needet?
On Fri, 09 Jul 2004, Mario Ivankovits [EMAIL PROTECTED] wrote: If i adapt vfs to make it compatible with the api change i will break the slide-webdavclient library. So i have to stick on httpclient-2.0. There is a Gump project for the 2.0 branch of httpclient[1] because of the amount of backwards incompatible changes in httpclient. Maybe simply making your Gump descriptor point to that will be enough? The real solution would be to adapt slide-webdavclient together with vfs or to get the httpclient developers to care more about backwards compatibility. Stefan Footnotes: [1] name=commons-httpclient-2.0-branch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
I tend to agree with most of what has been said in this thread so far. The reasons the Python rewrite started AFAIR: * get more people involved: didn't work, there are even less people working on Gump's code base than before. * get people involved from outside the Java community didn't work either. * simplify things Not sure. For me finding the time to actually learn Python idioms to get beyond my very basic understanding (what you get by reading Mark's Dive into Python) has proven to be almost impossible. I don't know whether it's a matter of the code-base or the language or my abilities - and as such would need to look into Adam's rework. I know that I managed to wrap my head around the Java side of traditional Gump in far less time than I've spent on reading the Gumpy code so far - and I still don't get Python Gump. I never tried to really understand all parts of traditional's XSLT sheets, I never had to. But before we try to start all over again. Who is actually willing to write code for Gump as opposed to just toss around ideas - and who really has the time to do so and isn't already overcomitted to too many things? If it turns out to be just Adam anyway, there is little to no reason to change anything. What I'm trying to say is that Python didn't help Gump but I'm not sure it did harm to it either. For most (if not all?) of us Gump is a very interesting project, but a second or third project next to our main project(s) and as such simply suffers from if I only had time ... syndroms. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon-tools.xml
mcconnell2004/07/09 05:19:40 Modified:project avalon-tools.xml Log: Put back the build.sysclasspath override - I need to validate a build with this in place before moving forward. Revision ChangesPath 1.23 +1 -4 gump/project/avalon-tools.xml Index: avalon-tools.xml === RCS file: /home/cvs/gump/project/avalon-tools.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- avalon-tools.xml 9 Jul 2004 07:43:04 - 1.22 +++ avalon-tools.xml 9 Jul 2004 12:19:40 - 1.23 @@ -45,12 +45,11 @@ project name=avalon-tools-magic license name=central/system/license/LICENSE.TXT/ -mkdir dir=tools/magic/target/classes/ -mkdir dir=tools/magic/target/test-classes/ ant basedir=tools/magic !-- for magic -- property name=magic.home reference=home project=magic/ property name=gump.signature value=@@DATE@@/ + property name=build.sysclasspath value=/ !-- testing -- !-- external references -- depend property=gump.resource.ant project=ant id=ant/ depend property=gump.resource.junit project=junit/ @@ -59,8 +58,6 @@ !-- end for -- /ant depend project=magic runtime=true inherit=runtime/ -work nested=tools/magic/target/classes/ -work nested=tools/magic/target/test-classes/ home nested=tools/magic/target/deliverables/ jar name=jars/avalon-tools-magic-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
On Fri, 09 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Just a quick note - I'm putting back in the build.sysclasspath override because I need to validate that this is the only remaining issue. It isn't 8-( The build tries to copy a jar that isn't there: standard.test: [x:junit] Running org.apache.avalon.tools.model.test.ContextTestCase [x:junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0,829 sec test: standard.install: install: BUILD FAILED /javastuff/gump/avalon-tools/tools/magic/build.xml:30: Warning: Could not find file /javastuff/gump/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic.jar to copy. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
Stefan Bodewig wrote: On Fri, 09 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Just a quick note - I'm putting back in the build.sysclasspath override because I need to validate that this is the only remaining issue. It isn't 8-( The build tries to copy a jar that isn't there: BUILD FAILED /javastuff/gump/avalon-tools/tools/magic/build.xml:30: Warning: Could not find file /javastuff/gump/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic.jar to copy. I know what this is - its not magic - its supplementary stuff I've added to make my life easier. I'll have this fixed in just a moment. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting lots of /tmp/*.xls on Brutus
In any case, the files are created in the system temp directory, using the java File.createTempFile method call. I dont know if that is something that can be controlled by setting environment variables. Does JDK 1.3+ cover POI users? http://java.sun.com/j2se/1.3/docs/api/java/io/File.html#createTempFile(java.lang.String,%20java.lang.String,%20java.io.File) Seems you could pass ./tmp, which would make Gump happy. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
Stephen McConnell wrote: Stefan Bodewig wrote: On Fri, 09 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Just a quick note - I'm putting back in the build.sysclasspath override because I need to validate that this is the only remaining issue. It isn't 8-( The build tries to copy a jar that isn't there: BUILD FAILED /javastuff/gump/avalon-tools/tools/magic/build.xml:30: Warning: Could not find file /javastuff/gump/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic.jar to copy. I know what this is - its not magic - its supplementary stuff I've added to make my life easier. I'll have this fixed in just a moment. ... and fixed. Should have that other email done in a tick. Cheers, Steve. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build.sysclasspath management
I'm learning all sorts of things about how gump works! Please keep in mind that this message is based on a bunch of assumptions and limited experience - but I think I'm correct (so please feel free to correct any mistakes). If your in a hurry - skip to the end. Anyway - here goes... Gump and Ant basically collaborate together though the subversion of classloader creation. First of all - a gump project definition is for all intensive purposes a descriptor enabling the establishment of a single classpath. Ant provides support for a system property build.sysclasspath which if set to none ensures that the bootstrap classpath is used throughout the execution of an ant session. Gump, using the project definition creates a single project classpath, and using the build.sysclasspath property takes effective control over the classloaders created with ant - enabling community wide normalization of classpath constructs. This approach is quite effective when dealing with simple ant build procedures (compile, test, jar, javadoc, etc.) as it enables the reuse of the classic build definition build.xml within a continuous integration context. In contrast - Magic maintains an index of project definitions. Each definition contains information about compilation, build, test and runtime dependencies. Magic uses this information together with property values supplied by gump to construct appropriate classloaders for the respective build phases. In the case of a build that requires a plugin, Magic creates a classloader for the plugin on the fly. Magic also makes extensive use of meta-information for build and runtime processes (generating and consuming multiple definitions in a single project build). Currently the Magic based build of Magic is failing due to the gump's subversion of control over classpath management. Specifically - the magic generated classpath for unit testing is being ignored by ant (due to the build.sysclasspath property setting) resulting in a inconsistent classpath under the junit task. While this particular problem can be solved with things like gump work directives - it does not address the underlying problem of classloader management. In effect the magic build will fail on the first project requesting a plugin. Clearly - the assumptions behind the project == classpath notion become an issue when dealing with a build system which provides artifact resolution. In this scenario the build system needs information about artifact locations. In effect it's my opinion that gump should be delegating the responsibility to the builder for classpath and classloader management. This leads me to the question of how to properly handle the disabling of the gump declaration of build.sysclasspath. As things stand this is declared within the gump workspace. It seems to me that modifying this is not a good idea as it would probably break gump on all non-magic builds. Instead there appears to be a least a couple of options: a) enable the ability to disable build.sysclasspath on the AntBuilder or b) add a MagicBuilder which disables build.sysclasspath Outside of the these two I have the feeling I'm getting into workarounds (things like overloading the property is not nice - and forking another java process seems like cludge). OK - thoughts? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: GumpDevelopment
Date: 2004-07-09T07:21:06 Editor: 67.234.191.96 Wiki: Gump Wiki Page: GumpDevelopment URL: http://wiki.apache.org/gump/GumpDevelopment Added the PyDoc link Change Log: -- @@ -14,6 +14,10 @@ then browse the WWW site (on http://localhost:1234) it generates to get class documentation. +Note: Currently an instance of pydoc runs on brutus: + + [http://brutus.apache.org/gump/pydoc Gump PyDoc] + = Debugging = Gump uses the standard Python 'logging' package (bundled in 2.3) but has a copy of it [under python/] for 2.2. Typically the command line options of ''--debug'' and ''--verbose'' turn this on. Gump code current uses a single log instance (not one per package/module). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: GumpDevelopment
Date: 2004-07-09T07:24:24 Editor: 67.234.191.96 Wiki: Gump Wiki Page: GumpDevelopment URL: http://wiki.apache.org/gump/GumpDevelopment Changed Python 2.2 to 2.3 Change Log: -- @@ -2,13 +2,13 @@ Gump development is primarily in Python, see GumpPython. -Gump use Python 2.2, not 2.3, which means a set of features are not available. +Gump uses Python 2.3 or above. = Overview = Use pydoc to get a look at the classes. -In $GUMP/pythoin, with $PYTHONPATH set (to `pwd`), run pydoc: +In $GUMP/python, with $PYTHONPATH set (to `pwd`), run pydoc: python $PYTHON\lib\pydoc.py -p 1234 gump @@ -20,7 +20,7 @@ = Debugging = -Gump uses the standard Python 'logging' package (bundled in 2.3) but has a copy of it [under python/] for 2.2. Typically the command line options of ''--debug'' and ''--verbose'' turn this on. Gump code current uses a single log instance (not one per package/module). +Gump uses the standard Python 'logging' package (bundled in 2.3). Typically the command line options of ''--debug'' and ''--verbose'' turn this on. Gump code current uses a single log instance (not one per package/module). Write to the log using log.debug( ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: GumpDevelopment
Date: 2004-07-09T07:59:39 Editor: 67.234.191.96 Wiki: Gump Wiki Page: GumpDevelopment URL: http://wiki.apache.org/gump/GumpDevelopment Fixed link (needed / on end). Change Log: -- @@ -16,7 +16,7 @@ Note: Currently an instance of pydoc runs on brutus: - [http://brutus.apache.org/gump/pydoc Gump PyDoc] + [http://brutus.apache.org/gump/pydoc/ Gump PyDoc] = Debugging = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: GumpDevelopment
Date: 2004-07-09T08:25:33 Editor: 67.234.191.96 Wiki: Gump Wiki Page: GumpDevelopment URL: http://wiki.apache.org/gump/GumpDevelopment Reference GumpCode Change Log: -- @@ -18,6 +18,8 @@ [http://brutus.apache.org/gump/pydoc/ Gump PyDoc] +See als othe code documentation at '''GumpCode'''. + = Debugging = Gump uses the standard Python 'logging' package (bundled in 2.3). Typically the command line options of ''--debug'' and ''--verbose'' turn this on. Gump code current uses a single log instance (not one per package/module). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: GumpCode
Date: 2004-07-09T08:28:01 Editor: 67.234.191.96 Wiki: Gump Wiki Page: GumpCode URL: http://wiki.apache.org/gump/GumpCode no comment Change Log: -- @@ -7,6 +7,8 @@ '''Main Packages:''' +See GumpInternals for how a run (the tree of context) is formed (objects from XML) and worked on. + * [http://brutus.apache.org/gump/pydoc/gump.core.html Core Classes (e.g. Gump Run)] * [http://brutus.apache.org/gump/pydoc/gump.model.html Object Model (e.g. Project/Module...)] * [http://brutus.apache.org/gump/pydoc/gump.runner.html Running (perform a run)] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project james-server.xml
mcconnell2004/07/09 10:35:02 Modified:project james-server.xml Log: add commons pool, lang, and collections to dependencies Revision ChangesPath 1.11 +3 -0 gump/project/james-server.xml Index: james-server.xml === RCS file: /home/cvs/gump/project/james-server.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- james-server.xml 8 Jul 2004 22:42:16 - 1.10 +++ james-server.xml 9 Jul 2004 17:35:02 - 1.11 @@ -51,6 +51,9 @@ depend project=cornerstone-store-impl inherit=runtime/ depend project=commons-net/ depend project=commons-dbcp/ +depend project=commons-pool/ +depend project=commons-lang/ +depend project=commons-collections/ depend project=jakarta-oro/ depend project=town/ depend project=dnsjava/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump/build builder.py
ajack 2004/07/09 11:20:36
Modified:python/gump/document/xdocs xdoc.py
python/gump/build builder.py
Log:
1) Attempt to use rmtree (to remove a full dir)
2) PythonPowered
Revision ChangesPath
1.4 +2 -2 gump/python/gump/document/xdocs/xdoc.py
Index: xdoc.py
===
RCS file: /home/cvs/gump/python/gump/document/xdocs/xdoc.py,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- xdoc.py 8 Jul 2004 20:33:09 - 1.3
+++ xdoc.py 9 Jul 2004 18:20:36 - 1.4
@@ -756,7 +756,7 @@
self.context.writeLine(' tda
href=%s/gump_stats/index.htmlStats/a/tdtd|/td' % self.rootpath)
self.context.writeLine(' tda
href=%s/gump_xref/index.htmlXRef/a/td' % self.rootpath)
-self.context.writeLine(' td colspan=3img align=right
src=%s/images/gump-logo.png alt=Logo//td' % self.rootpath)
+self.context.writeLine(' td colspan=3img align=right
src=%s/images/gump-logo.png alt=Gump Logo//td' % self.rootpath)
self.context.writeLine(' /tr')
self.context.writeLine('/table')
else:
@@ -779,7 +779,7 @@
self.context.writeLine('/document')
else:
from gump.core.config import default
-self.context.writeLine('p align=rightLast Updated: %s/p' %
default.datetime)
+self.context.writeLine('p align=rightLast Updated: %s.img
align=right src=%s/images/PythonPowered.gif alt=Python Logo//p' %
default.datetime)
self.context.writeLine('/html')
self.close()
1.6 +21 -1 gump/python/gump/build/builder.py
Index: builder.py
===
RCS file: /home/cvs/gump/python/gump/build/builder.py,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- builder.py8 Jul 2004 20:33:09 - 1.5
+++ builder.py9 Jul 2004 18:20:36 - 1.6
@@ -16,6 +16,18 @@
# limitations under the License.
+
+ This is the main project builder for gump.
+
+ 1) Pre build tasks (deleting directories/files, making directories)
+ are performed here.
+
+ 2) Leveraging ant and/or maven and/or script 'assistants' the
+ project work is done (based of 'stat's, so --debug can be set in
+ a series of failures)
+
+ 3) Post build tasks (verifying jars exist, publishing to repositories,
+ etc).
@@ -183,6 +195,13 @@
def performDelete(self,project,delete,index=0):
Return the delete command for a delete entry
+
+return
+
+# :TODO: Re-instate this some time, when can delete
+# non-empty directories.
+
+
basedir=os.path.abspath(project.getModule().getWorkingDirectory() or
dir.base)
#
@@ -191,7 +210,8 @@
if delete.hasDirectory():
dir=delete.getDirectory()
try:
-os.rmdir(dir)
+import shutil
+shutil.rmtree(dir)
project.addInfo('Deleted directory ['+dir+']')
except:
project.addError('Failed to delete directory ['+dir+']')
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
Adam R. B. Jack wrote: 3h 23m. That's an improvement! :-) Daft, but I've not been paying attention (too painful to look) :-) -- what was it before? The cycle time between updates of the web site was around 9 hours - gump was reporting about 5 hours for the run (so we are already seeing a big improvement on that aspect). In addition there is that mystery 4 hours between the end of the run and the appearance off documentation. Still, it can do far far better. Multi-threading the CVS/SVN ought reduce the latency. The main problem (for no clear reason I can gather) still seems to be generating documentation. Just an observation - that way things are using the current setup is for me better. Ok the docs are not a nice but what I can see immediately is the following: (a) a message saying gump is running and it started at ... (b) result as they unfold which gives me more time to hit the issue (e.g. I figure I've fixed james during the last run because I was able to access the info before the run had completed) Things I wasn't too impressed with was the dirty big red banner complaining about my subversion of build.sysclasspath which kind of made me cringe. :-) Ever tried a targeted run? Nope - never. I'll leave that sort of thing to Niclas! If one runs to (say) depot or something like this (a trimmed stack), this thing flies. It is something that clogs up over time I can't track it down (ok, haven't yet). Watching the interactive progress you get a feel for this as well - gump kicks off and rips though the early entries but things get progressively slower. But the end of the run she's not showing the same degree enthusiasm! I sometimes wonder if it is the Python implementation, not Gumpy per se. Something to do with the number of objects in memory. Sooner or later I'll find it. :-) Steve. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump n' magic update
I have heard some horror stories about getting those Gump building boxes working, and we are somewhat in over our heads, as I don't think anyone with Python experience is interested in helping out... Those were the bad old days are part of what inspired me to tinker w/ Python Gump. ;-) It takes me about 10 minutes to set up a new Gump for my local usage. If one wanted to build the thing from scratch (from OS up) here is some good information: http://wiki.apache.org/gump/BrutusConfig Heck, folks w/ a better link than me my modem could do this on their own PC, it really doesn't need a server. For work I created an instance, copied the minimal workspace in, added my work projects, and (over about 20 minutes w/ gump/preview.py) trimmed a decent workset. That gump takes 20 minutes to run, start to finish (including all the Ant/Jakarta stuff I depend upon). If anybody is interested in trying, I'm game to work with them, so long as contsructive feedback is gathered/reported. Alternatively ... I think the test workspace on brutus could be used for 'targeted' runs, such as avalon* or whatever. I.e. a workspace that is complete, but is available for focused on-demand testing. I don't know how to allow folks to request a run w/o an account on the box, but a simple WWW page w/ a single 'project list/expression' field could post to a script that launched the test gump (but leverage the locking to only run one at once). I kinda like this idea... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Stefan Bodewig wrote: But before we try to start all over again. Who is actually willing to write code for Gump as opposed to just toss around ideas - and who really has the time to do so and isn't already overcomitted to too many things? If it turns out to be just Adam anyway, there is little to no reason to change anything. Well, Gump have sparked interest with me and Stephen, and we will probably remain 'power users' of Gump... SO... If Gumpic :o) can be designed with modularity in mind, and perhaps even incorporate some of the findings that Stephen has collected while working with Gump integration into Avalon Magic build system, I think you can expect a reasonable degree of help from both of us for a Java implementation. With Python, I won't even try... sorry... Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
