Re: jtidy
On Tue, 12 Oct 2004, Adam Jack [EMAIL PROTECTED] wrote: The jtidy build.xml vanished, so it is Maven or nada. Anybody else tempted to package jtidy Yep. Depends on the answer to my question below and/or how easy a migration to a Maven build would be. -- 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'm very reluctant to make more parts of our build systems installed. Stefan - 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: Java package sealed?
On Wed, 13 Oct 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: My theory: Ant loads Jetty's version of servlet.jar in addition to the one from Jakarta. The first one is sealed, the second one is first in the class loader and so we load the class from a different jar than the one that sealed it. Theory confirmed. I've managed to get my traditional Gump to try and build cactus-framework-12 by faking Tidy.jar. I've found two ways to successfully build cactus: (1) remove the Class-Path entry from org.mortbay.jetty.jar's MANIFEST.MF (2) turning the Sealed: true into Sealed: false in Jetty's javax.servlet.jar's MANIFEST.MF. Option (2) could easily be achieved by a property in Jetty's build file. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDK 1.5 now running Gump...
Has someone made JDK 1.5 the default JVM for Gump?? Sun has introduced a incompatible change (do they ever follow their own compatibility advice?) org.w3c.dom.Node interface have additional methods in it, which breaks crimson and xerces. I assume that Xerces is also referencing impl classes in rt.jar. Anybody knows anything about this? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Standardizing on Maven names
On Tue, 12 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: We are having all sort of issues because maven and gump use different naming schemes. Now, why don't we just adopt their naming conventions and live peacefully together from that point on? Wholeheartedly yes when it comes to jar ids. Talking about project names, I really wouldn't want to call ant jakarta-ant or cocoon xml-cocoon. But I guess I could live with this for pragmatic reasons. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Standardizing on Maven names
The maven repository uses ant and I guess cocoon would be used for these. Let me clarify some terminology, just so I understand: In gump there are projects, where a project id is unique globally, and there are jar ids, where jar ids are unique within project, right? So this parallels quite nicely to Maven's groupId (globally unique) and artifactId (unique within group). Now the twists :) However, I'm worried there still might be a disconnect because Maven talks about projects within a group, where Gump talks about projects being a group. eg: groupId geronimo, artifactId geronimo-clustering but the project is geronimo-clustering, and that's where the gump descriptor will be generated. Each subproject will have a descriptor. Is this what gump expects? From what I can see, it is, so that's ok. Next twist: the Apache Repository group has come up with a standard repo format, and we are working towards that in future Maven versions. groupIds are likely to be fully-qualified. ie maven - org.apache.maven (maybe even deeper) commons-collections - org.apache.commons.collections If we start migrating to different group IDs like this, will that cause any issues? I'm guessing the only thing is that it might make an ugly project name (as Stefan pointed out), so maybe gump needs to explicitly declare a groupId, different from the project id. Thoughts? This is a bit of a way off, and I don't think it really changes anything - but best to make sure. Cheers, Brett On Wed, 13 Oct 2004 09:54:16 +0200, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 12 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: We are having all sort of issues because maven and gump use different naming schemes. Now, why don't we just adopt their naming conventions and live peacefully together from that point on? Wholeheartedly yes when it comes to jar ids. Talking about project names, I really wouldn't want to call ant jakarta-ant or cocoon xml-cocoon. But I guess I could live with this for pragmatic reasons. 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: [RT] Standardizing on Maven names
On Wednesday 13 October 2004 18:17, Brett Porter wrote: Let me clarify some terminology, just so I understand: In gump there are projects, where a project id is unique globally, and there are jar ids, where jar ids are unique within project, right? So this parallels quite nicely to Maven's groupId (globally unique) and artifactId (unique within group). Yes and perhaps no. Gump will only issue a single build command per project. That build command may create more than one artifact (Maven lingo), unlike standard Maven builds. Therefor the need for an ID of Jars within the project. Next twist: the Apache Repository group has come up with a standard repo format, and we are working towards that in future Maven versions. I think all involved should agree on the same solution, whatever that is. I personally think that the long-term goal should be that a single 'complete' model which describes everything needed for build systems, and extendible to provide additional information for different build systems. RDF is probably the best candidate for this. Then this would become a non-existent issue. If we start migrating to different group IDs like this, will that cause any issues? I think there will be some short-term pain of managing to make the changes without bringing Gump success rate back to 0%. :'( Should it be done? I don't know. What is the status of the entire Repository project? 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] Standardizing on Maven names
On Wed, 13 Oct 2004, Brett Porter [EMAIL PROTECTED] wrote: The maven repository uses ant and I guess cocoon would be used for these. When Niclas generated the Fulcrum descriptors it contained things like jakarta-ant, jakarta-turbine-torque, jakarta-log4j or jakarta-avalon that had to be fixed manually[1] after that. Maybe the Gump plugin needs an update, or Niclas used an old version, dunno. In gump there are projects, where a project id is unique globally, and there are jar ids, where jar ids are unique within project, right? Yes. However, I'm worried there still might be a disconnect because Maven talks about projects within a group, where Gump talks about projects being a group. eg: groupId geronimo, artifactId geronimo-clustering but the project is geronimo-clustering, and that's where the gump descriptor will be generated. Each subproject will have a descriptor. So maybe Gump projects are really more like Maven projects, except they may create multiple artifacts (if this is what Niclas said). Next twist: the Apache Repository group has come up with a standard repo format, and we are working towards that in future Maven versions. groupIds are likely to be fully-qualified. ie maven - org.apache.maven (maybe even deeper) commons-collections - org.apache.commons.collections If we start migrating to different group IDs like this, will that cause any issues? If Gump projects are like Maven projects and not groups, it shouldn't matter. I'm guessing the only thing is that it might make an ugly project name (as Stefan pointed out), so maybe gump needs to explicitly declare a groupId, different from the project id. I currently feel that we may be forced to declare artifact and group id individually on the jars we create, at least optionally. Really difficult situations arise when projects get split (jakarta-slide used to contain slide-webdavclient which has now become a separate project in Gump) or artifacts get split. This will be a problem to deal with since Gump living on the edge will have to follow such moves immediately while Maven project files can't be adapted without SNAPSHOTs being available IIUC. Stefan Footnotes: [1] http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-turbine-fulcrum.xml?r1=1.48r2=1.49 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jtidy
I really haven't followed Maven development, but when we tried to list the dependencies last time, some things (werkz is something I remember) simply were unbuildable if not un-findable. We'll sort that out, I'm sure. I thought the issue was dom4j - since resolved. There are things like werkz, forehead, comons-grant which are pretty much dead outside of Maven. The plan is to fold them in for Maven 1.1, as they are quite small. But we'll still build them for now. We'll sort something out. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Standardizing on Maven names
Maybe the Gump plugin needs an update, or Niclas used an old version, dunno. There's only been one version with the maven tag. I've just discovered http://cvs.apache.org/viewcvs.cgi/maven-plugins/gump/src/plugin-resources/maven2gump.properties which apparently maps ids to gump ids. Among other things, things like: ant=jakarta-ant Hmm... I had no idea that was there. Not exactly an elegant way to maintain a list. I'll get rid of it and cut a new version of the plugin. Are there any still needing mapping that need be kept? I currently feel that we may be forced to declare artifact and group id individually on the jars we create, at least optionally. I think this is a better way to do any compatibility mapping, if possible. For example, it would help in doing what you mentioned next: Really difficult situations arise when projects get split (jakarta-slide used to contain slide-webdavclient which has now become a separate project in Gump) or artifacts get split. This will be a problem to deal with since Gump living on the edge will have to follow such moves immediately while Maven project files can't be adapted without SNAPSHOTs being available IIUC. the options for this seem to be: - maintain the old one as a link to the new one in some way - fork the gump descriptor - old points to old code, new to new (not a migration really) - keep project same, but map projects to group/artifact Ids that can change I'm sure you guys already handle this and know the best option to take. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project struts-sslext.xml
On 13 Oct 2004, [EMAIL PROTECTED] wrote: Struts 1.2 compatible version is in a different module cvs repository=sourceforge -dir=sslext module=sslext110/ +dir=sslext module=sslext120/ does Gump detect this change or do we need to clean out the CVS dir manually to force a checkout instead of update? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump has hanged...
On Wed, 13 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Wednesday 13 October 2004 11:48, Niclas Hedhman wrote: http://brutus.apache.org/gump/public/buildLog.html Stopped on the 120th project... And done it again :o( which project is the 120th? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Magic generated Gump descriptor for magic-xdoc-plugin needs tweak
Hi, the Gump project that used to be called saxon now is saxon7, so wherever you maintain the mapping, please adjust it and regenerate the descriptor. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP][PATCH] excalibur-event has been split
into excalibur-event-api and excalibur-event-impl. I don't know whether you need the implementation - my guess is you will at runtime. Anyway, I've just changed the dependency to -api. Cheers Stefan Index: gump.xml === --- gump.xml(revision 54740) +++ gump.xml(working copy) @@ -60,7 +60,7 @@ depend project=excalibur-pool/ depend project=excalibur-component/ depend project=excalibur-logger/ -depend project=excalibur-event inherit=runtime/ +depend project=excalibur-event-api inherit=runtime/ depend project=excalibur-legacy id=i18n/ depend project=excalibur-testcase/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-75) Move Ant nightly builds from user bodewig to nightlybuild
The following comment has been added to this issue: Author: Stefan Bodewig Created: Wed, 13 Oct 2004 6:54 AM Body: Leo, is there anything I can do to help? Basically you'd need to copy over the repo and extracted directories from my home dir (or point the script to the extracted dir in my home dir and check out Ant's CVS into a place where the script knows how to update it). - View this comment: http://issues.apache.org/jira/browse/GUMP-75?page=comments#action_53989 - View the issue: http://issues.apache.org/jira/browse/GUMP-75 Here is an overview of the issue: - Key: GUMP-75 Summary: Move Ant nightly builds from user bodewig to nightlybuild Type: Wish Status: In Progress Priority: Minor Project: Gump Components: configuration of live servers Assignee: Leo Simons Reporter: Stefan Bodewig Created: Tue, 3 Aug 2004 5:11 AM Updated: Wed, 13 Oct 2004 6:54 AM Description: There is a shell script in bodewig's home dir on brutus that has been successful in producing nightly builds of Ant in http://brutus.apache.org/~bodewig/. Please add the script to the experimental system of user nightlybuild and disable bodewig's script after that. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-7) Coccondev does not seem to be pickup up headless definition
Message: The following issue has been closed. Resolver: Stefan Bodewig Date: Wed, 13 Oct 2004 6:55 AM cocoondev is no longer running any kind of Gump service. - View the issue: http://issues.apache.org/jira/browse/GUMP-7 Here is an overview of the issue: - Key: GUMP-7 Summary: Coccondev does not seem to be pickup up headless definition Type: Bug Status: Closed Priority: Blocker Resolution: WON'T FIX Project: Gump Components: configuration of live servers Fix Fors: unspecified Versions: unspecified Assignee: Reporter: Sebb Created: Wed, 10 Dec 2003 10:26 AM Updated: Wed, 13 Oct 2004 6:55 AM Environment: Operating System: Other Platform: Other Description: Coccondev does not seem to be pickup up the java.awt.headless definition, which was added to gump.xml recently. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-2) Gump does not fail a build if the jar name=*output file* is not found
Message: The following issue has been closed. Resolver: Stefan Bodewig Date: Wed, 13 Oct 2004 7:00 AM The Java/XSLT version is no longer under development. - View the issue: http://issues.apache.org/jira/browse/GUMP-2 Here is an overview of the issue: - Key: GUMP-2 Summary: Gump does not fail a build if the jar name=*output file* is not found Type: Bug Status: Closed Resolution: WON'T FIX Project: Gump Components: Java/XSLT Fix Fors: unspecified Versions: unspecified Assignee: Reporter: Adam Jack Created: Thu, 26 Jun 2003 1:25 PM Updated: Wed, 13 Oct 2004 7:00 AM Environment: Operating System: Other Platform: Other Description: it merely marks dependent projects as fail due to dependency. As such, no nags are sent. This reduces the feedback/effectiveness of Gump as a continuous integration tool. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-18) bench.png moved/removed
Message: The following issue has been closed. Resolver: Stefan Bodewig Date: Wed, 13 Oct 2004 7:02 AM I don't know when it happened, but the Gump site has a bench. - View the issue: http://issues.apache.org/jira/browse/GUMP-18 Here is an overview of the issue: - Key: GUMP-18 Summary: bench.png moved/removed Type: Bug Status: Closed Priority: Major Resolution: FIXED Project: Gump Components: Java/XSLT Fix Fors: unspecified Assignee: Stefan Bodewig Reporter: Adam Jack Created: Sun, 22 Feb 2004 7:48 AM Updated: Wed, 13 Oct 2004 7:02 AM Description: Traditional Gump links to http://jakarta.apache.org/gump/images/bench.png, which no longer exists on the Gump site. Should Gump use a local icon, or ought we restore the image? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5 now running Gump...
On Wed, 13 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Has someone made JDK 1.5 the default JVM for Gump?? We have a JDK 1.5 Gump. http://brutus.apache.org/gump/jdk15/ I think Niclas meant: Is the public Gump running JDK 1.5 (by accident) right now? The build failures of Crimson and Xerces-1 you can see in the log of the current(ly stalled) Gump run look as if it was the case. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump has hanged...
On Wed, 13 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Wednesday 13 October 2004 11:48, Niclas Hedhman wrote: http://brutus.apache.org/gump/public/buildLog.html Stopped on the 120th project... And done it again :o( which project is the 120th? Not sure that matters. The build log (HTML page) is only updated every 5, so it needs to be in that ballpark. Actually, the logs show: INFO:gump:Build Project: #[(122, 706)] : saxon6 : [state:Unset] Traceback (most recent call last): File bin/integrate.py, line 109, in ? irun() File bin/integrate.py, line 86, in irun result = getRunner(run).perform() File /usr/local/gump/public/gump/python/gump/core/runner/runner.py, line 213, in perform return self.performRun() File /usr/local/gump/public/gump/python/gump/core/runner/demand.py, line 186, in performRun module=project.getModule() File /usr/local/gump/public/gump/python/gump/core/model/project.py, line 663, in getModule if not self.inModule(): raise RuntimeError, 'Project [' + self.name + '] not in a module.]' RuntimeError: Project [jdox] not in a module.] This *bug* is when a packaged project is reference but not in module, i.e. not known. I'll enter a JIRA entry, it has happened a bit recently and needs fixing. BTW: We used to get this log e-mailed to us in case of failure, I'll check why that isn't occurring either. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5 now running Gump...
I think Niclas meant: Is the public Gump running JDK 1.5 (by accident) right now? Opps, ok. http://brutus.apache.org/gump/public/index.html shows: Java.version 1.4.2_05 and this ought'nt have change since Stefano updated it a week-ish ago. Also, I see this in their build: CLASSPATH :/opt/jdk1.4/lib/tools.jar The build failures of Crimson and Xerces-1 you can see in the log of the current(ly stalled) Gump run look as if it was the case. As such, hmm ... I can't explain this. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java package sealed?
I've seen this before, but I'm not sure which of the jars the package gets loaded from. Is there any way to get a temporary -debug output of the build? I still haven't figured out how I can selectively build a single project in Gump now. Add debug=true (or verbose=true) as an attribute on the ant or maven element. See:http://gump.apache.org/metadata/builder.html regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-85) A package typo or mis-naming or mis-match crashes Gump
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GUMP-85 Here is an overview of the issue: - Key: GUMP-85 Summary: A package typo or mis-naming or mis-match crashes Gump Type: Bug Status: Unassigned Priority: Critical Project: Gump Assignee: Reporter: Adam Jack Created: Wed, 13 Oct 2004 7:48 AM Updated: Wed, 13 Oct 2004 7:48 AM Description: Gump ought not react so poorly to this. INFO:gump:Build Project: #[(122, 706)] : saxon6 : [state:Unset] Traceback (most recent call last): File bin/integrate.py, line 109, in ? irun() File bin/integrate.py, line 86, in irun result = getRunner(run).perform() File /usr/local/gump/public/gump/python/gump/core/runner/runner.py, line 213, in perform return self.performRun() File /usr/local/gump/public/gump/python/gump/core/runner/demand.py, line 186, in performRun module=project.getModule() File /usr/local/gump/public/gump/python/gump/core/model/project.py, line 663, in getModule if not self.inModule(): raise RuntimeError, 'Project [' + self.name + '] not in a module.]' RuntimeError: Project [jdox] not in a module.] - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump has hanged...
Actually, the logs show: INFO:gump:Build Project: #[(122, 706)] : saxon6 : [state:Unset] Traceback (most recent call last): File bin/integrate.py, line 109, in ? irun() File bin/integrate.py, line 86, in irun result = getRunner(run).perform() File /usr/local/gump/public/gump/python/gump/core/runner/runner.py, line 213, in perform return self.performRun() File /usr/local/gump/public/gump/python/gump/core/runner/demand.py, line 186, in performRun module=project.getModule() File /usr/local/gump/public/gump/python/gump/core/model/project.py, line 663, in getModule if not self.inModule(): raise RuntimeError, 'Project [' + self.name + '] not in a module.]' RuntimeError: Project [jdox] not in a module.] I assumed that jdox was a typo for qdox, since the packages/jdox-1.5 contained a qdox jar. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump has hanged...
On Wednesday 13 October 2004 22:52, Adam R. B. Jack wrote: I assumed that jdox was a typo for qdox, since the packages/jdox-1.5 contained a qdox jar. Fixed already? There is no jdox ref in my Gump descriptors... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump has hanged...
On Wednesday 13 October 2004 22:52, Adam R. B. Jack wrote: I assumed that jdox was a typo for qdox, since the packages/jdox-1.5 contained a qdox jar. Fixed already? There is no jdox ref in my Gump descriptors... Yup. You on the commits mailing list? http://gump.apache.org/mail.html#Commits+List regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5 now running Gump...
On Wed, 13 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: So, the only other explaination is that the xml-apis or something have brought DOM v3 into CVS/SVN, Doesn't look that way: http://cvs.apache.org/viewcvs.cgi/xml-commons/java/external/src/org/w3c/dom/Node.java last change is more than a year old. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5 now running Gump...
Java.version 1.4.2_05 This is from the LAST reasonably successful build - 76%. THEN something happened, and xerces and crimson doesn't build since they are somehow compiling against DOM v3, and not DOM v2. Good point, it is a run out of date. I'm waiting for cron to kick in to set the environment, and then we'll see. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump has hanged...
On Wednesday 13 October 2004 22:58, Adam R. B. Jack wrote: You on the commits mailing list? Apparently not. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
irc://irc.freenode.net/#asfgump
For when we get busy working together (and/or Gump is biting the dust) I think the IRC channel is a good place to meet. When I can remember (and/or when my link is stable) I'll try to be available at: irc://irc.freenode.net/#asfgump regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Standardizing on Maven names
Stefan Bodewig wrote: On Tue, 12 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: We are having all sort of issues because maven and gump use different naming schemes. Now, why don't we just adopt their naming conventions and live peacefully together from that point on? Wholeheartedly yes when it comes to jar ids. Talking about project names, I really wouldn't want to call ant jakarta-ant or cocoon xml-cocoon. But I guess I could live with this for pragmatic reasons. Hmmm, yeah, that would suck. I think, personally, that Gump and Maven should start talking about creating a more serious infrastructure and joining forces from the POM point of view. What do you guys think about that? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Magic generated Gump descriptor for magic-xdoc-plugin needs tweak
Stefan Bodewig wrote: Hi, the Gump project that used to be called saxon now is saxon7, so wherever you maintain the mapping, please adjust it and regenerate the descriptor. no, it's called saxon6 now. saxon7 already existed. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: irc://irc.freenode.net/#asfgump
On Wednesday 13 October 2004 23:16, Adam R. B. Jack wrote: For when we get busy working together (and/or Gump is biting the dust) I think the IRC channel is a good place to meet. When I can remember (and/or when my link is stable) I'll try to be available at: irc://irc.freenode.net/#asfgump Not me, not tonight... Have to hit the bed. Maybe tomorrow night. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5 now running Gump...
Stefan Bodewig wrote: On Wed, 13 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Has someone made JDK 1.5 the default JVM for Gump?? We have a JDK 1.5 Gump. http://brutus.apache.org/gump/jdk15/ I think Niclas meant: Is the public Gump running JDK 1.5 (by accident) right now? No, it's not. The build failures of Crimson and Xerces-1 you can see in the log of the current(ly stalled) Gump run look as if it was the case. I have changed the crontab last night to do this: 0:00 - public [jdk1.4 + gump/live + nagging] 3:00 - public [jdk1.4 + gump/live] 6:00 - jdk15 [jdk1.5 + gump/live] 9:00 - public [jdk1.4 + gump/live] 12:00 - test [jdk1.4 + gump/trunk] 15:00 - public [jdk1.4 + gump/live] 18:00 - kaffe [kaffe + gump/live] 21:00 - public [jdk1.4 + gump/live] I'm giving 3 hours now since I had the impression that builds were starting to overlap. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Standardizing on Maven names
On Thursday 14 October 2004 00:33, Stefano Mazzocchi wrote: I think, personally, that Gump and Maven should start talking about creating a more serious infrastructure and joining forces from the POM point of view. What do you guys think about that? Definately... RDF, perhaps :o) Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Kaffe? [was Re: JDK 1.5 now running Gump...]
Adam R. B. Jack wrote: Ok, I've made the gump/cron/local-env-brutus.sh put the chosen JDK at the front of the path (it was at the end.) export JAVA_HOME=/opt/jdk1.4 export PATH=$JAVA_HOME/bin:$PATH This seems to cure things, for now: http://brutus.apache.org/gump/test/buildLog.html regards, a, yes! damn, sorry people, the kaffe vm was installed by apt-get so it went in the default path and since they have a java symlink I think that's what happened. I will ge rid of those symlinks. sorry about that (but I guess, only those who don't do anything don't break anything ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: JDK 1.5 now running Gump...
On Thursday 14 October 2004 01:12, Stefano Mazzocchi wrote: I'm giving 3 hours now since I had the impression that builds were starting to overlap. Perhaps not enough :o( Last log says ; 3 hours 7 minutes. Start Date/Time (UTC) Tue, 12 Oct 2004 19:02:00 (UTC) End Date/Time (UTC) Tue, 12 Oct 2004 22:09:10 (UTC) -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Kaffe? [was Re: JDK 1.5 now running Gump...]
sorry about that (but I guess, only those who don't do anything don't break anything ;-) Precisely. No problem, no apology needed.. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.5 now running Gump...
Niclas Hedhman wrote: On Thursday 14 October 2004 01:12, Stefano Mazzocchi wrote: I'm giving 3 hours now since I had the impression that builds were starting to overlap. Perhaps not enough :o( Last log says ; 3 hours 7 minutes. Start Date/Time (UTC) Tue, 12 Oct 2004 19:02:00 (UTC) End Date/Time (UTC) Tue, 12 Oct 2004 22:09:10 (UTC) few minutes overlap is fine, an hour is not. Also note that those 3 hours will be much reduced now that overlap is reduced. gump is disk-bound and I think the overlap was causing massive delays. since we have two disks and 4 processors, we should start thinking about moving workspaces in the two disks. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
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 icu4j (in module icu4j) success *** G U M P [EMAIL PROTECTED]: Project icu4j (in module icu4j) 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 icu4j *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/icu4j/icu4j/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [icu4j.jar] identifier set to project name The following work was performed: http://brutus.apache.org/gump/public/icu4j/icu4j/gump_work/build_icu4j_icu4j.html Work Name: build_icu4j_icu4j (Type: Build) Work ended in a state of : Success Elapsed: 52 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 all [Working Directory: /usr/local/gump/public/workspace/icu4j] CLASSPATH : /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/icu4j/build/classes:/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 - [javac] Note: Recompile with -deprecation for details. tools: [javac] Compiling 63 source files to /usr/local/gump/public/workspace/icu4j/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. richedit: [javac] Compiling 143 source files to /usr/local/gump/public/workspace/icu4j/classes [javac] Note: /usr/local/gump/public/workspace/icu4j/src/com/ibm/richtext/textpanel/StyledTextClipboard.java uses or overrides a deprecated API. [javac] Note: Recompile with -deprecation for details. [copy] Copying 2 files to /usr/local/gump/public/workspace/icu4j/classes/com/ibm/richtext/textapps/resources demos: [javac] Compiling 28 source files to /usr/local/gump/public/workspace/icu4j/classes [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. jar: [jar] Building jar: /usr/local/gump/public/workspace/icu4j/icu4j.jar docs: [echo] doc params: -breakiterator -use -tagletpath ./classes -taglet com.ibm.icu.dev.tool.docs.ICUTaglet -group 'ICU Core' 'com.ibm.icu.lang*:com.ibm.icu.math*:com.ibm.icu.text*:com.ibm.icu.util*:com.ibm.icu.stringprep*' -group 'ICU Tests' 'com.ibm.icu.dev.test*' -group 'Demos' 'com.ibm.icu.dev.demo*' -group 'ICU Tools' 'com.ibm.icu.dev*' [mkdir] Created dir: /usr/local/gump/public/workspace/icu4j/doc [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package com.ibm.icu.lang... [javadoc] Loading source files for package com.ibm.icu.math... [javadoc] Loading source files for package com.ibm.icu.text... [javadoc] Loading source files for package com.ibm.icu.util... [javadoc] Constructing Javadoc information... [javadoc] Registered Taglet com.ibm.icu.dev.tool.docs.ICUTaglet ... [javadoc] Standard Doclet version 1.4.2_05 [javadoc] Building tree for all the packages and classes... [javadoc] /usr/local/gump/public/workspace/icu4j/src/com/ibm/icu/text/UnicodeSet.java:2847: warning - @return tag has no arguments. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Warning: bad deprecated tag '' [javadoc] Warning: bad deprecated tag '' [javadoc] /usr/local/gump/public/workspace/icu4j/src/com/ibm/icu/util/ByteArrayWrapper.java:61: warning - @param argument byteBuffer is not a parameter name. [javadoc] /usr/local/gump/public/workspace/icu4j/src/com/ibm/icu/util/ByteArrayWrapper.java:71: warning - @param argument byteBuffer is not a parameter name. [javadoc] Generating /usr/local/gump/public/workspace/icu4j/doc/stylesheet.css... [javadoc] Note: Custom tags that could override future standard tags: @bug. To avoid potential overrides, use at least one
Re: Project 515 1 hour
Niclas Hedhman wrote: AFAIU, brutus has spent more than 1 hour on project 515. what is project 515? Is there anything that can be put in place so that people like me can reset it? define reset. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
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? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 12:17, Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Project findbugs (in module findbugs) failed [javac] Compiling 371 source files to /usr/local/gump/public/workspace/findbugs/build/classes [javac] javac: invalid target release: jsr14 I turns out that xdoclet - jrefactory-pretty - jrefactory - findbugs and findbugs *NEEDS* jdk 1.5 I think this is fucked up. Yes, I can confirm this is the case. Including that the findbugs.jar that is part of the jrefactory CVS checkout contains JDK1.4 incompatible classes, so jrefactory doesn't build either from its CVS checkout. now, xdoclet appears to be using maven now, and that dependency on jrefactory-pretty is gone in their POM. 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... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: building Forrest (Was: [RT] fixing gump)
On Thursday 14 October 2004 13:06, David Crossley wrote: It seems that Gump is still using the old descriptor in our SVN. How do i get Gump to switch? The profile/gump.xml looks okay, but the last time that it was built was two days ago using the old descriptor. It doesn't look Ok in my checked out copy. Have you perhaps forgotten to commit it? Anyway, I have committed the change I think is necessary... Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
