BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 10 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. [EMAIL PROTECTED]: Module lenya success, but with warnings. [EMAIL PROTECTED]: Module opensaml success, but with warnings. [EMAIL PROTECTED]: Project nant (in module nant) failed [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. [EMAIL PROTECTED]: Module struts success, but with warnings. [EMAIL PROTECTED]: Project asm (in module asm) failed [EMAIL PROTECTED]: Project easymock (in module easymock) failed [EMAIL PROTECTED]: Project jtidy-cvs (in module jtidy) failed [EMAIL PROTECTED]: Project JacORB (in module JacORB) failed *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module castor contains errors. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/castor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/castor/gump_work/update_castor.html Work Name: update_castor (Type: Update) Work ended in a state of : Failed Elapsed: Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvs/castor update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/castor] - /cvs/castor: no such repository - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/castor/rss.xml - Atom: http://brutus.apache.org/gump/public/castor/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2508012005, brutus:brutus-public:2508012005 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Module lenya success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module lenya contains errors. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/lenya/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/lenya/gump_work/update_lenya.html Work Name: update_lenya (Type: Update) Work ended in a state of : Failed Elapsed: 59 secs Command Line: svn --quiet update --non-interactive lenya [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: Working copy 'lenya/src/webapp/lenya/resources/bxe/plugins' not locked - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/lenya/rss.xml - Atom: http://brutus.apache.org/gump/public/lenya/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2508012005, brutus:brutus-public:2508012005 Gump E-mail Identifier (unique within run) #2. *** G U M P [EMAIL PROTECTED]: Module opensaml success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module opensaml contains errors. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/opensaml/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/opensaml/gump_work/update_opensaml.html Work Name: update_opensaml (Type: Update) Work ended in a state of : Failed Elapsed: 3 mins 9 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/home/cvs/shibboleth update -P -d -A [Working Directory:
Re: The Gump3 branch
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. 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? 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. 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'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. 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 feel we need Gump3 to be easy to run in pieces, and in parts. 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? 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. I see you have a Maven parser, but could/should that be a plug-in? If you can leverage the framework here, perhaps in multi-stage runs (e.g. pre/run/post for loading metadata, pre/run/post for building, etc.) that might be nice. [Not sure if it is overkill, but I think it was a big weakness in Gump2 that needs to be addresses.] Another weakness of Gump2 was the (eventually huge) in-memory trees combining model and results. Hmm, I'm not sure if this goes away here (or not), and I fear not. How are we going to allow (say) a results plug-in to inject the build log (and/or commandline or whatever) into the results DB? I suspect it needs to reach out and touch the memory structures. Maybe little has changed here. [I half wondered about using XML file between components so we could completed run build and later run results generate. I never got to it 'cos I felt it was a lot of work and maybe overkill. Thoughts?] [Hmm, do we need a Wiki page w/ re-design goals/objectives to measure this framework against?] I think we need to treat internal plug-ins the same as community added, i.e. east our own dog food. Do you know Python patterns for discovering and loading such plug-ins? I'd like to start by writting plug-ins that this framework can run. Is (say) an RDF generating plug-in missing the point of DynaGump, or something allowable? I'm game to start work on the DB interface for generating history, or others. The other stuff that's missing is a lot of plugins. The new architecture as I set things up identifies three stages: - preprocessing - build/run - postprocessing This a tried and tested model you've used a lot in containers? Just curious of it's origins. I wonder if (eventually) we'd like to be able to break Gump3 completely from the sequential run, perhaps into an event-based engine. And each of those can have plugins (basically what are now called actors). Preprocessing plugins that need to be built include source repository updaters. Build tools that need to be built include all the handlers for the different Commands. Postprocessing that needs to be built include the dynagump adapter. Basically everything
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]
