Re: Gump PMC Report 12/2006
Stefan Bodewig wrote: * Stefano has set up a Gump build running on top of Harmony[1] which currently is stuck by not finding a javac command line compatible compiler. It should be noted that the reason why Gump can't find javac is not because it's not properly installed in the path (that would be an easy fix), but because no javac existed for harmony. Instead of routing around the problem, I let it hanging there to apply a little pressure on the harmony dev team, which in fact resulted in the creation of a javac executable that is now being tested. We should expect rather speedy forward motion on that quickly. Note how that machine is at Geir's house. We would really like to move it somewhere else but vmgump is already overloaded and the gump solaris zone (or a new harmony zone) doesn't help because Harmony doesn't support solaris yet. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [gump] Gump running on Harmony!!
Stefan Bodewig wrote: On Wed, 15 Nov 2006, Leo Simons [EMAIL PROTECTED] wrote: On Nov 15, 2006, at 5:27 PM, Stefano Mazzocchi wrote: Great news everyone, I've finally managed to get Gump running with Harmony. cool. 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'? We don't even need an alias since Ant's bootstrap script and javac task will use jikes if you set an environment variable (for the bootstrap script) or an Ant property. I think we already do that for the Kaffe builds on helios. I see. I'll take a look. Stefano, you later mention ecj. Ant could probably benefit from a compiler adapter to it so you could set a property in Gump's workspace and have ant use that on all projects. The environment variable JAVAC should work for bootstrap.sh as well, as long as ecj is command line compatible to javac. Not sure what action you are suggesting me to do :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gump] Gump running on Harmony!!
Great news everyone, I've finally managed to get Gump running with Harmony. 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? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [gump] Gump running on Harmony!!
Leo Simons wrote: 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'? I'm thinking of leaving the pressure and see if anybody writes a javac wrapper around ecj ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build of mx4j in gump
Sander Temme wrote: I don't have rights on vmgump, so I can't help you there. we should fix that. thoughts anybody? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump-commits in mailing lists archives
Antoine Levy-Lambert wrote: Hi, I noticed that gump-commits is not on marc and on gmane. Would it be OK that I contact these 2 sites to ask them to archive gump-commits ? mail-archives.a.o seems currently the only web site which is archiving this list. no problem for me. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bcel failure
Antoine Levy-Lambert wrote: Stefan Bodewig wrote: What would be the correct mvn goal to invoke if we want a jatr and maybe run tests? Stefan mvn package builds the jars under target I think. mvn package runs the tests as well (by default, at least) mvn install builds the jars, runs the tests, and copies the jars to $HOME/.m2/repository/groupId/artifactId/version correct -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
socket connection problems for vmgump?
So I have my own copy of gump running on the harmony testing server (note: this gump is currently powered by Sun 1.5 running on x86_64, not harmony yet since there are issues builing in such CPU architecture) http://67.86.14.213:1/gump/ and it indicates 79.77% success while vmgump indicates 78.81% Further inspection shows that jakarta common-net is failing because a test is failing http://vmgump.apache.org/gump/public/jakarta-commons/commons-net/gump_work/build_jakarta-commons_commons-net.html [junit] Testcase: testInitial took 0.017 sec [junit] Testcase: testCompareTimes took 190.053 sec [junit] Caused an ERROR [junit] Connection timed out [junit] java.net.ConnectException: Connection timed out [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) [junit] at java.net.Socket.connect(Socket.java:507) [junit] at java.net.Socket.connect(Socket.java:457) [junit] at java.net.Socket.init(Socket.java:365) [junit] at java.net.Socket.init(Socket.java:207) [junit] at org.apache.commons.net.DefaultSocketFactory.createSocket(DefaultSocketFactory.java:67) [junit] at org.apache.commons.net.SocketClient.connect(SocketClient.java:141) [junit] at org.apache.commons.net.time.TimeTCPClientTest.testCompareTimes(TimeTCPClientTest.java:128) [junit] that test fails on vmgump but it doesn't fail on the harmony testing server. Could it be that there are some 'firewalling' issues with making non-HTTP connections out? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bcel failure
Stefan Bodewig wrote: On Fri, 10 Nov 2006, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: This requires adding in the gump metadata of projects built with ant which are maven dependees the groupId and artifactId of each jar, plus the version that maven wants. version*s* since different Maven projects might ask for different versions. What you describe would either require manually updating all descriptors or making Gump smart enough to parse Maven2 POMs. In an off-list discussion Steve mentioned an idea to me that may even be easier to implement: Create a Web Application that understands Maven's remote repository layout and point mvn to this webapp as the only available repository to use. This webapp would then map the artifact id to the corresponding Gump jar and serve up the latest artifacts from the current build. This way we only need to understand the groupId/artifactId mappings but (1) can ignore the version information completely and (2) don't give mvn a chance to pull in uncontrolled artifacts at all. how about following maven1 footsteps: we force maven2 to stay offline and then we use symlinks in the .m2 repo to point at the gump-generated jars? superhacky, but it could work and doesn't require webapp development/management -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r386930 - /gump/branches/Gump3/dynagump/
Leo Simons wrote: Note-to-self: extract some of the documentation I wrote within the dynagump tree (How gump works) was one I think and save if off somewhere findable. ops, forgot about that. Gotta love version control :-) On Sun, Mar 19, 2006 at 05:51:48AM -, [EMAIL PROTECTED] wrote: Author: stefano Date: Sat Mar 18 21:51:47 2006 New Revision: 386930 URL: http://svn.apache.org/viewcvs?rev=386930view=rev Log: killing cocoon-based dynagump (since nobody is working on it anyway) Removed: gump/branches/Gump3/dynagump/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gump3] mavenization2 of dynagump completed
I've completed the mavenization2 of dynagump and I've cleaned it up so that now we can actually build it and use it. svn co http://svn.apache.org/repos/asf/gump/branches/gump3/dynagump/ cd dynagump mvn package mvn jetty6:run then open http://127.0.0.1:8080/ and enjoy :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gump3] stuck on getting gump3 off the ground
So, here I am, trying to get Gump3 off the ground again. 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. Help? -- 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 I/O errors --max-delete=NUMdon't delete more than NUM files --partial keep partially transferred files --force force deletion of directories even if not empty --numeric-ids don't map uid/gid values by user/group name --timeout=TIME set I/O timeout in seconds -I, --ignore-times turn off mod time file size quick check --size-only ignore mod time for quick check (use size) --modify-window=NUM compare mod times with reduced accuracy -T --temp-dir=DIR create temporary files in directory DIR --compare-dest=DIR also compare destination files relative to DIR --link-dest=DIR create hardlinks to DIR for unchanged files -P equivalent to --partial --progress -z, --compress compress file data -C, --cvs-exclude auto ignore files in the same way CVS does --exclude=PATTERN exclude files matching PATTERN --exclude-from=FILE exclude patterns listed in FILE --include=PATTERN don't exclude files matching PATTERN --include-from=FILE don't exclude patterns listed in FILE --files-from=FILE read FILE for list of source-file names -0 --from0
[fyi] OpenGrok
http://www.opensolaris.org/os/project/opengrok/ wouldn't be kinda cool to have gump aggregate all the source code and tell opengrok what to do with it? would be sort of a lxr.mozilla.org for apache, clearly something we are missing. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 does last successful build
Leo Simons wrote: 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 :-) swt :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation
Leo Simons wrote: 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. As far as we currently stand, it is *OK* to *LINK* to LGPL and not to redistribute it. There is no board resolution about it yet, but it's coming (Cliff, hint hint ;-) So, I suggest that we worry about this only when are ready to ship something. Also, remember, the act of 'bundling' and 'shipping' is what constitutes problems for us (details to come in the resolution), therefore if the user gets it on their own, we are fine. The use of things like maven to build, since they fetch the jars on their own, would therefore remove all our legal concerns, yet allow us to keep the hibernate functionality. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
Upayavira wrote: Jorg Heymans wrote: Upayavira wrote: I've created an external in trunk/src/gump, which has just module.xml in it (our gump.xml). I just updated a minute ago and got Fetching external item into 'src\gump' A src\gump\module.xml Updated external to revision 289588. Fab. That means it has worked. I've removed the gump.xml file, and changed build.properties to point to the new src/gump/module.xml file. That means that now, Gump and Cocoon now share their gump descriptor. So, does that mean I can have my donut now? Nice job :-) Here is your donut (o) Juicy, eh? ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation
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 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) 6) the SQL data seems weird, but this is probably not your fault 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. 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 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 it's not (or at least, not as a standalone jar)... but I suggest we keep it out since it's GPL stuff. In any case, it looks like a very good job from where I stand. Will know more as soon as I can get it running ;-) -- Stefano, who is pleased to have been reminded on why he hated JSPs in the first place :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation
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 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) 6) the SQL data seems weird, but this is probably not your fault 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. 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 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 it's not (or at least, not as a standalone jar)... but I suggest we keep it out since it's GPL stuff. In any case, it looks like a very good job from where I stand. Will know more as soon as I can get it running ;-) Seem that Java 1.5 was indeed a bad idea. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6295519 Thomas, how much work would be to downgrade this to 1.4? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation -- choice of technology
Thomas wrote: Leo Simons wrote: 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 :-) If i go with struts it will be very simple Servelts+struts thats about it I hope to be able not use any other framwork for the database comunication but if I get a lot of protest there from you or other that works with Gump, I'll use a framwork for that to (Hybernate). 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 :-) The thing that I got stuck on with cocoon is when it gets abit more complicated, create generators and more custome stuff. I have no problems when it comes to communicating with the database take out rows, update, add, the basic stuff. The problems comes when I want to do something with the data that I get. No problems on presenting the data writing xslt's and generating pages from xml files. That part I think works porfectly and is the reason why I whan't to lear more about cocoon. But when you whant to costumize the webapp abit more like generators I'm lost. The level of knoledge you need to proceed with that is huge and the tutorials often miss parts like filenames of files that are created and wich files he is working on (editing). Small things that is so important when you are new to things like a compleat framework. Something concrete is for example you get a value from the database and you whant to multiply it with another value that you also get from the db. To me it sounds like I have missed something essential. If I have missed somthing that makes me go Haha I might go with cocoon but as it is now cocoon is taking to much time to learn for me to make some progres before the summer of code is over. Good points and I don't have the energy/time to fill that teaching gap, I'm afraid. I don't mind if you go Struts+Hibernate, but at least, keep the html templates that of the current dynagump. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Gump descriptor is now in Gump's SVN
Stefan Bodewig wrote: On Wed, 13 Jul 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Oh, crap! SVN can't externalize a file, but only a directory!!! It can't? And I already thought that feature was overhyped, oh my. what do we do now ?!? Move the cocoon descriptor into a subdirectory of metadata and do the same on the cocoon side, that's all I can come up with. When svn supports internal symlinks, that will become another option. there is another solution: virtualize the external with an ant get in the cocoon build. Why didn't I think of that before? I'll propose this on the cocoon mail list and report back once we have a solution. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Gump descriptor is now in Gump's SVN
Stefan Bodewig wrote: Hi, after we've migrated Gump's metadata over to svn as well, there shouldn't be any need to keep the Cocoon descriptor inside of the cocoon tree. I've just committed , | Added: | gump/metadata/project/cocoon.xml | - copied unchanged from r216130, cocoon/trunk/gump.xml ` and with svn:externals of gump.xml https::/svn.apache.org/repos/asf/gump/metadata/project/cocoon.xml on the cocoon directory you'd have your local copy - and all of you and all of us can change it. Starting with the next Gump run, Gump will use the copy of its own. Finally!!! I'll make that happen. Stefan++!! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Gump descriptor is now in Gump's SVN
Stefano Mazzocchi wrote: Stefan Bodewig wrote: Hi, after we've migrated Gump's metadata over to svn as well, there shouldn't be any need to keep the Cocoon descriptor inside of the cocoon tree. I've just committed , | Added: | gump/metadata/project/cocoon.xml | - copied unchanged from r216130, cocoon/trunk/gump.xml ` and with svn:externals of gump.xml https::/svn.apache.org/repos/asf/gump/metadata/project/cocoon.xml on the cocoon directory you'd have your local copy - and all of you and all of us can change it. Starting with the next Gump run, Gump will use the copy of its own. Finally!!! I'll make that happen. Stefan++!! Oh, crap! SVN can't externalize a file, but only a directory!!! what do we do now ?!? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Metadata are now in svn
Stefan Bodewig wrote: Hi all, Henri was kind enough to take care of the svn migration, metadata now live in http://svn.apache.org/repos/asf/gump/metadata/. If anybody encounters a problem with accessing this, please yell. It is supposed to provide write access for all Apache committers. I've already modified live and made sure the workspace defintion is present on vmgump - I have not changed cron/gump.py yet, but will try to do so soon. I'll also modify trunk and change the configuration on helios. After that you can start to clean up my mess ;-) henri++ and stefan++ :-) -- Stefano, dressed up like a cheerleader... give me an S, give me a T... okok, you got the idea ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump3 for bootstrapping your entire environment
Leo Simons wrote: 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. Nothing is impossible if you get obsessed enough about it (why would we be here watching gump fail every day ;-), but 'pointlessly complex' definately. Now, the biggest question of all: does gump3 implement fallback? Ah, getting impatient now, are we? :-) Working on it. you're *DA* man. -- Stefano, who plans to trick Leo's summer employer in forcing him to implement an RDF export of gump data ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime.exec Ant Gump3
Leo Simons wrote: 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. do you think it's time to throw a python task force at it? 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. -- Stefano, ego-tickle master ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump3 for bootstrapping your entire environment
Leo Simons wrote: 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 :) Boy, this is so cool is starting to hurt :-) (... not to be able to participate!) I wonder how long a 'gump world' of debian would take to run (and whether or not you can reach a 100% ;-) Now, the biggest question of all: does gump3 implement fallback? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoC update - gump3 and maven
Justin Merz wrote: Just wanted to give an update. I have Gump3 reading in maven files (though in the module descriptor, the project tag MUST contain type=maven). I then parse info with a new file mavenizer.py, which reads in the maven file and creates a new gump ready project file. This file is then read into gump instead of the maven descriptor file. I have a basic skeleton of the new gump ready file already being created (ie it has file name, dependent projects, etc) and it seems to be accepted by gump. I am using a stripped down version of the torque maven file for testing, and will move onto larger projects when I have integrated and checked all dependences from this test case. How about granting our GSoC friends commit access so that they can show us what they are doing? thoughts? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration of metadata
Adam R. B. Jack wrote: I'm halfway torn between throwing history away and simply importing CVS HEAD manually and doing a trunk-only conversion. Well, not really true, I'd probably prefer keeping the history, but could live without it. What's your preference? +1 for keep the history. The second question is, where should our metadata end up in SVN? Probably in http://svn.apache.org/repos/asf/gump/metadata/trunk - I envision metadata branches for Gump3 later, so I'd be against a flat structure like site currently has. +1 in theory, 'cos looking at our SVN tree we do seem to use /gump/X/trunk when we have a sub-project X, but see below. Since today folks (1) checkout Gump from SVN and (2) checkout metadata from CVS into ./metadata, I don't see a hardship of having two places. That said, will SVN allow us to do this w/o pain? of course, svn:external is your friend :-) Can we have an empty /repos/asf/gump/trunk/metadata become a local working directory, and then checkout /repos/asf/gump/metadata/trunk into it? I suspect not. I think we got away with it because we were using two separate SCMs. Something will have to give, I'm just not sure what, i.e. (1) no empty ./metadata w/ a FILLME.txt (2) ../metadata not ./metadata (3) not separate SVN trees. Thoughts? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration of metadata
Stefan Bodewig wrote: On Mon, 04 Jul 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: ALWAYS KEEP HISTORY! cvs2svn does that for you anyway! If you use it 8-) If you don't keep it, you'll regret it, believe me. Working on time series data mining is part of my day job! Simply adding a CVS export to svn could do, it is an option, even if you don't like it. No, that stinks. All my history datamining tools are based on SVN log. I volunteer to do the processing, if that's your problem. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynagumper is alive!
Leo Simons wrote: Hi gang, so I figured we'd need to get Thomas some more data. Rather than invent it by hand, I figured I'd fix up the dynagumper plugin to work properly. See https://svn.apache.org/repos/asf/gump/branches/Gump3/pygump/python/gump/plugins/dynagumper.py I'm not proud of the code at all (its got some ugly shortcuts I took cuz I wanted the thing working), but I'm very happy with how little there is. Its probably also readable enough and easy enough to modify. That's a Good Thing(tm) since it shows the architectural work is paying off :-) 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 :-). We probably want a --do-database switch so its possible to run gump3 without mysql available. 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? Awesome! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation -- choice of technology
Thomas wrote: Stefano Some questions for you about cocoon. Sure. I have just poked around abit but what I find mostly is look at the examples. That is a good way to learn if you know some basic stuff. Yep, agreed. How dose the structure of the application looklike where to put files and folders ?? well, first of all, cocoon is, if you wish, a huge servlet. So, it looks like just any other j2ee webapp with a servlet container around. dynagump is prepackaged with jetty running a cocoon webapp, but it's really two things (and one could think about running dynagump in tomcat, if one wishes to do so) I like jetty better because it's smaller and easier to configure/embed and starts/stops faster. The cocoon specificities are mostly: 1) webapp/sitemap.xmap is where the pipelines are defined and where the URL - pipeline processing takes place (NOTE: sitemaps can nest other sitemaps, so their location could vary and you can have multiple of them) 2) webapp/WEB-INF/cocoon.xconf is where the cocoon configurations remain. You should not have to do anything there. Remeber that I'm comming from J2EE where every config file and folder has it's place I'm guessing it's the same here. What config files do I need to know about and what is ehcache-2. The ehcache-2 is never alive and all I get is an Error saying so. Thats my first error in geting dynagump to work. ehcache is the caching engine. cocoon is pretty agressive on caching. you might want to tweak the cocoon.xconf settings on caching if that still causes you troubles. One step at the time I'm on my way. Awesome. Note: dynagump is not the latest and greatest cocoon, so maybe there could be bugs that are already fixed. If you sound some others let me know. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration of metadata
Stefan Bodewig wrote: Hi, it looks as if most of us were leaning towards migrating to SVN now. We now need to decide on the details. I'm halfway torn between throwing history away and simply importing CVS HEAD manually and doing a trunk-only conversion. Well, not really true, I'd probably prefer keeping the history, but could live without it. What's your preference? ALWAYS KEEP HISTORY! cvs2svn does that for you anyway! The second question is, where should our metadata end up in SVN? Probably in http://svn.apache.org/repos/asf/gump/metadata/trunk - I envision metadata branches for Gump3 later, so I'd be against a flat structure like site currently has. svn mv is your friend anyway ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FYI] generating python modules dependency graphs
http://www.tarind.com/depgraph.html might be helpful :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 Presentation -- choice of technology
[your clock is screwed ;-)] Thomas wrote: Some input from me about what I think of what technoligy to use. This is just my opinion and of corse I'm willing to learn something new if thats what you think would work the best. I think what works best for you works best for us. On Jun 30, 2005, at 7:24 PM, Adam R. B. Jack wrote: To my knowledge here are the best known candiates (plus some others I've heard discussed.) - Java JSP/Struts. Java and JSP + Struts I know well... the easy way to get a result. Java is my main programming language and I personaly think I know it well regarding webapplication in Java, J2EE and struts. Cool. - Cocoon (Stefano has spent significant time on this, he feels it is worth evaluating.) Cocoon: I have never used it but sounds like I can get som help from Stefano. So that might work for me to. Great. - mod_python (Leo has spent some time on this, he feels it is worth evaluating.) mod_python: I have never used python, so that sound like a challange but challanges is just a good thing... It all depends on what I need to have finished at the end of summer of code. Learning python is easy (especially if you know java) but you don't have to. Gump3 is architected in a way so that different modules can be built with different languages, the idea was to capture more people that way. But I suggest you start reading the excellent dive into python (http://diveintopython.org/) just to get a sense of what it is. - PHP (why not?) PHP: I have done som work with PHP. But I rather prefer some type of Java or none script language before PHP. Nice to hear that ;-) To toss another idea out there... I highly recommend Ruby on Rails - it's elegant, clean, and ties to a DB easily. Erik Ruby on Rails: never used it never even programed in Ruby. But the same gose here as for mod_python. I heard good things on RoR, but nobody here knows Ruby and we are trying to increase the community size not decrease it ;-) To summarize this. I prefer a java based language and framework. The advantage of using mod_python is that alot of other thing in gump and around gump is written in python. I don't have anything against lerning something new but the result will take abit longer and would not be as good implemented as if had been Javabased. I don't know what and how much I need to do compleat the summer of code project. My intention and hope is that I can keep on working on this and be a part of the Gump project even after the summer of code. We would hope that to be the case too. So, make yourself at home, follow Leo's excellent directions and let us know how you feel when you get there. For the moment I'm setting Gump and I'm trying to get it to work. I'm also trying to get an over view of the database and what all the tables is. Great. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New dynagump component in Jira
Leo Simons wrote: Thomas, Stefano, I added a new dynagump component in jira: http://issues.apache.org/jira/browse/GUMP which has just a few of the boring things I jotted down a while back that would be really nice to get done. Might be nice for getting some feet wet ;-) I saw that, awesome! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
GSoC Gump-related project breakdown
Where is it? I would like to know who is working on what, who is the mentor and what their plans are. Can we work on that please? NOTE: I'm not a mentor and therefore I don't have access to the GSoC webapp. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump presentation SoC
Adam R. B. Jack wrote: BTW: (all) I've also mentioned that Cocoon was likely not our favoured approach, since we don't have cycles to help you with it. There was a working cocoon implementation of Dynagump, I don't know the status for that. I *am* interested in helping that succeed, rather than seeing a new refactored version of a presentation framework for gump in python. Cocoon might be a little steep learning curve, but I've done a lot already, it just needs a bunch of SQL queries against the data that gump generated (since gump3 was not generating any data at that time). -- Stefano, beating himself in the head for this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GSoC Gump-related project breakdown
Adam R. B. Jack wrote: Stefano, I would like to know who is working on what, who is the mentor and what their plans are. When I sent the list of the two to the Gump PMC list, I failed to recall that the URLs were protected. You e-mail is a timely reminder to 'speak' to those who got accepted, and those who did not. Apache recieved over 700 applicants for eventually 38 projects (a number we did not know until a day before deadline day) so unfortunately there were was a lot of disappointment, for ASFers included. To those of you who applied for a Gump project, but failed to be accepted, please accept our thanks for your interest our shared disappointment in not being able to proceed. The reasons for acceptance/rejection were many, and varied, although one prime motivator was how 'interesting' the project was to the ASF community as a whole, not individual projects/mentors, etc. As such, if your project was not accepted, please don't read too much into it. With OSS one needs one's own sense of purpose and some thick skin. Please utilize it now. The two accepted for Gump (see [1]) are: Project: gump-and-maven Title Make gump 3 bootstrap and integrate maven and maven 2 Mentor: Scott Sanders Participant: Justin Merz Project: gump-presentation Title Provide a web interface to the gump 3 database Mentor: Adam Jack Participant: Thomas Hedin For both, plans are still developing... No applications were accepted for: Project: gump-doap Title Make gump 3 integrate Description of a Project (DOAP) Mentor: Adam Jack regards, Adam Adam, thank you, this is very helpful. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spikesource, Gump3 Presentation
Simon Kitching wrote: Hi, The thread about Gump3 presentation made me think about spikesource (www.spikesource.com) Spikesource are a new commercial company. One of the things they do is have a gump-like setup that makes daily builds of a range of open-source projects. I know because they recently emailed commons-dev asking why commons-logging was failing to build for them. They have a web interface to the current build state here: http://spikesource.com/spikewatch/ Just thought people might be interested... To me, it looks pretty laughable compared to gump... what am I missing? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SoC Update
Justin wrote: Group I set up Gump3 in Cygwin (took a little bit). Also got java1.4, python2.4, and MySQL4.1 set up in my new enviroment. Adam, I read all the instructions/pages you sent me. Thanks they were a big help. I have located the normailzer.py function which appears to have part of the maven implementation code in it. I have started to dissect it. I sent off my CLA this morning. I set up a wiki page for th project http://wiki.apache.org/gump/GumpAndMaven You already rock :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrating meta-data to svn
Stefan Bodewig wrote: Hi all, after the last minotaur update we've (temporarily?) lost commit access to the gump CVS module. Are we ready to make the transition to svn yet? About half the projects have migrated and most committers should be able to use it by now. +1 -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Google SoC
Justin wrote: Hi I was just accepted by the google's summer of code to work on the gump-maven project. I was wondering which version of gump (ie 1, 2, 3) I should be using and where i acquire that code. Justin, welcome! It's a pleasure to have you on board. Gump 1 is pretty much deprecated, so don't consider that. Gump 2 is our current 'production' branch, even if production is a big word for gump ;-) I would suggest you to start from Gump 3, which is a little cleaner and less complex and has a more modular architecture. What do others think? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH][Gump] your definitions break Gump builds
Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Hmm, so why don't you realize that you have a typo in it for many days? Like when you rename a jar but forget to update the descriptor? because cocoon doesn't use *all* of that data, only parts. Truth be told, cocoon could have two files, one for gump and one for its own build system, but they would contain the same information. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH][Gump] your definitions break Gump builds
Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Hmm, so why don't you realize that you have a typo in it for many days? Like when you rename a jar but forget to update the descriptor? because cocoon doesn't use *all* of that data, only parts. Unfortunately Gump gets into trouble because of the parts Cocoon doesn't use. I know. If you don't use any of the projects you define for jars in your repo, maybe you better shouldn't define those projects at all? Instead nag the Gump crew to turn them into installed packages. I personally wouldn't be against such a thing. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? Sylvain can, or I could, but I'd certainly prefer if the Coccon PMC made the change. ok, I'll start a vote. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH][Gump] your definitions break Gump builds
Stefan Bodewig wrote: On Thu, 16 Jun 2005, Upayavira [EMAIL PROTECTED] wrote: I've committed this patch to Cocoon trunk. Many thanks. I presume that is the correct place. Until the Cocoon project is annoyed enough by our patches and moves the descriptor over to Gump land, I think it is. 8-) Stefan, it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move public onto JDK 1.5? (was Re: Brutus going down)
Adam R. B. Jack wrote: Leo wrote: It is likely that there won't be any e-mail sent out by gump for a few days. It is likely that the non-standard workspaces (kaffe, testing and jdk15) will be offline for quite a while. Does it make sense to move public (with nagging) to JDK 1.5? -1, macosx still doesn't have 1.5 stable. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brutus going down
Adam R. B. Jack wrote: Brutus will be going down somewhere today or tomorrow. It will be wiped to start hosting Apache's SVN install. For somebody trying to play catch-up, where are the alternative places to run a Gump instance? I'd like to be able tinker with a Gump3 on some *nix type platform, and I could perhaps help a little w/ any Gump2 re-installs. Thanks in advance for any pointers to wiki pages (and/or ways I can find where/how I need to log in.) Also, a random observation. It is interesting that we aren't wanting to save the database of 'historical information' that we've accumulated (in MySQL, or DBM). Sure, few really know it is there (given we don't have a presentation interface into it) but I also wonder at it's value. Is historical information really important to Gump's contributions, or is it more in the here an now? That, or if it isn't in a form that aggregators/index engines can consume, it doesn't fit today's world. I wonder if there is something in either of these. DON'T KILL THE LOGS! please, please, please, let's keep the logs!!! there is a goldmine of information there that is waiting to be explored! Adam, can you give us (or leo) pointers to where is all the data that gump saves so that we can restore it on the new installation? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brutus going down
Leo Simons wrote: Adam wrote: Stefano wrote: DON'T KILL THE LOGS! Hehehe. I already had mysql backed up locally. Would that they'd be logs. We never had space (or haven't optimized sufficiently) to keep the build logs. Gump's (internal) logs aren't worth a lot, but exist, if wanted. I really doubt we'll be able to salvage much from those. And they take up a few 100 megs. I will dump those out myself. I just bought a 250Gb firewire drive :-) (and my group is buying a new box that has 1Tb of stuff in it, disk space is not our problem any more ;-) I hope we give good consideration to 'Net history (and access for external services, e.g. google) with Gump3. Aye. Adam, can you give us (or leo) pointers to where is all the data that gump saves so that we can restore it on the new installation? Basically there is the MySQL database, and a DBM file (at /usr/local/gump/public/gump/work/stats.db). These contain what history we have. [Same DBM exists for Kaffe, JDK1.5, etc.] Got all of those. 1000kb, gzipped. that's it? BTW: Are we saving the crontab and any scripts in ~gump, Leo? Could be valuable. Where ought we put these to be moved, into Gump SVN? yes. Also see http://wiki.apache.org/gump/VmgumpConfig BTW: I hope '/usr/local/gump/packages' is being moved across. yep, those are on vmgump as well. cool. That'd remove a huge chunk of the pain of a fresh install. Really, it'd be good to go through that pain. There is *so* *much* cruft in the packages dir. We've only added there (for many years), never pruned. No-one can really mirror our install and get a similar tree without that cruft. very true, but it's going to be painful to replicate. you volunteering? ;-) Also, if we kept '/usr/local/gump/staging' (along w/ timestamps) then Gump might continue to accurately records how long since a code update (on more stale projects.) Uh. Gump's been running on vmgump for a while. It'd mean throwing /that/ info away. ... We shouldn't be /too/ fussed about being librarians. Or, alternatively, scratch your itch. I will. Did I mention I work for the libraries :-) There's a full backup from second-half-of-march of all drives sitting on the firewire drive attached to brutus. ah I hope to give that stuff a permanent home when we get the 1TB drive storage hooked up to helios. kewl. Combined with the databases, I think that's enough. I'll do another round of saving myself, but yes, that reassures me. From a sysadmin POV, gump consumes too much disk space to be snapshotted in full, and its hard (see above) to figure out what bits do need to be saved, and near-impossible to do something with those bits. That needs to be neatly split out. If you (no-one in particular) wish perfect conservation of output, fix things so its easy to administer them that way. I.e. /usr/local/gump/save-this-every-day /usr/local/gump/save-this-once-a-month /usr/local/gump/this-is-in-svn /usr/local/gump/this-is-just-cache-lose-it-if-needed Yes, this is called for. Gump will be of incredible historical value in the future, but things get saved only when they are well behaving and now gump was not designed with digital preservation of its findings in mind... but given the cost of storage, I think we should rethink that. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump run queue
Stefan Bodewig wrote: On Tue, 26 Apr 2005, Leo Simons [EMAIL PROTECTED] wrote: This just popped into my head. Naïve line-based schedule file using simple commands together with cron could be real nice. +1 +1 Although we may find that we need overlapping Gump runs at times. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump3 design idea: workspace/ considered harmful
Stefan Bodewig wrote:
On Mon, 25 Apr 2005, Leo Simons [EMAIL PROTECTED] wrote:
In the next version of our in development xml model and in the
development of gump3, configuration information is left out and
instead provided on the commandline or using environment
variables.
+1 to separating environment configuration from the
Module/Project/Repository/Whatever stuff making up a Gump definition.
It may too much for env vars, though. I.e. we may end up having too
many environment variables or command line options.
Looking into my old workspace defintion I'd have basedir, pkgdir and
maybe a dir for checked out sources (if I want something other than
{basedir}/cvs). Then there is logdir.
There may be a dir for jars, javdocs or junitreports, if I want to
publish them. Nagging needs a mailserver and a sender address. The
database wants to get configured, I guess I could have a location
independent of logdir for RSS feeds. The current threads
configuration should be part of the environmental setting as well.
IMHO we still better maintain these settings in a file. Doesn't have
to be an XML file and should be separate from project definitions.
+1
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-109) verify gump3 digital algorithm
[ http://issues.apache.org/jira/browse/GUMP-109?page=comments#action_63349 ] Stefano Mazzocchi commented on GUMP-109: I sent my comments to Leo. Honestly, I don't think that that visual algebra is going to help people understand how the algorithm works, but it's really complex stuff (way more complex than it first appears). I think it would be ideal to come up with some pseudocode but both Leo and I tried and failed to come up with something that doesn't end up being code itself. Maybe it's just easier to sit down and code it ;-) verify gump3 digital algorithm -- Key: GUMP-109 URL: http://issues.apache.org/jira/browse/GUMP-109 Project: Gump Type: Sub-task Components: Documentation Versions: Gump3-alpha-4 Reporter: Leo Simons Assignee: Stefano Mazzocchi Fix For: Gump3-alpha-4 -- 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] Work started: (GUMP-109) verify gump3 digital algorithm
[ http://issues.apache.org/jira/browse/GUMP-109?page=all ] Work on GUMP-109 started by Stefano Mazzocchi verify gump3 digital algorithm -- Key: GUMP-109 URL: http://issues.apache.org/jira/browse/GUMP-109 Project: Gump Type: Sub-task Components: Documentation Versions: Gump3-alpha-4 Reporter: Leo Simons Assignee: Stefano Mazzocchi Fix For: Gump3-alpha-4 -- 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] Work stopped: (GUMP-109) verify gump3 digital algorithm
[ http://issues.apache.org/jira/browse/GUMP-109?page=all ] Work on GUMP-109 stopped by Stefano Mazzocchi verify gump3 digital algorithm -- Key: GUMP-109 URL: http://issues.apache.org/jira/browse/GUMP-109 Project: Gump Type: Sub-task Components: Documentation Versions: Gump3-alpha-4 Reporter: Leo Simons Assignee: Stefano Mazzocchi Fix For: Gump3-alpha-4 -- 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: Gump's History By E-mail up to April 2004
Leo Simons wrote: Hi gang! Python gump is now a little over two years old! Congratulations everyone :-D Oh, and, FWIW, I would say that gump in one form or another is now about 4 years, 3 months old. Older than I thought actually...just some highlights from the past few years (gotta love mail archives): 21 Sep 2000: Apache tinderbox idea is born http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/29.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 18 Jan 2001: Sam writes tinderbox prototype code http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200101.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 26 Jan 2001: Gump moves to jakarta http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200101.mbox/[EMAIL PROTECTED] 18 Feb 2001: Scott ports gump to ant (uses python!) http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200102.mbox/[EMAIL PROTECTED] 04 Apr 2001: Alexandria (including gump) presented at ApacheCon 2001 http://apachecon.com/2001/US/html/sessions.html 09 Apr 2001: Gump development starts picking up after ApacheCon... http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200104.mbox/[EMAIL PROTECTED] 08 May 2002: Gump builds maven http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200205.mbox/[EMAIL PROTECTED] 13 Jul 2002: First attempt at historical result tracking http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200207.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 12 Nov 2002: Gump repository is opened up to all of apache http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200211.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 01 Jan 2003: jakarta-gump is set up (from alexandria remnants) http://mail-archives.apache.org/mod_mbox/gump-general/200301.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 13 Apr 2003: Sam rewrites gump basics in python http://mail-archives.apache.org/mod_mbox/gump-general/200304.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 23 Aug 2003: Adam get's sucked into gump development http://mail-archives.apache.org/mod_mbox/gump-general/200308.mbox/[EMAIL PROTECTED] 11 Sep 2003: Gumpy is set up on lsd http://mail-archives.apache.org/mod_mbox/gump-general/200309.mbox/[EMAIL PROTECTED] 09 Oct 2003: Java gump starts dying along with Sam's machine http://mail-archives.apache.org/mod_mbox/gump-general/200310.mbox/[EMAIL PROTECTED] 26 Nov 2003: Gump gets subversion support http://mail-archives.apache.org/mod_mbox/gump-general/200311.mbox/[EMAIL PROTECTED] 01 Dec 2003: Actual start of support for maven http://mail-archives.apache.org/mod_mbox/gump-general/200312.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 19 Feb 2004: Gump announced as top level project http://mail-archives.apache.org/mod_mbox/gump-general/200402.mbox/[EMAIL PROTECTED] !!!BIG EVENT!!! 03 Mar 2004: Stefan starts committing to Python Gump, others follow suit http://mail-archives.apache.org/mod_mbox/gump-general/200403.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/gump-general/200403.mbox/[EMAIL PROTECTED] 08 Mar 2004: Stefano starts his RT series http://mail-archives.apache.org/mod_mbox/gump-general/200403.mbox/[EMAIL PROTECTED] 18 Mar 2004: Much improvement to State of the Gump tree http://mail-archives.apache.org/mod_mbox/gump-general/200403.mbox/[EMAIL PROTECTED] 25 Mar 2004: Gump gets its dedicated ASF box, brutus http://mail-archives.apache.org/mod_mbox/gump-general/200403.mbox/[EMAIL PROTECTED] 25 Mar 2004: Leo starts his RT series http://mail-archives.apache.org/mod_mbox/gump-general/200403.mbox/[EMAIL PROTECTED] 21 Apr 2004: First appearance of intelligent algorithm ideas http://mail-archives.apache.org/mod_mbox/gump-general/200404.mbox/[EMAIL PROTECTED] Maybe I'm going to do last year (april 2004 -- april 2005) tomorrow if there's interest. Is there? YES! the historians will love you for that ;-) Btw, this makes a pretty kickass web page (or wiki page) as well! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RDF
Leo Simons wrote:
On 17-04-2005 00:53, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Example, if you have the Module object and the Project object, you have
to decide which way the link goes and the notion of Module.projects
means, this is the list of projects this module contains.
Problem is that this implicit modeling forces you to say decide the
direction of the link, and, in case you want both, you have to model
this explicitly and at update, you need to know where to change.
In RDF, you don't have to do all that.
Exactly! If you want a bi-directional link you have to model it explicitly
and it is always very evident when using it, ie
project.module.repository.workspace.name
Just yells You're handling a project and accessing something related to the
workspace. Why is that right at ya.
Yep.
One thing that got Gump2 into problem was that things were relatively
tightly coupled to another. Having manual modelling means that its easy to
spot that coupling (just delete all links from repository-workspace, run
your project-related code, boom, it blows up).
As with databases, I (model designer) have to work real hard so the plugin
programmer has an easier time. Interestingly...
I find it somewhat ironic that you now code in a dynamically typed
language (and, AFAIK, with good feelings about it) and you advocate that
static typing of your data (object or SQL doesn't really matter) is
better for you.
I hadn't realised that this clearly just yet. I've been conciously making a
lot of things statically typed to keep it understandable. Now...
snip/
failed_builds = model.get(?x is_a Build where ?x status 'failed')
Is indeed quite understandable. At least I had no problem understanding that
when I first saw it.
Glad to hear that. I find it quite understandable myself, but only when
you remove all the complexity that is introduced by the fact that all
those things need to be globally unique URIs. Luckily some APIs came to
the rescue.
Sure, the argument that objects are better than dealing with JDBC
resultsets by hand stands, but making this a general rule could be turn
out to be a mistake.
Do you know of an open-source reasonably sized RDF-model-based application
that follows the approach you're describing? I'd like to see how it turns
out! I was looking at Haystack the other day but uhm, it suffers from all of
those research project flaws.
eheh, well, we are building one as we speak, but can't tell you more :-)
Let me just say that we have been dealing with as many as 30 million
statements and as long as your queries are reasonable (say you don't
iterate over all of the nodes!), the performance is reasonable as well.
Haystack tried to do too much (they are modelling their entire system,
including the UI, with RDF statements... which means that its pretty
much painful to do anything).
Same comment again
I find it somewhat ironic that you now code in a dynamically typed
language (and, AFAIK, with good feelings about it) and you advocate that
static typing of your data (object or SQL doesn't really matter) is
better for you.
You know, I still have mixed feelings about a lot of that. I have read so
much python code recently that is hard to understand because its really
dynamic, often for no good reason. And I've also see a lot of python code
look really bad because developers want to add security in there that can't
truly be enforced (ie Zope). And a whole lot of python code that is horribly
structured simply because you can do a lot of glueing so easily.
On a code level scale, working with python can be real fun once you get the
hang of it, but every time I write something like
for command in [command for command in commands \
if isinstance(command,Script)]:
handle_script(command)
(which is kinda pythonic)
I do wonder whether
it = commands.iterator();
while(it.hasNext()) {
command = it.next();
if(command instanceof Script)
handleScript(command);
}
Doesn't make more sense if there's other developers that have to understand
the code.
True enough.
All I can tell is that semi-structures deal with the entropy of things a
lot better than forcing structure on top of them: refactoring data in
a triple store could be as easy as writing a few other owl:sameAs
statements between node types and running an inferencing engine on it
(maybe for a few hours or a day... *while* the system is still running).
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] module, project, target = repository, module, project...
Leo Simons wrote: Oh, ehm, I was even briefly tempted to turn our model into RDF but there ain't that many good tools for RDF editing :-D The more I think about it, the more I think that having our data in RDF would be a tremendous win, also in terms of programming. There are python triple stores that are just fine and would allow you to load all the data in RDF, then *query* it for the stuff you need. No object model work, just look for the statements you want (example: give me all the projects in this repository, or give me all the project that depend on this other project). How do we get there? Well, I would suggest to RDFize our XML data by writing a few XSLT stylesheets and run them on them. So, instead of having people to write (and learn!) RDF, you can just have them write their XML data as they did in the past. That gets you started without having to convince people ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RDF
Leo Simons wrote: On 16-04-2005 18:30, Stefano Mazzocchi [EMAIL PROTECTED] wrote: The more I think about it, the more I think that having our data in RDF would be a tremendous win, also in terms of programming. Show me! Nice try ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RDF
Leo Simons wrote: [snip] So, ehm, no, I don't actually think it'll be a tremendous win. It'll bring some huge benefits, but it'll incur a big cost as well. Simplicity loss. Or maybe not. I'm not exactly an expert here. We do have one of those around I think. Hence: Show me! The way you deal with statements is a little different than the way you deal with objects. Objects have explicit semantics, as much as statements, but their relationships are not typed. Example, if you have the Module object and the Project object, you have to decide which way the link goes and the notion of Module.projects means, this is the list of projects this module contains. Problem is that this implicit modeling forces you to say decide the direction of the link, and, in case you want both, you have to model this explicitly and at update, you need to know where to change. In RDF, you don't have to do all that. If you have a bunch of statements ModuleA -(is_a)- Module ProjectA -(is_a)- Project ModuleA -(contains)- ProjectA ProjectA -(has_name)- Cocoon@en^string Build-20050415-343 -(is_a)- Build Build-20050415-343 -(built)- ProjectA Build-20050415-343 -(status)- failed@en^string Build-20050415-343 -(depends)- Build-20050415-234 ... and so on. It's basically a log of the things you come to know about stuff and this becomes your knowledge base. No structure, you don't need it, you just need to be careful about how you model things and this becomes natural and grows with you. No need to define the objects nor the schema before you know how complex your data is. Very incremental, very XP, fits nicely both in the lazyness mode and in the separation between data production and data consumption that we want to enforce in Gump3. Now, what about the data consumption side? Well, the data is in the triple store, so you need to query it. There are many different ways to do this, but two main categories: 1) via an API 2) via a query language depending on the triple store you use, you get a different API and/or query language. The API feels more natural, but can be less optimized by the triple store. For example (pseudocode) Get all modules: modules = getSubjects(is_a,Module); Get all builds that failed: builds = model.getSubjects(is_a,Build); foreach (build in builds): status = model.getObjects(build,status) if (status == failed): failed_builds.add(build) you get the idea. But you could also so something like failed_builds = model.get(?x is_a Build where ?x status 'failed') which is not that hard to get. Objects are just syntax sugar around SQL statements: you have to model your data first, then add it in. In RDF is the other way around, you pile up your data and the database follows you. Sure, the argument that objects are better than dealing with JDBC resultsets by hand stands, but making this a general rule could be turn out to be a mistake. The vision of RDF is data first, metadata later. The vision of relational databases is metadata first, data later. And the funny thing is that there is nothing in the relational model that suggests you that (in fact, RDF is nothing but an explicit relational model with globally unique identifiers) but the idea of building a database by creating a schema was driven by the vision that statical typing is good for you even if it locks you in (certanly is good for the query indexers, and performance is clearly not the best feature of a triple store nowadays) I find it somewhat ironic that you now code in a dynamically typed language (and, AFAIK, with good feelings about it) and you advocate that static typing of your data (object or SQL doesn't really matter) is better for you. I think RDF offers a better model, especially for something integrating data and metadata from different independent domains like Gump. But of course, I'm biased. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Moving to python 2.4 for Gump3
Leo Simons wrote: Hi gang, I propose we start requiring Python 2.4 for Gump3. Motivation: 1) the subprocess module described in PEP 324 finally properly solves running processes within python using a decent interface. It's new in python 2.4. Needless to say, we run a lot of subprocesses! 2) decorators. Similar to java attributes. See PEP 318. There's a bunch of stuff I've been thinking about regarding conditional execution of plugins that would be real easy to set up cleanly using attributes: class MyBuildResultsProcessorPlugin(AbstractPlugin): @skip_if_build_failed def visit_project(project): pass class MyBuildResultsRecoveryPlugin(AbstractPlugin): @only_if_build_failed def visit_project(project): pass And there's of course a bunch of other stuff as well, but its less important to us. Packages are available under ubuntu (hoary), debian (sarge), fedora (4-devel), DarwinPorts, and of course there's a bunch of other kinds of distributions to be gotten from the python.org site. Any objections? No, go for it. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Why gump really does need a usable plugin architecture
Leo Simons wrote: Hi gang, I have known this for a long time, its the main reason I spent so much time learning about platforms and frameworks, but now I found Jason Carreira has explained it well: http://www.manageability.org/blog/stuff/the-architecture-of-participation Gump is about more communication between developers. Most open source developers sure as hell won't feel like communicating if they have no influence over the communication medium. We need to provide freedom to tinker. Don't like the reports that gump sends your way? Write a different plugin that does exactly what you want. It's easy to do and easy to test. Sure, that's one side. The other side is called balkanization: when everybody wonders off and forgets about the rest of the ecosystem. In media stat virtus. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump at ApacheCon Europe?
Dalibor Topic wrote: Adam R. B. Jack ajack at apache.org writes: Questions, comments, suggestions? Gump hacking (by most) at such a macro and community level. I'd love to see content simply on the people and endeavours that have been brought together by it's processing on various platforms (JDK1.5, Kaffe, etc.) Yeah, I was thinking about submitting a 'how I learned to stop worrying and love the gump' great title :-) thingie describing the experiences I had with the gump/kaffe collaboration and spreading praise on the gump team and the ASF in general :) great talk by leo at fosdem btw. i believe green banned it all on video, and puts it online somewhere. URL? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump at ApacheCon Europe?
Dalibor Topic wrote: Stefano Mazzocchi stefano at apache.org writes: Dalibor Topic wrote: Yeah, I was thinking about submitting a 'how I learned to stop worrying and love the gump' great title heh :) great talk by leo at fosdem btw. i believe green banned it all on video, and puts it online somewhere. URL? None so far. According to green's blog from http://www.spindazzle.org/green/index.php?p=39 it's not going to be oscar-worthy, though, thanks to RyanAir losing his luggage. damn -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump @ Fosdem, Saturday 26 february
Leo Simons wrote: Hi Everyone! This Saturday, during The Free and Open Source Developers European Meeting (FOSDEM), I'll be giving a short (approx 40 minutes) presentation that will mainly be about gump, as part of the Building Bridges track that's occurring Saturday afternoon at the Classpath Hacker Room. The entire building bridges track is hopefully going to be very interesting. Various developers from different free and open source developer communities are getting together to talk about reaching out to each other for mutual benefit, fun, etc. I'm very exited about the possibilities of cooperation, and I'm definitely not the only one! Besides the building bridges afternoon there will of course be lots of actual bridge building during events such as pre-dinner drinks, dinner, and after-dinner drinks. FOSDEM is free for everyone with no registration required, so if you happen to be in the neighbourhood, do make sure to pop by. For more information, please see: http://www.fosdem.org/2005/index/dev_room_classpath And in general http://www.fosdem.org/ I'm not sure if there's wireless, but if there is, I expect there'll be all sorts of fun-to-watch traffic in IRC channels such as #classpath, which might be interesting to peek at if you're unable to attend. Slides will go up online somewhere as well, no doubt. Hope to see you at fosdem! Have fun! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resolving a brutus specific issue
Brett Porter wrote: http://brutus.apache.org/gump/public/apseda/apseda/gump_file/TEST-org.apache.apseda.examples.DiscardProtocolProviderTest.txt.html Is it possible that I can get access to brutus to investigate this further? It seems to be some sort of firewall related issue - I'd like to tweak the test case until it works. It's looking for available ports and talking to localhost, so there shouldn't be any problem... If not, has someone with access got some cycles to spare? I'm on it. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: /home on brutus is full
Stefan Bodewig wrote: On Wed, 26 Jan 2005, Stefan Bodewig [EMAIL PROTECTED] wrote: I'll go through the list of modules sometime later today and purge unneeded stuff from our workspaces Just finished. We had some now obsolete copies of cocoon-2.1, cocoon-lenya and some other modules that have been filled with jars. Purging them freed almost 3 GByte in the public workspace alone. /home is down to 70% usage now, but we should wait until we had a half-way sucessful public Gump run to have real numbers. Right now all build artifacts have been synced away and not re-created. /usr which holds the test and jdk15 workspaces gained a bit more than 2 GByte. Great job! Another way to do it is to blast those directories entirely and have gump repopulate them from the start, it should be able to do it. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: /home on brutus is full
Stefan Bodewig wrote: On Wed, 26 Jan 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Another way to do it is to blast those directories entirely and have gump repopulate them from the start, it should be able to do it. Yes, I know. But given the incredible speed of sourceforge's CVS right now I was willing to do some manual work instead. Makese sense. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: /home on brutus is full
Stefan Bodewig wrote: On Tue, 25 Jan 2005, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 25 Jan 2005, David Crossley [EMAIL PROTECTED] wrote: Not sure what caused the sudden fill-up, but it is not me. It seems as if the kaffe and public Gump workspaces lived on /home - maybe one of them is generating a lot of logs ATM, I'll look into it. I couldn't find anything unusual. kaffe and public together take almost the same amount of space as test and jdk1.5, so the disk space cosumption we see is pretty much expected. I managed to squeeze about one GByte out of home by moving the installed packages and the jars generated by the public Gump instance over to /usr. /home still is 90% full, though. A quick du -Hx on /home told me that we are spending almost all disk space in /gump (~22G) where the only directories holding more than one GByte are 4.3G./gump/workspaces2/kaffe/workspace/cvs 7.3G./gump/workspaces2/kaffe/workspace 6.2G./gump/workspaces2/public/workspace/cvs 12G ./gump/workspaces2/public/workspace so the two workspaces (checked out sources plus working copies for builds) simply eat about 20G. I don't know whether we stand any chance of getting more disk space into brutus. Apart from that, the only stuff we could share are the checked out sources. And this only if we can ensure that no two CVS updates/SVN updates on the same tree run in parallel, or an update in parallel with a sync operation. have you cleaned up the 'jars' directory? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3 questions
Adam Jack wrote: Ok, I'm hooked. awesome :-) 4) (BTW: For DynaGump) was phpmyadmin removed, or moved, from Brutus? [I can go look, just wondering if somebody did something intentional.] Hmmm, not me. Alternative, might we open up SQL access on Brutus' firewall so we can use Control Center? [I believe I recall Stefano saying he trusted it's security sufficiently.] I would follow Leo's suggestion of using an SSH tunnel for now. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaGump (was Re: The Gump3 branch)
Boy, this really came across wrong. First of all (and not for the first time, but probably not for the last either.. unfortunately) allow me to apologize: I *really* would love to just have time to spend on this, showing how gump could potentially be the killer app of the semantic web... but no, I'm supposed to deliver other things... :-( Anyway, this is not an excuse to be rude and disrespectful and I'm sorry for that. Adam R. B. Jack wrote: The goal now is to allow Gump3 to perform builds and put its data into the database so that dynagump can start publishing it. Everything else is secondary. I agree, but I think Gump3 is a good idea and I'd like to see it for the long run. The *right*/focused plan for now is to accept that Gump3 is months (and a lot of work) off (I know from experience) and that the shortest path to DynaGump is not Gump3. Work with me to finish the DynaGump actor for Gump2 that I wrote for you, and let's get it up and running. Let's start exercising/integrating DynaGump now, not wait for a core re-write.\ Good point: SoC also enforces polymorphism. The best thing that happened to Gump2 is that folks were running Gump1 in parrelel. Countless bugs were detected/resolved by being able to run side by side and compare. The best things we can do for Gump3 is allow Gump2 to talk to DynaGump in parrellel. Very good point as well. If we create a workspace on Brutus called DynaGump and configure it to a DB with both old and new DB schemas in it, we can have DynaGump up a running in no time. Nothing (IMHO) better than running DynaGump against DBs formed by old and new Gump (2 3) and also comparing it to the HTML results generated by Gump2. Let's allow Gump3 to be team formed by giving it time, whilst we make one incremental improvement and allow DynaGump to be born. Can we agree on this as a step in the plan? +1 But I also hope that we'll work as a team this time. Stefano, you make me smile. :-) You are so strong in your opinions (at least how they read to others) that you come perilously close to stymieing the community you love. Yeah, well, (looking down) I know. I gave up on Depot, leaving behind parts I love/long to see, mainly 'cos it was becoming a one man band. Gump, however, is thriving community, and even when I was the only Python coder we had vast community efforts in metadata/management/communications (Wikis/Documentation/Blogs)/problem resolution/and so on. Gump's code is only a small component of it's whole. Agreed. Yet, we *must* have more people touching the code and, IMO, we should do so by thinking that every line of python code puts us a little bit farther away from that goal. I welcome more coders into Gump code, in fact I've longed for it tried to encourage entry many times. Yes, I know. I'm *not* blaming it on you. I'm blaming it more on me. Gump2 was a one man band 'cos nobody else wished to invest time and effort in a possibly dying venture, and yet out of it (in part by you helping it becoming a TLP) Gump was re-born and is once again thriving. Oh, here I really came across wrong: if it wasn't for your effort, I wouldn't have been involved in the first place since I thought that Sam's try just had failed to attract attention and momentum. Your energy and vitality gave me new hope and I think that's why we have a lot more gumpers today (even if they still don't touch the code!). Hopefully, the next wave will be the final one: when the community behaves just like any other and it's diversified enough to sustain any single individual leaving. Gump thrives based of it's contributions to the community, and hence their contributions to it (via metadata/effort) not due to the code. I welcome Gump3 as great opportunity for discussion and solving some mistakes of Gump2. Leo has address some, but not all (as I'll write) that need solving. I see no point in doing a re-write if after months and much effort we are no better off, and we've just shifted the one man team to a new man who we'll near burn out w/ all the 'implementation nits' that pure theory doesn't prepare you for. I'm no Leo, but I know this, I've been there. Completely agree. Stefano, we are a team, and as a team we will have different world views/skill sets/insights -- and yes, have different weakness/make different mistakes. I'll keep raising concerns/issues based off my one-man-band wealth of experience, and hope we'll all keep an open mind to what is re-instating a past mistake, and what is a practical insight. Part of being a team is, perhaps, you educating me into your views/insights and me pressure testing them on me. Let's not let our desire for progress to weaken our team. Very wise. Again, I apologize. I came across wrong, rude and disrespectful. It was not my intention. I very much welcome the idea of using gump2 and gump3 *both* to drive dynagump. I say let's do it :-) -- Stefano. - To unsubscribe, e-mail: [EMAIL
Re: The Gump3 branch
Adam R. B. Jack wrote: I'm a PIPE lover the much as the next guy, but simple flat stream pipes are not what we are building. Our components use complex results. Do we need contracts for those, or things (like DOM tree/XML structures) that we can persist/stream/validate. [How does Cocoon address this?] Cocoon pipelines are not streams of characters but streams of structured events (using the SAX API). So, for example, if you have ab//a to pass along, the events are: - startElement(a) - startElement(b) - endElement(b) - endElement(a) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Gump3 branch
Adam R. B. Jack wrote: Phew, have I been busy :-D. You certainly have. I got up real early (before I go cut up cars w/ the jaws of life) so I could take a read of this. I'm impress, inspired and (frankly) a little awed. I love how you've been far bolder than I ever was with putting your stamp on this thing, and enforcing clean practices. I was trying to replicate what existed, and make incremental deviations, but you've stood your ground from the start, enforcing your will/beliefs on this thing. I'm sure your previous container/component works have given you a lot of experience to inject here, and I think Gump lucked out that you gave it the time/framework. yes, I agree with Adam (and expressed my sentiments to Leo privately so far), Gump3 is very avalonish, in the pure IoC way, which is *very* refreshing for me :-) [and also refreshing to see that all the years spent in trying to get avalon working were not that useless] Ok, so love fest over a few questions (and there will be more, 'cos I don't have enough time now.) I guess my questions are concerns about where the pure theory meets the many practicalities that Gump bumps into. I'm sure your IOC/container experiences have required you to answer this before, but how do you allow components to communicate/collaborate? well, you don't :-) No, seriously, IoC drives your ability to interact. Leo is not using a proper component manager (and I agree that would be overkill), but it's using the idea that if a component needs something, it calls a factory (or a method factory) that will return a component, or a proxy/facade for the component to talk to. This allows isolation and polymorphism. There were times when building logic wanted to know something historically (had this built before, etc.) in order to determine how much effort (or what switches) to use. Is inter-component communications like this a real no-no, or is this something that might be coincidentally allowed via steps in pre-processing, etc. if the building component needs the historical component, it will ask its parent for it and the parent will either know how to obtain one or will delegate to its parent until somebody knows how. Do you think we have a chance to re-instate threading in this model? [It is a minor nit, not a show stopper, but I liked the large run-time reduction of concurrent checkouts.] I don't see any architectural impediment for this. I've gotten the Gump3 branch into a state where everything works (for me), as far as stuff is implemented. The main core thing that is missing is cyclic dependency detection. I've got the right algorithm written down on paper, just need to make it happen. The hooks for it are there already though (the gump.engine.modeller.Verifier class). Mind pumping a few command lines up to a wiki or somewhere? I'd like to run the engine, and unit tests, and such. Gump2 was a pain to run (we never cured it's confusion) and I'd like to start comfortably with Gump3 fro mthe get go. No, I think Wikis and documentations here are more harmful than useful at this stage, because they get out of synch. I would much rather spend time in making the code self-documented and the error messages, CLI-interface very very very explicit. Leo already did a great start on this. On thought in that regard is partial runs. I think Gump2 was beleived (although not actually true) to be less incremental build friendly since it wouldn't allow one to do build X, update X. [It was there in Gump3, just the command line was so crude folks never got to use it.]. I think you mean Gump2 and yes, the command line was aweful. I feel we need Gump3 to be easy to run in pieces, and in parts. Absolutely. Easily asking for things that include/exclude components on the fly. Nicola's (and Sam's) wxPython GUI was a nice user this way. Any thoughts on re-instating that? -1 as well. it's pretty much useless to have a GUI when you are running gump over a server and accessing it over a SSH text shell. We don't need anything that allows to include/exclude components on the fly (if not a configuration file) and we don't need a gui to edit the metadata. what we need is: 1) the ability to run gump on a single project or on a group of them 2) the ability to validate metadata on a single project on on a group of them 3) keep it simple stupid 4) reduce the complexity to a minimum 5) prevent YAGNI I think that generating plug-ins (perhaps even for loading, and such) is key. I'm not sure (yet) if the new model is any better than the old in allowing the core steps (loading, modelling) to be pluged-in, but I think it need to be investigated. Adam, please, let's not commit the same mistakes again: we should fix things only if they are broken. The goal now is to allow Gump3 to perform builds and put its data into the database so that dynagump can start publishing it. Everything else is secondary. I see you have a Maven parser, but could/should that be a plug-in? This is
Re: Gump Maven Plugin 2.0 Released
Brett Porter wrote:
We are pleased to announce the Maven Gump Plug-in 2.0 release!
http://maven.apache.org/reference/plugins/gump/
Changes in this version include:
New Features:
o Add maven.gump.module.name property for overriding the module name
o Add junitreport element to the descriptor
o Add multiproject module for generating a single module with several
projects within the one descriptor.
o Add nag element at module level Issue: MPGUMP-3.
o Handle subversion as an SCM type
Fixed bugs:
o Set maven.final.name as a property for the amp;lt;maven element, instead of
final.name
o Set home to ${basedir} instead of ${maven.build.dir}, and set jar path
relative to that
Changes:
o Stop mapping Maven names to gump names inside the plugin, but allow the
project to do this for itself Issue: MPGUMP-2.
To automatically install the plugin, type the following on a single line:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven
-DgroupId=maven
-DartifactId=maven-gump-plugin
-Dversion=2.0
For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-gump-plugin-2.0.jar
Have fun!
-The Maven Gump Plug-in development team
Great job!!!
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [revelation!!] circular dependencies do NOT exist!
Stefan Bodewig wrote: On Thu, 16 Dec 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Until today, i thought that no matter how well maintained, a dependency graph would always be a general graph, and cycles would develop, sooner of later (it is still amazing that gump reached 750 projects without explicit circular dependencies). Because we've already used the time-travel approach to break them in a couple of places packaged-dom4j - jaxen-from-packaged-dom4j - dom4j - jaxen and packaged-jcs - bootstrap-ojb - jcs - db-ojb (hmm, the later used to be the case, but right now I don't see any difference between bootstrap-ojb and db-ojb anymore) Cool, see how many things we don't know. Stefan, before we finish Gump 3.0 make sure you don't get hit by a truck ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [revelation!!] circular dependencies do NOT exist!
Leo Simons wrote: So while we can probably build gump to work like this (heck, it already works like this manually), we'd need to do some powerful visualisation to make people understand what's going on. eheh, here is where the fun (for me, as a research scientist) starts :-) A:20041215 failed because B:20041214 depends on C:20041213 for bootstrapping which depends on behaviour of A:20041212 that was broken from A:20041213 on. try and figure that out for 700 projects, and explain it properly! :-D So while circular dependencies don't exist if we ingrain our graph with the time dimension completely, it will at the same time become a lot more difficult to understand the graph and act upon changes to it. :/ I've been spending a few weeks now studying hard about pretty much everything there is to know about user interface design for data visualization tecniques. I'm not done yet (I have some 20 books to go ;-) but I'm seeing the light at the end of the tunnel. more (and some screenshots) soon. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating mono(?)
Davanum Srinivas wrote: Can we upgrade the mono install to Debian/EXPERIMENTAL found at http://pkg-mono.alioth.debian.org/? Can someone please walk me through this process? Am looking at the man pages of apt-get etc...but want to be sure that i don't break anything. don't worry, if you break something we'll fix it ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Native Build Dependancies
Stefan Bodewig wrote: Stefano, could you please apt-get install automake? done, installed automake and updated autoconf. autoconf2.59a-2 automake1.4-p6-8 -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Native Build Dependancies
Bill Barker wrote: Currently Gump is reporting that 'jakarta-tomcat-jk-native-configure' is failing, but this is really because 'jakarta-tomcat-jk-native-buildconf' is failing (but not with a status code, so Gump has no way of knowing this). The reason is that the buildconf.sh script depends on automake being installed. As I see it, there are three options: 1) Have some nice person install automake someplace where it will be in the $PATH when Gump runs. 2) Have some nice person install automake as an installed package, modify the metadata to depend on it, and modify the Gump code for script to place the depends in the $PATH. This is like $CLASSPATH for ant. 3) Kill off jakarta-tomcat-jk-native*. Since mod_jk isn't really being developed for httpd/2.1.x, this isn't as drastic as it sounds. the preferred gumpy way would be #2, but I could stick for both #1 and #2 either way. i can do #1 in a second, I might need a little help for #2... also the question is: once we start with these native dependencies how far off should we go? OS? ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
[EMAIL PROTECTED] wrote: Stefano, Some afterthoughts. Hopefully to help clarify. The scope of a Project in our system (currently) is that of a build (a series of builds) for a given instance of (1) product-release on a given (2) target. This of course means that a single configuration for a given instance of #1 would then fan out to several Projects (as we have used this word). I am not completely happy with this arrangement, since our Project does not distinguish between: (a) separate configurations, or (b) the same configurations build on different targets. And somehow I think this distinction should be more clearly represented in the data model. I think if (1) were to be defined as the Project and the (2)'s under it would be SubProject (to use some names), and keep the arbitrary grouping mechanism, though now at the SubProject level, then I think we've gained something w/o any other feature loss. I'm sorry, I totally lost you here :-/ -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
[EMAIL PROTECTED] wrote: Stefano: See my responses below. Stefano Mazzocchi [EMAIL PROTECTED] wrote on 12/10/2004 02:21:48 PM: [EMAIL PROTECTED] wrote: [...] In my Build Results system, I have a schema that also includes a few additional things: - abritrary groupings of projects, which helps in organizaing various forms of the presentation of the data Can you elaborate more on this? Yes, it is a many-to-many relation between the Project and Group tables. Thus, I can define one group which is all mainline builds (we have several release streams managed by separate branches), regardless of platforms build on. Another group would be all Windows/2003 builds. It is merely a way of seeing a limited set of project names, though when presented on the web page, I do also display some project attributes for each project displayed, like the lable link of the current build as well as the last good build. Ok, I see. What I was thinking is that this (and other of your suggestions) adds a meta-metadata layer and I'm not sure if I want to add this complexity at this point (given that the model is complex enough already). I agree that this meta-metadata layer will be very useful (for annotation, grouping and further user interaction around the collected data) but this is something we can add incrementally later on. - the general notion of attributes associated with each: - build (instance) - project - group - the whole system attributes as in annotations or as in related data? I'm not sure what is the difference between annotations (like added noted, do you mean?) and related data. But what these tables do is, basically to allow one to add new fields to the associated table without a schema change. They are name/value pairs, with the added key (foreign key) of the id of the table to which they relate. Thus, for the Project table: Project Attributes: - proj_id (foreign key) - name (string, key) - value (blob) Project: - proj_id (key) - ... etc ... In the case of the system wide attributes table, there is no id field. That table I use for stuff like debug on/off/level, motd, and so far little else. Ok, this is again another meta-metadata layer but this is something that I'm not sure I like. It smells of overdesign and at this point I want to keep features that are just critical for having the system working. the simplest thing that can possibly work. And since my system is focused on creating interaction between people about given built baselines, I have the notion of a notes history associated with any given build, in a similar spirit as the comment history of a given bug in bugzilla. I like the concept of allowing bugzilla-style communication to happen without requiring people to subscribe to various mail lists, like a common ground for communication to happen. But I don't want this to be too global, because I want gump-related discussions to happen on the mail list. You could tie-in email notification when this table is updated. We don't do that, but it's not a bad idea. Bugzilla of course does this. Good suggestion. Again, this applies to the meta-metadata layer but it strikes me as a very useful feature to have right away. What do others think? Like the notes table, I have separate tables for (references to) artifacts, yes, the artifact table is missing, that's a good point. I use the notion of an external Artifact Repository and refer into that with this table. The artifacts themselves are not stored in the database nor on the database server. Just wanted to be clear about that. The notion of an Artifact Repository: ah, well, I have my idea of what I want, and then there's the reality that we don't have much more (at present) than a web-based storage mechanism, organized hierarchically within the file system. Thus version information is exposed in the file-path name space, and 3rd party artifacts are managed in yet another system. My notion of an Artifact Repository would be a place to store any 3rd party artifact that any build could depend on. Build themselves would be producers, but could also be consumers. One of the main points of this is: that I separate, architecturally, the Artifact Repository, as a separate service, from the build system itself. Keep in mind that we DO NOT WANT gump to build anything that anybody would start use for their own stuff. It is critical, socially and politically and for the security ecosystem that gump's artifact repository is not used for anything else rather than distributed gumping and fallback scenarios. Consider it a cache, a repository of precomputed calculations rather than anything else. This is true for executables: for javadocs and docs, this is a different story but we should not attack too many problems at the same time. and another for results, to support any arbitrary number of artifacts/results to a given build-instance. Good point. [...] So, things missing are: 1) bugzilla like
Re: Recent Gump Error and DefaultHandler
Ceki Gülcü wrote: Stefan, Many thanks for the detailed report and the proposed fix. If my memory serves me correctly, we have already encountered the same exact problem previously and had solved it. This particular instance of the problem will get fixed later today. It's a good thing Gump compiles project with JDK 1.5, instead of JDK 1.4 which most of us still seem to use. On a different but related matter, I would love if Gump's scope (or mission statement) could be extended to run tests on the many different platforms it is deployed on. If that were the case, Gump would act as a virtual test lab, with a huge added value for a project like log4j. Gump currently has the technical capability to run test cases. So, maybe there is nothing else to change except symbolically extend Gump's mission statement. Perhaps this has been already discussed or is being worked on but maybe it is not. I believe the matter deserves some consideration. We are in the process of discussing the architecture of Gump 3.0 which will split gump into three stages: 1) project metadata harvesting (try to capture data from projects rather than having gump people maintain them) 2) do the build 3) mine and present the build metadata having the 3 stages separated would allow us to open stage #2 for multiple machines. The goal is to have as many CPU/OS/Environments as possible testing our code. Ceki, as constructors do when they are renovating a space please, excuse the mess, we're working to make it better and we also know that we cannot simply shut down gump, because if we did, all the uncaught problems will keep percolating (the tendency of the ecosystem to break is a *lot* higher than the tendency for the system to heal itself up... which is something we are concerned about and this new architecture (with a new social scheme, as you suggested) should make things better). HTH -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [xalan][kaffe] Xalan build with Jikes uses classes in rt.jar
Davanum Srinivas wrote: Folks, After spening 4+ hourseXalan build with Jikes on JDK1.4 succeeds because it uses classes in rt.jar and FAILS in Kaffe because the classes are not present. which classes? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump [brutus-kaffe]
[EMAIL PROTECTED] wrote: There is a problem with run 'brutus-kaffe' (13122004_150001), location : http://brutus.apache.org/gump/kaffe The log ought be at: http://brutus.apache.org/gump/kaffe/gump_log.txt The last (up to) 50 lines of the log are : A python/gump/core/config.py A python/gump/core/commandLine.py A python/gump/util A python/gump/util/owner.py A python/gump/util/__init__.py A python/gump/util/domutils.py A python/gump/util/tools.py A python/gump/util/threads A python/gump/util/threads/__init__.py A python/gump/util/threads/tools.py A python/gump/util/mysql.py A python/gump/util/note.py A python/gump/util/locks.py A python/gump/util/sync.py A python/gump/util/file.py A python/gump/util/http.py A python/gump/util/work.py A python/gump/util/smtp.py A python/gump/util/listener.py A python/gump/util/tasks.py A python/gump/util/timing.py A python/gump/util/process A python/gump/util/process/command.py A python/gump/util/process/__init__.py A python/gump/util/process/launcher.py A python/gump/tool A python/gump/tool/svg A python/gump/tool/svg/drawing.py A python/gump/tool/svg/depdiag.py A python/gump/tool/svg/svg.py A python/gump/tool/svg/__init__.py A python/gump/tool/svg/scale.py A python/gump/tool/performance A python/gump/tool/performance/deps.py A python/gump/tool/performance/__init__.py A python/gump/tool/performance/xdocs.py A python/gump/tool/performance/gurus.py A python/gump/tool/guru A python/gump/tool/guru/stats.py A python/gump/tool/guru/__init__.py A python/gump/tool/guru/xref.py A python/gump/tool/integration A python/gump/tool/integration/depot.py A python/gump/tool/integration/cvs.py A python/gump/tool/integration/__init__.py A python/gump/tool/__init__.py A python/gump/tool/shared A python/gump/tool/shared/__init__.py A python/gump/tool/shared/comparator.py Process Exit Code : 1 -- Gump Version: 2.0.2-alpha-0003 Hmmm, what's wrong with the kaffe build? it keeps on sending these messages. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
Niclas Hedhman wrote: On Monday 13 December 2004 16:24, Stefan Bodewig wrote: I think at least Stefan(o) prefer Gump an approach where Gump can parse Maven POMs directly. :o) Cool. But you are back to some of the problems listed for approach 1., e.g. there are artifacts that are not inter-project consistent. So, POM *alone* is not enough, but can remove the need for a gump goal in Maven. Yep. POM alone is not enough, we should start thinking about a registry of project names on where everybody can agree upon. Brett, what's your opinion on this? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
Eric Pugh wrote: Just catching up on my email after being gone for a week. One thing that strikes me about the project id's is that this seems to continue the same discussion we have had in the past about maven generated project id's versus the gump project id's... Do the project id's have to have meaning? While it's nice to look at a project id and pick out some data, like the version and the timestamp or what not, eventually gump will run into another project where the id's mean something different and are generated differently. I don't mind a project id like 787234 that I then look up and find out is what ever specific meaning it has. Like version, or host, or whatnot. I think that when we establish project naming conventions we'll run into conflicts with how other projects name themselves I would welcome project IDs of the form http://www.apache.org/projects/cocoon and then http://www.apache.org/projects/cocoon#v1.0 for a particular released version, or http://www.apache.org/projects/cocoon#20041210 Eric, I really don't care what ID we choose, as long as it does identify something univocally also in a global and distributed environment. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
[EMAIL PROTECTED] wrote: This is cool. FWIW, here's some bits from my experience, implemeting something similar in a MySQL database. Awesome! In my Build Results system, I have a schema that also includes a few additional things: - abritrary groupings of projects, which helps in organizaing various forms of the presentation of the data Can you elaborate more on this? - the general notion of attributes associated with each: - build (instance) - project - group - the whole system attributes as in annotations or as in related data? And since my system is focused on creating interaction between people about given built baselines, I have the notion of a notes history associated with any given build, in a similar spirit as the comment history of a given bug in bugzilla. I like the concept of allowing bugzilla-style communication to happen without requiring people to subscribe to various mail lists, like a common ground for communication to happen. But I don't want this to be too global, because I want gump-related discussions to happen on the mail list. Like the notes table, I have separate tables for (references to) artifacts, yes, the artifact table is missing, that's a good point. and another for results, to support any arbitrary number of artifacts/results to a given build-instance. Good point. This could be hidden in your diagram inside the builds entity/table, but wasn't explicit. No, you're right, we need to add that. I've built a lot of generality into my schema, since I need to support many inputs into this database, from various (new and old) build systems. Thus things like the result table is kept very general within the database. One area that is not very well thought out (in my case) are how results and/or build instances depend on each other, a core requirement for Gump, as it seems. Hope this helps. Comments? So, things missing are: 1) bugzilla like comments (on build results only? or what else?) 2) artifact table / artifact type table Anything else you guys see missing? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0
Adam R. B. Jack wrote: Ok, here is my thinking on how we proceed towards Gump 3.0, i.e.: 1) Metadata Gathering 2) Processing (Build/Sync/Update) 3) Results/Presentation/History Query/Analysis Fnor *now* ... 1) Phase One (Metadata Gathering) is simply the way to get XML documention into a local file system for Gump to process. Eventually this could be crawlers (etc.) that parse GOMs and POMs, but (for now) the CVS update HTTP gets are tolerable. [If anybody has an itch to tackle this first, speak up, but I think it is a reasonable/significant amount of work and (IMHO) can wait a little while longer.] +1 2) Phase Two (Building) is what we currently have as core, but that outputs to an historical database (plus some files for those w/o huge databases). It will not do RDF/RSS/Atom/Notification/XHTML Presentation (or XDOCS). It will not do Stats (neither XHTML presentation nor internal to DBM) nor will it do XRef (XHTML). +1 3) Phase Three (Analysis/Communication) is a whole new world; re-writting the 'will not do' list from above from the results database. This could be Python code, or Cocoon, or ... I'd like to focus my time on (2) and request that others help with (3). I'm game. I can take ownership of #3. Question: We currently run JDK1.5 and Kaffe off TRUNK not LIVE. Ought we change this? yeah, it makes sense. Alternatively, ought we perform this Gump work in a separate branch. I think I can add to the current w/o too much instability, then remove stuff when needed. I'm game to listen to others opinions/concerns though. Currently, Dynagump is the code name for #3 and does not depend on any code from Gump (only on a common database schema). I think we keep it the way it is for now, we can move stuff back and forth later on, thanks to SVN. [FWIIW: Personally, I'd love to get back to NAnt building except that Mono is still my roadblock.I think Gump 3.0 ought be far less resource bound, and it ought help us simplify running/operating Gump. As such, I hope it leads to more users and hence more hands to help with NAnt, etc.] I personally would love to see Mono stuff being gumped as well, but it's a low priority for me ATM. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] Gump 3.0 - Database Model
Since I received no pushback on my proposal, let's move on discussing the database model. I think the first step is to identify the entities that we want to model, their relationships and their respective cardinality. Here is what Leo and I came up with so far (attached as PDF). Comments/criticism/questions appreciated. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
Stefano Mazzocchi wrote: Since I received no pushback on my proposal, let's move on discussing the database model. I think the first step is to identify the entities that we want to model, their relationships and their respective cardinality. Here is what Leo and I came up with so far (attached as PDF). Comments/criticism/questions appreciated. Hmmm, trying again. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
Stefano Mazzocchi wrote: Stefano Mazzocchi wrote: Since I received no pushback on my proposal, let's move on discussing the database model. I think the first step is to identify the entities that we want to model, their relationships and their respective cardinality. Here is what Leo and I came up with so far (attached as PDF). Comments/criticism/questions appreciated. Hmmm, trying again. Damn, it seems that my attachments get filtered out. All right, find it over here: http://tinyurl.com/4qt9a -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [kaffe][status] jakarta-regexp junit
Davanum Srinivas wrote: Once we get these fixed by kaffe team, we will hit the next big obstacle on our side which is Xalan. We need to fix ant's Jikes support for -bootclasspath as mentioned here - http://marc.theaimsgroup.com/?l=gumpm=110252986623266w=2 Dims, thanks so much for your help here! you rock! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] Gump 3.0
I've been working for a while to describe an improved architecture for Gump and I have decided to go public with the discussion because I want this to be a community effort. - o - First and foremost, I believe that gump is one of the most exiting things happening that ever happened in the software space over the last few years but I also thinks that both technical, architectural and social limitations are stopping it from exihibit its real potential. The biggest problem I have is the fact that gump is such an integrated system: it tries to do too much in one single stage. Don't get me wrong: the internals of gump 2.x are rather modular and well architected, but the overall system architecture is too monolithic. So, here is my first suggestion: split gump in three stages. 1) metadata aggregation 2) build 3) build data use - o - Stage 1: Metadata aggregation - Gump will socially scale only when the metadata about the problem will be taken care by the people that administer the project rather then a few gump meisters. In this regard, I believe Maven to be far superior in term of gump-friendliness than ant because of its complete declarative nature (ant builds are a functional language, where project metadata cannot be transparently be inferred from them). In a perfect world, all project would *need* an metadata representation of their structure so that a build tool can parse that and understand what the project needs. In the real world, there are two camps: 1) procedural: make,configure,sh,ant 2) declerative: maven,apt-get,ports and the second normally build on the first one. The absolute need for gump (or apt-get, or BSD ports) is to have a declarative layer on top of the procedural one for every project, a 'semantic' layer that the system can understand and work on. Debian shows that it's possible to socially scale the concept of adding a semantic layer on top of existing project efforts, in a completely independent fashion. Maven shows that it's possible for the projects themselves to make good use of this information (also calling ant, if special needs are required). For gump, what's important is that having maven generate gump descriptors is both stupid and inefficient: gump should be able to digest directly the maven POM, without requiring any effort from the project. We should be maintaing the metadata representation only for the projects that don't have that data integrated in their build system (like pure ant projects or make/configure projects). So, what is a metadata aggregation layer? It's a crawler for project metadata. Crawls project and their descriptors and aggregates them in a service that can be queried to obtain that information. In short [bunch of locations] -- crawler -- metadata database - o - Stage 2: Build -- This is what today we think as gump. In short, it's the service that uses the project metadata, does the fetching, preparing, building and generates a bunch of data as a result. The difference from today's gump is that this build-only gump outputs data into a database, not into HTML pages or RSS scripts. The build stage and the data use stage are separated. In short: metadata database -- gump -- build data database - o - Stage 3: Build Data Use --- This is what todays is performed by the 'actors' inside Gump 2.x, the current actors are: 1) document 2) repository 3) notify 4) stats 5) syndication 6) timing 7) rdf 8) mysql 9) results we could aggregate them in the following taxonomy: [web] [html] document - creates the forrest output results - creates the XHTML output stats - does the stats part timing - does the timing part [others] syndication - does the RSS feeds RDF - does the RDF descriptors [email] notify - notifies the mail lists [history] mysql - saves historical data repository - saves the built jar files My suggestion is to remove all those away from the stage 2 and just let the historical actors be in stage 2 (basically pumping all the data into the historical database) and let the others reside in stage 3. So, for stage 3 I see two possible services: 1) the web service, taking care of things like: - web pages - historical graphs - syndication of results 2) the notification service, taking care of sending emails to the various projects In short: metadata database --+ +-- email notifier +--+ build data database --+ +-- webapp - o - Advantages -- This new architecture has several advantages: 1) the concerns are more easily separated, also means that different stages can be built using different languages. The webapp, for example, that I'm working working on (codename 'dynagump' and located in
Re: new docs - html
Leo Simons wrote: Stefano, I converted the docs I wrote a while back to html (trunk/src/xdocs). Hope you find time to wire 'em into dynagump. Lemme know if I can do anything there :-D Nice! Will do! thanks mate! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)
Davanum Srinivas wrote:
Stefano,
i think i poked through all the jars in JDK 1.4 and did not find
it...hence the question.
Found it!!!
The problem is in the XJavac task that Xerces2 uses to compile stuff
(probably it's a left-over workaround from an ant bug on the javac task).
Now, not only I can't find the sourcecode of that sucker (I had to
decompile it with jad (find it attached) but here is the offending part:
String s = ((String) properties.get( java.vendor )).toUpperCase(
Locale.ENGLISH );
if(s.indexOf(IBM) = 0)
{
// create an IBM-specific classpath
}
else if(s.indexOf(SUN) = 0 ||
s.indexOf(BLACKDOWN) = 0 ||
s.indexOf(APPLE) = 0)
{
// build the regular classpath
}
note how the classpath *IS*NOT*BUILT* if neither of the above match!
I would strongly lobby with the xerces people to get rid of that silly task.
--
Stefano.
// Decompiled by Jad v1.5.8c. Copyright 2001 Pavel Kouznetsov.
// Jad home page: http://www.geocities.com/kpdus/jad.html
// Decompiler options: packimports(3)
// Source File Name: XJavac.java
package org.apache.xerces.util;
import java.util.Hashtable;
import java.util.Locale;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.taskdefs.Javac;
import org.apache.tools.ant.types.Path;
import org.apache.tools.ant.util.JavaEnvUtils;
public class XJavac extends Javac
{
public XJavac()
{
}
public void execute()
throws BuildException
{
if(isJDK14OrHigher())
{
java.util.Properties properties = null;
try
{
properties = System.getProperties();
}
catch(Exception exception)
{
throw new BuildException(unable to determine java vendor
because could not access system properties!);
}
String s =
((String)properties.get(java.vendor)).toUpperCase(Locale.ENGLISH);
if(s.indexOf(IBM) = 0)
{
Path path = createBootclasspath();
String s1 = System.getProperty(java.home);
StringBuffer stringbuffer = new StringBuffer();
stringbuffer.append(s1).append(/lib/charsets.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/core.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/graphics.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/javaws.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/jaws.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/security.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/server.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/JawBridge.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/gskikm.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/ibmjceprovider.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/indicim.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/jaccess.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/ldapsec.jar:);
path.createPathElement().setPath(stringbuffer.toString());
stringbuffer.replace(s1.length(), stringbuffer.length(),
/lib/ext/oldcertpath.jar);
path.createPathElement().setPath(stringbuffer.toString());
setBootclasspath(path);
} else
if(s.indexOf(SUN) = 0 || s.indexOf(BLACKDOWN) = 0 ||
s.indexOf(APPLE) = 0)
{
Path path1 = createBootclasspath();
Path path2 = getClasspath();
path1.append(path2);
String s2 = (String)properties.get(sun.boot.class.path);
Path path3 = new Path(null);
Re: Hello Gump
Davanum Srinivas wrote: xml-commons/java/build/resolver.jar??? JDK1.4 probably has the classes built-in is my guess. o, yeah, that would explain it. I think xerces is missing a dependency on xml-commons! weird that we never found out in all this time ;-) -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hello Gump
Adam R. B. Jack wrote: Howdy folks, Long time no speak! (I've been unexpectedly buried helping my wife w/ her start-up, learning DotNet). I've missed you. I've missed Gump. I'm going try hard to get back online here. Give me pointers as to where I ought focus my energies. yey! we were beginning to feel lonely here withyou you, Adam :-) There is one top priority bug that is being bugging people a lot. When a project is not built because one of the dependencies didn't build and then gets build again because the dependency solved its problems, the project receives an email that is has no longer a problem. We have concensus to feel that this is annoying and the projects should be made aware of their change in status *only* when they fix their own problems, not when people down the road does. Either we solve this, or we stop sending email until we figure out a better way because this is harming our ability to make gump appear useful. WDYT? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)
Davanum Srinivas wrote: oops...i updated brutus.xml as ANT_OPTS is not really picked up. Added: sysproperty name=jikes.class.path value=/usr/local/gump/kaffe/workspace/xml-xerces2/java/tools/resolver.jar/ Anybody against removing this and adding a dependency on xml-commons/resolver from xml-xerces2? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
Stefan Bodewig wrote: On Thu, 2 Dec 2004, Eric Pugh [EMAIL PROTECTED] wrote: Is there a feeling that attempting to build with previous versions that passed isn't a good idea? Not at all. It is a very good idea that only needs to get coded. The only is the problem here. And I have the algorithm ready too :-) I just need to sit down and code this, but first I need to have Dynagump running because the historical information is critical for that algorithm to work and current gump's historical information sucks pretty bad. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
Eric Pugh wrote: I think that it's more complex then just turning it on or off.. I'm in favor of turning it off for now if thats the only option. What I prefer is that if a prereq doesn't build/builds finally, I don't get nagged. That is what generates (typically) the flood of emails... I only care if my project doesn't build/builds... Feel free to submit a patch. :-D No, seriously, gump is not really up to the task of keeping up with a community of users that see it as a pain in the ass (myself included). I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: change of module names or repositories
sebb wrote: On Wed, 01 Dec 2004 09:09:21 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote: Hi all, if you change the name of a CVS module or some code base switches from CVS to SVN or any other change like this happens, we need to remove the existing working copy from brutus. In velocity's case we had: svn --quiet update --non-interactive jakarta-velocity svn: 'jakarta-velocity' is not a working copy Could Gump detect the rename - or this error - automatically, and send a suitable warning to a Gump mailing list as a backup? Just wondering. well, Gump could not only detect the rename but perform a checkout instead of an update. Again, another bug that needs fixing. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
Ceki Gülcü wrote: At 03:44 PM 12/1/2004, Stefano Mazzocchi wrote: I think it's better if we start to nag ourselves first and see how we can increase the signal/noise ratio before we go back public. It's not only about gump's signal/noise ratio but the attitude adopted when things break. Allowing unaware developers to become aware that things broke (or may brake) offers tangible benefits. Once the dialog is triggered, it should go both ways. Depicting gump offenders as morons won't get us anywhere. In the past, the social algorithm for gump has been: 1) Gump checks for dependency issues. 2) If gump detects problems, social pressure is applied on the offender until the offenders yield. Otherwise, the offender is depicted as an insensitive moron. I suggest you review this social algorithm. Gump spot a problem that was caused by log4j that impacted velocity. cause and impact are used without negative connotation, just an evidence of a fact. This problem lasted for 35 runs. This triggered concerns in the gump list as Niclas decided to quit for that, feeling that the system is simply too fragile. People's reaction was to intervene and Eric proposed to change the velocity dependency from log4j to log4j-12. On the other side, I decided that it might have been a trivial change so I contacted Geir and asked him to change. Note how, up to this point, you nor log4j were not involved at all. Geir rushed to fix the problem and found out that it was harder to fix than he expected, because log4j didn't deprecate the contract in a released version before breaking it. Again, this is a *FACT*, not a judgement. *He* asked you to make a smoother transition for that contract change, in order to allow a smoother transition for velocity users once log4j 1.3 is released. Your response was that you don't have the resources to do that. At this point, our reaction was to change the dependency between velocity and log4j so that we could move on. If you have a better social algorithm that would stop you from feeling insulted, let us know what it is. Our goal is not to insult people or to create trouble. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
