Re: [GUMP][PATCH] Add avalon-framework impl classes
Stefan Bodewig wrote: Hi, I currently don't understand why Gump on LSD thinks Cocoon would depend on avalon-fortress-container, but the Gump instance on covalent.net tries to build it[1]. The build fails since Cocoon only states a dependency on the avalon-framework API but uses implementation classes as well[2]. The appended patch should fix that. Steffan: I'll be digging into the remaining cocoon/avalon dependencies this week - focussing on seperating fortress from some of the excalibur utilities. That should get the coocoon depedencies green across the board. Cheers, Stephen. Cheers Stefan Footnotes: [1] http://gump.covalent.net/log/cocoon.html [2] http://marc.theaimsgroup.com/?l=avalon-devm=107961713821764w=2 -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][PATCH] Add avalon-framework impl classes
On Tue, 23 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: I'll simply try whether meta-sourceresolve builds without fortress-tools to see whether it is unneeded here as well. I think I need your help here, Stephen. excalibur-sourceresolve and excalibur-meta-sourceresolve compile the same classes using the same build file and target and claim to produce exactly the same jars. They only differ in their stated dependencies. Are they the same project? If so, we should probably drop meta-sourceresolve. In traditional Gump, excalibur-xmlutils builds since Gump finds the jar produced by excalibur-sourceresolve. Python Gump on the other hand knows that excalibur-meta-sourceresolve hasn't been built and this causes the pre-req failures upstream. It turns out that xmlutils compiles just fine against the jar created by excalibur-sourceresolve - and so would Cocoon. I'm puzzled. Right now I'd probably replace excalibur-meta-sourceresolve with excalibur-sourceresolve all over the place. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][PATCH] Add avalon-framework impl classes
Stefan Bodewig wrote: On Tue, 23 Mar 2004, Stephen McConnell [EMAIL PROTECTED] wrote: I'll be digging into the remaining cocoon/avalon dependencies this week Thanks a lot. That should get the coocoon depedencies green across the board. For the old, traditional Gump builds, they already are. I can't see why there should be any dependency on fortress in Cocoon. Cocoon doesn't state one and I don't see a path that would make it an inherited dependency. I'm guessing its related to the following: cocoon -- excalibur-xmlutil -- excalibur-meta-sourceresolve -- fortress (tools and container) And I figure that excalibur-xmlutil can probably be linked to the excalibur-sourceresolve thereby eliminating the fortress dependency. Stephen. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][PATCH] Add avalon-framework impl classes
On Tue, 23 Mar 2004, Stephen McConnell [EMAIL PROTECTED] wrote: I'm guessing its related to the following: cocoon -- excalibur-xmlutil -- excalibur-meta-sourceresolve -- fortress (tools and container) Yes, I didn't see the meta when I looked at it. See my other mail on why it works for traditional Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon-excalibur.xml
bodewig 2004/03/23 02:11:41 Modified:project avalon-excalibur.xml Log: Remove excalibur-meta-sourceresolve Revision ChangesPath 1.122 +2 -34 gump/project/avalon-excalibur.xml Index: avalon-excalibur.xml === RCS file: /home/cvs/gump/project/avalon-excalibur.xml,v retrieving revision 1.121 retrieving revision 1.122 diff -u -r1.121 -r1.122 --- avalon-excalibur.xml 19 Mar 2004 11:02:39 - 1.121 +++ avalon-excalibur.xml 23 Mar 2004 10:11:41 - 1.122 @@ -607,7 +607,7 @@ depend project=ant inherit=runtime/ depend project=avalon-framework runtime=true id=combined/ depend project=excalibur-pool inherit=runtime/ -depend project=excalibur-meta-sourceresolve inherit=runtime/ +depend project=excalibur-sourceresolve inherit=runtime/ depend project=xml-xerces/ depend project=xml-xalan2/ @@ -813,38 +813,6 @@ to=[EMAIL PROTECTED]/ /project -project name=excalibur-meta-sourceresolve -packageorg.apache.excalibur.source/package - -ant basedir=sourceresolve target=jar -property name=package-version value=@@DATE@@/ -property name=junit.failonerror value=true/ -property name=do.checkstyle value=true/ -property name=skip.dependencies value=true/ -property name=project.version value=@@DATE@@/ -/ant - -depend property=excalibur-fortress-tools.jar project=avalon-fortress-tools inherit=runtime/ -depend property=qdox.jar project=phoenix-qdox/ -depend project=excalibur-pool runtime=true/ -depend project=ant inherit=runtime/ -option project=checkstyle inherit=runtime/ -depend project=junit/ -depend project=avalon-framework runtime=true id=combined/ -depend project=avalon-fortress-container/ -depend project=avalon-fortress-tools runtime=true/ -depend project=xml-xerces/ -depend project=xml-xalan2/ - -work nested=sourceresolve/target/classes/ -work nested=sourceresolve/target/test-classes/ - -home nested=sourceresolve/ -jar name=target/excalibur-sourceresolve-@@DATE@@.jar/ - -nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ -/project - project name=excalibur-store packageorg.apache.excalibur.store/package @@ -1036,7 +1004,7 @@ depend project=excalibur-instrument/ depend project=excalibur-component id=component/ depend project=excalibur-pool/ -depend property=excalibur-sourceresolve.jar project=excalibur-meta-sourceresolve/ +depend property=excalibur-sourceresolve.jar project=excalibur-sourceresolve/ depend project=excalibur-store/ !-- test-time dependencies -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: last night's failure]
Original Message Subject: last night's failure Date: Tue, 23 Mar 2004 10:57:50 +0100 From: Leo Simons [EMAIL PROTECTED] Newsgroups: gmane.comp.jakarta.gump Gump didn't run last night on LSD. I can't really figure out why right now. Here's the contents of /data3/gump/log/gumpy.html: XMP --- G U M P Y --- G U M P Y Gump run on lsd at Tue Mar 23 02:00:01 CET 2004 GUMP TARGET : all GUMP: /data3/gump/gump-install GUMP W/S: /data3/gump/ GUMP LOG: /data3/gump/log --- G U M P Y GUMPY.sh version 1.0.6 --- G U M P Y --- G U M P Y ? local-env-py.sh ? lsd.xml P project/antworks-importer.xml P project/avalon.xml P project/db-ojb.xml P project/jakarta-jmeter.xml P project/jakarta-poi.xml P project/smartfrog.xml --- G U M P Y declare -x CLASSPATH=/usr/java/j2sdk1.4.2//lib/tools.jar declare -x FORREST_HOME=/home/ajack/opt/forrest declare -x GUMP=/data3/gump/gump-install declare -x GUMPY_VERSION=1.0.6 declare -x GUMP_DATE=Tue Mar 23 02:00:01 CET 2004 declare -x GUMP_FINAL_LOG=/data3/gump/log/gumpy.html declare -x GUMP_HOST=lsd declare -x GUMP_LOG=/data3/gump//tmp/gumpy.html declare -x GUMP_LOG_DIR=/data3/gump/log declare -x GUMP_PROFILE_LOG_DIR=/data3/gump/log/myprofile declare -x GUMP_PYTHON=/data3/gump/gump-install/python declare -x GUMP_TARGET=all declare -x GUMP_TMP=/data3/gump/gump-install/tmp declare -x GUMP_WORKSPACE=lsd declare -x GUMP_WS=/data3/gump/ declare -x GUMP_WS_TMP=/data3/gump//tmp declare -x HOME=/home/ajack declare -x HOST_LOCAL_ENV=local-env-py-lsd.sh declare -x JAVA_HOME=/usr/java/j2sdk1.4.2/ declare -x LOCAL_ENV=local-env-py.sh declare -x LOGNAME=ajack declare -x MAVEN_HOME=/home/ajack/opt/maven-1.0-rc1 declare -x OLDPWD=/data3/gump/gump-install declare -x PATH=/usr/bin:/bin:/home/ajack/opt/forrest/bin:/home/ajack/opt/maven-1.0-rc1/bin:/usr/java/j2sdk1.4.2//bin declare -x PWD=/data3/gump/gump-install declare -x PYTHONPATH=/data3/gump/gump-install/python declare -x ROOT=/data3/gump declare -x SEPARATOR=--- G U M P Y declare -x SHELL=/bin/sh declare -x SHLVL=2 Python 2.2.3 --- G U M P Y Clean *.pyc files. --- G U M P Y Traceback (most recent call last): File gump/integrate.py, line 85, in ? irun() File gump/integrate.py, line 56, in irun workspace=WorkspaceLoader().load(ws, 0) File /data3/gump/gump-install/python/gump/model/loader.py, line 96, in load XMLServer.map, XMLTracker.map) File /data3/gump/gump-install/python/gump/model/workspace.py, line 384, in complete project.complete(self) File /data3/gump/gump-install/python/gump/model/project.py, line 468, in complete dependency.getProject().complete(workspace) File /data3/gump/gump-install/python/gump/model/project.py, line 468, in complete dependency.getProject().complete(workspace) File /data3/gump/gump-install/python/gump/model/project.py, line really big snip of identical errors 468, in complete dependency.getProject().complete(workspace) File /data3/gump/gump-install/python/gump/model/project.py, line 461, in complete if self.ant: self.ant.expand(self,workspace) File /data3/gump/gump-install/python/gump/model/ant.py, line 52, in expand self.expandProperties(project,workspace) File /data3/gump/gump-install/python/gump/model/ant.py, line 61, in expandProperties self.importProperty(property) File /data3/gump/gump-install/python/gump/model/property.py, line 164, in importProperty self.addProperty(Property(xmlproperty,self)) File /data3/gump/gump-install/python/gump/model/property.py, line 27, in __init__ NamedModelObject.__init__(self,xml.getName(),xml,parent) File /data3/gump/gump-install/python/gump/model/object.py, line 138, in __init__ ModelObject.__init__(self,xml,owner) File /data3/gump/gump-install/python/gump/model/object.py, line 40, in __init__ FileHolder.__init__(self) File /data3/gump/gump-install/python/gump/utils/file.py, line 154, in __init__ self.filelist=FileList(self) File /data3/gump/gump-install/python/gump/utils/file.py, line 118, in __init__ Ownable.__init__(self,owner) File /data3/gump/gump-install/python/gump/utils/owner.py, line 27, in __init__ self.setOwner(owner) File /data3/gump/gump-install/python/gump/utils/owner.py, line 33, in setOwner if self == owner: RuntimeError: maximum recursion depth exceeded Integration completed with exit code : 1 Failed to integrate, exited with [1], exiting... /XMP I don't have time to investigate further right now, I'm afraid. -- cheers, - Leo Simons
Re: [Fwd: last night's failure]
On Tue, 23 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: Gump didn't run last night on LSD. I can't really figure out why right now. I think it has been caused by the circular dependency between two jicarilla projects (that I've just removed by commenting out jicarilla in the Gump descriptor).[1] Unlike Jenny, GUMPY doesn't detect the cycle and dies in an infinite recursion. Stefan Footnotes: [1] http://marc.theaimsgroup.com/?l=gumpm=108002496013392w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump nag mails (was Re: STANDARD_1_0_BRANCH doesn't build)
Stefan Bodewig wrote: Hi, Gump has been trying to tell you about the build problem for the past three weeks, but looking at the list archives, the nag mails have never been delivered to the list. Gump is configured to use Ted Husted's address to send the nag mails for any taglib failures. The only reason I can imagine that the mails are not going to the list is that Ted is no longer subscribed to the list (at least not using the specific address that Gump uses) and the moderator didn't moderate the Gump nag mails in. taglibs-dev has a backlog of 58 moderation requests pending. Ted Husted unsubscribed from taglibs-dev on 31 Mar 2003. taglibs-dev has one moderator defined: [EMAIL PROTECTED] As a temporary fix, I added [EMAIL PROTECTED] to the 'allow' list for this mailing list. - Sam Ruby Two questions: (1) Dear moderator, why didn't you accept/allow the nag messages? Are they unwanted by the taglibs community? If so, it would be easier to turn nagging off in Gump than to silently discard them. At least the Gump community wouldn't think you'd know about any problems. Since all taglibs committers (all Apache committers) are Gump committers as well, you can easily disable nagging yourself. (2) If nagging is wanted by the community, should Gump use a different sender address than Ted's? Any address would do as long as the mails get moderated in. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-37) user.dir not set correctly in forked JVM
Message:
A new issue has been created in JIRA.
-
View the issue:
http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-37
Here is an overview of the issue:
-
Key: GUMP-37
Summary: user.dir not set correctly in forked JVM
Type: Bug
Status: Unassigned
Priority: Major
Project: Gump
Components:
Python
Assignee:
Reporter: Sebb
Created: Tue, 23 Mar 2004 4:52 AM
Updated: Tue, 23 Mar 2004 4:52 AM
Description:
JMeter testing is getting some odd errors, which appear to be because user.dir is not
being set according to the dir attribute of the java command.
The same code works OK on traditional Gump - e.g. Covalent.
build.xml looks like this:
echo
gump.run = ${gump.run}
java.awt.headless = ${java.awt.headless}
test.headless = ${test.headless}
user.dir = ${user.dir}
basedir = ${basedir}
/echo
java classname=org.apache.jorphan.test.AllTests fork=yes dir=${basedir}/bin
...
The output on LSD is:
[echo]gump.run = true
[echo]java.awt.headless = true
[echo]test.headless = true
[echo]user.dir = /data3/gump/jakarta-jmeter
[echo]basedir = /data3/gump/jakarta-jmeter
[echo]
[java] Executing '/usr/java/j2sdk1.4.2/jre/bin/java' with arguments:
...
[java] '-Duser.dir=/data3/gump/jakarta-jmeter'
...
[java] The ' characters around the executable and arguments are
[java] not part of the command.
[java] Setting up logging props using file: ./jmetertest.properties
[java] Using initializeProperties() from org.apache.jmeter.util.JMeterUtils
[java] Setting up initial properties using: ./jmetertest.properties
[java] Initializing Properties: ./jmetertest.properties
[java] Setting JMeter home: /data3/gump/jakarta-jmeter/./..
[java] java.version=1.4.2
[java] java.home=/usr/java/j2sdk1.4.2/jre
[java] user.dir=/data3/gump/jakarta-jmeter
The output on Covalent is:
[echo]gump.run = true
[echo]java.awt.headless = true
[echo]test.headless = true
[echo]user.dir = /data/gump/jakarta-jmeter
[echo]basedir = /data/gump/jakarta-jmeter
[echo]
[java] Setting up logging props using file: ./jmetertest.properties
[java] Using initializeProperties() from org.apache.jmeter.util.JMeterUtils
[java] Setting up initial properties using: ./jmetertest.properties
[java] Initializing Properties: ./jmetertest.properties
[java] Setting JMeter home: /data/gump/jakarta-jmeter/bin/./..
[java] java.version=1.4.1_02
[java] java.home=/usr/j2sdk1.4.1_02/jre
[java] user.dir=/data/gump/jakarta-jmeter/bin
As can be seen, in the Covalent case, user.dir is set to basedir/bin, whereas on LSD,
user.dir is the same as basedir - i.e. the bin subdirectory appears to have been lost.
This affects the JMeter home setting, which in turn causes some tests to fail.
The actual working directory on Gumpy appears to be OK - which is why the test works
at least partially - it's just that the property user.dir is incorrect.
Surely user.dir should always point to the current working directory?
Is it perhaps being (incorrectly) overridden by Gumpy?
-
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] Created: (GUMP-38) Does cope with circular dependencies
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-38 Here is an overview of the issue: - Key: GUMP-38 Summary: Does cope with circular dependencies Type: Bug Status: Unassigned Priority: Major Project: Gump Components: Python Assignee: Reporter: Adam Jack Created: Tue, 23 Mar 2004 6:33 AM Updated: Tue, 23 Mar 2004 6:33 AM Description: 1) Circular includes in metadata(href links that circle) are not detected. Logic will spin until it crashes. 2) Circular dependencies (perhaps within project property based dependencies) are not detected. Logic will spin until it crashes. (most recent call last): File gump/integrate.py, line 85, in ? irun() File gump/integrate.py, line 56, in irun workspace=WorkspaceLoader().load(ws, 0) File /data3/gump/gump-install/python/gump/model/loader.py, line 96, in load XMLServer.map, XMLTracker.map) File /data3/gump/gump-install/python/gump/model/workspace.py, line 384, in complete project.complete(self) File /data3/gump/gump-install/python/gump/model/project.py, line 468, in complete dependency.getProject().complete(workspace) File /data3/gump/gump-install/python/gump/model/project.py, line 468, in complete dependency.getProject().complete(workspace) File /data3/gump/gump-install/python/gump/model/project.py, line really big snip of identical errors 468, in complete dependency.getProject().complete(workspace) File /data3/gump/gump-install/python/gump/model/project.py, line 461, in complete if self.ant: self.ant.expand(self,workspace) File /data3/gump/gump-install/python/gump/model/ant.py, line 52, in expand self.expandProperties(project,workspace) File /data3/gump/gump-install/python/gump/model/ant.py, line 61, in expandProperties self.importProperty(property) File /data3/gump/gump-install/python/gump/model/property.py, line 164, in importProperty self.addProperty(Property(xmlproperty,self)) File /data3/gump/gump-install/python/gump/model/property.py, line 27, in __init__ NamedModelObject.__init__(self,xml.getName(),xml,parent) File /data3/gump/gump-install/python/gump/model/object.py, line 138, in __init__ ModelObject.__init__(self,xml,owner) File /data3/gump/gump-install/python/gump/model/object.py, line 40, in __init__ FileHolder.__init__(self) File /data3/gump/gump-install/python/gump/utils/file.py, line 154, in __init__ self.filelist=FileList(self) File /data3/gump/gump-install/python/gump/utils/file.py, line 118, in __init__ Ownable.__init__(self,owner) File /data3/gump/gump-install/python/gump/utils/owner.py, line 27, in __init__ self.setOwner(owner) File /data3/gump/gump-install/python/gump/utils/owner.py, line 33, in setOwner if self == owner: RuntimeError: maximum recursion depth exceeded Integration completed with exit code : 1 Failed to integrate, exited with [1], exiting... - 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]
cvs commit: gump/project avalon.xml
mcconnell2004/03/23 06:33:31 Modified:project avalon.xml Log: Add merlin-unit project. Revision ChangesPath 1.41 +24 -1 gump/project/avalon.xml Index: avalon.xml === RCS file: /home/cvs/gump/project/avalon.xml,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- avalon.xml23 Mar 2004 06:38:10 - 1.40 +++ avalon.xml23 Mar 2004 14:33:30 - 1.41 @@ -1173,7 +1173,6 @@ depend project=ant inherit=runtime/ depend project=junit/ depend project=xml-xerces/ -depend project=merlin-api/ depend project=avalon-repository-api/ depend project=avalon-repository-spi/ depend project=avalon-repository-util/ @@ -1193,6 +1192,30 @@ /project +project name=merlin-unit +packageorg.apache.avalon.merlin/package +ant basedir=merlin/kernel/unit target=jar +property name=project.version value=@@DATE@@/ +/ant + +depend project=ant inherit=runtime/ +depend project=junit/ +depend project=xml-xerces/ +depend project=avalon-repository-api/ +depend project=avalon-repository-spi/ +depend project=avalon-repository-util/ +depend project=avalon-repository-main/ + +mkdir dir=merlin/kernel/unit/target/classes/ +work nested=merlin/kernel/unit/target/classes/ +mkdir dir=merlin/kernel/unit/target/test-classes/ +work nested=merlin/kernel/unit/target/test-classes/ +home nested=merlin/kernel/unit/ +jar name=target/merlin-unit-@@DATE@@.jar/ +javadoc nested=merlin/kernel/unit/target/docs/apidocs/ +nag to=[EMAIL PROTECTED] + from=Gump Integration Build lt;[EMAIL PROTECTED]gt;/ +/project /module - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: last night's failure]
Gump didn't run last night on LSD. I can't really figure out why right now. I think it has been caused by the circular dependency between two jicarilla projects (that I've just removed by commenting out jicarilla in the Gump descriptor).[1] Unlike Jenny, GUMPY doesn't detect the cycle and dies in an infinite recursion. Gumpy tries to detect/handle this (at the project dependency level) but I am pretty certain it doesn't at the metadata load level [following URLs]. That said, this certainly looks like an issue at the dependency resolution level, so that logic needs to be improved. Maybe the logic doesn't extend to property-based dependencies or something. We need to add unit tests for this. I've added: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-38 Thanks Stefan (and traditional) for spotting this. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][PATCH] Add avalon-framework impl classes
I currently don't understand why Gump on LSD thinks Cocoon would depend on avalon-fortress-container, but the Gump instance on covalent.net tries to build it[1]. I wonder if the removal of the 'full dependencies' and 'full dependees' tables (on 'working projects') is a good thing or not. It might be nice in this case. It seems to me that cocoon depends upon xmlutil: http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon.html#Project+Dependenci es and excalibur-xmlutil depends upon avalon-fortress-container: http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-xmlutil.html ... however (unfortunately) without the full depends information the trail goes somewhat cold. Luckily we can follow the pre-req fails: excalibur-meta-sourceresolve avalon-fortress-tools avalon-fortress-container We need a nicer way to determine this path. Looking at this list I see the dependency is runtime, not compile time. I'm not awake enough to determine if it is misguided (or not) to set this as pre-requisite failed or not. Thoughts? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-taglibs.xml
martinc 2004/03/23 07:34:35 Modified:project jakarta-taglibs.xml Log: Set myself as the sender of nag messages to Jakarta Taglibs. Revision ChangesPath 1.61 +26 -26gump/project/jakarta-taglibs.xml Index: jakarta-taglibs.xml === RCS file: /home/cvs/gump/project/jakarta-taglibs.xml,v retrieving revision 1.60 retrieving revision 1.61 diff -u -r1.60 -r1.61 --- jakarta-taglibs.xml 27 Feb 2004 09:22:56 - 1.60 +++ jakarta-taglibs.xml 23 Mar 2004 15:34:35 - 1.61 @@ -39,7 +39,7 @@ jar name=dist/application/taglibs-application.jar/ license name=LICENSE/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-benchmark @@ -55,7 +55,7 @@ javadoc nested=dist/doc/doc/benchmark-doc/javadoc/ jar name=dist/benchmark/taglibs-benchmark.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-bsf @@ -73,7 +73,7 @@ javadoc nested=dist/doc/doc/bsf-doc/javadoc/ jar name=dist/bsf/taglibs-bsf.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-cache @@ -93,7 +93,7 @@ javadoc nested=dist/doc/doc/cache-doc/javadoc/ jar name=dist/cache/taglibs-cache.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-datetime @@ -110,7 +110,7 @@ javadoc nested=dist/doc/doc/datetime-doc/javadoc/ jar name=dist/datetime/taglibs-datetime.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-dbtags @@ -127,7 +127,7 @@ javadoc nested=dist/doc/doc/dbtags-doc/javadoc/ jar name=dist/dbtags/taglibs-dbtags.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-i18n @@ -143,7 +143,7 @@ javadoc nested=dist/doc/doc/i18n-doc/javadoc/ jar name=dist/i18n/taglibs-i18n.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-input @@ -159,7 +159,7 @@ javadoc nested=dist/doc/doc/input-doc/javadoc/ jar name=dist/input/taglibs-input.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-io @@ -175,7 +175,7 @@ javadoc nested=dist/doc/doc/io-doc/javadoc/ jar name=dist/io/taglibs-io.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-jmstags @@ -203,7 +203,7 @@ javadoc nested=dist/doc/doc/jmstags-doc/javadoc/ jar name=dist/jmstags/taglibs-jmstags.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-jndi @@ -219,7 +219,7 @@ javadoc nested=dist/doc/doc/jndi-doc/javadoc/ jar name=dist/jndi/taglibs-jndi.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-log @@ -238,7 +238,7 @@ javadoc nested=dist/doc/doc/log-doc/javadoc/ jar name=dist/log/taglibs-log.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-mailer @@ -257,7 +257,7 @@ javadoc nested=dist/doc/doc/mailer-doc/javadoc/ jar name=dist/mailer/taglibs-mailer.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project project name=jakarta-taglibs-page @@ -273,7 +273,7 @@ javadoc nested=dist/doc/doc/page-doc/javadoc/ jar name=dist/page/taglibs-page.jar/ nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin
Re: [GUMP][PATCH] Add avalon-framework impl classes
On Tue, 23 Mar 2004, Adam Jack [EMAIL PROTECTED] wrote: It seems to me that cocoon depends upon xmlutil: The dependency is there - see later that thread - I just didn't see it since I missed that xmlutils depended on meta-sourceresolve and not on sourceresolve (which has no fortress dependency). Sorry about the confusion Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New moderator (was Re: Gump nag mails (was Re: STANDARD_1_0_BRANCH doesn't build))
On 23.03.2004, at 16:41, Martin Cooper wrote: apmail folks, Please add me as a moderator of the following lists: [EMAIL PROTECTED] [EMAIL PROTECTED] Thanks. Done, added [EMAIL PROTECTED] as a moderator of the lists above. Cheers, Erik smime.p7s Description: S/MIME cryptographic signature
cvs commit: gump/project jstl-jsp-12.xml
bodewig 2004/03/23 08:29:05 Modified:project jstl-jsp-12.xml Log: Make Martin the sender for nags of the jstl-1.2 branch as well Revision ChangesPath 1.5 +1 -1 gump/project/jstl-jsp-12.xml Index: jstl-jsp-12.xml === RCS file: /home/cvs/gump/project/jstl-jsp-12.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jstl-jsp-12.xml 27 Feb 2004 09:22:56 - 1.4 +++ jstl-jsp-12.xml 23 Mar 2004 16:29:05 - 1.5 @@ -63,7 +63,7 @@ jar name=standard/standard/lib/jstl.jar id=jstl / jar name=standard/standard/lib/standard.jar id=standard / nag to=[EMAIL PROTECTED] - from=Ted Husted lt;[EMAIL PROTECTED]gt;/ + from=Martin Cooper lt;[EMAIL PROTECTED]gt;/ /project /module - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RT] href considered harmful
Descriptors living elsewhere has proven to be confusing for users, and it has led to duplicate project descriptors on more than one occassion. What about projects which do not contain an apache committer? I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I am +1 for apache projects, since our cvs is open to all committers, but how do we handle others? Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] href considered harmful
Gump is a social experiment, and this part of the experiment has shown to be a negative and annoying factor. I feel that my own recent experiences with jicarilla are an excellent example: even with an active and experienced member of the core gump group trying to actively maintain gump descriptors in sourceforge cvs, things break and the workflow is nothing short of a nightmare. It is a tough decision to remove a feature (like href) that has such potential for 'community outreach'. It seems such a good idea (to avoid CVS bound, and distribute responsibility) and that it can't be bad, can it? I think it can... I think we have to review exactly where we stand w.r.t to the Gump workflow, and recognize that we tried to distribute metadata management too soon for the communities. Sure, for an expert Gump metadata is simple, but it does have a lot of complex choices (to support reality). The combinatorials of Gump metadata (when merged) are quite daunting. With no generator/wizards/overviewer/compiler/tester we are expecting the community to throw metadata up to us and hope it runs. That is counter productive to our goal of happy communities. Gump metadata is like having a complex development in a runtime interpreted language with nightly runs based upon untested code in a repository. This is analogous to punch cards batch runs and requests more patience/discipline/investment than communities will give. [Heck, this *is* the early days of my writing Gumpy in Python checking in to test remotely, prior to getting some unit tests. ;-) Hard, hard, work --a frustrating bad development environment.] I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I think we are in a state where this is a good thing, for those that can. Gumpmeisters need to help communities (until we code tools, wizards/whatever to help generate that.) I don't think 'hrefs' are themselves the core problem, but deprecating them help bring things into the hands of the experts, so I am for it. (PS: I love writing like this every now and then...it's a writing exercise; don't take it /too/ seriously :D) ;-) Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jrefactory.xml
antoine 2004/03/23 12:55:05 Modified:project jrefactory.xml Log: changed the target invoked for the jrefactory alone Revision ChangesPath 1.16 +20 -1 gump/project/jrefactory.xml Index: jrefactory.xml === RCS file: /home/cvs/gump/project/jrefactory.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- jrefactory.xml27 Feb 2004 09:22:56 - 1.15 +++ jrefactory.xml23 Mar 2004 20:55:05 - 1.16 @@ -27,14 +27,33 @@ project name=jrefactory packageorg.acm.seguin/package -ant target=jar/ +ant target=JRefactory.jar/ depend project=ant inherit=runtime/ depend project=xml-xerces/ depend project=jaxen/ depend project=junit/ +depend project=dom4j/ +depend project=javacc/ option project=jrefactory-prettynoclasspath//option work nested=ant.build/classes/ work nested=test/classes/ +work nested=jar/ErrorList.jar/ +work nested=jar/ProjectViewer.jar/ +work nested=jar/bcel.jar/ +work nested=jar/collect.jar/ +work nested=jar/core.jar/ +work nested=jar/coreplugin.jar/ +work nested=jar/findbugs.jar/ +work nested=jar/findbugsGUI.jar/ +work nested=jar/gjc-rt.jar/ +work nested=jar/jai_codec.jar/ +work nested=jar/jai_core.jar/ +work nested=jar/jbuilder.jar/ +work nested=jar/jedit.jar/ +work nested=jar/openide.jar/ +work nested=jar/primetime.jar/ +work nested=jar/proguard.jar/ +work nested=jar/saxpath-1.0-fcs.jar/ jar name=ant.build/lib/jrefactory.jar/ /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] href considered harmful
Adam Jack wrote: Gump is a social experiment, and this part of the experiment has shown to be a negative and annoying factor. I feel that my own recent experiences with jicarilla are an excellent example: even with an active and experienced member of the core gump group trying to actively maintain gump descriptors in sourceforge cvs, things break and the workflow is nothing short of a nightmare. It is a tough decision to remove a feature (like href) that has such potential for 'community outreach'. It seems such a good idea (to avoid CVS bound, and distribute responsibility) and that it can't be bad, can it? I think it can... I think we have to review exactly where we stand w.r.t to the Gump workflow, and recognize that we tried to distribute metadata management too soon for the communities. Sure, for an expert Gump metadata is simple, but it does have a lot of complex choices (to support reality). The combinatorials of Gump metadata (when merged) are quite daunting. With no generator/wizards/overviewer/compiler/tester we are expecting the community to throw metadata up to us and hope it runs. That is counter productive to our goal of happy communities. Gump metadata is like having a complex development in a runtime interpreted language with nightly runs based upon untested code in a repository. This is analogous to punch cards batch runs and requests more patience/discipline/investment than communities will give. [Heck, this *is* the early days of my writing Gumpy in Python checking in to test remotely, prior to getting some unit tests. ;-) Hard, hard, work --a frustrating bad development environment.] Adam, I agree very much with all you have written. May I ask you another question : if I would like to replace the use of ls and cat in gumpy with pure python code (like sync), do you have any suggestions ? Do we already have testcases for the use of ls and cat in the tools.py ? Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jrefactory.xml
[EMAIL PROTECTED] wrote: antoine 2004/03/23 12:55:05 Modified:project jrefactory.xml Log: changed the target invoked for the jrefactory alone Revision ChangesPath 1.16 +20 -1 gump/project/jrefactory.xml Index: jrefactory.xml === Adam, can you do a sanity check on my changes. I changed the target invoked for the project jrefactory, because the all target redid the pretty project (I guess we do not want to build a project twice in a run), and also it deleted the original jar produced in pretty and rebuilt it under another name, which the dependencies of pretty (xdoclet) did not know. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pure Python (was Re: [RT] href considered harmful)
if I would like to replace the use of ls and cat in gumpy with pure python code (like sync), do you have any suggestions ? Do we already have testcases for the use of ls and cat in the tools.py ? Huh? I think this has already been done (see FileHolder in files.py), I just left the old code in there (in tools.py). Did I leave tests in by accident that cause problems? Do you have any real runtime problems? I thought your sync.py not the last piece in that port to pure. The only remaining thing I'm aware off that isn't pure Python that ought be pure is 'pgrep', which is broken anyway and logged into JIRA as such. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fog factor
Question for a gump newbi. As the fog clears - you would anticipate a fog factor approaching zero. In the context of gump - is zero fog a good thing? Summary - I don't understand the fog factor index - can anyone explain it or point me to relevant documentation? Cheers, Steve. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Question for a gump newbi. As the fog clears - you would anticipate a fog factor approaching zero. Maybe it should, a boundary value is more comparable. In the context of gump - is zero fog a good thing? Summary - I don't understand the fog factor index - can anyone explain it or point me to relevant documentation? For today, quite the reverse. The larger the better. Gump does what Gump does, and some projects support that better than others. FOG is an attempt to translate that into something simple/comparable/tangible so folks can get a quick insight into something's suitability as a Gump dependency for their project. [It doesn't today directly translate to any other project 'quality' metric, but it might one day.] regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Adam Jack wrote: Question for a gump newbi. As the fog clears - you would anticipate a fog factor approaching zero. Maybe it should, a boundary value is more comparable. In the context of gump - is zero fog a good thing? Summary - I don't understand the fog factor index - can anyone explain it or point me to relevant documentation? For today, quite the reverse. The larger the better. Gump does what Gump does, and some projects support that better than others. FOG is an attempt to translate that into something simple/comparable/tangible so folks can get a quick insight into something's suitability as a Gump dependency for their project. [It doesn't today directly translate to any other project 'quality' metric, but it might one day.] I had a hunch that this was the case - so current-fog ~= clarity and as such real fog may perhaps be better defined as real-fog = 1/(current-fog) If that's is a correct (reasonable) assumption - is this something I should post to JIRA? Cheers, Stephen. 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/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Maybe it should, a boundary value is more comparable. Sorry, I meant to type bounded value as in 0-1. On this course they showed 30 of us fives line of text, and asked us to count the number of Fs. Many folks found 3, and some found as many as 7. As time went on more and more folks found the 7, as they noticed the Fs hidden on the end in the simple words like 'of' that they mentally/unintentionally skipped. I was one of the two who just couldn't make it out of the 3 box even after everybody else had defected. I just can't see the words I type compared with the words I think. Odd a little frustrating/embarrasing... Thankfully code gets strictly interpretteded... ;-) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
If that's is a correct (reasonable) assumption - is this something I should post to JIRA? Please do add all comments you have on FOG to JIRA at: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-21 regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Adam Jack wrote: If that's is a correct (reasonable) assumption - is this something I should post to JIRA? Please do add all comments you have on FOG to JIRA at: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-21 Done! Cheers, Steve. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
On Tue, 23 Mar 2004, Adam Jack wrote: Question for a gump newbi. As the fog clears - you would anticipate a fog factor approaching zero. Maybe it should, a boundary value is more comparable. In the context of gump - is zero fog a good thing? Summary - I don't understand the fog factor index - can anyone explain it or point me to relevant documentation? For today, quite the reverse. The larger the better. I think part of the problem is that people think of fog as that murky stuff that nobody likes, instead of FOG as Friend Of Gump. If it was clear that it's a friendship index, I don't think there would be a need to invert the sense, because a higher friendship index sounds better than a low one. ;-) My 2 cents... -- Martin Cooper Gump does what Gump does, and some projects support that better than others. FOG is an attempt to translate that into something simple/comparable/tangible so folks can get a quick insight into something's suitability as a Gump dependency for their project. [It doesn't today directly translate to any other project 'quality' metric, but it might one day.] 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: fog factor
Stephen McConnell wrote: Adam Jack wrote: Question for a gump newbi. As the fog clears - you would anticipate a fog factor approaching zero. Maybe it should, a boundary value is more comparable. In the context of gump - is zero fog a good thing? Summary - I don't understand the fog factor index - can anyone explain it or point me to relevant documentation? For today, quite the reverse. The larger the better. Gump does what Gump does, and some projects support that better than others. FOG is an attempt to translate that into something simple/comparable/tangible so folks can get a quick insight into something's suitability as a Gump dependency for their project. [It doesn't today directly translate to any other project 'quality' metric, but it might one day.] I had a hunch that this was the case - so current-fog ~= clarity and as such real fog may perhaps be better defined as real-fog = 1/(current-fog) If that's is a correct (reasonable) assumption - is this something I should post to JIRA? FoG stands for Friend of Gump, not for fog as in the white stuff suspended in the air that doesn't allow you to see thru. Adam, I think we should get rid of FoG entirely until we have a better solution. It is causing more harm than good. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] href considered harmful
Leo Simons wrote: I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I agree with you as a general principle. Too bad that the entire cocoon build system relies on the gump descriptor for its blocks and this is going to be so for a while. If you deprecate href, cocoon will be seriously damaged. Now, I am the one to blame for this, but my rationale was to keep gump and cocoon in synch by making sure that everytime you built cocoon, you were also testing if the gump descriptor was right. Of course, only gump can do the full check, but the cocoon build can help a little bit. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 11 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed [EMAIL PROTECTED]: freemarker/freemarker failed [EMAIL PROTECTED]: jakarta-tapestry/ognl failed [EMAIL PROTECTED]: javasrc/javasrc failed [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed [EMAIL PROTECTED]: jakarta-turbine-tdk/jakarta-turbine-tdk-docs failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed [EMAIL PROTECTED]: castor/castor failed [EMAIL PROTECTED]: jrefactory/jrefactory failed [EMAIL PROTECTED]: jgen/jgen failed G U M P [EMAIL PROTECTED]: webwork/webwork failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project webwork has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/webwork/webwork.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Enable verbose output, due to 2 previous error(s). - Error - Failed with reason build failed - - - - - -- -- G U M P Gump performed this work: Work Name: build_webwork_webwork (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 22 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only [Working Directory: /data3/gump/webwork] - [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:92: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:96: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:102: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:107: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 15 errors BUILD FAILED /data3/gump/webwork/build.xml:167: Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268) at org.apache.tools.ant.Task.perform(Task.java:363) at org.apache.tools.ant.Target.execute(Target.java:301) at org.apache.tools.ant.Target.performTasks(Target.java:328)
Re: [RT] href considered harmful
On Tue, 23 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: the whole build breaking last night because some lameass sourceforge developer doesn't know how to write gump descriptors (even if it was me) annoys the hell out of me. It should not be possible. Absolutely true. Gump shouldn't break. Note that this is not limited to Gumpy, traditional Gump dies in Jenny as well when a circular dependency has been detected - it's just that our Gump installations went on and used the generated build.sh and update.sh files of the night before. The basic cause for that happening was the use of the 'href' attribute to link to remote descriptors accessed via webcvs. The basic cause was that somebody modified a descriptor without checking whether anything got broken by the change. ;-) href adds to this problem a lot, I agree. If you modify a descriptor that is in Gump's module, you can run ant verify before you commit the change - this is a lot harder to do (custom profile) if your descriptor is referenced via href. And delays like we still see them for anoncvs at sourceforge certainly make things worse. On the other hand, href has some potential that we shouldn't throw away. The ant-contrib project has two descriptors that are more or less maintained by me, no big deal, but take a look at the dom testsuite descriptors. Curt Arnold has written them. In particular, look at the very top of the descriptor for the copyright message and the license - this could never live in a Apache metadata module for legal reasons. Well, maybe it could since the license is less restrictive than the ASL, but you get the point. No webapp would enable anybody to put a different license on the descriptor, for whatever reason he/she should choose to do so. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jrefactory.xml
On 23 Mar 2004, [EMAIL PROTECTED] wrote: +work nested=jar/ErrorList.jar/ +work nested=jar/ProjectViewer.jar/ +work nested=jar/bcel.jar/ +work nested=jar/collect.jar/ +work nested=jar/core.jar/ +work nested=jar/coreplugin.jar/ +work nested=jar/findbugs.jar/ +work nested=jar/findbugsGUI.jar/ +work nested=jar/gjc-rt.jar/ +work nested=jar/jai_codec.jar/ +work nested=jar/jai_core.jar/ +work nested=jar/jbuilder.jar/ +work nested=jar/jedit.jar/ +work nested=jar/openide.jar/ +work nested=jar/primetime.jar/ +work nested=jar/proguard.jar/ +work nested=jar/saxpath-1.0-fcs.jar/ ugly. Any idea what the contents are? bcel.jar sounds like jakarta-bcel, collect could be commons-collections. JAI could be an installed package if other projects need it as well. saxpath is already somewhere as an installed package. In general I'd rather use a technique like project name=jai jar name=jar/jai_codec.jar/ jar name=jar/jai_core.jar/ /project inside the module combined with depend project=jai/ in the project for jars in CVS. This enables us to switch between using a jar from CVS, using an installed package and building a project from scratch more easily. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Adam, I think we should get rid of FoG entirely until we have a better solution. It is causing more harm than good. What is harm and what is refining discussion? If we remove it, what incentive do folks have to contribute improvements? I'll do whatever the group determines, but first teach me OSS 101 on such matters, please. Is this too bad to tolerate, or just bad enough to entice? Input? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
On Wed, 24 Mar 2004, Adam Jack wrote: Adam, I think we should get rid of FoG entirely until we have a better solution. It is causing more harm than good. IMHO, you just need to ensure that people understand what FoG means. The acronym by itself is pure confusion, so I'd suggest either picking another one or avoiding an acronym all together. -- Martin Cooper What is harm and what is refining discussion? If we remove it, what incentive do folks have to contribute improvements? I'll do whatever the group determines, but first teach me OSS 101 on such matters, please. Is this too bad to tolerate, or just bad enough to entice? Input? 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: BATCH: All dressed up, with nowhere to go...
On Tue, 23 Mar 2004, Adam Jack [EMAIL PROTECTED] wrote: Can we find a community e-mail address that would possible be willing to 'hear' these, and approach them? Difficult, the issues are too diverse. Let's look at them case by case [EMAIL PROTECTED]: webwork/webwork failed At least one missing dependcy. We just build this project as a detector for some Apache projects. I doubt that they are aware that Gump is building the project. [EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed The top item on my TODO list. A real API compatibility problem between mx4j and Axis. [EMAIL PROTECTED]: freemarker/freemarker failed Uses old jdom API. Same as webwork. [EMAIL PROTECTED]: jakarta-tapestry/ognl failed Tapestry is a problem in itself, since the Gump descriptor is inside the tapestry module. A manual nag together with a patch to the descriptor may help. Number two on my TODO list, helping hands welcome 8-) [EMAIL PROTECTED]: javasrc/javasrc failed Nag! [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed Simply needs 1.4.2_04 on LSD, not a problem with the project. [EMAIL PROTECTED]: jakarta-turbine-tdk/jakarta-turbine-tdk-docs failed Odd. Works fine on gump.covalent.net. We should work this out before we nag anybody. [EMAIL PROTECTED]: eyebrowse/eyebrowse failed Missing Mysql JDBC driver. Similar to webwork (they don't know what we are doing with their project). [EMAIL PROTECTED]: castor/castor failed Missing work entry. Similar to webwork, but this time we really need to build it since some of our projects (jetspeed, pluto) depend on it. [EMAIL PROTECTED]: jrefactory/jrefactory failed See webwork. It would probably suffice to turn the pretty printer it into an installed package. [EMAIL PROTECTED]: jgen/jgen failed Hasn't upgraded to later released versions of FOP in years (looks more or less dead[1]), will probably never build. Only project that depends on it is Turbine 3 which itself hasn't built since years. Could be turned into an installed package. On the other hand it is quite possible that they've never been told that jgen doesn't build against any recent FOP version. We could ask the FOP people for advice and send a patch to the jgen list to bring them up to FOP 0.20.5. Low on my personal priority list. Stefan Footnotes: [1] http://sourceforge.net/mailarchive/forum.php?forum_id=2500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] href considered harmful
On Wed, 24 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: No webapp would enable anybody to put a different license on the descriptor, for whatever reason he/she should choose to do so. do you really think that will actually become an issue? Not really. There may be the issue of ownership, though. I don't want anybody to modify *my* descriptor. Not in the domts case, but it could become an issue and maybe even is today. Do you think Curt Arnold would object to moving the descriptor, for example? I asked him where he wanted to put it. Since Curt is no Apache committer but wanted to be able to maintain it, he decided to put it on the W3C box. This issue could be resolved by a webapp or granting karma to Curt. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][PATCH] Add avalon-framework impl classes
On Tue, 23 Mar 2004, Adam Jack [EMAIL PROTECTED] wrote: I wonder if we need to present 'dependency paths' (at least from cause to project, if not between all projects) either as lists or (help willing) visual graphs. That would help a lot. Many people will probably be very surprised what their project indirectly depends on. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump-Check task (was: Re: [RT] href considered harmful)
Stefano Mazzocchi wrote: Leo Simons wrote: I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I agree with you as a general principle. Too bad that the entire cocoon build system relies on the gump descriptor for its blocks and this is going to be so for a while. If you deprecate href, cocoon will be seriously damaged. who said anything about deprecate? I said its harmful, that's different. I consider the use of static factories in java applications harmful, but its not like static methods will be deprecated anytime soon! :D I think no-one wants to actually disable the ability to use href. Now, I am the one to blame for this, but my rationale was to keep gump and cocoon in synch by making sure that everytime you built cocoon, you were also testing if the gump descriptor was right. Of course, only gump can do the full check, but the cocoon build can help a little bit. hmm. Good point. You want the ability to verify a project state is consistent with what gump expects it to be after a build, but only gump can verify that. Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Like Ozzie, I'm just a dreamer ;) -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon.xml
mcconnell2004/03/23 23:50:13 Modified:project avalon.xml Log: Add missing runtime dependencies. Revision ChangesPath 1.42 +9 -0 gump/project/avalon.xml Index: avalon.xml === RCS file: /home/cvs/gump/project/avalon.xml,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- avalon.xml23 Mar 2004 14:33:30 - 1.41 +++ avalon.xml24 Mar 2004 07:50:13 - 1.42 @@ -1084,6 +1084,9 @@ depend project=excalibur-lifecycle-api runtime=true/ depend project=excalibur-configuration runtime=true/ +depend project=avalon-util-exception runtime=true/ +depend project=avalon-util-env runtime=true/ + mkdir dir=merlin/activation/impl/target/classes/ work nested=merlin/activation/impl/target/classes/ mkdir dir=merlin/activation/impl/target/test-classes/ @@ -1180,6 +1183,9 @@ depend project=avalon-util-i18n / depend project=commons-cli / +depend project=avalon-util-exception runtime=true/ +depend project=avalon-util-env runtime=true/ + mkdir dir=merlin/kernel/cli/target/classes/ work nested=merlin/kernel/cli/target/classes/ mkdir dir=merlin/kernel/cli/target/test-classes/ @@ -1205,6 +1211,9 @@ depend project=avalon-repository-spi/ depend project=avalon-repository-util/ depend project=avalon-repository-main/ + +depend project=avalon-util-exception runtime=true/ +depend project=avalon-util-env runtime=true/ mkdir dir=merlin/kernel/unit/target/classes/ work nested=merlin/kernel/unit/target/classes/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project castor.xml
bodewig 2004/03/23 23:58:25 Modified:project castor.xml Log: Add missing work directory Revision ChangesPath 1.26 +7 -1 gump/project/castor.xml Index: castor.xml === RCS file: /home/cvs/gump/project/castor.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- castor.xml14 Mar 2004 22:05:37 - 1.25 +++ castor.xml24 Mar 2004 07:58:25 - 1.26 @@ -30,13 +30,14 @@ property name=version value=@@DATE@@/ /ant depend project=ant inherit=runtime/ -work nested=lib/xerces-J_1.4.0.jar/ +depend project=xerces-1.4.0/ depend project=ldapsdk/ depend project=jdbc/ depend project=jta/ depend project=jakarta-regexp/ depend project=jakarta-oro/ depend project=commons-logging/ +work nested=build/classes/ home nested=dist/ jar name=castor-@@DATE@@.jar/ jar name=castor-@@DATE@@-xml.jar/ @@ -50,6 +51,11 @@ Netscape Directory SDK for Java /description jar name=lib/ldapjdk_4.1.jar/ + /project + + !-- only until xml-xerces1 builds on LSD -- + project name=xerces-1.4.0 +jar name=lib/xerces-J_1.4.0.jar/ /project /module - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP][PATCH] Add avalon-framework impl classes
On Tue, 23 Mar 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Right now I'd probably replace excalibur-meta-sourceresolve with excalibur-sourceresolve all over the place. +1 We were thinking the same thing. I'm cc'ing [EMAIL PROTECTED] just for reference. Cool, I'll just go ahead and modify all descriptors I can touch - and then add meta-sourceresolve as a deprecated alternative name. Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
