Re: Problem running Apache Gump [brutus-test]
On Fri, 3 Dec 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: It was. So I entered this fix. Thanks I've no idea if Stefan's original issue (what he went in to fix) was resolved. It was. The original code would ignore jvmargs that were nested into ant or maven, it expected them to be children of project. Our docs said something different - and IMHO they are a property of the build process, not the project. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Resolver for Xerces on Kaffe was Re: Hello Gump)
On Sun, 05 Dec 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: We never noticed that xerces dependeded on that library before This is not really true. We once had a Gump build that broke because Xerces-J required xml-resolver about two weeks ago. And on the next build everything succeeded. I thought they had removed the dependency, while in reality they patched xjavac 8-( +1 for adding a dependency on resolver to xerces while making resolver depend on jaxp instead of xerces. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed
On Fri, 3 Dec 2004, Ian P. Springer [EMAIL PROTECTED] wrote: I'm looking into fixing the wsdl4j and naming deps for Apollo, but I'm unsure how the Gump / Maven combo works. Is it that the Gump dep's name must match the Maven dep's artifactId? No. I think Gump's id attribute on the jar element (which defaults to the project's name) must match Maven's artifactId. For example, one of our Maven deps has artifactId axis-wsdl4j, but the wsdl4j Gump project's jar name is wsdl4j. Then I really think your Maven dep is wrong since wsdl4j is not produced by Axis and shouldn't be considered part of Axis IMHO. So would adding: !-- alias -- project name=axis-wsdl4j depend project=wsdl4j inherit=jars/ /project To the wsdl4j Gump descriptor fix things? Probably not. Adding project name=axis-wsdl4j depend project=wsdl4j/ home nested=build/ jar name=lib/wsdl4j.jar id=axis-wsdl4j/ /project To wsdl4j.xml probably would. But really, I think your Maven artifactId is wrong. Also, how do the versions fit in? The maven jarnames are all verioned, whereas the Gump jarnames are not. We usually add versions containing the magic @@DATE@@ token via properties to the jar names. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed
For example, one of our Maven deps has artifactId axis-wsdl4j, but the wsdl4j Gump project's jar name is wsdl4j. Then I really think your Maven dep is wrong since wsdl4j is not produced by Axis and shouldn't be considered part of Axis IMHO. It appears the correct ID is axis:axis-wsdl4j, ie the artifact ID is axis-wsdl4j, the group axis. This seems right. So is the problem that wsdl4j has declared itself to be something different in gump than it did in Maven? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed
On Mon, 6 Dec 2004, Brett Porter [EMAIL PROTECTED] wrote: For example, one of our Maven deps has artifactId axis-wsdl4j, but the wsdl4j Gump project's jar name is wsdl4j. Then I really think your Maven dep is wrong since wsdl4j is not produced by Axis and shouldn't be considered part of Axis IMHO. It appears the correct ID is axis:axis-wsdl4j, ie the artifact ID is axis-wsdl4j, the group axis. This seems right. So is the problem that wsdl4j has declared itself to be something different in gump than it did in Maven? Maybe. Did wsdl declare itself at either end? I don't think anybody has asked them, which group they want to belong to. The piece built by Gump most certainly is not part of Axis in any way, but comes directly out of an IBM CVS repo. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Project apollo (in module apollo) failed
| For example, one of our Maven deps has artifactId | axis-wsdl4j, but | the wsdl4j Gump project's jar name is wsdl4j. | | Then I really think your Maven dep is wrong since wsdl4j is not | produced by Axis and shouldn't be considered part of Axis IMHO. | | It appears the correct ID is axis:axis-wsdl4j, ie the artifact ID is | axis-wsdl4j, the group axis. This seems right. | | So is the problem that wsdl4j has declared itself to be something | different in gump than it did in Maven? The axis:axis-wsdl4j is a result of how Axis publishes the wsdl4j jar in the Maven repo (http://www.apache.org/dist/java-repository/axis/jars/). If it it makes things easier, I could publish the jar in the snapshot repo (http://cvs.apache.org/repository/) under wsdl4j:wsdl4j and then reference that in our Maven descriptors.. Btw, I noticed in Axis' gump descriptor, the wsdl4j jar is specified as follows: ant basedir=java target=dist ... depend name=wsdl4j.jar project=wsdl4j id=wsdl4j / ... /ant as opposed to: depend project=wsdl4j / In case that provides any clue. Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xml-xerces2 / jaxp - failure and possible fix
Folks, I just saw the failure at http://brutus.apache.org/gump/public/xml-xerces2/xml-xerces/gump_work/build_xml-xerces2_xml-xerces.html i recreated the failure by hand on brutus and was able to come up with a possible fix, which basically to drop java_xml_pack-summer-02_01/jaxp-1.2_01/xercesImpl.jar and java_xml_pack-summer-02_01/jaxp-1.2_01/xalan.jar. updated cvs:gump/project/xml-xerces2.xml...let's see if the 12:00 Noon PST run is any better. thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unit testing
1) get a real OS* 2) alternatively, get Cygwin* 3) cd F:\data\Python\gump-svn\python svn up sh ./gump test should now sort-of work. * I built a convenience thin shell wrapper. You could also just take a look at what it does; its really straightforward Adam Jack wrote: Also, could somebody point me to Wiki/Docs changes for this new config, or an archive thread, or simply give a little information on it? Not really. It didn't work when I looked at it. Now you can run them again, but there's a few failures. I talked a bit about using the unittest package a while back. Searching the list for test in the subject line should get some hits I hope :-D g'night peeps! - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new docs - html
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 cheers, - LSD - 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: [RT] Gump 3.0
Stefano Mazzocchi wrote: Comments? Not really. Most of it sounds obvious by now, actually :-D More images related to this architecture are at: http://svn.apache.org/repos/asf/gump/trunk/src/xdocs/gump.pdf though I'm afraid some of the comments in the gump.ppt alongside there didn't make it into the PDF. I'll also point out that your RT (probably on purpose) leaves out a *lot* of talk about (lifting) social limitations. The fun bit about the thinking there is that it tends to span all those stages and database. That really needs to be written down as well at some point so some of the design decisions make more sense :-D Finally I'll point out (just to keep this e-mail short, really, there's a lot to say), one other thing to realize is that this DB-based-architecture will help us move away from the batch-based approach we have right now. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: turning off email
It just dawned on me I zapped it, but for the testing (HEAD) code-base not the production one. I could update that, and I will. We gotta stop the spam. Also, there is something weird going on inside Gump's states. There seems to be an Unset state getting inserted, hence breaking the do not spam on Pre-req-Failed - Success logic (since we have Pre-req - Unset - Success, or something) . Ok, zapping now... regards Adam - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: Gump [EMAIL PROTECTED] Sent: Monday, December 06, 2004 4:49 PM Subject: turning off email Avalon got flooded again with no longer an issue emails today. Adam, what's the easiest way to stop this for now? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Recent build failures in commons
We got a lot of this today: internal-test: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jelly-tags/junit/target/test-reports [junit] Running org.apache.commons.jelly.tags.junit.TestJUnit [junit] Exception in thread main java.lang.NullPointerException [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter.formatOutput(XMLJUnitResultFormatter.java:265) [junit] at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter.setSystemOutput(XMLJUnitResultFormatter.java:93) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.sendOutAndErr(JUnitTestRunner.java:426) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:310) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:661) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:562) BUILD FAILED /home/gump/workspaces2/public/workspace/jelly-tags/junit/build.xml:97: java.lang.NoClassDefFoundError: org/w3c/dom/ranges/DocumentRange Is there some change internal to gump or do we have to add xml-apis to our dependencies? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How do our unit tests work?
Adam, I've been scratching my head to figure out what is going on with those unit tests. * Is it true that they *depend* on one another and need to execute in a particular order? What is the nature of that dependency and how can we remove it? * How can I figure out what tests need what files/workspace stuff in place? It would be nice if we could make each test totally isolated from the others. cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent build failures in commons
On Tue, 7 Dec 2004, Dion Gillard [EMAIL PROTECTED] wrote: Is there some change internal to gump or do we have to add xml-apis to our dependencies? Yes and yes 8-) xerces no longer publishes xml-apis.jar so all builds that used their xerces dependency to get access to DOM and friends will now need to depend on xml-apis explicitly. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed
On Mon, 6 Dec 2004, Ian P. Springer [EMAIL PROTECTED] wrote: | For example, one of our Maven deps has artifactId | axis-wsdl4j, but | the wsdl4j Gump project's jar name is wsdl4j. | | Then I really think your Maven dep is wrong since wsdl4j is not | produced by Axis and shouldn't be considered part of Axis IMHO. | | It appears the correct ID is axis:axis-wsdl4j, ie the artifact ID | is axis-wsdl4j, the group axis. This seems right. | | So is the problem that wsdl4j has declared itself to be something | different in gump than it did in Maven? The axis:axis-wsdl4j is a result of how Axis publishes the wsdl4j jar in the Maven repo Given that I know a few projects that have jars in the Maven repo without any help by the project itself, I'm not sure it is correct to say how Axis publishes in this context. I'll start a new thread under a different subject to catch Dims' attention 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed
On Tue, 7 Dec 2004, Brett Porter [EMAIL PROTECTED] wrote: There are probably 3 solutions: 1) change the gump IDs to match (project axis, id axis-wsdl4j?) 2) map the gump ID with an additional file as Stefan mentioned earlier 3) add the ability to map to a different gump ID in the project.xml dependencies element and have it come out in the gump descriptor. I'm going to do (3) eventually, with (1) an additional long term solution and (2) the workaround we've been using. I'd agree with you that (1) should be the best approach, if wsdl4j actually was an artifact of Axis. Since it gets created by a totally different project and merely gets redistributed by Axis, I think it is simply wrong to depend on axis:axis-wsdl4j in any Maven build at all. Like I said, I'll start a new thread. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
