Re: cvs commit: gump/project ant.xml checkstyle.xml excalibur.xml incubator-altrmi.xml jakarta-bcel.xml jakarta-velocity.xml mx4j.xml xdoclet.xml xml-xalan.xml
we've only ever synced in Apache releases 5.0 and 5.1 AFAICT. Cheers, Brett On Tue, 19 Oct 2004 08:23:32 +0200, Stefan Bodewig [EMAIL PROTECTED] wrote: On 16 Oct 2004, [EMAIL PROTECTED] wrote: Must change the jakarta-bcel project to 'bcel' to get the Maven working. Note that bcel had a long life at sourceforge before it came to Jakarta. I'm not sure that bcel at Maven means the same thing as Apache's bcel. 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: [EMAIL PROTECTED]: Project commons-jelly (in module jakarta-commons) failed
On Tue, 19 Oct 2004, Dion Gillard [EMAIL PROTECTED] wrote: I can't subscribe to [EMAIL PROTECTED] after several attempts, I almost believe this is a problem with your gmail account. I sent a mail to you offering my help (as a Gump list moderator I do have certain powers ;-) to which you didn't respond - maybe you didn't receive it? Tell us where the descriptors are in the build output. Since it is not in the build output (yet?): the descriptor is here http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons.xml I'd like to switch Jelly to a maven build please The dependencies should be the same (minus Ant?), so all we'd need to change would be ant - maven. Which goal would be the best choice? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.1 still hanging about??
On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
Anyone has any clue what this is?
Yes.
If you use javac without a target attribute, Ant won't use the
-target command line switch. Sun changed the default of -target 1.3
to -target 1.4 with JDK 1.4 so many builds switched to specifying
target=1.1 to create classes that can be used on older JDKs.
Now the same happens to the source attribute. If you leave it off,
Ant won't pass -source to the compiler. In JDK 1.4 the default for
-source has been 1.3 which means -target 1.1 is fine (and thus nobody
specified the source attribute). With JDK 1.5 they changed the
default to 1.4 and then a
javac target=1.1/
will use -target 1.1 -source 1.4 implicitly on JDK 1.5 which is an
incompatible combination of argument.
To make things worse, -target 1.1 -source 1.3 doesn't work for JDK 1.5
either IIRC and at the same time -source doesn't allow 1.2 or 1.1 in
JDK 1.4 so you need to do something silly like the Ant build file
target name=javac.preset depends=javac.preset.1.5+,javac.preset.1.5-/
target name=javac.preset.1.5+ depends=check_for_optional_packages
if=jdk1.5+
presetdef name=javac.preset
javac source=${javac.source}/
/presetdef
/target
target name=javac.preset.1.5- depends=check_for_optional_packages
unless=jdk1.5+
presetdef name=javac.preset
javac/
/presetdef
/target
in order to support all JDKs properly.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 5 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module james-server success, but with warnings. [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. [EMAIL PROTECTED]: Module werkz success, but with warnings. [EMAIL PROTECTED]: Project jtidy-cvs (in module jtidy) failed [EMAIL PROTECTED]: Project jetty-plus (in module jetty) failed *** G U M P [EMAIL PROTECTED]: Module james-server success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module james-server contains errors. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/james-server/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/james-server/gump_work/update_james-server.html Work Name: update_james-server (Type: Update) Work ended in a state of : Failed Elapsed: Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/home/cvspublic/trunk/ update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/james-server] - /home/cvspublic/trunk: no such repository - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/james-server/rss.xml - Atom: http://brutus.apache.org/gump/public/james-server/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 2619102004, brutus:brutus-public:2619102004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project txt2html-task contains errors. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [ant] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant] -INFO- No license on redistributable project with outputs. -ERROR- Failed to publish [/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant] to repository : [Errno 21] Is a directory The following work was performed: http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/gump_work/build_jakarta-servletapi-5_txt2html-task.html Work Name: build_jakarta-servletapi-5_txt2html-task (Type: Build) Work ended in a state of : Success Elapsed: 2 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only ant [Working Directory: /usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant:/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 - Buildfile: build.xml prepare: [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/classes [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/docs [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/docs/api [mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/examples
Re: Saxon
Stefan Bodewig wrote: On Sun, 17 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Saxon v6 must be called saxon and not saxon6, since we otherwise can't get Maven builds to work. I think we are finally reaching a point where we see that we need a way to specify the groupId for Maven independent of the Gump project name. We shouldn't go on renaming projects (back and forth in the case of saxon) IMHO. I can hardly agree more. Niclas already found human obstacles on this name synchronization but I believe that the general rule applies: if gump needs projects to adjust to him, gump is buggy and must be fixed. What does it mean in practice? we should be able to indicate *explicitly* how identifiers are mapped from the gump world to the maven world. I'm totally in favor of making sure that this mapping is as simple as possible, hopefully 1to1 in the future, but right now, there are mismatches and they need to be taken care of from the gump descriptors: if we need to tell projects to rename their dependencies because of gump, we have a problem. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: 1.1 still hanging about??
Stefan Bodewig wrote:
On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
Anyone has any clue what this is?
Yes.
If you use javac without a target attribute, Ant won't use the
-target command line switch. Sun changed the default of -target 1.3
to -target 1.4 with JDK 1.4 so many builds switched to specifying
target=1.1 to create classes that can be used on older JDKs.
Now the same happens to the source attribute. If you leave it off,
Ant won't pass -source to the compiler. In JDK 1.4 the default for
-source has been 1.3 which means -target 1.1 is fine (and thus nobody
specified the source attribute). With JDK 1.5 they changed the
default to 1.4 and then a
javac target=1.1/
will use -target 1.1 -source 1.4 implicitly on JDK 1.5 which is an
incompatible combination of argument.
To make things worse, -target 1.1 -source 1.3 doesn't work for JDK 1.5
either IIRC and at the same time -source doesn't allow 1.2 or 1.1 in
JDK 1.4 so you need to do something silly like the Ant build file
target name=javac.preset depends=javac.preset.1.5+,javac.preset.1.5-/
target name=javac.preset.1.5+ depends=check_for_optional_packages
if=jdk1.5+
presetdef name=javac.preset
javac source=${javac.source}/
/presetdef
/target
target name=javac.preset.1.5- depends=check_for_optional_packages
unless=jdk1.5+
presetdef name=javac.preset
javac/
/presetdef
/target
Can't Ant work around this by itself?
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Please put in gump repo the tagishauth-1.0.3.jar
On Tuesday 19 October 2004 19:42, Stefan Bodewig wrote: The jars you list come from four different Opensymphony projects. I can't find OSUser on opensymphony.org at all, BTW. We might want to build all of them from source one day, so they should be separate Gump projects instead of one big one. This is my fault. I recommended the four Jars in one project, simply due to I thought it was more convenient with 1 dir with 4 Jars instead of 4 dirs with 1 jar each... Either way can do, no technical obstacles. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Selling Gump...
Eric Pugh wrote: To sum up.. Better marketing of Gump and easier use of a specific version of a Jar would really help Gump's acceptance and percieved value. Yes, definately agree. Here is my todo list: 1) push for equilibrium [ongoing] 2) push for metadata aggregation back in gump [ongoing, two modules left, soon both will be resolved] 3) separate the build part from the data presentation part [starting] 4) implement continous building 5) implement jar fallback Note how #5 will allow us to move to the what you describe: the convergence of continous integration and build systems. I agree with Niclas, Gump needs better marketing. The way I see it, Gump is a cause-effect amplifier. It should amplify the cause of some effect on a project, either your own, or projects you depend on. For this to work properly, we need an tree in equilibrium and this is what we should focus on first. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: gump/project excalibur.xml xml-xalan.xml
On Tuesday 19 October 2004 19:19, [EMAIL PROTECTED] wrote: bodewig 2004/10/19 04:19:55 Modified:project excalibur.xml xml-xalan.xml Log: having the same jar with two ids seems to drop one id leading to the breakage for jstl and others You will need to modify maven.py as well, since Artifacts with type=boot seems to not be generating the maven.jar.xalan= override, in which case you get a Artifact not found. I have been trying before with manual property declarations for that, but unable to succeed. Cheers Niclas-- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please put in gump repo the tagishauth-1.0.3.jar
On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Tuesday 19 October 2004 19:42, Stefan Bodewig wrote: The jars you list come from four different Opensymphony projects. I can't find OSUser on opensymphony.org at all, BTW. We might want to build all of them from source one day, so they should be separate Gump projects instead of one big one. This is my fault. I recommended the four Jars in one project, simply due to I thought it was more convenient with 1 dir with 4 Jars instead of 4 dirs with 1 jar each... Either way can do, no technical obstacles. OK, I've added osworkflow, oscore and propertyset - using the latest downloads from Opensymphony. I didn't add OSUser since I can't seem to find it there. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml xml-xalan.xml
On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: You will need to modify maven.py as well, since Artifacts with type=boot seems to not be generating the maven.jar.xalan= override, in which case you get a Artifact not found. Hmm, sounds like a bug to me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml xml-xalan.xml
On Tue, 19 Oct 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: You will need to modify maven.py as well, since Artifacts with type=boot seems to not be generating the maven.jar.xalan= override, in which case you get a Artifact not found. Hmm, sounds like a bug to me. which seems to be fixed with revision 54102 http://cvs.apache.org/viewcvs.cgi/gump/trunk/python/gump/core/build/maven.py?r1=53813r2=54102p1=gump/trunk/python/gump/build/maven.pyp2=gump/trunk/python/gump/build/maven.pyroot=Apache-SVN which in turn should appear in the live branch (which I understand is running on brutus) since revision 54593 about eight days ago. When have you last tried to use type=boot together with maven jar overrides? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Favor for the Gump Project
Greg,
I'm writing you on behalf of Gump (http://gump.apache.org) the continous
integration tool that the ASF runs to understand project dependencies
issues.
As you might know, Jetty is required to build some of the ASF project
and we recently found out (with not ease of pain!) that jetty is causing
a little problem with the fact that it's 'sealing' the jars that it
produces.
For example, if you take a look here:
http://brutus.apache.org/gump/test/project_todos.html
you'll see that the 20 projects are prevented from building because the
cactus-framework depends on jetty *and* on the servlet API *and* the ant
build file for cactus-framework checks for the availability of the
servlet API 2.4, resulting in the servlet API classes to be loaded both
from the jetty.jar and from the servlet-api.jar, but since jetty.jar is
sealed, a security violation is thrown!
Now, Gump, as a practice, does *NOT* ask projects to change their
descriptors for him, but we believe that it would be enough to apply the
following patch
15:31:49.0 -0700
@@ -220,7 +220,7 @@
jar jarfile=${servlet.jar} basedir=${classes}
include name=javax/servlet/** /
manifest
- attribute name=Sealed value=true/
+ attribute name=Sealed value=${jar.sealed}/
attribute name=Built-By value=${user.name}/
attribute name=Specification-Title value=Java API for
Servlets/
attribute name=Specification-Version value=2.4/
@@ -237,7 +237,7 @@
target name=jetty.jar depends=classes,servlet.jar
jar jarfile=${jetty.jar}
manifest
- attribute name=Sealed value=true/
+ attribute name=Sealed value=${jar.sealed}/
attribute name=Built-By value=${user.name}/
attribute name=Specification-Version
value=${RELEASE.MAJOR}/
attribute name=Implementation-Version
value=${RELEASE.MAJOR.MINOR}/
so that jar sealing could be turned on and off at need.
We deeply apologize for the incovenience and we realize it's none of
your concern if gump builds or not, but this very simple patch would
help up a great deal.
Thanks for your understanding.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
RE: Please put in gump repo the tagishauth-1.0.3.jar
Humm.. OSUser isn't listed on the homepage, but does exist as a CVS repo. I'll dig deeper and get back to you. Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: Re: Please put in gump repo the tagishauth-1.0.3.jar On Tue, 19 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Tuesday 19 October 2004 19:42, Stefan Bodewig wrote: The jars you list come from four different Opensymphony projects. I can't find OSUser on opensymphony.org at all, BTW. We might want to build all of them from source one day, so they should be separate Gump projects instead of one big one. This is my fault. I recommended the four Jars in one project, simply due to I thought it was more convenient with 1 dir with 4 Jars instead of 4 dirs with 1 jar each... Either way can do, no technical obstacles. OK, I've added osworkflow, oscore and propertyset - using the latest downloads from Opensymphony. I didn't add OSUser since I can't seem to find it there. 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 jetty.xml
On 19 Oct 2004, [EMAIL PROTECTED] wrote: it seems that jetty-plus is not able to compile because it can't see its own JMX stuff Among other things. I don't think we have org.enhydra.jdbc or org.objectweb.transaction.jta in Gump yet. NOTE: jetty-plus doesn't seem to pickup the gump-build classpath, how do we inject it in? Why do you think so? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Module james-server success, but with warnings. this should be fixed (was looking in the wrong directory of the repository) [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. this is due to this line !-- not a jar, but I don't see a way to create one either -- jar name=jsr152/build/ant/ the task seems not to be generating a jar, can we publish a directory of classes instead of a jar? is jar dir=/ allowed? [EMAIL PROTECTED]: Module werkz success, but with warnings. the werkz module is gone and Maven is the only one that depends on it. Should we blast it? [EMAIL PROTECTED]: Project jtidy-cvs (in module jtidy) failed this requires these maven plugins maven-sourceforge-plugin-1.0.jar maven-statcvs-plugin-2.4.jar maven-findbugs-plugin-0.8.4.jar maven-xhtml-plugin-1.2.jar maven-checkstyle-plugin-2.4.1.jar so I just added them to the maven repository on brutus (kudos to Eric for the IRC help!) [EMAIL PROTECTED]: Project jetty-plus (in module jetty) failed I added the JMX jar to the jetty project, this should make this work -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: gump/project jetty.xml
On Tue, 19 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: On 19 Oct 2004, [EMAIL PROTECTED] wrote: NOTE: jetty-plus doesn't seem to pickup the gump-build classpath, how do we inject it in? Why do you think so? http://brutus.apache.org/gump/public/jetty/jetty-plus/gump_work/build_jetty_jetty-plus.html look in the build section, it's classpath environment is completely different and picked up from the local directories. its expanded.classpath property is different from the CLASSPATH environment (which looks fine). Digging into the build file, this really is supposed to be a path of local jars - only that Ant will completely ignore it when it is used in java, javac or junit. Nothing special here. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The bigger picture: Centralized Build Results
I was just reading about selling Gump, etc., and I had several thoughts. I've been following the Gump lists for the past 10 months, joining because I was impressed with Gump's data model. I have been looking into all sorts of continuous integration/build systems for my company, including CruiseControl and BuildBot. I regularly follow the Gump, CruiseControl and BuildBot lists. PROBLEM STATEMENT In a large organization, there are several projects, often each with their own ideas, desires, approaches and their own tools. Often is the desire to bring these various information sources together. The problem I see is that each continuous integration/build system tries to be everything and in its own way, a monolithic approach of sorts. In my company, there are several projects running different build and test systems, some of our own invention, some CruiseControl, etc. Ownership of much of this stuff is decentralized, but lately there is more and more of a desire to bring much of this information together. (Gump would have worked just as well as CruiseControl, but someone had already started with CruiseControl, and it is functioning quite well for the task. Now that it has the momentum, switching to another tool would not only be more difficult, but also difficult to justify.) Then, how does one approach the integration of all this information, potentially from several systems, several sources? A wholesale replacement of tools to achieve a single type of system is not an option where I work. I suspect that would be the same elsewhere. PROPOSAL What I suggest is a split in the architecture, as follows: (1) build loop: triggers, bootstraps, hooks into SCM, actions; (2) presentation; (3) notification. From the central data store point of view: (1) is the producer, (2) and (3) are consumers of the data. In my ideal world, the data model would be the standard, the APIs into the data store would be a part of that standard. The pieces above would plug in to the standard. Furthermore, I think the Gump data model is more thought out and closer to the generic ideal for this. So I think the Gump project is the correct place to drive this idea. The task would be to first develop the standard data model manifested in a relational database engine, and define and write the APIs into it. CONCLUSION As far as the idea of selling Gump, I think plenty of traction could be achieved by this approach. Gump could then be introduced incrementally into existing projects, getting more visibility and usage within the world, thus gaining the economies of scale and futher contributions to its development. RELATED WORK In order to bring all this together within my organization, I have embarked on this approach. I have defined a data model (schema) and implemented it in MySQL with a perl-based CGI programs as the front-end. Within the perl CGIs, I use Class::DBI for data access, and the Template Toolkit for rendering the HTML presentation. This implements the central data store and part (2) above in the architecture, the presentation. A couple of the CGI programs are web services, not intended to publish any data, but are only there for submission of build/test results; a couple of simple client-side scripts exist to post data to these web services, thus defining an API for posting data. This system, by itself, performs no builds whatsoever, but only exists as a container for the data and its presentation. The intention is to post all build results and related test results to this single database. Notification has yet been implemented, as of yet, but it is in the plan. Downside: the system I developed is not an open source project. wade
Re: cvs commit: gump/project excalibur.xml xml-xalan.xml
On Tuesday 19 October 2004 22:03, Stefan Bodewig wrote: When have you last tried to use type=boot together with maven jar overrides? try?? If you get excalibur-logger back working, then Excalibur will break on excalibur-xmlutil, where I found this symptom. Xalan is (was) in the bootclasspath, yet Maven complained of missing dependency. I don't know where to find the overrides file, or even if I have access to it. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 1 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Project JavaxTvUtilTimerTests (in module test-apps) success *** G U M P [EMAIL PROTECTED]: Project JavaxTvUtilTimerTests (in module test-apps) success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project JavaxTvUtilTimerTests *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://knex/gump/test-apps/JavaxTvUtilTimerTests/index.html That said, some information snippets are provided here. The following work was performed: http://knex/gump/test-apps/JavaxTvUtilTimerTests/gump_work/build_test-apps_JavaxTvUtilTimerTests.html Work Name: build_test-apps_JavaxTvUtilTimerTests (Type: Build) Work ended in a state of : Success Elapsed: 7 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/build/gump/work/merge.xml -Dbuild.sysclasspath=ignore -Dlib.dir=/build/gump/public/workspace/tvnav/built/bin [Working Directory: /build/gump/public/workspace/test-apps/JavaxTvUtilTimerTests] CLASSPATH : /usr/java/j2sdk1.4.2_04/lib/tools.jar:/build/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/build/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/build/gump/public/workspace/ant/dist/lib/ant-swing.jar:/build/gump/public/workspace/ant/dist/lib/ant-trax.jar:/build/gump/public/workspace/ant/dist/lib/ant-junit.jar:/build/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/build/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/build/gump/public/workspace/ant/dist/lib/ant.jar:/build/gump/public/workspace/lbrt-ant-tasks/built/lbrt-tools.jar - Buildfile: build.xml init: compile: [mkdir] Created dir: /build/gump/public/workspace/test-apps/JavaxTvUtilTimerTests/built/classes [javac] Compiling 1 source file to /build/gump/public/workspace/test-apps/JavaxTvUtilTimerTests/built/classes deploy: BUILD SUCCESSFUL Total time: 6 seconds - To subscribe to this information via syndicated feeds: - RSS: http://knex/gump/test-apps/JavaxTvUtilTimerTests/rss.xml - Atom: http://knex/gump/test-apps/JavaxTvUtilTimerTests/atom.xml == Gump Tracking Only === Produced by Gump version 2.1.0-alpha-0003. Gump Run 20041019175402, knex.vmodem.com:knex:20041019175402 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: knex] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Gump wrote: Dear Gumpmeisters, The following 1 notifys should have been sent Sorry folks, this run got away on me. Please go about your business, nothing to see here. :) -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
