Re: [daemon] Fwd: Compiling jsvc Win32
Dion Gillard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Who else from daemon should be on the PMC? The other two that survived the move with commit rights are mturk and jfclere. Since AFAIK, they both lurk on this list, I would guess that they would have added their names if they wanted it, but I haven't asked them myself :). On 7/9/07, Bill Barker [EMAIL PROTECTED] wrote: Dion Gillard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The lack of response on this: http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200707.mbox/ajax/[EMAIL PROTECTED] is telling. How dormant is daemon? Using jsvc on Windows has never been supported. The jsvc module is only for *nix systems. Windows systems should use procrun. Daemon is fairly mature, but not particularly dormant. It gets commits every few months. It could use some more eyes for systems like OS/X, but otherwise is relatively healthy for a commons project, aside from not having much PMC representation. -- Forwarded message -- From: JsD [EMAIL PROTECTED] Date: Jul 9, 2007 12:09 PM Subject: Re: Compiling jsvc Win32 To: [EMAIL PROTECTED] After finding out that one must have the latest version of Visual Studio to build, I decided to look for another route. Finally I found JavaService ( http://forge.objectweb.org/projects/javaservice/). This project comes pre-built and works like a charm. I strongly suggest this for those who do not wish to purchase or use Visual Studio. Cheers, JsD On 5/3/07, JsD [EMAIL PROTECTED] wrote: On 4/28/07, JsD [EMAIL PROTECTED] wrote: Hello, I am trying to compile from source on Windows XP using Cygwin. I have installed the latest make, autoconf, gcc in cygwin environment. The configure runs fine. When I try to make I get the following: /cygdrive/c/_other/_s/java/daemon-1.0.1/src/native/unix $ make make -C native all make[1]: Entering directory `/cygdrive/c/_other/_s/java/daemon-1.0.1 /src/native/unix/native' gcc -g -O2 -DOS_CYGWIN -DDSO_DLFCN -DNO_SETSID -DCPU=\i386\ -I/cygdrive/c/jdk1.5.0_11/include -I/cygdrive/c/jdk1.5.0_11/include/win32 -Wall -Wstrict-prototypes -c jsvc-unix.c -o jsvc-unix.o jsvc-unix.c:229: warning: function declaration isn't a prototype jsvc-unix.c: In function `check_pid': jsvc-unix.c:279: warning: implicit declaration of function `lockf' jsvc-unix.c:279: error: `F_LOCK' undeclared (first use in this function) jsvc-unix.c:279: error: (Each undeclared identifier is reported only once jsvc-unix.c:279: error: for each function it appears in.) jsvc-unix.c :286: error: `F_ULOCK' undeclared (first use in this function) jsvc-unix.c: In function `get_pidf': jsvc-unix.c:321: error: `F_LOCK' undeclared (first use in this function) jsvc-unix.c:323: error: `F_ULOCK' undeclared (first use in this function) jsvc-unix.c: In function `wait_child': jsvc-unix.c:405: error: `F_LOCK' undeclared (first use in this function) jsvc-unix.c:407: error: `F_ULOCK' undeclared (first use in this function) jsvc-unix.c : In function `main': jsvc-unix.c:693: warning: implicit declaration of function `SetTerm' make[1]: *** [jsvc-unix.o] Error 1 make[1]: Leaving directory `/cygdrive/c/_other/_s/java/daemon-1.0.1 /src/native/unix/native' make: *** [native/all] Error 2 ~end~ Any help is greatly appreciated. I would love to run this on *nix but I am unfortunately stuck with windoze at this point :( Thanks, JsD Following up... Are there any *detailed* instructions out there on how to build jsvc on Win32? Any help is appreciated. JsD -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [daemon] Fwd: Compiling jsvc Win32
Dion Gillard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The lack of response on this: http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200707.mbox/ajax/[EMAIL PROTECTED] is telling. How dormant is daemon? Using jsvc on Windows has never been supported. The jsvc module is only for *nix systems. Windows systems should use procrun. Daemon is fairly mature, but not particularly dormant. It gets commits every few months. It could use some more eyes for systems like OS/X, but otherwise is relatively healthy for a commons project, aside from not having much PMC representation. -- Forwarded message -- From: JsD [EMAIL PROTECTED] Date: Jul 9, 2007 12:09 PM Subject: Re: Compiling jsvc Win32 To: [EMAIL PROTECTED] After finding out that one must have the latest version of Visual Studio to build, I decided to look for another route. Finally I found JavaService ( http://forge.objectweb.org/projects/javaservice/). This project comes pre-built and works like a charm. I strongly suggest this for those who do not wish to purchase or use Visual Studio. Cheers, JsD On 5/3/07, JsD [EMAIL PROTECTED] wrote: On 4/28/07, JsD [EMAIL PROTECTED] wrote: Hello, I am trying to compile from source on Windows XP using Cygwin. I have installed the latest make, autoconf, gcc in cygwin environment. The configure runs fine. When I try to make I get the following: /cygdrive/c/_other/_s/java/daemon-1.0.1/src/native/unix $ make make -C native all make[1]: Entering directory `/cygdrive/c/_other/_s/java/daemon-1.0.1 /src/native/unix/native' gcc -g -O2 -DOS_CYGWIN -DDSO_DLFCN -DNO_SETSID -DCPU=\i386\ -I/cygdrive/c/jdk1.5.0_11/include -I/cygdrive/c/jdk1.5.0_11/include/win32 -Wall -Wstrict-prototypes -c jsvc-unix.c -o jsvc-unix.o jsvc-unix.c:229: warning: function declaration isn't a prototype jsvc-unix.c: In function `check_pid': jsvc-unix.c:279: warning: implicit declaration of function `lockf' jsvc-unix.c:279: error: `F_LOCK' undeclared (first use in this function) jsvc-unix.c:279: error: (Each undeclared identifier is reported only once jsvc-unix.c:279: error: for each function it appears in.) jsvc-unix.c :286: error: `F_ULOCK' undeclared (first use in this function) jsvc-unix.c: In function `get_pidf': jsvc-unix.c:321: error: `F_LOCK' undeclared (first use in this function) jsvc-unix.c:323: error: `F_ULOCK' undeclared (first use in this function) jsvc-unix.c: In function `wait_child': jsvc-unix.c:405: error: `F_LOCK' undeclared (first use in this function) jsvc-unix.c:407: error: `F_ULOCK' undeclared (first use in this function) jsvc-unix.c : In function `main': jsvc-unix.c:693: warning: implicit declaration of function `SetTerm' make[1]: *** [jsvc-unix.o] Error 1 make[1]: Leaving directory `/cygdrive/c/_other/_s/java/daemon-1.0.1 /src/native/unix/native' make: *** [native/all] Error 2 ~end~ Any help is greatly appreciated. I would love to run this on *nix but I am unfortunately stuck with windoze at this point :( Thanks, JsD Following up... Are there any *detailed* instructions out there on how to build jsvc on Win32? Any help is appreciated. JsD -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons Modeler 2.0.1 RC2
+1 (non-binding) Niall Pemberton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have created a second release candidate for Modeler 2.0.1 following the problem Phil found in the first RC. Commons Modeler 2.0 didn't include the ant.properties file in the jar which is causing problems in Tomcat. Modeler 2.0.1 is a minor bug fix release fully backwards compatible to fix that issue and a few other build problems - full details in the release notes. Release Notes: http://people.apache.org/~niallp/modeler-2.0.1-rc2/RELEASE-NOTES.txt The artifacts being voted on are here: http://people.apache.org/~niallp/modeler-2.0.1-rc2/ Site: http://people.apache.org/~niallp/modeler-2.0.1-rc2/site/ RAT Report: http://people.apache.org/~niallp/modeler-2.0.1-rc2/rat-commons-modeler-2.0.1-src.txt [ ] +1 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-email (in module jakarta-commons) failed
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, 14 Jun 2007, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/14/07, Ben Speakmon [EMAIL PROTECTED] wrote: Well, it works fine when I blow away my local m1 repository, so I'm not sure what the problem is. The problem is that nobody has updated the Gump descriptor with the new dependencies. How do I tell Gump to build it with maven 2 now? I don't believe Gump supports m2 yet :( It sort of does, but since it is not a real Gump build (it allows Maven2 to pull the dependencies from the repository instead of providing them itself) so we don't really like to use it. Technically you simply replace maven with mvn in the Gump descriptor. BTW, I'd rather say m2 doesn't support the Gump usecase 8-) Yes :). But if you go the mvn / route, then you loose any value that Gump can provide, since you won't get early warning if, say, wiser, makes an incompatible change. Just say no to Maven :). Wiser's ant build system shouldn't be too hard setup in Gump. I don't think much of it, but I'd like to avoid a sh*t thowing contest, so no comment ;). However, I won't have free cycles until the w/e to do it, so let the doachracy work :). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MATH] Initial ideas for adding naive prime algorithms
Roy van Rijn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While browsing through the Commons Math API today I noticed there aren't any prime algorithms in it. Then I noticed the request for these algorithms on the wiki WishList. Is anybody working on this yet? If not, could this be a good start? http://www.redcode.nl/tmp/PrimeUtils.rar I'm somewhat interested, but for those of us that don't use a mac, could you publish in more universal format (e.g. .tar.gz/.zip)? Of course, this will need all of the legal IP clearance if it gets accepted, so in the meantime, you should probably look at http://www.apache.org/licenses/#grants. Roy (new to ASF) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: permissions downgrading in commons-daemon jsvc
Travis McLeskey [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, The child() function in jsvc-unix.c does not seem to behave consistently across platforms: - on Linux, the capabilities and uid are set (in linuxset_user_group()) BEFORE java_init() and java_load() are called - on other platforms, set_user_group() is called AFTER java_init() and java_load() I see that the logic has worked that way since jsvc came over from Tomcat. A comment in jsvc-unix.c says that setuid()/setgid() only apply the current thread so we must do it now, but I don't understand that. Does anyone remember the rationale for this inconsistency? Does it still need to work that way? I don't have a Linux box to play with right now, so I don't know. Maybe with the newer kernal versions it isn't necessary anymore. The problem was a security hole where on Linux other threads in the JVM (e.g. finalizer) would retain root privileges. I've never liked this peice of code, so would happily get rid if it. But I'm not in a position to confirm that the newer Linux kernals have joined the rest of the *nix world :). My specific problem is that, in my Daemon.init() method, I'm trying to read files that are owned and readable only by the user invoking jsvc (root, in my case), but it can't read those files after linuxset_user_group() is called. (One workaround would be to add CAP_DAC_OVERRIDE to CAPS and CAPSMIN.) Thanks, Travis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MODELER-21) MbeansDescriptorsDigesterSource.java is never build if just setting commons-digester.jar property in build.properties
[
http://issues.apache.org/jira/browse/MODELER-21?page=comments#action_12456680 ]
Bill Barker commented on MODELER-21:
Patch applied to SVN trunk. Thanks much!
MbeansDescriptorsDigesterSource.java is never build if just setting
commons-digester.jar property in build.properties
-
Key: MODELER-21
URL: http://issues.apache.org/jira/browse/MODELER-21
Project: Commons Modeler
Issue Type: Bug
Affects Versions: 1.1
Environment: Gentoo Linux
Reporter: Petteri Räty
Attachments: commons-modeler-commons-digester.patch
[EMAIL PROTECTED] /mnt/checkouts/commons-modeler-trunk $ ant -d jar | grep
digester
Setting project property: commons-digester.jar -
/usr/share/commons-digester/lib/commons-digester.jar
Setting project property: commons-digester.home -
/usr/share/java/commons-digester-1.4.1
Override ignored for property commons-digester.jar
Setting project property: commons-digester.lib -
/usr/share/java/commons-digester-1.4.1
Setting project property: commons-digester.loc -
http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digester-1.4.1.tar.gz
Setting project property: digester.home - /mnt/jakarta-commons/digester
Override ignored for property commons-digester.jar
[available] class org.apache.commons.digester.Digester was not found
[available] Unable to load class org.apache.commons.digester.Digester to set
property digester.available
fileset: Setup scanner in dir /mnt/checkouts/commons-modeler-trunk/src/java
with patternSet{ includes: [] excludes:
[org/apache/commons/modeler/ant/*PropertyHelper.java:unless-ant16.available,
org/apache/commons/modeler/modules/MbeansDescriptorsDigesterSource.java:unless-digester.available]
}
[EMAIL PROTECTED] /mnt/checkouts/commons-modeler-trunk $ grep digeste
build.properties
commons-digester.jar=/usr/share/commons-digester/lib/commons-digester.jar
After fixing the problem with a patch that follows:
[EMAIL PROTECTED] /mnt/checkouts/commons-modeler-trunk $ ant -d jar | grep
digester
Setting project property: commons-digester.jar -
/usr/share/commons-digester/lib/commons-digester.jar
Setting project property: commons-digester.home -
/usr/share/java/commons-digester-1.4.1
Override ignored for property commons-digester.jar
Setting project property: commons-digester.lib -
/usr/share/java/commons-digester-1.4.1
Setting project property: commons-digester.loc -
http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digester-1.4.1.tar.gz
Setting project property: digester.home - /mnt/jakarta-commons/digester
Override ignored for property commons-digester.jar
Finding class org.apache.commons.digester.Digester
Loaded from /usr/share/commons-digester/lib/commons-digester.jar
org/apache/commons/digester/Digester.class
Class org.apache.commons.digester.Digester loaded from ant loader
(parentFirst)
Setting project property: digester.available - true
fileset: Setup scanner in dir /mnt/checkouts/commons-modeler-trunk/src/java
with patternSet{ includes: [] excludes:
[org/apache/commons/modeler/ant/*PropertyHelper.java:unless-ant16.available,
org/apache/commons/modeler/modules/MbeansDescriptorsDigesterSource.java:unless-digester.available]
}
[javac]
'/mnt/checkouts/commons-modeler-trunk/target/classes:/usr/share/ant-core/lib/ant.jar:/usr/share/commons-digester/lib/commons-digester.jar:/usr/share/commons-logging/lib/commons-logging.jar:/usr/share/mx4j-core-3.0/lib/mx4j.jar:/usr/share/ant-core/lib/ant-launcher.jar:/usr/share/xml-commons-external-1.3/lib/xml-apis-ext.jar:/usr/share/xerces-2/lib/xercesImpl.jar:/usr/share/jdepend/lib/jdepend.jar:/usr/share/sun-jaf-bin/lib/activation.jar:/usr/share/xalan/lib/xalan.jar:/usr/share/sun-javamail-bin/lib/smtp.jar:/usr/share/jython/lib/jython.jar:/usr/share/antlr/lib/antlr.jar:/usr/share/xml-commons-external-1.3/lib/xml-apis.jar:/usr/share/junit/lib/junit.jar:/usr/share/rhino-1.5/lib/js.jar:/usr/share/xalan/lib/serializer.jar:/usr/share/commons-collections/lib/commons-collections.jar:/usr/share/jakarta-regexp-1.3/lib/jakarta-regexp.jar:/usr/share/bcel/lib/bcel.jar:/usr/share/sun-javamail-bin/lib/mail.jar:/usr/share/bsh/lib/bsh.jar:/usr/share/jakarta-oro-2.0/lib/jakarta-oro.jar:/usr/share/commons-logging/lib/commons-logging-api.jar:/usr/share/jta/lib/jta.jar:/usr/share/log4j/lib/log4j.jar:/usr/share/commons-logging/lib/commons-logging-adapters.jar:/usr/share/commons-net/lib/commons-net.jar:/usr/share/sun-javamail-bin/lib/pop3.jar:/usr/share/sun-javamail-bin/lib/imap.jar:/usr/share/sun-javamail-bin/lib/mailapi.jar:/usr/share/commons-beanutils-1.6/lib/commons-beanutils.jar:/usr/share/jsch/lib/jsch.jar:/opt/sun-jdk-1.5.0.10/lib/tools.jar:/mnt/checkouts/commons-modeler-trunk:/usr/share/ant
[jira] Commented: (MODELER-20) ant jar in trunk fails
[ http://issues.apache.org/jira/browse/MODELER-20?page=comments#action_12456681 ] Bill Barker commented on MODELER-20: I modified your patch, but in the SVN trunk it is now possible to do `ant dist` directly. ant jar in trunk fails -- Key: MODELER-20 URL: http://issues.apache.org/jira/browse/MODELER-20 Project: Commons Modeler Issue Type: Bug Affects Versions: 2.0 Environment: Gentoo Linux using commons modeler SVN trunk Reporter: Petteri Räty Attachments: commons-modeler-trunk-build.xml.patch After a fresh svn co of svn trunk on 2006-12-07: [EMAIL PROTECTED] /mnt/checkouts/commons-modeler-trunk $ ant jar Buildfile: build.xml compile-only: BUILD FAILED /mnt/checkouts/commons-modeler-trunk/build.xml:160: destination directory /mnt/checkouts/commons-modeler-trunk/target/classes does not exist or is not a directory Total time: 0 seconds -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DAEMON-88) JMX java options can cause silent service failure
[ http://issues.apache.org/jira/browse/DAEMON-88?page=comments#action_12456684 ] Bill Barker commented on DAEMON-88: --- Unless you have NTFS, that won't work on Windows. Yes, logging could be better. JMX java options can cause silent service failure - Key: DAEMON-88 URL: http://issues.apache.org/jira/browse/DAEMON-88 Project: Commons Daemon Issue Type: Bug Reporter: Mark Thomas See http://issues.apache.org/bugzilla/show_bug.cgi?id=35635 for the full history. Short version is: * Install 5.5.20 * add -Dcom.sun.management.jmxremote.port= and -Dcom.sun.management.jmxremote.password.file=C:\jmxremote.password to Java Options * Try to start the service The service fails to start and creates only zero byte log files -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] codec net proxy failed.
Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi James, Sorry for the response latency. Nothing should have changed in the setup. In the logs (linked below) we are seeing Connection refused to host: 209.237.227.200; nested exception is: [junit] java.net.ConnectException: Connection timed out Is that host available and accepting connections? I'm betting that that host is vmbuild :). Gump has the same error, except the address differs in the last number (and is the address of vmgump). So I'm guessing that the machines aren't allowing connections on their external address. -Phil On 11/15/06, James Carman [EMAIL PROTECTED] wrote: I haven't changed anything with proxy's RMI-based test cases. Has something in the environment changed that would not allow the test cases to run successfully (they need to create an RMI registry, lookup an RMI registry, etc.)? On 11/15/06, Henri Yandell [EMAIL PROTECTED] wrote: I've sudo'd over to your user (hope you don't mind), fixed things up (put the new nightly_wrapper.sh in place) and changed the crontab from 0:17 to 2:58 so it'll run again. I also ran svn cleanup on the trunks-proper as things were a bit messed up for cli/jelly. need to improve the script to do its best to fix things and get rid of tmp build files before kicking things off (added as a todo in the script). It seems to be ticking along, so hopefully an email will show telling us our failures etc. Hen On 11/15/06, Henri Yandell [EMAIL PROTECTED] wrote: Found the errors (the source $conf line is failing). And that I'm an idiot who left an 'exit;' in too, though that's a relief in this case as it stops things from running. Time for some scripting... On 11/15/06, Henri Yandell [EMAIL PROTECTED] wrote: I suspect I broke the nightly build :) Did you get errors Phil? [we need to add a commons user on vmbuild and give various of us on there sudo to that] On 13 Nov 2006 12:01:02 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20061113/codec.log http://people.apache.org/~psteitz/commons-nightlies/20061113/net.log http://people.apache.org/~psteitz/commons-nightlies/20061113/proxy.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] codec net proxy failed.
I found the problem with Gump, and I'm betting that it is the same problem with [nightly build]. The /etc/hosts file on vmgump still had the old IP address for vmgump. I changed it to the new address, and now INA.getLocalHost() returns the right address. Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi James, Sorry for the response latency. Nothing should have changed in the setup. In the logs (linked below) we are seeing Connection refused to host: 209.237.227.200; nested exception is: [junit] java.net.ConnectException: Connection timed out Is that host available and accepting connections? I'm betting that that host is vmbuild :). Gump has the same error, except the address differs in the last number (and is the address of vmgump). So I'm guessing that the machines aren't allowing connections on their external address. -Phil On 11/15/06, James Carman [EMAIL PROTECTED] wrote: I haven't changed anything with proxy's RMI-based test cases. Has something in the environment changed that would not allow the test cases to run successfully (they need to create an RMI registry, lookup an RMI registry, etc.)? On 11/15/06, Henri Yandell [EMAIL PROTECTED] wrote: I've sudo'd over to your user (hope you don't mind), fixed things up (put the new nightly_wrapper.sh in place) and changed the crontab from 0:17 to 2:58 so it'll run again. I also ran svn cleanup on the trunks-proper as things were a bit messed up for cli/jelly. need to improve the script to do its best to fix things and get rid of tmp build files before kicking things off (added as a todo in the script). It seems to be ticking along, so hopefully an email will show telling us our failures etc. Hen On 11/15/06, Henri Yandell [EMAIL PROTECTED] wrote: Found the errors (the source $conf line is failing). And that I'm an idiot who left an 'exit;' in too, though that's a relief in this case as it stops things from running. Time for some scripting... On 11/15/06, Henri Yandell [EMAIL PROTECTED] wrote: I suspect I broke the nightly build :) Did you get errors Phil? [we need to add a commons user on vmbuild and give various of us on there sudo to that] On 13 Nov 2006 12:01:02 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20061113/codec.log http://people.apache.org/~psteitz/commons-nightlies/20061113/net.log http://people.apache.org/~psteitz/commons-nightlies/20061113/proxy.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] codec net proxy failed.
Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 11/18/06, Bill Barker [EMAIL PROTECTED] wrote: I found the problem with Gump, and I'm betting that it is the same problem with [nightly build]. The /etc/hosts file on vmgump still had the old IP address for vmgump. I changed it to the new address, and now INA.getLocalHost() returns the right address. Thanks, Bill. I see this in /etc/hosts on vmbuild: 209.237.227.200 vmbuild I get a different IP when I ping or do nslookup. I guess I should change it to what DNS gives? Why is this entry there, anyway? Yes, if you change it to the DNS address, then c-n will quit trying to connect to a machine that no longer exists, and connect to vmbuild instead :). It's there so that the machine can locate itself during bootup (before the bind daemon starts), or at least that's the traditional reason to have it. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [daemon] Re: Obtaining procrun for Win32
Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi David, This thread might be of use: http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL PROTECTED] Looking at my last year of user archives, I don't see any questions on daemon being answered and I can see lots of svn commits for it so it's still active. Ccing the commons-dev list to point this out to the daemon developers. Yes, the [daemon] developers are mostly Tomcat developers with little involvement with other commons projects. That is probably why the don't hang out on comons-user (I know it is my reason :). You can always send them over to [EMAIL PROTECTED], where there are plenty of people to answer [daemon] question. And the thread cited above is probably the best answer to the user's question. Thanks, Hen On 11/1/06, David Sills [EMAIL PROTECTED] wrote: Hi there: I went to look on the commons daemon site for Procrun, and although I see a page explaining its use, I see nowhere from which to download the software. The Native binaries page has only versions for various UNIX flavors. Sorry if I am being dense, but I really like Apache software, and would like to consider Procrun as a Windows service provider along with some other options for adoption. Any advice would be gratefully received. Thanks! David Sills - 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: Migrate commons-fileupload to Maven 2
-0 Since it will kill the Gump build (as well as all of the 23 projects that depend directly or indirectly on c-f :). However, the Maven people don't care, and I'm getting tired of fighting this war, so no veto from me. Jochen Wiedmann [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I have just checked in the required changes for building site and distribution of commons-fileupload with Maven 2. See http://people.apache.org/~jochen/commons-fileupload for details. Now that is done, I'd like to get rid of the Maven 1 stuff. In particular, I'd like to change the project layout, so that it matches the Maven 2 standards. Additionally, I'd like to remove the files project.(properties|xml) and maven.xml, as well as xdocs/navigation.xml. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][modeler] Promote 2.0 RC1 to 2.0 Final (was Re: [modeler] 2.0 RC1 ready for review)
+1 Davanum Srinivas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks Rahul, will keep those in mind for the next time around. Team, Could i get some votes to promote the 2.0 RC1 to 2.0 Final? Here's my +1 to get the ball rolling. thanks, dims On 7/22/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 7/21/06, Davanum Srinivas [EMAIL PROTECTED] wrote: One more rev folks..Changed the version to 2.0 because of the incompatible api change. Also please note that the minimum jdk version is 1.3. http://people.apache.org/~dims/commons-modeler-2.0-RC1/ snip/ Looks good: * Sigs, md5s pan out * Source distro jars,sites,dists * jar/manifest looks ok Nits (not blockers, IMO): * POM and jar md5s not in recommended format * We should aim to have all component sites display docs for latest 3 (?) releases -Rahul thanks, dims snap/ -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MODELER-15) [modeler] IntrospectionUtils memory leak
[ http://issues.apache.org/jira/browse/MODELER-15?page=comments#action_12420718 ] Bill Barker commented on MODELER-15: It's resolved as far as Modeler is concerned. There needs to be some minor changes in Tomcat for it to have any effect. [modeler] IntrospectionUtils memory leak Key: MODELER-15 URL: http://issues.apache.org/jira/browse/MODELER-15 Project: Commons Modeler Type: Bug Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: Chris Fix For: 1.1.1 When I reload my webapp, and I profile, I see Method objects in IntrospectionUtils grow and grow (to the thousands of instances), and none of my class Objects (or static references) get collected. This is in the objectsMethods HashTable. One suggestion: remove the caching or Another suggestion: add a method that clears it (or clears it for a certain classloader), and make sure this method gets called from Tomcat when it unloads a webapp (since I dont know how a webapp could call this method if this class is loaded from the system classloader) More info: http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action? pageId=2669 Thanks! Chris -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MODELER-15) [modeler] IntrospectionUtils memory leak
[ http://issues.apache.org/jira/browse/MODELER-15?page=comments#action_12420768 ] Bill Barker commented on MODELER-15: A quick search of BZ doesn't show any (and I don't remember seeing one come through [EMAIL PROTECTED]). I think that Chris actually knew what he was doing, and posted to the correct list :). [modeler] IntrospectionUtils memory leak Key: MODELER-15 URL: http://issues.apache.org/jira/browse/MODELER-15 Project: Commons Modeler Type: Bug Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: Chris Fix For: 1.1.1 When I reload my webapp, and I profile, I see Method objects in IntrospectionUtils grow and grow (to the thousands of instances), and none of my class Objects (or static references) get collected. This is in the objectsMethods HashTable. One suggestion: remove the caching or Another suggestion: add a method that clears it (or clears it for a certain classloader), and make sure this method gets called from Tomcat when it unloads a webapp (since I dont know how a webapp could call this method if this class is loaded from the system classloader) More info: http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action? pageId=2669 Thanks! Chris -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed
The metadata for Gump is stored in the Gump SVN repo. It ignores (or, rather overrides) whatever is in the project POM. The reason, of course, is that most of the time you want Gump to try and compile your project against the HEAD of it's dependancies, so you get a warning when somebody in another project changes something that breaks yours. To update the metadata, all you need do is: $ svn co https://svn.apache.org/repos/asf/gump/metadata $ cd metadata/project $ vi jakarta-commons-jelly.xml $ svn ci Paul Libbrecht [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Gump experts, Failures in these three tests are due, I think, to old jaxen, indeed jaxen 1.1-beta-4 is referenced in many places in http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.htmland the other failing gump reports. Explanation for this is the gumpmetadata to be found at: http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-commons-jelly.xmlwhich indeed states explicitly jaxen 1.1-beta-8.Is this gump descriptor automatically generated ?Using a manually triggered process or every nights ? (it appears thefirst must be true since jaxen 1.1-beta-8 is in the project.xml sinceyesterday).I've tried: maven generate-gump -Dmaven.gump.svn.dir=commons/proper/jelly/trunkshould I upload the result somewhere ?thankspaul development wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For moreinformation please visit http://gump.apache.org/nagged.html, and/or contactthe folk at [EMAIL PROTECTED] Project commons-jelly-tags-html has an issue affecting its communityintegration. This issue affects 1 projects. The curr ent state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-html : Commons Jelly Full details are available at:http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages)were provided: -DEBUG- Sole output [commons-jelly-tags-html-07062006.jar] identifier setto project name -DEBUG- Dependency on xml-xerces exists, no need to add for propertymaven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ht ml/project.properties -INFO- Project Reports in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed:http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH:/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-j elly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] atorg.apache.commons.jelly.tags.junit.Ca seTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase:testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused anERROR [junit]file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You
Re: [Modeler] Resync and Release for commons-modeler
Dennis Lundberg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've done some issue-management on modeler. Bill Barker wrote: As I remarked in http://svn.apache.org/viewvc?rev=411629view=rev, resyncing with Tomcat's version of Modeler will never get accepted by the Tomcat team for TC 5.x. However, I promise to patch TC5 to fix MODELER-15 once it is decided to upgrade. From a Modeler point of view, don't you think that MODELER-15 has been resolved? MODELER-17 is fixed now (but I lack karma to mark it as such :). Marked as resolved. I consider MODELER-10 to be INVALID (for reasons explained there, but again, there is that karma thing :). Marked as invalid. I consider MODELER-3 to be assigned to Dennis. Committed and resolved. MODELER-2 is already fixed, but just not marked as such. Marked as resolved. I lack karma to fix MODELER-6, and really don't care all that much. Tested and marked as invalid. That pretty much covers the state of open issues with [modeler]. Once Dennis has committed his patch, I see no reason for somebody not to step up and RM a [VOTE]. What version are we looking at here? 1.1.1 or 1.2? It's primarily a bug-fix release at the moment, so I'd go for 1.1.1. However, it's really up to whoever steps up to RM the release :). snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Modeler] Resync and Release for commons-modeler
Dennis Lundberg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Davanum Srinivas wrote: Bill, Yoav, Dennis, Could you please help with [1] and the resync with Tomcat's version of modeler? Once that is done, rbb and/or i can start a VOTE thread for a release that we need for Geronimo. Thanks, dims [1] http://issues.apache.org/jira/browse/MODELER-3 Like I said in that JIRA-issue, and the thread on general [2], it all depends on what minimum Java version we want for modeler. If we are OK with 1.3 I can go ahead and fix [1]. It's only a POM change, so I really don't care (I never use the POM, and Tomcat doesn't even use Maven :). In fact, the Ant build defaults to using the JMX RI. If the user really wants to use a 1.2 JVM, all they would have to do is to swap out the JMX implementation. But, since I am not a modeler user myself, I really cannot say which Java version is OK to use. That should be up to the current users of modeler, which seems to be Geronimo and Tomcat. [2]http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/[EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MODELER-10) [modeler] DTD violation when using simple wrapping
[
http://issues.apache.org/jira/browse/MODELER-10?page=comments#action_12414674 ]
Bill Barker commented on MODELER-10:
The 'domain' attribute is for defining the metadata. I see nowhere in the docs
where it claims that it will be used loadMBeans. The xml file format for
loadMBeans doesn't actually have a published DTD, and it's just a coincidence
that the tag name is the same as for loadMetadata. In fact, AFAIK, using the
'name' field in loadMBeans is an undocumented option. What you are trying to
do would fail really badly if you had a more complex example, and should log
errors even with your example.
For your bad example, what you want is:
mbeans-descriptors
mbean name=Pool
objectName=myNodDefaultDomain:name=Pool
className=my.package.Pool
description=Object Pool
domain=myNonDefaultDomain
group=dontCare
type=dontCare
attribute name=Size
description=number of currently pooled objects
type=java.lang.Integer
writeable=true/
/mbean
/mbeans-descriptors
[modeler] DTD violation when using simple wrapping
--
Key: MODELER-10
URL: http://issues.apache.org/jira/browse/MODELER-10
Project: Commons Modeler
Type: Bug
Environment: Operating System: other
Platform: Other
Reporter: L. Hahn
Attachments: modeler.diff.bz2
- using MBean implementation of sun j2sdk 1.5.0_02 win 32 bit
When just wrapping a class without overriding BaseModelMBean, a working
configuration looks like this:
8 --
mbeans-descriptors
mbean name=myNonDefaultDomain:name=Pool
className=dontCare
description=Object Pool
domain=dontCare
group=dontCare
code=my.package.Pool
type=dontCare
attribute name=Size
description=number of currently pooled objects
type=java.lang.Integer
writeable=true/
/mbean
/mbeans-descriptors
-- 8
The class my.package.Pool:
8 --
package my.package;
public class Pool
{
Integer size = new Integer(42);
public Pool(){}
public Integer getSize() {
return size;
}
public void setSize(Integer size)
{
this.size = size;
}
}
-- 8
The code to register the MBean inside the platform MBean server:
-- 8
URL url= this.getClass().getResource(MBeanConfig.xml);
Registry registry = Registry.getRegistry(null, null);
registry.setMBeanServer(ManagementFactory.getPlatformMBeanServer());
registry.loadMetadata(url);
registry.loadMBeans(url);
--- 8 ---
The field viewed with jconsole (local connected) is
MBeans=Tree=myNonDefaultDomain=Pool=size = 42
Following the API-Docs one would expect
8 --
mbeans-descriptors
mbean name=Pool
className=my.package.Pool
description=Object Pool
domain=myNonDefaultDomain
group=dontCare
type=dontCare
attribute name=Size
description=number of currently pooled objects
type=java.lang.Integer
writeable=true/
/mbean
/mbeans-descriptors
-- 8
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MODELER-15) [modeler] IntrospectionUtils memory leak
[ http://issues.apache.org/jira/browse/MODELER-15?page=comments#action_12414675 ] Bill Barker commented on MODELER-15: A method has been added to IntrospectionUtils to clear the cached methods (similar to the one in the Tomcat class that this was stolen from :). Of course, it won't have any effect until the next release of Modeler, and after that when the Tomcat team decides to upgrade to it. However, this has already been fixed for Tomcat 6.x with an independent patch. [modeler] IntrospectionUtils memory leak Key: MODELER-15 URL: http://issues.apache.org/jira/browse/MODELER-15 Project: Commons Modeler Type: Bug Environment: Operating System: other Platform: Other Reporter: Chris When I reload my webapp, and I profile, I see Method objects in IntrospectionUtils grow and grow (to the thousands of instances), and none of my class Objects (or static references) get collected. This is in the objectsMethods HashTable. One suggestion: remove the caching or Another suggestion: add a method that clears it (or clears it for a certain classloader), and make sure this method gets called from Tomcat when it unloads a webapp (since I dont know how a webapp could call this method if this class is loaded from the system classloader) More info: http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action? pageId=2669 Thanks! Chris -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MODELER-17) [modeler] MbeansSource don't use args at mbeans and operations
[ http://issues.apache.org/jira/browse/MODELER-17?page=comments#action_12414679 ] Bill Barker commented on MODELER-17: A patch for this has now been committed to the SVN, and will appear in V1.1.2. [modeler] MbeansSource don't use args at mbeans and operations -- Key: MODELER-17 URL: http://issues.apache.org/jira/browse/MODELER-17 Project: Commons Modeler Type: Improvement Versions: 1.1.1 Environment: Operating System: All Platform: PC Reporter: Peter Rossbach Priority: Minor Attachments: MbeansSource20040128.patch I missing the feature to set args at construct a mbean or calling a jmx- operation. A look inside MbeansSource and see that args parsed but not used. Ohh. OK, now a I have add this feature and add tag jmx-atttriute to set without construting a bean values to mbeans attributes. Peter s. added patch with Testcase and examples. PS: To strange things: a) all operation must have unique names, You can't have init() and init (String,String) as mbean operations. b) boolean isAttribute get-methode not found. currently only getattribute supported. c) missing mbean-instance.dtd ;-) Example script: bean mbean name=Bean:type=Bean code=org.apache.commons.modeler.modules.MyBean attribute name=name value=Peter/ /mbean jmx-attribute objectName=Bean:type=Bean name=street value=Am Jo/ jmx-operation objectName=Bean:type=Bean operation=start/ mbean name=Bean:type=Bean2 code=org.apache.commons.modeler.modules.MyBean /mbean jmx-operation objectName=Bean:type=Bean2 operation=setall arg type=java.lang.String value=Peter/ arg type=java.lang.StringAm Jo/arg /jmx-operation mbean name=Bean:type=Bean3 code=org.apache.commons.modeler.modules.MyBean arg type=java.lang.String value=Peter/ arg type=java.lang.StringAm Jo/arg /mbean /bean -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Modeler] Resync and Release for commons-modeler
As I remarked in http://svn.apache.org/viewvc?rev=411629view=rev, resyncing with Tomcat's version of Modeler will never get accepted by the Tomcat team for TC 5.x. However, I promise to patch TC5 to fix MODELER-15 once it is decided to upgrade. MODELER-17 is fixed now (but I lack karma to mark it as such :). I consider MODELER-10 to be INVALID (for reasons explained there, but again, there is that karma thing :). I consider MODELER-3 to be assigned to Dennis. MODELER-2 is already fixed, but just not marked as such. I lack karma to fix MODELER-6, and really don't care all that much. That pretty much covers the state of open issues with [modeler]. Once Dennis has committed his patch, I see no reason for somebody not to step up and RM a [VOTE]. Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dennis Lundberg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Davanum Srinivas wrote: Bill, Yoav, Dennis, Could you please help with [1] and the resync with Tomcat's version of modeler? Once that is done, rbb and/or i can start a VOTE thread for a release that we need for Geronimo. Thanks, dims [1] http://issues.apache.org/jira/browse/MODELER-3 Like I said in that JIRA-issue, and the thread on general [2], it all depends on what minimum Java version we want for modeler. If we are OK with 1.3 I can go ahead and fix [1]. It's only a POM change, so I really don't care (I never use the POM, and Tomcat doesn't even use Maven :). In fact, the Ant build defaults to using the JMX RI. If the user really wants to use a 1.2 JVM, all they would have to do is to swap out the JMX implementation. But, since I am not a modeler user myself, I really cannot say which Java version is OK to use. That should be up to the current users of modeler, which seems to be Geronimo and Tomcat. [2]http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/[EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-daemon with JVM included in Fedora?
The jsvc program requires to load the JVM .so file in order to launch the JVM. With Sun's JVM, the file is called 'libjvm.so'. What I need to know is what is the equivalent .so file called with GNU Java. Of course, I *could* download and install it and look around, but since you've already got it installed, you could find this out faster than I could. After you have found it, you just need to add it to the location_jvm_default table in location.c, and recompile jsvc. However, it would be nice if you post your findings back to the list so that it can be included in the official version :). Bernard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Bill Thanks for your reply. I think the JVM that comes with fedora 4 is a bit different. # eche $JAVA_HOME returns nothing From the jsvc output below I understand that jsvc has a problem finding the JVM. However it appears to be ok otherwise because I can run tomcat without problems. I used yum to get my jsvc packages: # rpm -qa | grep jakarta-commons-daemon jakarta-commons-daemon-1.0.1-1jpp jakarta-commons-daemon-jsvc-1.0.1-1jpp These have worked for me on RedHat 9 with Sun's JVM. On Fedora 4: # java -version java version 1.4.2 gij (GNU libgcj) version 4.0.0 20050519 (Red Hat 4.0.0-8) I would be grateful for any ideas. Thanks Bernard I'm way too bored to actually research this myself, but if you could post the results of: $ ls -lR $JAVA_HOME I can probably tell you what you need to patch to get this working for GNU Java. You could also try building from SVN co, since there have been some JVM compatibility fixes there, but off of the top of my head, I don't remember one for GNU Java. Starting tomcat: Error: jsvc execution failed 22/05/2006 22:42:42 5229 jsvc debug: +-- DUMPING PARSED COMMAND LINE ARGUMENTS -- 22/05/2006 22:42:42 5229 jsvc debug: | Detach: True 22/05/2006 22:42:42 5229 jsvc debug: | Show Version:No 22/05/2006 22:42:42 5229 jsvc debug: | Show Help: No 22/05/2006 22:42:42 5229 jsvc debug: | Check Only: Disabled 22/05/2006 22:42:42 5229 jsvc debug: | Stop:False 22/05/2006 22:42:42 5229 jsvc debug: | Wait:5000 22/05/2006 22:42:42 5229 jsvc debug: | Run as service: No 22/05/2006 22:42:42 5229 jsvc debug: | Install service: No 22/05/2006 22:42:42 5229 jsvc debug: | Remove service: No 22/05/2006 22:42:42 5229 jsvc debug: | JVM Name:null 22/05/2006 22:42:42 5229 jsvc debug: | Java Home: /usr/lib/jvm/java 22/05/2006 22:42:42 5229 jsvc debug: | PID File: /var/run/jsvc.pid 22/05/2006 22:42:42 5229 jsvc debug: | User Name: myuser 22/05/2006 22:42:42 5229 jsvc debug: | Extra Options: 3 22/05/2006 22:42:43 5229 jsvc debug: | -Dcatalina.home=/usr/share/tomcat5 22/05/2006 22:42:43 5229 jsvc debug: | -Djava.io.tmpdir=/usr/share/tomcat5/temp 22/05/2006 22:42:43 5229 jsvc debug: | -Djava.class.path=/usr/lib/jvm/java/lib/tools.jar:/usr/share/java/commons-daemon.jar:/usr/share/tomcat5/bin/bootstrap.jar:/usr/share/tomcat5/bin/commons-logging-api.jar:/usr/share/java/mx4j/mx4j-impl.jar:/usr/share/java/mx4j/mx4j-jmx.jar 22/05/2006 22:42:43 5229 jsvc debug: | Class Invoked: org.apache.catalina.startup.Bootstrap 22/05/2006 22:42:43 5229 jsvc debug: | Class Arguments: 0 22/05/2006 22:42:43 5229 jsvc debug: +--- 22/05/2006 22:42:43 5230 jsvc debug: user changed to 'myuser' 22/05/2006 22:42:43 5229 jsvc debug: User 'myuser' validated 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate Java Home in /usr/lib/jvm/java 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM configuration file /usr/lib/jvm/java/jre/lib/jvm.cfg 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM configuration file /usr/lib/jvm/java/lib/jvm.cfg 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM configuration file /usr/lib/jvm/java/jre/lib/i386/jvm.cfg 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM configuration file /usr/lib/jvm/java/lib/i386/jvm.cfg 22/05/2006 22:42:43 5229 jsvc debug: VM configuration file not found 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/jre/lib/i386/classic/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/jre/lib/i386/client/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/jre/lib/i386/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/lib/i386/classic/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/lib/i386/client/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/lib/i386/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library /usr/lib/jvm/java/jre/bin/i386/classic/libjvm.so 22/05/2006 22:42:43 5229 jsvc debug: Attempting to locate VM library
Re: commons-daemon with JVM included in Fedora?
I'm way too bored to actually research this myself, but if you could post the results of: $ ls -lR $JAVA_HOME I can probably tell you what you need to patch to get this working for GNU Java. You could also try building from SVN co, since there have been some JVM compatibility fixes there, but off of the top of my head, I don't remember one for GNU Java. Bernard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, jakarta-commons-daemon-jsvc-1.0.1-1jpp when installed on Fedora 4 Linux, does not appear to like the installed JVM: gij (GNU libgcj) version 4.0.0 20050519 (Red Hat 4.0.0-8) Can anyone suggest a way to get this working? I would like to use the installed JVM instead of Sun's. Many thanks Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Unifying maven reports?
Dennis Lundberg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dion Gillard wrote: Guys, this sounds like bike shed paint discussion. Well, in that case I want mine blue ;) Paint mine green ;-). We're under resourced here as it is. Do we really have extra volunteers waiting to frack about making reports consistent? Does it really make it easier for our users? I haven't seen complaints about inconsistent maven reports lately. AFAICT, maintaining the project.xml files hasn't been a big hassle. First off, I wouldn't be starting this discussion if I wasn't prepared to work on it. This is one of many steps that I feel are needed to get a faster, more reliable and more automated system for handling our component sites. That would in turn free the developers, who might not be interested in the site stuff, to do more coding or whatever they feel like contributing with. If you want to volunteer to maintain the pom for [modeler] and [daemon], I've got no complaints (knock yourself out :). If you want to volunteer *my* time to maintain them, then I'm totally -1 (I consider myself being nice by not WONTFIXing the bug that [modeler] won't even build under Maven, even if the result is the same :). -- Dennis Lundberg On 5/20/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Hello I would like to start a discussion about trying to unify which Maven reports should be used for each commons component. The reasons I find for unifying the reports are these: - Makes it easy for our users if we are consistent - they know what to expect - Makes it easier for us to maintain our project.xml files - Facilitate Maven 2 migration Digging into the Maven 1 POMs for commons proper I have come up with the list of reports here below. Some reports that are only used in a few components have been omitted. I have also tried to categorize and describe each report, borrowing/stealing a lot from chapter 6 in the new book Better Builds with Maven. + means that I think that all components should use this report o means that I think this report should be optional - means that I don't think any component should use this report Standard + license Source health + checkstyle (code formatting) + jdepend (quality metrics) + pmd/cpd (bugs, code duplication, coding standards) + tasklist (to do list) - findbugs (same as pmd?) - simian (same as cpd) Tests + cobertura (test coverage) + junit (test reports) - clover (same as cobertura) - jcoverage (same as cobertura) Changes since last release + changelog (SCM activity per commit) + clirr (binary compatibility) + developer-activity (SCM activity per developer) + file-activity (SCM activity per file) o changes - jdiff (same as clirr) Reference + javadoc + jxr (cross reference) User guide o faq - linkcheck (might be enabled during development) With that I will duck from the flames and see what the rest of you think :) -- Dennis Lundberg - 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: svn commit: r394397 - in /jakarta/commons/proper/jelly/trunk: jelly-tags/tag-project.xml parent-project.xml
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Author: polx Date: Sat Apr 15 16:25:06 2006 New Revision: 394397 URL: http://svn.apache.org/viewcvs?rev=394397view=rev Log: Upgrade to jaxen beta-8 which seems to work better with the XML taglib (at least tried here and by Felipe). Results of these should be shown in gump in the following days. Urm, no. Gump couldn't really care less what you change in the POM. It will override all of the dependant jars itself anyway (cause, that's what it does :). You'll need to change the Gump descriptor to have any effect at all with Gump. Pretty much, your option would be to go with Jaxen-HEAD, so you would need to do s@depend project=packaged-jaxen-1.1-beta-4/@depend project=jaxen /@ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-email (in module commons-jelly) failed
Yup, and if you change them yourself, you save the nags while waiting for one of the Gump maintainers to have time to figure out what change is required :). Felipe Leme [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 4/14/06, Felipe Leme [EMAIL PROTECTED] wrote: I mean, I couldn't figure it out what are the right settings, so I tried some stuff I googled around (like Just for the record, apparently the gump settings are available here: http://svn.apache.org/repos/asf/gump/metadata/project/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 31 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2810042006, vmgump.apache.org:vmgump-public:2810042006 Gump E-mail Identifier (unique within run) #23. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 31 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2810042006, vmgump.apache.org:vmgump-public:2810042006 Gump E-mail Identifier (unique within run) #23. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3009042006, vmgump.apache.org:vmgump-public:3009042006 Gump E-mail Identifier (unique within run) #23. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3009042006, vmgump.apache.org:vmgump-public:3009042006 Gump E-mail Identifier (unique within run) #23. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2808042006, vmgump.apache.org:vmgump-public:2808042006 Gump E-mail Identifier (unique within run) #25. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2808042006, vmgump.apache.org:vmgump-public:2808042006 Gump E-mail Identifier (unique within run) #25. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 22 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2707042006, vmgump.apache.org:vmgump-public:2707042006 Gump E-mail Identifier (unique within run) #26. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 22 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2707042006, vmgump.apache.org:vmgump-public:2707042006 Gump E-mail Identifier (unique within run) #26. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 19 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2706042006, vmgump.apache.org:vmgump-public:2706042006 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 19 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2706042006, vmgump.apache.org:vmgump-public:2706042006 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2705042006, vmgump.apache.org:vmgump-public:2705042006 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2705042006, vmgump.apache.org:vmgump-public:2705042006 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 13 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2504042006, vmgump.apache.org:vmgump-public:2504042006 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-daemon-native-configure (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-daemon-native-configure has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 13 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-daemon-native : Native application for daemon - commons-daemon-native-configure : Configure the build for daemon Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/gump_work/buildscript_jakarta-commons_commons-daemon-native-configure.html Work Name: buildscript_jakarta-commons_commons-daemon-native-configure (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix/configure [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/daemon/src/native/unix] - *** Current host *** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for sablevm... NONE checking for kaffe... NONE checking for javac-sablevm... NONE NONE configure: error: javac not found - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons/commons-daemon-native-configure/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2504042006, vmgump.apache.org:vmgump-public:2504042006 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-xml-test (in module commons-jelly) failed
Paul Libbrecht [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Now... this area piques me as it's getting so old and it looks like the site not being updated is half a consequence of the failing tests. So I tried it a bit more and got surprised to not reproduce this error with jaxen b8 or b7 but to be able to reproduce this with b4. I tried it with both maven 1.1 and maven 1.0.2 Is there a way to change the jaxen used ? Would anyone else be affected ? I'm guessing that it will then work with Jaxen HEAD. At the moment, Gump only has b4, b6 and HEAD for Jaxen. Getting another packaged version will depend on somebody having enough cycles to install it. I've gone ahead and changed jakarta-commons-jelly-tags-xml and jakarta-commons-jelly-tags-xml-test to depend / on Jaxen HEAD, to see how it goes. In general, you can change your dependancies via: $ svn co https://svn.apache.org/repos/asf/gump/metadata $ cd metadata/project $ vi jakarta-commons-jelly.xml $ svn ci If you need a specific version that isn't there already, drop a note to [EMAIL PROTECTED] and usually somebody will get around to installing it eventually ;-). And maybe one day we need to throw at select-attribute-parsing! thanks paul commons-jelly-tags-xml development wrote: [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:355:58: x:copyOf You must define an attribute called 'select' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes/org/apache/commons/jelly/tags/xml/suite.jelly:355:58: x:copyOf You must define an attribute called 'select' for this tag. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Prime Numbers Library.
Sharon Lourduraj [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, Thank you for the positive input on implementing Prime Number functions. I have created a 'wish' on the Math Wish List page. I would like to lay out an initial plan before everyone starts to jump into coding the algorithms. Here is the base off-my-head plan, in the order that might prove the implementation to be of positive value, also the order of difficulty: 1. Implement naive primality (quick tests, but are slow for large numbers) testing algorithms. These algorithms are not very fast and are mainly intended for small numbers. Some involve trial and error methods. Some involve generating a sieve, as aligned, to test the given number and derive result from the contents of the sieve. +1 IMHO, this really should be a part of [math]. 2. Implement probabilistic testing (classical tests) algorithms. These algorithms include tests that identify a number as a probable-prime, of course using logical deduction (Fermat, Miller-Rabin, etc.) theorized by mathematicians. These algorithms are relatively fast for large numbers, but are sophisticated. They do contain a calculated error margin. Currently, [math] doesn't support integer calculations bigger than 'int'. It could do 'long', but it's really not much of an improvement in this area. It's really is going to need a BigInteger class simply to handle the 2048+ bit integers that are of interest to crypto providers. Of course, the number theorests will want much larger :). And, yes, I'm volunteering. 3. Implement General purpose testing algorithms. These algorithms are extremely advanced. They are significantly faster than any other algorithms. Some of these algorithms have been widely accepted to work, but are based on conjectures that have still not been proved true (but are widely assumed to be). These algorithms will significantly test our brains and the scope of [math]. Bring it on ;-). Alright, all that thoughts are off my head now. Feel free to make any corrections, I do not have much knowledge of advanced algorithms just a keen interest. Also, feel free to make suggestions. I have created a wiki entry :-) http://wiki.apache.org/jakarta-commons/PrimeNumbers I will updated a full-fledged plan as time allows. Thanks, -Sharon P.S: Source 1: http://en.wikipedia.org/wiki/Primality_test Source 2: http://primes.utm.edu/prove/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-collections (in module jakarta-commons) failed
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] To whom it may engage... snip / [junit] Running org.apache.commons.collections.TestAllPackages [junit] Testsuite: org.apache.commons.collections.TestAllPackages [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.107 sec [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.107 sec [junit] Testcase: warning(junit.framework.TestSuite$1): FAILED [junit] No tests found in org.apache.commons.collections.TestAllPackages [junit] junit.framework.AssertionFailedError: No tests found in org.apache.commons.collections.TestAllPackages It seems that Ant already auto-detects JUnit-4, and in this case assumes that you've defined you're tests using pretty Annotations :). In particular, it doesn't look for the: public static Test suite() method in this case. If anybody cares, the options that I can see are: 1) Talk to the Ant developers to add something like legacy=true to the junit / task to force the old behavior even with JUnit-4 present. 2) Auto-detect JUnit-4 in the collections build.xml, and excecute a JUnit-4-compatible test-suite in this case. 3) Change the commons test-suite to be compatible with both JUnit-34. 4) Simply change the Gump descriptor to use junit3 to make the nags go away, and decide what you want to do about JUnit-4 support later. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Prime Numbers Library.
Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 3/11/06, Paul Libbrecht [EMAIL PROTECTED] wrote: I would fear of a library providing such functionality be enormous... any modularity in commons-math planned ? Good question, which comes up over and over again in [math]. That's why I suggested that we focus on primality testing, which is something with practical applications and that could define a more narrow scope. I don't see any harm in experimenting a little in this area. Could be I am wrong though and this will lead us off into a large amount of code. I am not a number theorist and have only passing familiarity with the algorithms for primality testing. WDYT? Actually, I am a number theorist (by training, not my day-job :). I'm interested enough that I could review submissions in this area. Of course, I have karma to commit them as well, but I don't like to step on toes for projects that I haven't really been active in ;-). When you say modularity do you mean splitting up the jar artifacts produced? I thnk we have talked about that before and could be it will make sense eventually to do this. Do you think the 1.1 jar is too big? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-math (in module jakarta-commons) failed
The HEAD of JUnit has been failing to build for a while (well, almost a week actually :). Math doesn't have an explicit dependancy on JUnit (it expects Ant to provide it with a copy), so it tries to build anyway. It then dies when there is no JUnit jar. Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A clean svn update of commons-math builds fine for me using ant. Any ideas? Hen On 3/5/06, Stefan Bodewig [EMAIL PROTECTED] wrote: Project commons-math has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-math : The Jakarta Mathematics Library - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-math (in module jakarta-commons) failed
Niall reminded me of this. Math has at least one test that requires swingui, which isn't there in JUnit HEAD. As a result, Math was changed to depend on the packaged junit-3.8.x.jar so that it would still build. Most other projects work fine with JUnit HEAD, so they don't even get attempted while JUnit is failing. Ant only has an optional dependancy on JUnit HEAD, so it simply chooses not to create ant-junit.jar when it builds. The result is that Math doesn't have ant-junit.jar available to it, so it fails. Of course, the best thing would be to convince the JUnit people to fix the broken commit that is causing it to fail :). A temporary solution would be to change Math depend on JUnit HEAD, and switch it back when JUnit starts building again. Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Math's build.xml is generated from Maven though. It can't be the only one - so why don't they fail too? A Maven version thing? Hen On 3/5/06, Bill Barker [EMAIL PROTECTED] wrote: The HEAD of JUnit has been failing to build for a while (well, almost a week actually :). Math doesn't have an explicit dependancy on JUnit (it expects Ant to provide it with a copy), so it tries to build anyway. It then dies when there is no JUnit jar. Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A clean svn update of commons-math builds fine for me using ant. Any ideas? Hen On 3/5/06, Stefan Bodewig [EMAIL PROTECTED] wrote: Project commons-math has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-math : The Jakarta Mathematics Library - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-math (in module jakarta-commons) failed
Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 3/5/06, Bill Barker [EMAIL PROTECTED] wrote: Niall reminded me of this. Math has at least one test that requires swingui, which isn't there in JUnit HEAD. As a result, Math was changed to depend on the packaged junit-3.8.x.jar so that it would still build. Most other projects work fine with JUnit HEAD, so they don't even get attempted while JUnit is failing. Ant only has an optional dependancy on JUnit HEAD, so it simply chooses not to create ant-junit.jar when it builds. The result is that Math doesn't have ant-junit.jar available to it, so it fails. Of course, the best thing would be to convince the JUnit people to fix the broken commit that is causing it to fail :). A temporary solution would be to change Math depend on JUnit HEAD, and switch it back when JUnit starts building again. I would be happy to do that if I know where the dependency was. Are there any imports / class names that I could search for to find this? Well, the Gump dependancy is done by: $ svn co https://svn.apache.org/repos/asf/gump/metadata/ $ cd metadata/project $ vi jakarta-commons.xml # s/junit3/junit $ svn ci If you want to check in build.xml (so it's no longer the pure Maven one), then you could test for the availability of org.apache.tools.ant.taskdefs.optional.junit.JUnitTask (since that's what's not being found at the moment), and not run the tests if it's not there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r383268 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Author: billbarker Date: Sat Mar 4 18:02:01 2006 New Revision: 383268 URL: http://svn.apache.org/viewcvs?rev=383268view=rev Log: Fix the case of the ObjectReference. Fix for Bug #30647 Sorry, should have included: Submitted By: Kirk Lund - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r383268 - /jakarta/commons/proper/modeler/trunk/src/java/org/apache/commons/modeler/ManagedBean.java
Brett Porter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] You can use: svn propedit --revprop -r383268 svn:log to fix it. Thanks for the info :). - Brett Bill Barker wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Author: billbarker Date: Sat Mar 4 18:02:01 2006 New Revision: 383268 URL: http://svn.apache.org/viewcvs?rev=383268view=rev Log: Fix the case of the ObjectReference. Fix for Bug #30647 Sorry, should have included: Submitted By: Kirk Lund - 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: svn commit: r383273 - /jakarta/commons/proper/modeler/trunk/project.xml
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Author: brett Date: Sat Mar 4 19:35:01 2006 New Revision: 383273 URL: http://svn.apache.org/viewcvs?rev=383273view=rev Log: update Maven descriptor Even after updating my build.properties to refect this change, 'maven jar' still doesn't work for me with Maven 1.0.2. From where it fails, I'm guessing that it's because I'm overriding maven.jar.ant to a 1.7 version (my ~/build.properties has maven.repo.remote.enabled=false as well as maven.jar.override=on: I'm a control freak :). As always, I'm happy that there are people that want to get involved with Modeler's Maven build. Just don't expect me to be one of them ;-). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] m1-m2 migration
As a warning, Gump currently doesn't support M2. As a result, any project that moves to *exclusively* requiring M2 will lose Gump builds (but will still get Nagged, unless they change the Gump descriptor :). Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So what's the plan? Currently Brett has the beginnings of a migration (read: all the hard work) in the commons-sandbox. It looks good, and I'm very impressed with the apt site system. Obviously continuing with sandbox makes sense; but how to do it? If it just got migrated, how long would we need the old maven-1 stuff to stay? Just long enough for us to vote on a migration? [csv] is ready to goto m2 only, so should I call a vote on that individually to remove the m1 stuff. then move onto the next project etc etc? Suddenly I'm fired up with energy again, so look out :) My post csv2svn break seems over. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: publishing commons-modeler jar to maven 2 repo
anita kulshreshtha [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Geronimo uses commomns-modeler-1.1.jar. How can I get this jar published to maven2 repository? The repository has 1.1M1. Urm, just do it ;-). None of the current Modeler developers (Oops, that's me :), really has the time to spend on working out what is required. Thanks IN Advance Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error after running SimpleDaemon
Xin Hua Sun [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Everyone, I download the source daemon-1.0.1.tar.gz from common daemon web side. I did some as follows; (1) run ./configure (2) run make (3) move to samples directory to compile SimpleDaemon.java. (4) run Native.sh to generate Native.so file (5) using ant to compile SimpleDaemon.java. (6) run Native.sh (7) run SimpleDaemon.sh I have two questions as follows; (1) After using ant to compile by build.xml, it didn't generate commons-daemon.jar file. How it generate it? This time, I got this file from web by download binaries code. You need to run 'ant dist' (yeah, yeah, I'm going to get kicked for this :). (2) The running will generate a toto.txt file. In this file, there is a error as follows; 22/02/2006 14:32:34 9369 jsvc.exec error: syscall failed in set_caps 22/02/2006 14:32:34 9369 jsvc.exec debug: set_caps(CAPS) failed Do you know how to fix above issue? Thanks for your help. You need to run as root for the O/S to allow the use of set_caps. Regards, Xin - Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, more on new and used cars. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] doesn't build on Java 5
Actually, the enum and Entities are just warnings. The only actual error is in StrBuilder.StrBuilderWriter, and is caused by the fact that Writer aquired it's own append method in Java 5, so the one in StrBuilder is no longer visible. Brett Porter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That's just the first error. After that, there are a number of enum named variables (easy to fix), but also the enum package seems to be a problem. It could be changed to .enums, but that's not backwards compatible. IS that a reasonable change to make on trunk for c-l 3.0? - Brett Stefan Bodewig wrote: Hi all, vmgump has switched to Java 5 (some will say finally) and commons-lang fails there. The reason are accented characters in Entities.java. Starting with Java 5 you have to specify the source file encoding to javac explicitly if you want to reach beyond ASCII (I'm not sure whether this is a bug or an intentional feature). I see two options, either user \uABCD escapes or specify encoding=ISO-8859-1 (or whatever) to your Ant javac task (not sure how to do that for Maven). 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: [all] release and build improvements: status?
Phil Steitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Good question. I was just thinking the same thing. The current doc in /releases is not bad for maven 1, but could use some updating. It might be better to put our energy into m2 migration and getting the release docs updated to reflect that. Brett and Dennis were working on the site generations stuff for m2, which is currently in very fragile state in m1. Their work is documented here: http://wiki.apache.org/jakarta-commons/CreatingSiteWithMaven2 Does anyone have objection to aiming for Maven 2 for the standard build and release process for commons? If no, we can try to focus on getting a migration plan and updated build / release docs. Well, Gump doesn't currently support Maven 2, so moving to an *only* build with Maven 2 would pretty much cripple Gump. That aside, I personally have no interest in Maven, so won't help for the projects I'm involved with (daemon modeler), and will veto removal of the ant build scripts from either. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] release and build improvements: status?
Brett Porter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: Well, Gump doesn't currently support Maven 2, so moving to an *only* build with Maven 2 would pretty much cripple Gump. I think Maven 2 support in Gump should be on this list of prereqs. Well, I'm only making progress slowly in understanding Maven 2 enough to create a plugin for the Repository that points to the Gump-built jars instead of the one declaired in the POM. If nobody that actually knows Maven 2 wants to step up on [EMAIL PROTECTED], it's going to be a long time before this happens ;-). That aside, I personally have no interest in Maven, so won't help for the projects I'm involved with (daemon modeler), and will veto removal of the ant build scripts from either. I don't think anyone is saying that Ant scripts should be removed if there is someone to maintain them. As a last resort, the mvn ant:ant output should do a sufficient job for gump. Actually, I understand that modeler won't build under Maven at all, and the daemon ant script is also unrelated to the (brain-dead) output of Maven. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] release and build improvements: status?
Brett Porter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: Well, I'm only making progress slowly in understanding Maven 2 enough to create a plugin for the Repository that points to the Gump-built jars instead of the one declaired in the POM. If nobody that actually knows Maven 2 wants to step up on [EMAIL PROTECTED], it's going to be a long time before this happens ;-). I am on [EMAIL PROTECTED], and I've already detailed how I will implement this in Maven, at length. I don't have time right now, but others are welcome to try. I don't imagine it will be a difficult change at all and I can certainly help. I don't believe changes are required in Gump other than to add a Maven 2 builder that you've already done, so a would be volunteer need not learn python. Yes, I know (and much appreciate) your plan for Maven 2 support in Gump. I've even come around on the issue of parsing the Gump descriptors (since we still have so many problems with transitive dependancies with Maven 1). I was simply trying to lure somebody else in until you had time :). And, yes, if any changes are required on the Python side to get this working, I'm more than happy to do them (so that Python knowledge is totally unnecessary to anybody that wants get involved :). I'm not sure what your plugin is that you refer to? A Maven plugin or a Gump plugin? In Maven, plugins are resolved from the repository too, so come in too late to introduce this. It needs a replacement dependency resolver installed in Maven, which was what I've proposed. Actually, I understand that modeler won't build under Maven at all, and the daemon ant script is also unrelated to the (brain-dead) output of Maven. The modeler build in SVN seems to work just fine under Maven. Yes, the generated ant scripts are fairly brain dead, but will work for anything with a simple Maven build. If you need to customise the build with plugins then they are not mapped into the generated Ant script and it will need to be maintained by hand. Modeler is pretty straight-forward (assuming it works). Daemon (because of the native dependancy) is a little bit more complex, and I can't see that Maven will replace Ant on this one (mostly since it has two active developers, neither of whom seem to want to learn Maven enough to try :). - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Gump failures
Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] *ping* Waking this thread up again. While it's bad for us to go Jelly HEAD + Jaxen HEAD - can't work so turn off the build, it's much worse for us to let the noise continue as that switches people off of paying attention to the gump errors. It becomes background noise. Actually, from the Gump page it's using jaxen-1.1b6 (Jaxen HEAD wasn't building for a long time, so a lot of projects got switched to a packaged version). Of course this might be interpreted as a feature request for gump; don't irritate us by repeating yourself, instead just send us a summary every now and then of the ones that are long term issues. Development on Gump is sort of slow right now. Unless somebody wants to step up with a patch, it may not happen anytime soon ;-). Still, +1 to any idea that gets rid of the background noise. The Jelly projects that are failing are basically the unit tests (this is also true for tags-html, the error for tags-swing is just wierd :). If nobody care about the tests, you could just get rid of those project /s in the jakarta-commons-jelly.xml file. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-validator (in module jakarta-commons) failed
The location of the jar changed in R279907 of build.xml, so Gump couldn't find it. I've told Gump the new location, so it should run ok in the run that starts in about two hours. Don Brown [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I must be missing something because this message seems to indicate the build was successful. What failed? Don On 9/10/05, Ted Husted [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-validator has an issue affecting its community integration. This issue affects 82 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-jelly-tags-quartz : Commons Jelly - commons-validator : Validation Framework - db-torque : Persistence Layer - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - fulcrum-intake : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-adapter-turbine : Services Framework - jakarta-jetspeed : Enterprise Information Portal - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-turbine-2 : A servlet based framework. - jakarta-turbine-3 : A servlet based framework. - jakarta-turbine-jcs : Cache - jakarta-velocity-tools : Velocity-Tools project - lenya : Content Management System - metro-reflector-blocks-complete : Avalon SVN - myfaces : JavaServer(tm) Faces implementation - quartz : Job Scheduler - scarab : Issue Tracking Built for the Ages - struts-core : Model 2 Model-View-Controller framework for Servlets and JSP - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP - struts-taglib-from-packages : Model 2 Model-View-Controller framework for Servlets and JSP - struts-tiles : Model 2 Model-View-Controller framework for Servlets and JSP - strutstestcase : An extension of the standard JUnit TestCase class that provi... Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-validator/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were
Re: [math][all] Mentoring for Google's Summer of Code program
I'm actually very interested in this project. I'm unlikely to have enough spare time to be a proper mentor, but I could volunteer to review the code submissions. Technically, I also have karma to commit code, but I haven't been active in [math] before now, so I'll probably defer to Phil or Al for that job ;-). I agree with Al that you will certainly earn your money with this proposal :). I agree with Al's suggestions for how to proceed. OS software is about building a community around the code. If the community is there, naive (and even buggy) implementations can always be improved on. Ryan Li [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all, Many thanks for your comments so far (please keep them coming!). I do realise that the proposal will probably take a number of specialised numerical analysts a few months if not years to complete. I'm all for cutting things down a bit (a lot rather), with an initial focus on the more classical methods for which efficient algorithms are well documented and can be implemented relatively easily. Seeing commons-math as a generic and compact library based on which other more sophisticated code can be written, I think the following could be useful: - performance tuning for matrix computation and add more decomposition methods - univariate integration (Romberg is what I have in mind) - true polynomial interpolation, as opposed to spline, it will be usually be used by other higher level numerical algorithms e.g. Romberg integration or other Richardson extrapolation procedures - univariate minimization - robust derivative-free multidimensional optimization (downhill simplex) - B-spline - ODE solver - (maybe?) Gaussian quadratures and then possibly move to the more ambitious part. At some point I would also like to add more special functions, and optimise the performance of existing ones. Please let me know what you think about this plan. I am actually a happy user of Colt myself, to me it seems that it focuses on the data structure side of numerical computation (which it does an excellent job), what I find it lacks specifically are the algorithm side of things like root finding, interpolation, integration, optimization (and possibly) ODE solver, the performance of some of the special functions also left something to be desired after they replaced the old IMSL code. There are scattered efforts on all the things mentioned above, some seem to be quite mature but most are experimental, I think it would be nice to have them all in one library (maybe just adapt if license compatible and code reasonably stable). As for code quality, I'll make sure I do extensive research into the literatures and (probably more important) existing implementations in whatever language before getting my hands on the keyboard, part of the reason I wanted to start such a project is that when I was doing coursework, I referenced many books and papers only to realise that some of the ideas were clearly better than what I was suggested to do in the project! Best regards, Ryan On 6/3/05, Rory Winston [EMAIL PROTECTED] wrote: I agree, it is a hugely ambitious project. Which is not necessarily a bad thing. I think a good start would be to qualify the scope of the project sooner rather than later, and get a firm idea for exactly what will (hopefully) be achieved. Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Questions of scope of Commons-Math aside gasp, what is the scope of the summer project? The scope of Ryan's proposal seems mighty ambitious, even if you remove the parts that aren't currently in scope for Commons-Math. If you intend to stay true to Apache's charter, the code will have to be developed firsthand, not copied from any other source, unless the license of the source is compatible or the author(s) are amenable to adding an Apache-compatible alternative license to their code or changing over to an Apache-compatible license. Coding that much from scratch and providing JUnit tests will be a heck of a lot of work (maybe a little onerous if you do TDD). And forgive my skepticism, but code developed for coursework is unlikely to be as bulletproof as the proposal aims for. Also, specifically what parts of the proposal are not already addressed by existing libraries such as Colt? I thought we were over the licensing hurdle for Colt, so anything it already does probably should not be duplicated by code newly written for the proposed project. All the above said, I'm not trying to be discouraging, and in fact I would be willing to participate in mentoring (I'll probably learn something new myself!). I just want reasonable expectations and goals to be set. And perhaps we can all ride the wave of youthful exuberance to grow a library that looks like the beginning of an Apache-Math-Java. Al --- Phil Steitz [EMAIL PROTECTED]
Re: [PATCH 1/1] daemon : Fix DaemonLoader to check that class implements 'Daemon' interface
Patch applied. Thanks much!
Nigel Rantor [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Index: DaemonLoader.java
===
RCS file:
/home/cvspublic/jakarta-commons/daemon/src/java/org/apache/commons/daemon/su
pport/DaemonLoader.java,v
retrieving revision 1.4
diff -u -r1.4 DaemonLoader.java
--- DaemonLoader.java 27 Feb 2004 07:57:51 - 1.4
+++ DaemonLoader.java 17 Aug 2004 13:48:11 -
@@ -110,14 +110,9 @@
if (c==null) throw new ClassNotFoundException(cn);
/* Check interface */
-Class[] interf = c.getInterfaces();
-boolean isdaemon = false;
-if ( interf != null ) {
- for(int i=0;iinterf.length;i++) {
-if
(interf[i].getName().equals(org.apache.commons.daemon.Daemon))
- isdaemon = true;
- }
-}
+Class daemon_class =
Class.forName(org.apache.commons.daemon.Daemon);
+boolean isdaemon = daemon_class.isAssignableFrom(c);
+
/* Check methods */
Class[] myclass = new Class[1];
if (isdaemon) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Modeler] Is Registry an MBean?
It is an MBean (in the sense that mserver.createMBean(org.apache.modeler.Registry, oname) works), just not a very useful one. There are too many bugs to try and use a Registry created this way. It's one of the things that make the current version of c-m difficult to use in an embedded environment. random-thoughts It might be better to deprecate Registry.getRegistry and move the factory methods into a separate RegistryFactory MBean. It might even be good to add a method taking an OName so that the Registry can be registered itself, or that the Factory can return the Registry by name. /random-thoughts Vikram Goyal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, The documentation for Modeler says that Registry itself is an MBean. However, it does not come up in the list of MBeans for the default domain and more importantly, I could not find it being registered with the MBeanServer anywhere in the source code. If the documentation incorrect in this regard? Thanks, Vikram - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [daemon] making a release
+1 - Original Message - From: jean-frederic clere [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 09, 2004 9:33 AM Subject: [daemon] making a release Hi, I am thinking of releasing daemon this week. (Friday). Any comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Daemon] Update tomcat.sh for TC 5?
Noel J. Bergman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] is it time to update the script to work with Tomcat 5 (and change the docs to say how to modify it for Tomcat 4.1.x)? What is the nature of the change? Does it make sense to copy the current one to tomcat4.sh, and then make the modifications for TC5? Or I suppose you could just tag the current one, so that someone could pull it from CVS. The changes are pretty minor. Mostly the startup class has changed from 'BootstrapService' to 'Bootstrap'. Also adding commons-logging-api.jar to the boot classpath. I have no objection to adding a 'tomcat4.sh' file. However, jsvc has never shipped-with TC 4, so it likely has a smaller user-base. But I like the suggestion :). --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Daemon] Update tomcat.sh for TC 5?
The current version of 'tomcat.sh' (the example /etc/init.d script for jsvc) is for Tomcat 4.1.x (and is documented as such). Since Tomcat 5.x is GA, and shipping jsvc with the distro, is it time to update the script to work with Tomcat 5 (and change the docs to say how to modify it for Tomcat 4.1.x)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/daemon/src/native/unix/native jsvc-unix.c
- Original Message -
From: jean-frederic clere [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 02, 2004 1:04 AM
Subject: Re: cvs commit: jakarta-commons/daemon/src/native/unix/native
jsvc-unix.c
Thanks. Happy new year.
Do you want to release daemon soon?
We probably should. There are still 4 bugs outstanding for Daemon:
23365) Probably a 'wontfix', or possibly a 'later'. I don't have strong
opinions on this one.
24936) I'll probably patch this one over the weekend (it's the last
procrun bug)
23723) I don't have access to Mac OS/X, so I can't really comment.
23368) You seem to be working on this one, so I haven't really looked at
it, but it's an Enh.
The only other question is whether or not Yoav wants to continue as the RM
(he's done a great job so far, so he has my +1 if he wants the job :).
Cheers
Jean-Frederic
[EMAIL PROTECTED] wrote:
billbarker2003/12/30 21:03:26
Modified:daemon/src/native/unix/native jsvc-unix.c
Log:
Fix problems with signal handling on Solaris (possibly others).
Fix for Bug #24247
Reported By: Peter Poloha [EMAIL PROTECTED]
Revision ChangesPath
1.8 +4 -4
jakarta-commons/daemon/src/native/unix/native/jsvc-unix.c
Index: jsvc-unix.c
===
RCS file:
/home/cvs/jakarta-commons/daemon/src/native/unix/native/jsvc-unix.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jsvc-unix.c 27 Sep 2003 16:49:13 - 1.7
+++ jsvc-unix.c 31 Dec 2003 05:03:25 - 1.8
@@ -271,10 +271,10 @@
/*
* Return the address of the current signal handler and set the new
one.
*/
-static void * signal_set(int sig, void * handler) {
+static void * signal_set(int sig, void * newHandler) {
void *hand;
-hand=signal(sig,handler);
+hand=signal(sig,newHandler);
#ifdef SIG_ERR
if (hand==SIG_ERR)
hand=NULL;
@@ -350,7 +350,7 @@
/* Install signal handlers */
handler_hup=signal_set(SIGHUP,handler);
handler_trm=signal_set(SIGTERM,handler);
-handler_trm=signal_set(SIGINT,handler);
+handler_int=signal_set(SIGINT,handler);
controlled = getpid();
log_debug(Waiting for a signal to be delivered);
while (!stopping) sleep(60); /* pause() not threadsafe */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons/PMC coverage
Well, it looks like this has more to say about the state of the 'project.xmls' ;-). I had thought that 'yoavs' was a PMC member, simply because I believed that we had already cleaned up the list of RMs (yoavs is the current RM for [daemon]). Also, 'costin' should clearly be included for [modeler] (wether he likes it or not :). Henri Yandell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] http://www.generationjava.com/article/apache/StateOfTheCommons.shtml lists the components [will have descriptions when I get around to them], and lists the Commons component coders [as listed in the CVS project.xmls, which every project has]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Jakarta Commons?
Stephen Colebourne [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jakarta is having trouble redefining what is truly stands for. I had hoped that in Jakarta-Commons we knew. However, since its specifically different to what is in the charter, I guess we should decide. And then update the charter. http://jakarta.apache.org/commons/charter.html From the websites: 'small scale, reusable, code components that are useful in multiple Jakarta subprojects' 'focused on all aspects of reusable Java components' 'creating and maintaining reusable Java components' 'collaboration and sharing, where developers from throughout the Jakarta community can work together on projects to be shared by the Jakarta projects and Jakarta users' There are other practical ways to define it. Each J-C component has insufficient community on its own to survive at Apache, either as an independent TLP or within another TLP. Yet within J-C the component is supported and watched over. For example, one way to view this is by mailing lists. If each commons component had its own mailing list, then most would be very quiet. Not enough to stand alone. My preferred short definition of J-C is: 'creating and maintaining small-scale, reusable, utility components written in Java' Is this definition OK? Any comments? This pretty much boots Daemon out of J-C, which would be IMHO would be a shame. Almost of the (supported) code in Daemon is written in C (basically, JNI wrappers to solve OS level restrictions on Java code), so it wouldn't fit the definition. However, it is most definitely Java-centric, so I'd be happiest if it stayed in Jakarta. I'm only a developer for Daemon, so I don't get to vote on its future. And if it is booted out to A-C, then I'll follow it there. But I think that it's best fit is with Jakarta. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Daemon]
jean-frederic clere [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I have fixed some of the problems and arange the documentation a little. I am thinking of taggging the CVS and making a release candidate. Any comments? +1 (of course, non-binding :) Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Daemon Project; set_caps patch and Daemon interface bug notice.
Kevin O'Donnell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Commons - great work on the Daemon sandbox project. I just put it into production in my environment today. I thought I would give some feedback on a few issues I had: * I have no idea what set_caps() is for, but in my environment it was breaking everything. I just commented it out and now it's working find. Should there be an IFDEF added? My patch is available here: http://threebit.net/tutorials/jakarta-daemon/set_caps.patch I don't have access to a Debian box to investigate further. If you could investigate (or at least post what goes wrong), it would be very helpful. At worst, we could change the configure scripts to detect Debian. The two boxes I tried it on are both: # cat /etc/issue; uname -a Debian GNU 3.0 Linux zedd.threebit.net 2.2.19 #1 Sat Jun 9 13:04:06 EST 2001 i686 unknown * org.apache.commons.daemon.Daemon.init() defines a DaemonContext, but DaemonLoader is looking for init(String[]). Which is correct? I got my stuff to work by defining my own interface (though, since reflection is used, I could have gotten away with no interface at all). http://threebit.net/tutorials/jakarta-daemon/src/net/threebit/daemonexample/ DaemonFixed.java A common problem with OS projects: The docs lag what it actually does. The daemon has been extended to support classes that don't implement Daemon (such as jakarta-tomcat-5) by calling init(String []) in this case. AFAIK, the DaemonContext call should work as well if the class implements Daemon (but since I use this for Tomcat mostly, I haven't tried recently). * Oh, and here's a miniscule example of a running service. http://threebit.net/tutorials/jakarta-daemon/src/net/threebit/daemonexample/ SampleService.java Cheers! Kevin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sandbox] Karma request
Could I get karma for sandbox for billbarker? Thanks much. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
