RE: Picking up the ball from Niclas (ugh!) on Velocity
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Gump is about establishing communication channels between development communities. ROTFLOL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
gump/maven plugins dependencies are broken
Have been trying to sort out an issue concerning dependency logic related to maven plugins during gump runs. If we take a look at the Fulcrum MimeType Impl project it declares a dependency (inside the maven project.xml) to the avalon-meta-plugin. Normally maven will load the plugin at buildtime (which involves the creation of a plugin classloader which in the case of the avalon-meta-plugin involves loading about 6 or 7 other jar files that are declared in the plugin's project.xml (embedded in the plugin jar file). However - something very strange is going on. Maven appears to be loading the version of the plugin declared in the project.xml and NOT the version of the plugin supplied by gump. This means that the wrong dependencies get pulled in - demonstrated by the fact that maven is complaining about a missing dependency excalibur-configuration. Please note that excalibur-configuration is *not* a dependency with the plugin supplied by gump - but it is a dependency in the version of the plugin declared in the project.xml file. Here is the build result referencing the invalid missing excalibur-configuration dependency. http://marc.theaimsgroup.com/?l=turbine-devr=1b=200410w=4 My conclusion is that the gump builder for maven is expanding dependencies based on the project.xml versioned plugin declaration via a remote repository instead of expanding the project.xml of the latest version of the plugin. The thing here is that there is no information available to the gump for maven builder to tell it where to find the plugin's project.xml. A possible solution here is to provide additional information to the builder - possibly a gump.properties file that would tell the gump builder where to find the definitive project.xml for the plugin. My currently feeling is that this issue is likely to block the majority of builds in the Fulcrum repository. Any suggestions? Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some progress on Fulcrum Component Builds!
-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Sent: 15 October 2004 07:06
To: Gump code and data
Subject: Re: Some progress on Fulcrum Component Builds!
On Friday 15 October 2004 07:45, Brett Porter wrote:
depend project=avalon-merlin-unit/ to depend
project=merlin-unit/
:o)
No, the project here refers to the name within Gump, but I think
that
the
following is needed;
depend property=maven.jar.merlin-unit project=avalon-merlin-
unit/
Brett, do you have any insight in this?? Steve?
AFAIK property is not needed. The gump plugin just generates:
depend project=${dependency} /
Yes, but the Gump ID and the Maven ArtifactID must correspond, and
they
don't
in this case.
Can we just put a symlink in place that links merlin-unit to
avalon-merlin-unit?.
Steve.
Niclas
--
+--//---+
/ http://www.bali.ac/
/ http://niclas.hedhman.org /
+--//---+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Some progress on Fulcrum Component Builds!
-Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: 15 October 2004 14:39 To: Gump code and data Subject: RE: Some progress on Fulcrum Component Builds! Great news! Last question (well probably not...) In the latest jakarta-turbine-fulcrum, all the jars are now versioned: jar name=fulcrum-pool-api-1.0.2.jar/ Is this due to some sort of issue with how the projects depend on each other? No. The issue is that gump is checking that the output produced by maven corresponds to the output declared under the jar tag in gump descriptor. If the build output does not correspond them gump will fail the project. In theory this should be handled via properties declared by gump to maven but that does not appear to be working for the moment. So the workaround is to add the explicit version to the gump descriptor. In the future, if I bump a version in my project.xml, should I also fix it here as well? As things stand - yes. Steve. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 12:37 PM To: Gump code and data Subject: Re: Some progress on Fulcrum Component Builds! Hi, Solution acquired. You keep merlin-unit in your Maven descriptors. I have created a new merlin-unit project in Gump, which inherits the Jar from avalon-merlin-unit. Everyone happy :o) Niclas On Friday 15 October 2004 19:29, Eric Pugh wrote: I see! This makes sense! Never thought about the impact on name changes on consumers of your code.. At least not in the way Gump is a consumer. So, because I use a specific version of merlin-unit, I am fine in my project. I can't change it to avalon-merlin-unit until the next version comes out. However, because of the name change, and Gump using the latest and greatest, my project doesn't know about the new version. So, in these types of situations, should I just somehow setup a package that I depend on, which would be the merlin-unit-3.3.0.jar version? Alternatively, should Gump's record for avalon-merlin-unit be annotated with all the prior names, so that at the end of the run it produces avalon-merlin-unit-@@DATE@@.jar as well as merlin-unit-@@DATE@@.jar? Or lastly, Could we just make another project record and just copy everything it does and change the last line to this: project name=avalon-merlin-unit license name=central/system/license/LICENSE.TXT/ ant basedir=runtime/merlin/unit !-- for magic -- property name=build.sysclasspath value=last/ property name=magic.home reference=home project=magic/ property name=gump.signature value=@@DATE@@/ SNIP/ !-- end for -- home nested=runtime/merlin/unit/target/deliverables/ jar name=jars/merlin-unit-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] from=Magic Integration lt;[EMAIL PROTECTED]gt;/ /project Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 12:15 PM To: Gump code and data Subject: Re: Some progress on Fulcrum Component Builds! On Friday 15 October 2004 19:10, Eric Pugh wrote: I am a little confused.. Why is the behavior of avalon-merlin- unit special/more difficult then any other dependency? That is due to a name change. merlin-unit is needed in your Maven descriptor since that has been released before. avalon-merlin-unit is the new name, and that is the Gump descriptor generated. So, when you add depend project=avalon-merlin-unit/ you will not get the proper override for the Maven descriptor, and Maven will report that merlin-unit-x-x.jar can not be found. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - 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] -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
RE: dependence on mysql jdbc driver bogus?
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 05:44 To: Gump code and data Subject: Re: dependence on mysql jdbc driver bogus? On Thursday 14 October 2004 11:37, Stefano Mazzocchi wrote: excalibur-datasource fails to build because it depends on mm-mysql but doing a grep -r mysql . in that directory doesn't yield anything. I suspect it's a bogus dependency in their POM. Thoughts? Yes, and I have sent them a patch for its removal. And is been applied. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 06:59 To: Gump code and data Subject: Re: BATCH: All dressed up, with nowhere to go... On Thursday 14 October 2004 12:33, Niclas Hedhman wrote: I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... IIUIC, Xdoclet is not yet Mavenized. They use Ant as the build system, and call upon Maven for the documentation generation. Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. WDYT? Yep. /Steve. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jtidy
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 13 October 2004 09:19 To: Gump code and data Subject: Re: jtidy -- it is the last step before Cocoon, it seems. That, or somehow we need to tackle this list below. Brett, if we built all those plugins from source, would we be able to use the freshly compiled versions of them in Maven using jar overrides or something? Or would this involve changing the Maven installation? I'll give a more explanatory answer, but the short answer is that it doesn't require changing the Maven installation, so this should be easy enough. plugins are a bit interesting in Maven 1.x. There are installation-wide plugins in $MAVEN_HOME/plugins There are user plugins in $MAVEN_HOME_LOCAL/plugins (usually $HOME/.maven/plugins) to gump, I imagine we never go near the second one, and only change the first one when we start building Maven from source. Then there are runtime only plugins - specified as dependencies (as in the case above), or built as part of a maven build using the reactor (see geronimo, I think). Since these ones are dependencies, they can be built using gump and handled as regular dependencies with jar overrides. They will not affect other projects, as they are not installed into either of the two locations above - just loaded into memory for the current maven run and forgotten once it stops. I'm very reluctant to make more parts of our build systems installed. Not exactly what you mean by installed here. I agree that they shouldn't be installed in Maven for all builders to use. I think that they have to be treated as with other dependencies: use jar overrides. But whether you build them from source, or package them is up to you. I'd say building them is unlikely to be problematic (unless they have some obscure dependencies): plugin:plugin is a very simple goal. Brett: Any ideas what will happen when a project declares a dependency on a artifact in both the project.xml and the gump project definition, and the plugin itself is not built by maven? This is the case with a plugin in the avalon repository that is build by Magic and used in Maven under the Fulcrum project. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 12 October 2004 10:02 To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta- turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml On 12 Oct 2004, [EMAIL PROTECTED] wrote: Fix a bunch of broken project names, AFAIU most of them have been autogenerated so we have a mismatch between the Gump plugin in Maven and Gump's view of the world, I'm afraid. There is no jakarta-turbine-fulcrum project (anymore?), There sure is. They have a bunch of projects producing a swag of components. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 12 October 2004 11:54 To: Gump code and data Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta- turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml On Tuesday 12 October 2004 17:26, Stephen McConnell wrote: There is no jakarta-turbine-fulcrum project (anymore?), There sure is. They have a bunch of projects producing a swag of components. Well, there is no jakarta-turbine-fulcrum project with that name. Each component is its own project now. Well, yes, but all under jakarta-turbine-fulcrum CVS. /Steve. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 12 October 2004 12:35 To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta- turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml On Tue, 12 Oct 2004, Stephen McConnell [EMAIL PROTECTED] wrote: -Original Message- From: Stefan Bodewig There is no jakarta-turbine-fulcrum project (anymore?), There sure is. They have a bunch of projects producing a swag of components. There is a jakarta-turbine-fulcrum /module/, no /project/. Nothing you could use in a single depend. True - I'm just saying that there is a Jakarta Turbine Fulcrum project within Apache. /Steve. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 12 October 2004 12:47 To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta- turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml On Tue, 12 Oct 2004, Stephen McConnell [EMAIL PROTECTED] wrote: True - I'm just saying that there is a Jakarta Turbine Fulcrum project within Apache. Sure. 8-) When I said project, I was talking about the Gump project. No offence intended in any way. How can one be possibly offended when one is only here for the entertainment? /Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] move the descriptors in our hands
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: 08 October 2004 16:58 To: Gump code and data Subject: Re: [vote] move the descriptors in our hands Stefan Bodewig wrote: On Thu, 7 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: ant-contrib comes and goes (I think) as it's gump descriptor fails to get read from SF.net's viewcvs. If it is of any help, go ahead and move the descriptors to Gump's CVS (I'm with a customer and without my ssh keys right now). I'm the one maintaining the ant-contrib descriptors (ant-contrib and cpptasks) anyway. So, should we go ahead and move all the descriptors in our hands? Please do not move the avalon-trunk.xml descriptor - it's automatically generated and does not need any human tweaking. Stephen. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Avalon artifactIds (was Re: Excalibur Gump/Maven)
-Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: 08 October 2004 22:58 To: Apache Gump Subject: Avalon artifactIds (was Re: Excalibur Gump/Maven) Ok, we are now down to this: BTW: Anybody else to tell me what avalon-framework in Maven land is ins Gump land? I think we have three dependencies, to it's one (a concern). Which ought I pick? avalon-framework-api or avalon-framework-legacy or avalon-framework-impl? Do we have a Gump/Maven disconnect here (due to changes in Avalon's artefacts) that needs to be updated in the Excalibur project.xml? avalon-framework-api this project defines the client API (interfaces, exceptions, immutable datatypes, etc. dealing with component lifecycle concerns). avalon-framework-legacy contains some deprecated classes that have structural dependencies on the avalon-logkit project. Is dependent on the framework api. avalon-framework-impl an implementation of the framework api. Is dependent on the framework api and framework-legacy. As to what's needed by Excalibur Logging - you would need to ask someone from the Excalibur project. Stephen. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [status] main issues
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. Stephen. we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [status] main issues
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. Stephen. we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: excalibur/excalibur-instrument-spi failed
All of the Excalibur projects are declared in a Gump definition which is available to all Apache committers in the gump cvs module. The file in question is: /gump/project/excalibur.xml Please note there this is a gump/maven issue that results in the generation of inconsistent property files during the execution of the build. It seems that the gump builder for maven may be generating properties that are inconsistent with the Gump naming conventions. If you get stuck in this area the best thing to do is to post the issues to the [EMAIL PROTECTED] list. Stephen. -Original Message- From: Leif Mortenson [mailto:[EMAIL PROTECTED] Sent: 02 October 2004 16:05 To: Excalibur Developers List Subject: Re: [EMAIL PROTECTED]: excalibur/excalibur-instrument-spi failed Sorry for my ignorance, but where are the gump projects configured? The instrument jar/project names all changed when I restructured Instrument a while back. excalibur-instrument-api - excalibur-instrument-api excalibur-instrument-http - excalibur-instrument-mgr-http excalibur-instrument-impl - excalibur-instrument-mgr-impl excalibur-instrument-spi - excalibur-instrument-mgr-api excalibur-instrument-altrmi - X I'd take care of getting gump fixed as far as the instrument packages if only I knew how Cheers, Leif Gump Integration Build wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project excalibur-instrument-spi has an issue affecting its community integration. This issue affects 4 projects, and has been outstanding for 23L runs. Project State : 'Failed' The following are affected: - excalibur-instrument-http : Repository of reusable components. - excalibur-instrument-impl : Repository of reusable components. - excalibur-instrument-manager : Repository of reusable components. - excalibur-instrument-spi : Repository of reusable components. Full details are available at: http://brutus.apache.org/gump/public/excalibur/excalibur-instrument- spi/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole output [excalibur-instrument-spi-02102004.jar] identifier set to project name -DEBUG- Dependency on junit exists, no need to add for property junit.jar. -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Made directory [/usr/local/gump/public/workspace/excalibur/containerkit/instrument/mgr- api/target/classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/excalibur/excalibur-instrument- spi/gump_work/build_excalibur_excalibur-instrument-spi.html Work Name: build_excalibur_excalibur-instrument-spi (Type: Build) State: Failed Elapsed: Command Line: java -Djava.awt.headless=true - Xbootclasspath/p:/usr/local/gump/public/workspace/xml- xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml- xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml- xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xm l- commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main - Dgump.merge=/usr/local/gump/public/gump/work/merge.xml - Dbuild.sysclasspath=only - Djunit.jar=/usr/local/gump/public/workspace/dist/junit/junit.jar - Dsrc.exclude.pattern=**/package.html - Dcheckstyle.jar=/usr/local/gump/public/workspace/checkstyle/target/dist/ ch eckstyle-02102004/checkstyle-02102004.jar -Dproject.version=02102004 -f gump-build.xml jar [Working Directory: /usr/local/gump/public/workspace/excalibur/instrument-manager/spi] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/ ex calibur/containerkit/instrument/mgr- api/target/classes:/usr/local/gump/public/workspace/excalibur/containerk it /instrument/mgr-api/target/test- classes:/usr/local/gump/public/workspace/avalon- trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-ap i- 02102004.jar:/usr/local/gump/public/workspace/avalon- tools/tools/magic/target/deliverables/jars/avalon-tools-magic- 02102004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/ lo cal/gump/public/workspace/ant/dist/lib/ant- stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/lo ca
RE: [rant] I hate this gump
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: 02 October 2004 19:26 To: Apache Gump Subject: [rant] I hate this gump This is a rant. I rant when I'm pissed, but I rant when I care. Cocoon received some 25 nags in a row, twice, in two days and it's likely to continue since I have no idea on how to fix the thing. I spent a few hours browsing around the gump html pages. I'm sorry, they are not only uselessly full of information that nobody really cares about, but they are also misleading *very misleading*. Example: http://brutus.apache.org/gump/public/cocoon-2.1/index.html look at what it says: SUCCESS success at what? at finding problems? then it says overall project success 18%. WTF? what is the measure of success for gump, anything higher than zero? So, we clearly have a problem and I try to fix it. I take the 'cocoon' module because is the root of the dependencies (obviously *I* know that, stupid gump doesn't tell me that, even if it knows) http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/index.html no such project avalon-framework. What? It has been there *FOREVER*... oh, yeah, it's the we love our users anthem we hear from avalon every day [we are fixing that one in another area, but it should be fixed soon] There is this message on cocoon-dev: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109320288814185w=4 And this reply: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109322232009166w=4 Stephen. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
Bret/Adam: Just a note on this dependency mapping question .. within the Magic build system we doing something similar. Dependencies declared in a magic project definition typically match up with the name of an artifact (id in maven). In cases where Gump declares a scoped name (e.g. junit relative to the ant-junit project, we include additional meta info within the magic project definition (loosely equivalent to maven's project.xml). Here is an example of the definition of an external resource (close to a maven dependency declaration). Within magic the groupId is 'ant' and the artifactId is 'ant-junit'. We have additional metadata to handle the mapping to a gump alias/id combination. Using the alias/id we can automatically resolve the gump resource and allocate this to the project group/name key. resource info groupant/group nameant-junit/name version1.6.2/version typejar/type /info gump classpath/ aliasant/alias idjunit/id /gump /resource This works quite well and we don't have any naming conflicts. Cheers, Steve. p.s. Just another thought - the build.properties file generated by Gump seems to be including all inherited project references irrespective of the definition in gump. For example, I recently removed all of the inherit attributes from the gump descriptor for the threads project (bringing it in line with the maven generated gump task output, but the properties file still contains a much larger set of dependency mappings. Would it be possible to simply restrict gump to generating only those properties that are explicitly declared (i.e. no inherited properties)? Cheers, Stephen. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 24 September 2004 05:24 To: Gump code and data Subject: Re: excalibur-thread-impl failure in Gump Ok, this time I got the reply-to right :) Unfortunately it has junit, the reason being was that Gump 'jar ids' were within the scope of the project, so the 'ant' was implied. Since Gump only has 'jar id' that is the only thing that Gump can pass to Maven. Hence we need to make Gump 'jar ids' globally unique, and (for want of a better) match Maven 'artifact ids'. Ok, I should explain Maven id's to clear this up a bit. They are composed of a group and an artifact ID. The group must be unique (this is easier to control than the whole id being unique), and the artifactId must be unique within the group (also easy for those maintaining the group to control). This guarantees the whole ID is unique. At the moment, groups are things like commons-collections, ant, and maven (see the root directory of http://www.ibiblio.org/maven/ for a list), but eventually we intend to move to a package structure, so the group would be org.apache.ant and such. The notation for an id is groupId:artifactId. Usually, artifactId is the same as the filename (files are built as artifactId-version.jar by default). This makes it much easier to remember and look up. For the above example, the ids should be junit:junit and ant:ant-junit respectively. JAR overrides do have a limitation in that they currently don't really support the Maven id structure of group:artifact, which is planned to be fixed for 1.1. So what I was saying here is that we never used to have a groupId - and the overrides you are using are a hangover of that. The property must match either the artifactId or id part of a dependency in project.xml. But if we have a project with ant:junit and junit:junit as dependencies - there'll be a problem as in both cases the old id is just junit. If you have time to explain in more detail I'd appreciate that, I'm not quite following. Hope this helped. I agree. I was saying correct because I thought it used junit, so I feel it ought ask for it (not have Maven transparently add it). In this way, Maven attempts to separate the build from the actual produced JAR (it isn't always successful, but we're working on that :) excaliber doesn't depend on junit in any way to use it AFAIK, so its not a dependency. It is a dependency of the excalbier unit tests though. Maven will specify that for you to avoid having to do it yourself only if you use the test plugin. In the same way, checkstyle is not a dependency of excaliber - but it is used if you run the maven checkstyle plugin report. Tests admittedly are a bit more fuzzy because you code and compile portions of your source against junit, but it should be treated the same. Or we build Maven from scratch using Gump'ed artifacts? I think this can happen now if you are game to try. Start by building from MAVEN-1_0-BRANCH and then later move to HEAD. If you want to build a Maven distribution using Maven 1.0, that's doable now. If you want to use ant 1.5, I'd need to modify the bootstrap to accept JAR overrides. Which do you prefer? Maybe start with Maven
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 22 September 2004 01:31 To: Gump code and data Subject: Re: excalibur-thread-impl failure in Gump Short answer: It has a problem in build.properties. There are two maven.jar.junit properties, and the second points at ant-junit.jar, which I assume does not declare junit.framework.TestCase. Ant-junit.jar is ant extensions to junit. This would be introduced with any dependency with a runtime inheritance property set (which is the case of the thread-impl gump project definition). I've just updated the def to remove the runtime inheritance stuff so that should simplify things a touch. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 09:49 To: [EMAIL PROTECTED] Subject: Re: excalibur-thread-impl failure in Gump On Mon, 20 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Nope ... excalibur-thread-impl still failing. Time for a maven expert? Probably yes. Maybe the junit plugin doesn't honour the jar overrides in project.properties? Maybe it's a classloader issue and the fact that junit.jar is on the CLASSPATH is hurting Maven? I took a look at excalibur-pool-impl which is almost identical (and has testcases) and it's working ok. I've just updated the project.xml to follow it as closely as possible. I don't think it's a classpath thing because maven ignores the gump supplied classpath anyway. So it's down to something in the project.xml, maven.xml or generated properties. Anyway - let's give it another run to see if the last change actually impacts anything. Steve. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 11:20 To: [EMAIL PROTECTED] Subject: Re: excalibur-thread-impl failure in Gump On Tue, 21 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: I took a look at excalibur-pool-impl which is almost identical (and has testcases) and it's working ok. I've just updated the project.xml to follow it as closely as possible. db-grafolia[1] works as well. But it doesn't even list a dependency on JUnit in the Gump descriptor. The listing in the gump descriptor is only going to effect the Gump ordering - not the execution in Maven. The junit target in maven fires off a junit plugin which has the junit stuff in its classpath - or at least is should. The excalibur-thread-impl has just failed again. I'm kind of at the end of ideas for possible solutions. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 11:11 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: excalibur-thread-impl failure in Gump Hi, for some reason Maven doesn't seem to pick up JUnit, even though it is listed in the project.properties generated by Gump - and it doesn't complain about it missing either. Since I know next to nothing about Maven, the following observation may be completely insignificant, but ... In project.xml all dependencies have groupId and artefactId elements while the one for JUnit only has an id element (which the others have not). Have already updated the project.xml to reflect the same convention. What's interesting is that the project build locally without any issues. Anyway - we'll see if this is the problem or not shortly! Cheers, Steve. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-jmeter.xml
-Original Message- From: sebb [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 12:49 To: Gump code and data Subject: Re: cvs commit: gump/project jakarta-jmeter.xml On 20 Sep 2004 09:18:33 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: bodewig 2004/09/20 02:18:33 Modified:project jakarta-jmeter.xml Log: remove broken project references Revision ChangesPath 1.106 +12 -10gump/project/jakarta-jmeter.xml Index: jakarta-jmeter.xml === RCS file: /home/cvs/gump/project/jakarta-jmeter.xml,v retrieving revision 1.105 retrieving revision 1.106 diff -u -r1.105 -r1.106 --- jakarta-jmeter.xml10 Sep 2004 14:01:01 - 1.105 +++ jakarta-jmeter.xml20 Sep 2004 09:18:32 - 1.106 @@ -85,9 +85,11 @@ depend project=commons-collections/ depend project=jtidy / -depend project=excalibur-compatibility / depend project=excalibur-logger / +!-- gone, no idea what to replace them with +depend project=excalibur-compatibility / depend project=excalibur-i18n / +-- Perhaps there needs to be an archive version of such items in Gump. These are the official released made by the Avalon project. http://www.apache.org/dist/avalon/excalibur-i18n/jars/ http://www.apache.org/dist/avalon/excalibur-compatibility/jars/ Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-jmeter.xml
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 12:57 To: Gump code and data Subject: Re: cvs commit: gump/project jakarta-jmeter.xml On Monday 20 September 2004 18:48, sebb wrote: +!-- gone, no idea what to replace them with +depend project=excalibur-compatibility / depend project=excalibur-i18n / Perhaps there needs to be an archive version of such items in Gump. By the way, I think I saw something about using an i18n package at CodeHaus or some other similar external source. There is also the following (maintained) version of i18n. http://www.apache.org/dist/avalon/avalon-util/jars/ You just need to switch package names to: org.apache.avalon.util.i18n Steve. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-jmeter.xml
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 13:10 To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-jmeter.xml On Mon, 20 Sep 2004, sebb [EMAIL PROTECTED] wrote: On 20 Sep 2004 09:18:33 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: remove broken project references -depend project=excalibur-compatibility / depend project=excalibur-logger / +!-- gone, no idea what to replace them with +depend project=excalibur-compatibility / depend project=excalibur-i18n / +-- Perhaps there needs to be an archive version of such items in Gump. Probably. Are the latest excalibur releases from Avalon the ones to look at? I surely can't answer this, but you (as a client of those libs) should know. All of the avalon stuff is good with full endorsed releases. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
is gump dead ?
Current gump run seems to have been locked on entry 34 for the last 36 mins. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: is gump dead ?
-Original Message-
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
Sent: 20 September 2004 17:05
To: [EMAIL PROTECTED]
Subject: Re: is gump dead ?
Current gump run seems to have been locked on entry 34 for the last
36
mins.
Timeout is 60 minutes ('cos some builds/tests used to take that long).
That
said, it seems to be chewing on project 38 (it only updates the page
every
5
projects) 'avalon-site'. Maybe the box is swamped w/ some JDK 1.5/mono
stuff. I can't quite tell. I'll keep looking.
As long time Avalon committer I have no idea what avalon-site does and
strongly suspect that project definition can be killed (it certainly is
not maintained) - but I'll check into the detail and provide some
qualified feedback on that point (avalon's site build is actually
executed under a separate gump project definition maintained via a Magic
build).
Cheers, Steve.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: is gump dead ?
-Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] As long time Avalon committer I have no idea what avalon-site does and strongly suspect that project definition can be killed (it certainly is not maintained) - but I'll check into the detail and provide some qualified feedback on that point (avalon's site build is actually executed under a separate gump project definition maintained via a Magic build). Took a look at avalon-site ... this is ancient cruft and is now not longer. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 11:35 To: 'Gump code and data' Cc: [EMAIL PROTECTED] Subject: RE: excalibur-thread-impl failure in Gump -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 11:11 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: excalibur-thread-impl failure in Gump Hi, for some reason Maven doesn't seem to pick up JUnit, even though it is listed in the project.properties generated by Gump - and it doesn't complain about it missing either. Since I know next to nothing about Maven, the following observation may be completely insignificant, but ... In project.xml all dependencies have groupId and artefactId elements while the one for JUnit only has an id element (which the others have not). Have already updated the project.xml to reflect the same convention. What's interesting is that the project build locally without any issues. Anyway - we'll see if this is the problem or not shortly! Nope ... excalibur-thread-impl still failing. Time for a maven expert? Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: cocoon-2.1/cocoon failed
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: 15 September 2004 06:44 To: Apache Gump Cc: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: cocoon-2.1/cocoon failed Gump wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 1 projects. Project State : 'Failed' The following are affected: - cocoon : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [cocoon.jar] identifier set to jar basename: [cocoon] -DEBUG- Jar [cocoon-tests.jar] identifier set to jar basename: [cocoon- tests] -DEBUG- Jar [cocoon-deprecated.jar] identifier set to jar basename: [cocoon-deprecated] -ERROR- No such project [avalon-framework] for property. -ERROR- Cannot resolve jar/jarpath of *unknown* [avalon-framework] -ERROR- Unhandled Property: avalonapi.jar on: Ant on Project:cocoon -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: excalibur-compatibility unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-instrument unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-instrument-manager unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-sourceresolve unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-xmlutil unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-store unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-pool unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-component unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-logger unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-event unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-i18n unknown to *this* workspace -ERROR- Bad Dependency. Project: excalibur-testcase unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository Gumpers, any suggestions? Niclas has been updating the Gump Excalibur descriptors to bring this content back to a 'live' state. In the process he moved the previously disabled descriptors to new file with real content but the last run didn't have the new file in the Gump workspace definition. In theory (if I'm reading the commits correctly) the majority of the above will come back in the next run - however, there are some Excalibur projects which are no longer maintained (e.g. the compatibility package) which will require additional updates to Gump before all downstream issues are cleared. Steve. -- Stefano, pretty excited to finally see cocoon coming up again in the gump radar after a year ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
what's happening with notification?
Gump notification has been off for a while now and I'm starting to see failures on dependent projects that are not being fixed. Can we bring notification back or is there a deeper problem? Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
gump is supplying invalid property values
Looking at the latest gump run results I'm seeing that even if dependent build are not successful, gump is still attempting to build dependees and in the process assigning and passing invalid property values to the build target. For example - avalon-http-impl dependency jasper-runtime is not available, however gump is supplying jasper-runtime outputs as a property value and continuing with the build. http://brutus.apache.org/gump/public/avalon-trunk/avalon-http-impl/gump_ work/build_avalon-trunk_avalon-http-impl.html BUILD FAILED /usr/local/gump/public/workspace/avalon-trunk/central/system/build/stand ard.xml:11: Gump source resource override for resource [artifact:jar:tomcat/jasper-runtime#27082004] references a non-existant path [/usr/local/gump/public/workspace/jakarta-tomcat-5/dist/common/lib/jaspe r-runtime.jar]. Seems to me that Gump should *not* attempt to execute a project unless it can assure that the values it is assigning are in fact valid. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetty (JAAS and Plus)
Thanks Adam .. I'll take it from here. Cheers, Steve. -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: 26 August 2004 16:52 To: Gump General Subject: Jetty (JAAS and Plus) The packaged-jetty package on Gupm has been updated to 5.0RC2 (per request). I've added a qiuck packaged-jetty-all that has the following. Maybe this will work for log4j-test until I get jetty working. It also has jaas. jar name=lib/org.mortbay.jetty.jar/ jar name=lib/org.mortbay.jetty.plus.jar/ jar name=lib/org.mortbay.jetty.jaas.jar/ I have no more time, but the jars in there (should you wish to edit the packkage descriptor are): [EMAIL PROTECTED]:/usr/local/gump/packages/jetty-5.0.RC2$ ls extra/lib/ org.jboss.jetty.jar org.mortbay.jetty-jdk1.2.jar org.mortbay.ftp.jar org.mortbay.jetty.plus.jar org.mortbay.j2ee.jar org.mortbay.jmx-jdk1.2.jar org.mortbay.jaas.jar org.mortbay.loadbalancer.ja Gotta run... regards Adam -- Have you Gump'ed your code today? http://gump.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more on gump
Thanks to some help from Adam we we're getting real close now: Successful builds: 128 Build failures: 1 Prerequisite failures:8 The single build failure is related to the avalon-http-examples project due to a FileNotFoundException: avalon/http/blocks/avalon-http-servlet-26082004.block. Looking at the avalon-http-servlet build I can see that the servlet block has been created and installed - so I'm a little confused (again) but I'll dig around and see what comes up. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: rev 36821 - in gump/live
Gump is currently on 496 of 677. Finger's crossed.. Adam: The Gump runs seem to be completing now following your patches this morning. However there does seem to be a problem related to notification. The Avalon dev list is kind of flooded with repeated notification messages (mostly notifying success which is nice - but it's a flood all the same). Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request for jetty updates
Any chance of getting Gump updated to include: http://sourceforge.net/project/showfiles.php?group_id=7322package_id=68 203release_id=229559 Could we update Gump's 'packaged-jetty' content to this version, and secondly, can we please also include the org.mortbay.jaas.jar file as this is needed to build the Avalon http facility. This file is included in the download distribution under the /extra/lib directory. With the org.mortbay.jaas.jar in place we will be able to close the following build failure: http://brutus.apache.org/gump/public/avalon-trunk/avalon-http-impl/index .html Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more on gump
-Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 24 August 2004 05:08 To: 'Avalon Developers List' Cc: [EMAIL PROTECTED] Subject: RE: more on gump Current status of the Avalon Gump builds: Successful builds: 98 Build failures: 9 Prerequisite failures: 30 Thinks are getting closer to total success: Successful builds: 116 Build failures: 3 Prerequisite failures: 18 Of the three failures, one is related to the site generation which for the moment I simply have not figured out. The second is an issue related to the version of JMX (using MX4J libs) - Gump is linked to version 2 and Avalon JMX facilities are linked to 1.1 (Cameron is digging into this as we speak - i.e. expect synchronization shortly). The third item is the http implementation which requires the addition of the org.mortbay.jaas.jar file by the Gump team (Gump guys .. we need your help on this one). Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more on gump
-Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 26 August 2004 07:10 To: 'Avalon Developers List' Cc: [EMAIL PROTECTED] Subject: RE: more on gump -Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 24 August 2004 05:08 To: 'Avalon Developers List' Cc: [EMAIL PROTECTED] Subject: RE: more on gump Current status of the Avalon Gump builds: Successful builds: 98 Build failures: 9 Prerequisite failures: 30 Thinks are getting closer to total success: Successful builds: 116 Build failures: 3 Prerequisite failures: 18 Of the three failures, one is related to the site generation which for the moment I simply have not figured out. The second is an issue related to the version of JMX (using MX4J libs) - Gump is linked to version 2 and Avalon JMX facilities are linked to 1.1 (Cameron is digging into this as we speak - i.e. expect synchronization shortly). Cameron has just committed updates to jmx that should in principal resolve the current jmx/mx4j builds (and resolve at least 2 of out our 18 prerequisite failures). We should have confirmation from Gump in around two or three hours. Cheers, Stephen. The third item is the http implementation which requires the addition of the org.mortbay.jaas.jar file by the Gump team (Gump guys .. we need your help on this one). Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [http] sorting deps
-Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] This of any help? http://neukadye.chalko.com/archive/13.html Thanks - yes, didn't think about that! Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: rev 36821 - in gump/live
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 24 August 2004 21:26 To: [EMAIL PROTECTED] Subject: svn commit: rev 36821 - in gump/live: . bin cron python python/gump python/gump/admin python/gump/build python/gump/core python/gump/document/text python/gump/document/xdocs python/gump/integration python/gump/java python/gump/model python/gump/process py Adam: It seems like this commit may have broken something somewhere. The last Gump run blocked somewhere after entry 269 in the build cycle following which Gump reset itself and started a fresh run. As I'm typing we are back at 269 again and Gump has failed to generate any new info for the past 18 minutes so I figure its dead. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: rev 36821 - in gump/live
It seems like this commit may have broken something somewhere. Thanks for the heads-up, I'll look. Gump is currently on its third cycle - spinning on whatever is following 269. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: rev 36821 - in gump/live
-Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: 25 August 2004 06:41 To: Gump code and data Subject: RE: svn commit: rev 36821 - in gump/live Gump is currently on its third cycle - spinning on whatever is following 269. It was a project that had previously built, that failed, that Gump was attempting to locate artifacts for (in it's repository). Gump is currently on 496 of 677. Finger's crossed.. This is more exciting than CNN! Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
request for jetty updates
Currently the gump 'packaged-jetty' project contains Jetty-5.0.beta2 from 11-02-04. The latest build from Mortbay is jetty-5.0.RC2. http://sourceforge.net/project/showfiles.php?group_id=7322package_id=68 203 Could we update gump's 'packaged-jetty' content to this version, and secondly, can we please also include the org.mortbay.jaas.jar file as this is needed to build the Avalon http facility. This file is included in the download distribution under the /extra/lib directory. Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[http] sorting deps
The gump build for the http impl has a few problems: http://brutus.apache.org/gump/public/avalon-trunk/avalon-http-impl/index .html 1. Error No such project [org.mortbay.jaas] for property. Have already sent an email to the gump list to request The addition of org.mortbay.jaas jar file. 2. Error No such project [jsp-api] for property. This corresponds to the resource declaration: resource info grouptomcat/group namejsp-api/name version5.0.18/version typejar/type /info /resource Need to figure out which of the tomcat related gump projects We should be linking to. 3. Error No such project [jasper-runtime] for property. This corresponds to the resource declaration: resource info grouptomcat/group namejasper-runtime/name version5.0.25/version typejar/type /info /resource Again - need to identity the appropriate gump project. 4. Error No such project [jasper-compiler] for property. This corresponds to the resource declaration: resource info grouptomcat/group namejasper-compiler/name version5.0.25/version typejar/type /info /resource Again - need to identity the appropriate gump project. Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
what's happend to gump?
Gump (in principal based on past behavior) should have kicked-off 1h 27m ago. Is there a problem? Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
more on gump
I have just replaced all of the avalon/trunk gump project descriptors so that they now point to svn content as opposed to cvs. I am expecting some errors related to project id to gump id names mappings and will sort these out as they come up. All of the new gump project definitions (138 in total) are using magic to build the respective targets based on generated definitions - so if something goes wrong we should be updating information in either magic's gump task or more probably gump alias declarations in our local index files. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more on gump -- cocoon def
Could someone please update the cocoon-2.1/cocoon gump descriptor and replace the following line: depend project=avalon-framework ids=impl api / with: depend project=avalon-framework-api/ depend project=avalon-framework-legacy/ depend project=avalon-framework-impl/ Cheers, Steve. -Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 22 August 2004 17:29 To: Avalon Developers List Cc: [EMAIL PROTECTED] Subject: more on gump I have just replaced all of the avalon/trunk gump project descriptors so that they now point to svn content as opposed to cvs. I am expecting some errors related to project id to gump id names mappings and will sort these out as they come up. All of the new gump project definitions (138 in total) are using magic to build the respective targets based on generated definitions - so if something goes wrong we should be updating information in either magic's gump task or more probably gump alias declarations in our local index files. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more on gump
Ummm - I'm a little lost - ... all Avalon projects are failing with the assertion that build.xml does not exist. That's a little odd because it exists in svn and the ant basedirs are all correct. Can anyone check if there were any problems with gump's svn checkout of the Avalon-svn repository content? Steve. -Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 22 August 2004 17:29 To: Avalon Developers List Cc: [EMAIL PROTECTED] Subject: more on gump I have just replaced all of the avalon/trunk gump project descriptors so that they now point to svn content as opposed to cvs. I am expecting some errors related to project id to gump id names mappings and will sort these out as they come up. All of the new gump project definitions (138 in total) are using magic to build the respective targets based on generated definitions - so if something goes wrong we should be updating information in either magic's gump task or more probably gump alias declarations in our local index files. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more on gump
-Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 22 August 2004 21:05 To: 'Gump code and data' Subject: RE: more on gump Ummm - I'm a little lost - ... all Avalon projects are failing with the assertion that build.xml does not exist. That's a little odd because it exists in svn and the ant basedirs are all correct. Can anyone check if there were any problems with gump's svn checkout of the Avalon-svn repository content? p.s. on this page: http://brutus.apache.org/gump/public/avalon/index.html There is this note: Error *** Failed to update from source control. Stale contents *** And this following link: http://brutus.apache.org/gump/public/avalon/gump_work/update_avalon.html shows an output message of: svn: 'avalon' is not a working copy Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
summary page bug
On the page: http://brutus.apache.org/gump/public/buildLog.html There is the following message: This Gump run is complete. It started at Sat, 21 Aug 2004 17:00:35 (UTC) and ended at Sat, 21 Aug 2004 17:00:35 (UTC). Perhaps the completion times may be incorrectly referencing the start time? Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: avalon-tools/avalon-tools-magic failed
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 27, 2004 18:15 To: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: avalon-tools/avalon-tools-magic failed On Sun, 25 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: More thinking - I'm starting to suspect that this may be a gump issue. The error is question is related to the *last* system property supplied by gump to magic. I see it, I see it!!! OK, enough enthusiasm. LOL :-) You set build.sysclasspath to an empty string and this makes Gumpy omit the equals sign on the command line (is this a bug?). This in turn makes Ant eat - Dgump.resource.junit=/usr/local/gump/public/workspace/dist/junit/junit.j ar as the value for the build.sysclasspath property. Yep - makes sense. I'm working though getting a bunch of things installed on a new machine and don't have cvs up yet - so hint, hint, feel free to make the change. Cheers, Steve. Solution: Use something else but for build.sysclasspath's value. I recommend append which is more or less identical to what Ant would do if the property wasn't there at all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: avalon-tools/avalon-tools-magic failed
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 10:36 To: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: avalon-tools/avalon-tools-magic failed On Sun, 25 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: More thinking - I'm starting to suspect that this may be a gump issue. The error is question is related to the *last* system property supplied by gump to magic. All other properties prior to the last property were handled correctly. Does this ring any bells with anyone? Not really. Can you insert some echos right in front of the problematic line so we can see whether Ant sees the correct value for the property? Will do. I'll can detect is we are running in a Gump context so I'll use this to trip a listing of system properties and project properties as well. That should give us a clue as to where the problem is. Steve. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP@brutus]: avalon-tools/avalon-tools-magic failed
I'm guessing that this is a result of the recent changes to handle
temporary files as part of the Resource.get(...) operation.
Looking at the build log - starting with the command line we can see
that the gump.resource.junit property is being supplied by Gump as a
system property:
-Dgump.resource.junit=/usr/local/gump/public/workspace/dist/junit/junit.
jar
However, when we look down further in the build when Magic is doing its
Gump sanity check (under InitializeTask.java), Magic is complaining that
there is no 'gump.resource.junit' property.
init:
[x:init] Executing gump sanity check.
...
Warning - missing property [gump.resource.junit].
As a consequence, magic's cache is not being updated and the end result
is that the classpath that magic is creating for the compilation run
does not include the junit jar file.
The actual code that is doing the lookup of the system property is here:
String gumpKey = gump.resource. + resource.getKey();
//
// the value of 'gumpKey' is not set to ' gump.resource.junit'
//
String path = project.getProperty( gumpKey );
if( null != path )
{
updateCache( project, resource, path );
}
else
{
final String warning =
Warning - missing property [ + gumpKey + ].;
project.log( warning );
}
Now the only way that we would get the log message is if the
project.getProperty( gumpKey ) returns a null value - so I'm wondering
if something has changed in Ant.
Anyone have any ideas on this?
Steve.
-Original Message-
From: Magic Integration [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 25, 2004 08:25
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: avalon-tools/avalon-tools-magic failed
Importance: High
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact folk at [EMAIL PROTECTED]
Project avalon-tools-magic has an issue affecting its community
integration.
This issue affects 1 projects.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- avalon-tools-magic : Avalon Tools.
Full details are available at:
http://brutus.apache.org/gump/public/avalon-tools/avalon-tools-
magic/index.html
That said, some snippets follow:
The following annotations were provided:
-DEBUG- Sole jar [avalon-tools-magic-20040725.jar] identifier set to
project name
-DEBUG- Dependency on ant exists, no need to add for property
gump.resource.ant-junit.
-DEBUG- Dependency on ant exists, no need to add for property
gump.resource.ant-nodeps.
-DEBUG- Dependency on magic exists, no need to add for property
magic.home.
-INFO- Enable verbose output, due to 1 previous error(s).
-INFO- Failed with reason build failed
-INFO- Enable debug output, due to build failure.
The following work was performed:
http://brutus.apache.org/gump/public/avalon-tools/avalon-tools-
magic/gump_work/build_avalon-tools_avalon-tools-magic.html
Work Name: build_avalon-tools_avalon-tools-magic (Type: Build)
State: Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main
-
verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -
Dgump.resource.ant-
nodeps=/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar -
Dgump.resource.ant=/usr/local/gump/public/workspace/ant/dist/lib/ant.jar
-
Dgump.signature=20040725 -
Dmagic.home=/usr/local/gump/public/workspace/avalon-
tools/tools/magic/target/20040725 -Dgump.resource.ant-
junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar -
Dbuild.sysclasspath -
Dgump.resource.junit=/usr/local/gump/public/workspace/dist/junit/junit.j
ar
[Working Directory: /usr/local/gump/public/workspace/avalon-
tools/tools/magic]
CLASSPATH :
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/
av
alon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-
20040725.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/
lo
cal/gump/public/workspace/ant/dist/lib/ant-
stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar
--
---
BUILD FAILED
/usr/local/gump/public/workspace/avalon-
tools/central/system/build/standard.xml:23:
java.io.FileNotFoundException:
junit/jars/junit-20040725.jar
at org.apache.avalon.tools.model.Resource.get(Unknown Source)
at org.apache.avalon.tools.model.Resource.getArtifact(Unknown
Source)
at org.apache.avalon.tools.model.Resource.getArtifact(Unknown
RE: Here's a wild idea
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Thursday, July 22, 2004 12:37 To: Gump code and data Subject: Re: Here's a wild idea Glen Stampoultzis wrote: I was thinking wouldn't it be great to be able to see your projects gump build status straight from your project page. As it is gump spits out html with the build status of each project. What if it also spit out a javascript file that could be included in a projects home page that showed a little green or red ball showing the projects build state? That would be very nice indeed. do we have a wish-list? Just create a gump entry with a type 'wish': http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10457 Cheers, Steve. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki defacing
Adam R. B. Jack wrote: Do we wish to require users to register w/ the Wiki before they deface, err ... I mean contribute? Seems other projects are doing this. Seeing the same style of contribution over on Avalon (yesterday and again today). I would go with requiring registration. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build.sysclasspath management
Stefan Bodewig wrote: On Fri, 09 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Ant provides support for a system property build.sysclasspath which if set to none nitpick, only - not none. ensures that the bootstrap classpath is used throughout the execution of an ant session. Clearly - the assumptions behind the project == classpath notion become an issue when dealing with a build system which provides artifact resolution. In this scenario the build system needs information about artifact locations. In effect it's my opinion that gump should be delegating the responsibility to the builder for classpath and classloader management. I'm not sure I follow you here. We'd also want to use the very latest of every plugin, so Gumo needs to build the plugins as well and as a consequence will know its location. Placing them all on a single classloader may not be nice, but will ensure the plugins can deal with the same set of libraries. I agree with you objective (and magic is supporting this). The issue comes down to the conflict of interest between the two following scenarios: (a) I stack the initial classloader with everything that is needed (plugins, lib, directories, etc.) in which case the system should work (b) I simulate the real runtime scenario by building classloader hierarchies and through integration testing validate not only the build integrity but also the integrity of runtime descriptors An example of the difference is that in scenario (b) I'm going to discover that a particular class has not been included in a deployment classloader because it was not referenced as a runtime dependency in whatever it is that is describing the deployment solution. But to discover this issue I need to be able to create the classloaders that simulate the deployment scenario. IMO - the real solution is to enable ant with repository based logic and instead of inhibiting ant classloader logic - focus instead on liberating ant such that classloaders can be created providing the jar references are uris to repository artifacts. Then link the repository handling within ant runtime with gump and your back in control. Add to this an ant -offline switch (backed with updates to ant's get task) and things are looking good. b) add a MagicBuilder which disables build.sysclasspath I prefer that. In the Maven context, build.sysclasspath is ignored as well and we rely on jar overrides to work. The biggest problems I see: * how to deal with plugins properly. Can I trust the plugins will do what I want? With custom tasks in Ant and the build sysclasspath setting I can ensure that no plugin ever gets a chance to use classes from any source that Gump doesn't control. A simple example was included in my earlier email. Magic makes a distinction between a plugin and a something like a ant taskdef. A plugin to Magic is a project with build, test and runtime dependencies that exports a definition of itself. The definition includes the declaration of the classloader in terms of artifact uris. A project that uses a plugin simply declares the plugin dependency and magic takes care of the construction of the classloader for the plugin by resolving artifact uris relative to its local repository. Its here that we intercept things and map the artifact to a gump generated jar file. * how do you deal with Magic build files that use snippets of plain Ant? No special handling. Just as maven users use jelly to supplement a build, magic uses ant. The main Magic benefit is the provision of a centralized version and dependency management framework within which there is more value to play within the rules than outside. Outside of the these two I have the feeling I'm getting into workarounds (things like overloading the property is not nice - and forking another java process seems like cludge). If you overload the property, you should use one of the supported values. last or even none seems to be what you want for Magic. I haven't located docs on this. Is there a url you can point me to? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build.sysclasspath management
Stephen McConnell wrote: If you overload the property, you should use one of the supported values. last or even none seems to be what you want for Magic. I haven't located docs on this. Is there a url you can point me to? Don't worry - I've found it. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build.sysclasspath management
Stephen McConnell wrote: Stephen McConnell wrote: If you overload the property, you should use one of the supported values. last or even none seems to be what you want for Magic. I haven't located docs on this. Is there a url you can point me to? Don't worry - I've found it. Actually - no. The ant docs (1.6.1) say Property| Values | build.sysclasspath | only, something else Is this an Ant 1.6.2 thing? Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Leo Simons wrote: Stefan Bodewig wrote: I tend to agree with most of what has been said in this thread so far. thought I'd chime in: what he said. I really want to learn python well enough to write more than simple shell scripts using it. I said that over a year ago. Here I am, still saying it. One has to wonder whether I'll still be saying it next year. In the meantime, I'm a gump junkie without the Power to Contribute. Would you like to take care of the MagicBuilder? Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heresy - a controversial or unorthodox opinion or doctrine
Adam R. B. Jack wrote: Well - maybe its not that bad ... but all the same - this is an early warning .. I'm thinking about making a copy of AntBuilder (gump/python/gump/builder/ant.py), renaming it to magic.py, making a couple of small but significant changes, sorting out what actually does the builder selection, updating it submitting a patch. And all of this with zero Python experience and no compiler. Nothing slightly heretic (unless you are talking about Ant religion not Gump religion). Magic is like Ant (based upon, I believe) but different, so you approach seems totally correct given today's Gump codebase. The only (small but significant) extras I can think off would be: 1) Add a magic element to the project metadata (like ant, like maven) and update gump/model/builder.py to have such a Magic class (based upon Builder), just like the Ant class. [Feel free to update xdocs for site documentation.] 2) Modify gump/model/project.py to create the self.magic member data, and hasMagic(), getMagic() beaner methods, and clone that small section in complete() (that constructs objects from XML) that constructs a Magic class for a magic DOM element. 3) Update gump/build/builder to have a self.magic and then if project.hasMagic() to call your gump/builder/magic.py. If this sounds like heresy then please yell out now because as I see it this is the next step in moving the magic gump equation forward. If anyone wants to shepherd me though the process I'll be very grateful. We have ant.py and maven.py, so when not magic.py? Get a few more and we can refactor these steps about to allow (1) auto-discovered/auto-loaded plugins based upon the element name (2) element name to model/builder auto mappings. A few more and we'll have enough experience for a reasonable plug-in strategy. (For example, I think the CLASSPATH generation could move into the builder, so we could have similar but non-Java such stuff). BTW: What are the differences between Ant and Magic as far as Gump is concerned? A MagicBuilder would set specific system properties (gump date, probably a verbose flag, exclusion of build.sysclasspath) and modify the classpath to be ant, junit and magic. Secondly, the semantics of gump depend would be interpreted as a dependnoclasspath. But in digging around I think this is step one of a two step process. In effect a MagicBuilder really only reduces the number of lines of gump information that needs to be read in - the real kicker will come from a magic module and the interaction between a magic module and a magic builder - but this is pure thinking ahead and I'm still dealing with the fact that someone has removed all of the braces from the source code! :-) Cheers, Steve. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
Stefan Bodewig wrote: On Fri, 09 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Just a quick note - I'm putting back in the build.sysclasspath override because I need to validate that this is the only remaining issue. It isn't 8-( The build tries to copy a jar that isn't there: BUILD FAILED /javastuff/gump/avalon-tools/tools/magic/build.xml:30: Warning: Could not find file /javastuff/gump/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic.jar to copy. I know what this is - its not magic - its supplementary stuff I've added to make my life easier. I'll have this fixed in just a moment. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
Stephen McConnell wrote: Stefan Bodewig wrote: On Fri, 09 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Just a quick note - I'm putting back in the build.sysclasspath override because I need to validate that this is the only remaining issue. It isn't 8-( The build tries to copy a jar that isn't there: BUILD FAILED /javastuff/gump/avalon-tools/tools/magic/build.xml:30: Warning: Could not find file /javastuff/gump/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic.jar to copy. I know what this is - its not magic - its supplementary stuff I've added to make my life easier. I'll have this fixed in just a moment. ... and fixed. Should have that other email done in a tick. Cheers, Steve. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build.sysclasspath management
I'm learning all sorts of things about how gump works! Please keep in mind that this message is based on a bunch of assumptions and limited experience - but I think I'm correct (so please feel free to correct any mistakes). If your in a hurry - skip to the end. Anyway - here goes... Gump and Ant basically collaborate together though the subversion of classloader creation. First of all - a gump project definition is for all intensive purposes a descriptor enabling the establishment of a single classpath. Ant provides support for a system property build.sysclasspath which if set to none ensures that the bootstrap classpath is used throughout the execution of an ant session. Gump, using the project definition creates a single project classpath, and using the build.sysclasspath property takes effective control over the classloaders created with ant - enabling community wide normalization of classpath constructs. This approach is quite effective when dealing with simple ant build procedures (compile, test, jar, javadoc, etc.) as it enables the reuse of the classic build definition build.xml within a continuous integration context. In contrast - Magic maintains an index of project definitions. Each definition contains information about compilation, build, test and runtime dependencies. Magic uses this information together with property values supplied by gump to construct appropriate classloaders for the respective build phases. In the case of a build that requires a plugin, Magic creates a classloader for the plugin on the fly. Magic also makes extensive use of meta-information for build and runtime processes (generating and consuming multiple definitions in a single project build). Currently the Magic based build of Magic is failing due to the gump's subversion of control over classpath management. Specifically - the magic generated classpath for unit testing is being ignored by ant (due to the build.sysclasspath property setting) resulting in a inconsistent classpath under the junit task. While this particular problem can be solved with things like gump work directives - it does not address the underlying problem of classloader management. In effect the magic build will fail on the first project requesting a plugin. Clearly - the assumptions behind the project == classpath notion become an issue when dealing with a build system which provides artifact resolution. In this scenario the build system needs information about artifact locations. In effect it's my opinion that gump should be delegating the responsibility to the builder for classpath and classloader management. This leads me to the question of how to properly handle the disabling of the gump declaration of build.sysclasspath. As things stand this is declared within the gump workspace. It seems to me that modifying this is not a good idea as it would probably break gump on all non-magic builds. Instead there appears to be a least a couple of options: a) enable the ability to disable build.sysclasspath on the AntBuilder or b) add a MagicBuilder which disables build.sysclasspath Outside of the these two I have the feeling I'm getting into workarounds (things like overloading the property is not nice - and forking another java process seems like cludge). OK - thoughts? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
Adam R. B. Jack wrote: 3h 23m. That's an improvement! :-) Daft, but I've not been paying attention (too painful to look) :-) -- what was it before? The cycle time between updates of the web site was around 9 hours - gump was reporting about 5 hours for the run (so we are already seeing a big improvement on that aspect). In addition there is that mystery 4 hours between the end of the run and the appearance off documentation. Still, it can do far far better. Multi-threading the CVS/SVN ought reduce the latency. The main problem (for no clear reason I can gather) still seems to be generating documentation. Just an observation - that way things are using the current setup is for me better. Ok the docs are not a nice but what I can see immediately is the following: (a) a message saying gump is running and it started at ... (b) result as they unfold which gives me more time to hit the issue (e.g. I figure I've fixed james during the last run because I was able to access the info before the run had completed) Things I wasn't too impressed with was the dirty big red banner complaining about my subversion of build.sysclasspath which kind of made me cringe. :-) Ever tried a targeted run? Nope - never. I'll leave that sort of thing to Niclas! If one runs to (say) depot or something like this (a trimmed stack), this thing flies. It is something that clogs up over time I can't track it down (ok, haven't yet). Watching the interactive progress you get a feel for this as well - gump kicks off and rips though the early entries but things get progressively slower. But the end of the run she's not showing the same degree enthusiasm! I sometimes wonder if it is the Python implementation, not Gumpy per se. Something to do with the number of objects in memory. Sooner or later I'll find it. :-) Steve. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reference=home
Just an observation ... the following statement should (according to the gump spec) assign the home directory of the magic project to the property magic.home. depend name=magic.home reference=home inherit=runtime project=magic runtime=true/ However - the value assigned by gump is the jar file. Seems like a bug in the antdepend handling code - in which case I'll post a JIRA issue. Can someone confirm? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dep inheritance ...
Stefan Bodewig wrote: On Wed, 07 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: depend name=magic.home reference=home inherit=runtime project=magic/ Which according to me should be provided us with a few more entries in the classpath. I guess I'm missing something. //ant/depend doesn't support the inherit attribute at all. In order to achieve what you want, you need to use //ant/property plus a second depend nested into project. Which is, what you've already done AFAICS. Yep - keeping my fingers crossed for the next round of results. :-) -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
missing 4 hours
The last gump run (which has come on-line about 30 mins ago) Start Date/Time (UTC) Thu, 08 Jul 2004 07:00:49 (UTC) End Date/Time (UTC) Thu, 08 Jul 2004 13:26:41 (UTC) What is happening between 13:26 and 17:15 (about 4 hours). There appears to be a really big delay between the end of a gump run and the publication of results. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing 4 hours
Adam R. B. Jack wrote: After tonight I'll be done w/ my EMT refresher will be able to commit to fixing what breaks. I am tempted to perform the merge, but turn off notification (which might send duplicates for some odd reason) and see what transpires. My opinion - go for it and lets see what happens. Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Adam R. B. Jack wrote: I think we need to enable plug-ins (the easiest way for communities to open up to new developers) +1 -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Adam R. B. Jack wrote:
Basically, I think Python Gump was the right thing to do 'cos it breathed
life into a somewhat mundane/infrastructural task. I do think it has become
a barrier to entry for many, which I find disturbing. As such, I'd not fight
against folks wanting to re-write in Java ('cos that is clearly quite
doable).
For what its worth - yes - Python is a barrier to entry for me
personally but I kind of like that. It's my perfect excuse for not
submitting patches and provides me with a good separation of me as tool
user versus developer (something I appreciate given the amount of stuff
I'm already committed to).
On the other hand - a java variant of Gump would be interesting in that
I could envisage closer integration between things like magic and gump
itself. It would also be a lot of fun to play around with gump plugins
- things that lavage the big interconnected picture - but I'm sure this
is possible with Python gump also.
0.02
Cheers, Steve.
--
|---|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ummm... help needed
Sebastian Bazley wrote: I don't have access to brutus, but perhaps you could use the Ant concat task to display the contents of the file. See for example JMeter, which uses it in its build.xml gump-test target: Works like a charm - I've added this into magic unit test task so we get a report listed automatically if a unit test fails when running under gump. Thanks!! -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
brutus may be having a problem
http://brutus.apache.org:8080/gump/modules.html Message: null Description: No details available. Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet Request URI modules.html cause /home/gump/jakarta-tomcat-5.0.24/webapps/gump/content/xdocs/modules.xml (No such file or directory) request-uri /gump/modules.html Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: james-server/james-server failed
Gump Build Robot wrote: snip -INFO- Failed with reason build failed snip CLASSPATH : snip /usr/local/gump/packages/phoenix-client.jar: /snip - at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:95) at org.apache.tools.ant.Task.perform(Task.java:366) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:133) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:91) at org.apache.tools.ant.Main.runBuild(Main.java:658) at org.apache.tools.ant.Main.startAnt(Main.java:188) at org.apache.tools.ant.Main.start(Main.java:151) at org.apache.tools.ant.Main.main(Main.java:241) Caused by: java.lang.ClassNotFoundException: org.apache.avalon.phoenix.tools.xdoclet.PhoenixXDoclet However - normally speaking the PhoenixXDoclet class is part of the phoenix-client jar file. Could someone please check if the jar file referenced by /usr/local/gump/packages/phoenix-client.jar actually contains org.apache.avalon.phoenix.tools.xdoclet.PhoenixXDoclet. Thanks, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
brutus on 8080
Just a note to let you know that I have not been able to connect with brutus for the last couple of days. Plain old http://brutus.apache.org appears to be working but the gump url does not. http://brutus.apache.org:8080/gump/modules.html Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus on 8080
Noel J. Bergman wrote: To: [EMAIL PROTECTED] Cc: Gump code and data FYI, you really want to reverse that. Brutus is a semi-dedicated server managed by GUMP. As for the specific ... I don't think that you want to ever use brutus.apache.org as the domain name. You may want to let the gump team know about this. I'm just following the urls provided the gump reports and published on the gump web site. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
[EMAIL PROTECTED] wrote: -depend project=junit/ -depend project=ant ids=ant junit nodeps/ +depend project=junit runtime=true/ +depend project=ant ids=ant junit nodeps runtime=true/ Stefan: The above dependencies are being generated automatically by magic's gump task. Can I assume that the junit, ant, ant-ant, ant-junit, and ant-nodeps definitions used by magic can be flagged as ignorable? .. i.e. I can update magic to simply not add dependencies that are flagged with ignore/. For example: resource info groupant/group nameant-nodeps/name version1.6.1/version typejar/type /info gump ignore/ /gump /resource Sound reasonable? Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: module centric output ...?
Good idea - I'll give this a shot! Steve. Leo Simons wrote: Stephen McConnell wrote: I have two projects that don't produce jars - instead they generate documentation into a common repository. For a gump run I can setup the repository relative to the module srcdir ... but I haven't figured out how to declare a non-home based resources via the gump project descriptor. how about http://gump.apache.org/metadata/builder.html#property you have one gump project that is the repository, then the other projects have a project/ referencing it... project name=my-repo home ../ blah ../ /project project name=non-code-component-A ant property name=repo.dir project=my-repo reference=home/ /ant /project project name=non-code-component-B ant property name=repo.dir project=my-repo reference=home/ /ant /project If you want my-repo to show up as a dependency on the project, I /think/ you need to also have a seperate depend tag: project name=my-repo home ../ blah ../ /project project name=non-code-component-A ant property name=repo.dir project=my-repo reference=home/ /ant depend project=my-repo/ /project project name=non-code-component-B ant property name=repo.dir project=my-repo reference=home/ /ant depend project=my-repo/ /project cheers, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sanity check
Hi again!
I've just committed some changes to avalon-tools.xml. Basically we now
have three projects defined:
* avalon-tools-magic-bootstrap
* avalon-tools-magic-home
* avalon-tools-magic
avalon-tools-magic-bootstrap
This should build the magic jar. It assumes the ant and junit will be
in the classpath. We can edit this definition as much as we want.
avalon-tools-magic-home
---
Uses the same buildfile as bootstrap to create and populate a directory
with doc generation themes and magic build template and sets the created
directory as the project home/. All generated project definitions
reference this project as a dependency (with inherit=runtime) and use
the home reference as the value assigned to ${magic.home}. This
definition is also changeable.
avalon-tools-magic
--
This is a generated gump project definition that is only included for
the purpose of testing the logic in the generation code. I.e. if there
are problems with this definition I'll need to update Magic's gump task.
The definition is a strait cut-and-past from this file:
http://www.apache.org/~mcconnell/temp/gump.xml
Everything is now committed so I guess there will be something
interesting to look at in the morning. In the meantime if anyone can
see any immediate issue I'd love to hear about them.
Cheers, Steve.
--
|---|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: sanity check
Stefan Bodewig wrote: On Mon, 05 Jul 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: you can't use depend when referencing avalon-tools-magic-home since it doesn't define any output. Simply use a plain property. ... and the attribute's name is reference, not resource. Thanks - have just fixed this in the gump task. Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sanity check
Stefan Bodewig wrote: On Mon, 05 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Everything is now committed so I guess there will be something interesting to look at in the morning. In the meantime if anyone can see any immediate issue I'd love to hear about them. Yep. you can't use depend when referencing avalon-tools-magic-home since it doesn't define any output. Simply use a plain property. Fixed. The depend for gump.resource.ant is lacking an id attribute in avalon-tools-magic. Have updated magic's index. Here is the revised generated output for magic building magic: project name=avalon-tools-magic license name=central/system/license/LICENSE.TXT/ ant basedir=tools/magic depend name=magic.home resource=home project=avalon-tools-magic-home inherit=runtime / property name=gump.signature value=@@DATE@@/ depend property=gump.resource.ant project=ant id=ant/ depend property=gump.resource.junit project=junit/ depend property=gump.resource.ant-junit project=ant id=junit/ depend property=gump.resource.ant-nodeps project=ant id=nodeps/ /ant home nested=tools/magic/target/deliverables/ jar name=jars/avalon-tools-magic-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] from=Magic Integration lt;[EMAIL PROTECTED]gt;/ /project Steve. I'll commit a fixed version shortly. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: avalon-tools/avalon-tools-magic-bootstrap failed
Ok - this I don't understand. The gump report says that bootstrap.xml is not found. Presumably there is something wrong with the ant definition in avalon-tools-magic-bootstrap and logically the same problem should occur on avalon-tools-magic-home. Steve. Gump Integration wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project avalon-tools-magic-bootstrap has an issue affecting its community integration. This issue affects 1 projects. Project State : 'Failed', Reason 'Build Failed' The following are affected: - avalon-tools-magic : Avalon Tools. Full details are available at: http://brutus.apache.org:8080/gump/avalon-tools/avalon-tools-magic-bootstrap/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [avalon-tools-magic-20040705.jar] identifier set to project name -INFO- Enable verbose output, due to 0 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. The following work was performed: http://brutus.apache.org:8080/gump/avalon-tools/avalon-tools-magic-bootstrap/gump_work/build_avalon-tools_avalon-tools-magic-bootstrap.html Work Name: build_avalon-tools_avalon-tools-magic-bootstrap (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 0 seconds Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dgump.signature=20040705 -f bootstrap.xml gump [Working Directory: /usr/local/gump/public/workspace/avalon-tools/tools/magic] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar- Apache Ant version 1.7alpha compiled on July 5 2004 Buildfile: bootstrap.xml does not exist! Build failed - To subscribe to this information via syndicated feeds: RSS: http://brutus.apache.org:8080/gump/avalon-tools/avalon-tools-magic-bootstrap/rss.xml Atom: http://brutus.apache.org:8080/gump/avalon-tools/avalon-tools-magic-bootstrap/atom.xml -- Produced by Gump 2.0.3-alpha-0002. [Run (20040705 00:00:14, brutus:brutus-public:20040705 00:00:14)] http://brutus.apache.org:8080/gump/index.html http://brutus.apache.org:8080/gump/options.html -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sanity check
Stefan Bodewig wrote: On Mon, 05 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: depend name=magic.home resource=home project=avalon-tools-magic-home inherit=runtime / has to be property, not depend. depend .../ is property reference=jarpath .../ (BTW, still resource should be reference). Umm - sorry about that! Here is the latest generation. project name=avalon-tools-magic license name=central/system/license/LICENSE.TXT/ ant basedir=tools/magic property name=magic.home reference=home project=avalon-tools-magic-home inherit=runtime / property name=gump.signature value=@@DATE@@/ depend property=gump.resource.ant project=ant id=ant/ depend property=gump.resource.junit project=junit/ depend property=gump.resource.ant-junit project=ant id=junit/ depend property=gump.resource.ant-nodeps project=ant id=nodeps/ /ant home nested=tools/magic/target/deliverables/ jar name=jars/avalon-tools-magic-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] from=Magic Integration lt;[EMAIL PROTECTED]gt;/ /project Steve. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sanity check
Stefan Bodewig wrote: On Mon, 05 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Here is the latest generation. looks good. OK - now for the big question. How do we integrate the generated avalon module definition into the gump process? Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sanity check
Stefan Bodewig wrote: On Mon, 05 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: How do we integrate the generated avalon module definition into the gump process? commit them to the Gump module as you've done for avalon-tools or commit them to the Avalon SVN repo and point the profile to them via http. The former allows non-Avalon people to tweak them if something goes wrong. Actually that's not desirable. If something goes wrong it's a issue related to the project definition that magic reads in (for example, a missing dependency). So the principal is .. update the magic definition and from that generate the gump module automatically. Running the following ant target on build.xml in avalon/truck generates the complete avalon module into a file name gump.xml: target name=gump x:home/ x:gump description=Magic Test Module public=true filename=gump.xml x:url href=http://avalon.apache.org// x:svn repository=avalon-svn dir=trunk/ x:license file=central/system/license/LICENSE.TXT/ /x:gump /target The idea scenario is that gump generates the module using the above after doing the checkout and before computing dependencies. Stephen. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem with brutus?
I'm getting Cannot find server or DNS Error from the gump link: http://brutus.apache.org:8080/gump/modules.html Is is just me? Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jar boot=true .../
I've now got in place magic generation of a single gump module for the avalon suite. To handle the bootstrapping side of things I've committed a gump module named avalon-tools which includes two projects: * avalon-tools-magic-bootstrap * avalon-tools-magic The avalon-tools-magic-bootstrap project definition includes the following line: jar type=boot name=jars/avalon-tools-magic-@@DATE@@.jar/ According to the documentation I need to setup a workspace before the boot attribute will be recognized. After looking at existing workspace definitions I figure I need a little help! Basically I want to ensure that the magic bootstrap jar file is included in ant's bootstrap classpath so ant properly handles the inclusion of magic as a antlib. Any help on setting this up will be greatly appreciated. Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multiple license references?
Is it possible to include two license references in a project descriptor .. e.g.: project name=widget license name=central/system/license/LICENSE.TXT/ license name=central/system/license/NOTICE.TXT/ .. /project Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
module centric output ...?
I have two projects that don't produce jars - instead they generate documentation into a common repository. For a gump run I can setup the repository relative to the module srcdir ... but I haven't figured out how to declare a non-home based resources via the gump project descriptor. Is this possible? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
running against the default target
Is it possible to tell gump to execute a project *without* supplying an explicit target. According to the docs if no target is defined in the ant .../ statement, the default target reverts to gump. What I would like is gump to execute ant without setting any target. Is this possible? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running against the default target
Adam R. B. Jack wrote: Is it possible to tell gump to execute a project *without* supplying an explicit target. According to the docs if no target is defined in the ant .../ statement, the default target reverts to gump. What I would like is gump to execute ant without setting any target. Is this possible? I ought not have made 'gump' the default, 'cos some projects don't want that. I backed that out recently. Didn't know I'd left it in the docs. No explicit target will mean no explicit target. Perfect! OK - re. docs - it currently states that if undefined then the default is gump. Cheers, Steve. p.s. here is the current status of a magic generated avalon module. http://www.apache.org/~mcconnell/temp/gump.xml SJM -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
id or ids
According to the docs a depend element can have an ids attribute. http://gump.apache.org/metadata/project.html#depend However, according to working examples (e.g. ant) the attribute appears to be id. Is it safe to assume that the docs can be updated to reference id and ids, or, is ids not valid? Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mapping magic group id to module
I'm playing around with the automatic generation of gump files and I'm dealing with the question how to handle the artifact group. My initial thinking is to generate a gump module per group and to populate the module with all project definitions that are (a) members the group AND (b) under the same source repository. There is one possible issue I see concerning gump association of a repository (cvs/svn) url to a module. In the usage I envisage, I would be generating something like 15-20 modules to cover the avalon suite. Each module would reference the same svn address. Is that an issue? Secondly, is it ok to have module names that contain the / character (e.g. avalon/composition)? Alternatively, what is the feasibility of extending module to support something like: module group name=avalon group name=composition project name=avalon-composition-api/ project name=avalon-composition-spi/ project name=avalon-composition-impl/ /group group/ ... /module Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Infrastructural stuff
Niclas Hedhman wrote: On Wednesday 23 June 2004 08:01, Stephen McConnell wrote: aka invisible! So how can we see if he is ok or not?? Send a probe! Leo, do you feel ignored by the public in large? Maybe you should look in the mirror... :o) :-) Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Infrastructural stuff
Leo Simons wrote: bad health. Hi Leo .. don't worry - your young - aka invisible! Get well soon! Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
Stefan Bodewig wrote: Hi all, two notes colored by my complete lack of Maven knowledge: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. I've adapted the descriptor to match the name we actually see just to get a successful build in Gump, but I'd prefer a way that allows us to get dated jar names via Maven. Probably we are just using the wrong property name or something like that. (2) The work entry inside the descriptor pointed to nowhere and there is no work entry for the generated test classes, still the test goal manages to load the freshly compiled test classes. This means that we are not getting the effect of build.sysclasspath=only in Maven builds. The jar overrides will catch the artifacts Gump knows about but Maven will happily let the goals (plugins, tasks, I don't know the correct terms) add more stuff to the classpath itself. For things like work directories for compiled classes this probably is good, but it may also lead to situations where Gump doesn't manage to substitute a jar from CVS with a freshly compiled one. Have been thinking about this issue for about a week and a bit. My conclusion is that the maven scenario is very similar to the magic scenario. To do real integration you need to be able do to something like set some special property so that magic or maven can take control over classloader definition in the knowledge that the build is a gump build (i.e. effects the repository cache that is used and the semantics concerning artifact handling). That means providing the current cache of artifact that have been generated so that magic or maven can map dependency reference to artifact in gumps cache. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump having problems?
Martin Cooper wrote: I've seen a couple of Gump nags today (from [EMAIL PROTECTED]) for projects that haven't changed, and used to build. One of them - for the Mailer taglib at jakarta-taglibs - had compilation errors because the JavaMail API wasn't available. Obviously, that's not a new dependency for a taglib that sends e-mail. ;-) And it's not an API that Gump would be building, either. Is there a problem with Gump that's causing these failures? Seeing the same problem with a bunch of gump build for unchanged avalon content. Steve. Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump compatible ant tasks and data types
Hi guys!
Sorry - but this is a longish email.
I'm starting to entertain some thoughts concerning the integration of
gump into a set of custom ant tasks and data types that I'm using to
build Avalon. Initially I was thinking about generating gump
descriptors - but I'm starting to think that this is the wrong direction
and that I should really be looking into task and datatype integration.
What I have in place is a small model that defines a project in terms of
dependencies and plug-ins. These description are sufficient to create
six different path constructs required to build respective target project.
These path constructs include:
1. main java compile classpath
2. unit test classpath
3. runtime api classpath
4. runtime spi classpath
5. runtime implementation classpath
6. composite runtime (4+5+6)
This information is constructed from a small project descriptor. The
following example shows the avalon activation package which is itself a
plugin within another package.
project basedir=../../runtime/activation/impl
info
groupavalon/activation/group
nameavalon-activation-impl/name
version2.0.0/version
/info
dependencies
include key=avalon-util-lifecycle/
include key=avalon-util-i18n/
include key=avalon-util-defaults/
include key=avalon-repository-spi/
include key=avalon-composition-spi/
include key=avalon-composition-impl
build=false test=true runtime=false/
include key=avalon-activation-api/
include key=avalon-test-components
build=false test=true runtime=false/
include key=avalon-test-playground
build=false test=true runtime=false/
/dependencies
/project
In the above example an include/ element holds a key to another
project or external resource definition. For example,
'avalon-util-lifecycle' is the key to another project that contains
dependencies on 'avalon-framework-api'. In turn, the framework api
definition references the logkit project. Logkit references a bunch of
external resources including log4j, servletapi, mailapi and jms.
From the point of view of gump integration - all of the tasks that are
used in this build solution use a common project model to establish any
of the six principal path definitions. For example, the following java
source from a typical task implementation demonstrates how an ant path
is constructed:
ResourceRef ref = new ResourceRef( getKey() );
Definition definition = getHome().getDefinition( ref );
Path classpath = definition.getPath( project, Policy.BUILD );
The Definition.getPath(..) method is basically building an ant path
based on the xml project descriptor shown above. It seems to me that it
would make a lot of sense for implementation of Definition.getPath(..)
to link into a small Gump API when resolving the path values.
The essence of the getPath( .. ) method is :
public Path getPath( Project project, int mode )
{
Path path = new Path( project );
ResourceRef[] refs =
getResourceRefs( mode, ResourceRef.ANY, true );
for( int i=0; irefs.length; i++ )
{
ResourceRef ref = refs[i];
Resource resource = getHome().getResource( ref );
File file = resource.getArtifact( project );
path.createPathElement().setLocation( file );
}
return path;
}
From the above - the important lines with respect to Gump integration
is the the following:
Resource resource = getHome().getResource( ref );
File file = resource.getArtifact( project );
path.createPathElement().setLocation( file );
Currently, the getArtifact(..) operation pulls in resources from a local
cache (backed by a number of repositories) based on resource identifier
information include group, resource name and version. My theory is that
I should be able to call runtime gump and request the gump artifact for
a particular group/name combination.
So - the questions is ... is there a nice small gump API I can build
against that would enable the possibility for a totally integrated solution?
Cheers, Steve.
--
|---|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
Noel J. Bergman wrote: Gump has some of this already. It can use a CVS tag (or SVN branch) of some module to allow this. Which would work really well if Avalon had tagged their stuff prior to complaints about why tagging is sort of vital, but all that we have are the current jars. Not even the Avalon folks who later tried were able to reproduce the contents. Not that you need to support that problem. :-) Just a point of clarification - James is released and running against an early unreleased version of Avalon content (the cornerstone.jar). The released (and tagged) version was made available about a year ago (and tested against James head prior to release). And, yes, moving to a reproducible version of Avalon is on the agenda, If you mean moving to a released version of Avalon then sure - that's highly recommended. right after we ship the next Release of James. And I would love to have James (both branch_2_1_fcs and MAIN) building with GUMP. One way to get a lot more value back from Gump for the James project would be to separate build descriptions for the different components that the James project is based on. * james core * dns * remote * pop3 * smtp * mail-store * user-store * spool * nntp-repository * nntp-server * fetchpop From here you would be able to get consistent feedback without the overhead of the relatively expensive dependency chain that exists in the current james server gump definition (23 direct, 203 implied). From this basis you could then worry about container strategies and put together a separate gump descriptor(s) that enables testing and packaging. If the above is *too* fine-grain, then why not simply break out your james server build from the container build? The Avalon project has already gone though the process of separating out the different subsystem that james is dependent (tagged in cvs and published under specific versions). Cheers, Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
gump stats looking odd
According to the following stats summary - one one gump project was successfull. What is impled by the 512 No Works item? --- Projects Successes FailuresPrereqs No Works Packages 563 01 (0.18%) 00 (0.00%) 00 (0.00%) 512 (90.94%) 50 (8.88%) --- Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Repository (was [collections] new snapshot to ibiblio)
Adam R. B. Jack wrote: Stephen McConnell [EMAIL PROTECTED] wrote: http://brutus.apache.org/gump/public/repolist.txt Right now (without metadata changes for Gump, but I know they are going to be needed) we have projectName (not moduleName) = groupId, jar ID = artefactId. This works ok for many, I believe. Of the 97 Avalon related projects i9n Gump almost all produce artifacts where the current projectName != groupId. The jar ID and artifactId are however largely consistent. Thanks for the review, I kinda expected to have to add a groupId to the metadata, probably at the module level (that can be overridden at the project level, if needed). I haven't thought about it enough to propose anything yet though (and was kinda hoping to combine it with jar repository information, for the product, to kill a few birds at once. I've done some work to match a jar repository like a CVS or SVN one.) BTW: Would moduleName have been a better match for groupId than projectName? I could default the above to one of these two. Within the avalon projects we generally have: gump-project-name == maven-artifact-id But its not 100% consistent. Modules could be repackaged to match maven-group-id, but keep in mind that this would result in a large number of groups - for example, this would generate separate groups for avalon-framework, avalon-logging, avalon-repository, avalon-meta, avalon-util, merlin, etc., etc. But yes - module name is probably a better bet. The ability to declare the module under a gump project definition would be easy to incorporate. Some work would still be needed to breakout gump projects with multiple artifacts into one gump project per artifact and an aggregating project where necessary (e.g. avalon-framework should be separated into avalon-framework-api, avalon-framework-impl and avalon-framework recast as an aggregation of the two). Cheers, Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
