DO NOT REPLY [Bug 38160] - [net] Freeze during FTP connect
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38160. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38160 --- Additional Comments From [EMAIL PROTECTED] 2008-01-29 04:28 --- Commons issues are now tracked using JIRA: http://issues.apache.org/jira/browse/NET This issue is here: https://issues.apache.org/jira/browse/NET-31 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nightly builds
Its not pretty, but they're available in continuum's working copy which people could grab the jars from http://tinyurl.com/26rcj9 Niall On Jan 29, 2008 6:14 AM, Henri Yandell [EMAIL PROTECTED] wrote: +1 Brett - did things get anywhere on the continuum-m2 repo bit? On Jan 27, 2008 8:05 AM, Torsten Curdt [EMAIL PROTECTED] wrote: It's probably not a bad idea to remove them until there is something in place again. My 2 cents -- Torsten On 26.01.2008, at 07:07, Roland Weber wrote: Hello Commons Developers, I just noticed that the download link for Nightly Snapshots [1] in your site navigation points to somewhat outdated packages. I'm not sure whether the location has moved or whether there is no nightly build anymore. Most packages at [2] are even older. I suggest to update or remove the link. Or is this an issue with Gump not getting to the Commons packages because of integration problems? cheers, Roland [1] http://people.apache.org/builds/jakarta-commons/nightly/ [2] http://people.apache.org/builds/commons/nightly/ - 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]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) 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-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/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-jaxme-29012008.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/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-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-29012008.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-29012008.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-29012008.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-29012008.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-29012008.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-29012008.jar:/srv/gump/public/workspace/apache-commons/jexl/dist/commons-jexl-29012008.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-29012008.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-29012008.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-29012008.jar:/srv/gump/ packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-29012008.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.characters(pChars, pOffset, pLen); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:305: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.init(pData); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:315: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] __handler_Name.init(getData()); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressHandler.java:22: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressHandler
Re: Translating Java commons Libs to C# commons libs
2008/1/29, Robert Johnson [EMAIL PROTECTED]: I would like to translate some of the Java commons libraries to IL libraries for C# to use with Mono .Net. Would this be of interest to the Apache commons community? OT question: did you try with IKVM? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Translating Java commons Libs to C# commons libs
Hi, I would like to translate some of the Java commons libraries to IL libraries for C# to use with Mono .Net. Would this be of interest to the Apache commons community? - Robert
Re: Translating Java commons Libs to C# commons libs
No I have not tried IKVM yet. This is on my list of things to try. What I would like to do is start using my C# skills to actually create a translation of the code. I have quite a bit of time on my hands and would like to use my skill to contribute to the project. - Robert On Jan 29, 2008 11:24 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/1/29, Robert Johnson [EMAIL PROTECTED]: I would like to translate some of the Java commons libraries to IL libraries for C# to use with Mono .Net. Would this be of interest to the Apache commons community? OT question: did you try with IKVM? Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD SUCCESSFUL: Commons CLI
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=43511projectId=158
Build statistics:
State: Ok
Previous State: Error
Started at: Tue 29 Jan 2008 07:39:43 -0800
Finished at: Tue 29 Jan 2008 07:40:14 -0800
Total time: 30s
Build Trigger: Schedule
Build Number: 10
Exit code: 0
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java Home version :
java version 1.4.2_15
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02)
Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
Builder version :
Maven version: 2.0.7
Java version: 1.4.2_15
OS name: linux version: 2.6.20-16-server arch: i386
SCM Changes:
Changed: niallp @ Tue 29 Jan 2008 06:41:10 -0800
Comment: Remove unused dependency
Files changed:
/commons/proper/cli/trunk/pom.xml ( 616350 )
/commons/proper/cli/trunk/project.xml ( 616350 )
Dependencies Changes:
No dependencies changed
Build Defintion:
POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Java 1.4
Description:
Test Summary:
Tests: 477
Failures: 0
Total time: 3454
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Commons CLI
[INFO]task-segment: [clean, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/158/target
[INFO] Deleting directory
/home/continuum/data/working-directory/158/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/158/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/158/target/site
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[copy] Copying 2 files to
/home/continuum/data/working-directory/158/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 43 source files to
/home/continuum/data/working-directory/158/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 53 source files to
/home/continuum/data/working-directory/158/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/continuum/data/working-directory/158/target/surefire-reports
---
T E S T S
---
Running org.apache.commons.cli2.option.ArgumentTest
Tests run: 36, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.093 sec
Running org.apache.commons.cli2.option.DefaultOptionTest
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec
Running org.apache.commons.cli2.validation.EnumValidatorTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.cli2.CommandLineDefaultsTest
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.cli2.option.SwitchTest
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec
Running org.apache.commons.cli2.bug.BugCLI122Test
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.cli2.bug.BugCLI12Test
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.cli2.bug.Bug27575Test
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.cli2.util.ComparatorsTest
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec
Running org.apache.commons.cli2.bug.Bug28005Test
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.cli2.option.NestedGroupTest
Tests run:
Re: [pool] trunk?
On Jan 29, 2008 6:51 AM, sebb [EMAIL PROTECTED] wrote: I would prefer to see trunk used for the main development, and branches for experimental stuff, but of course this changes over time. What is important is that the currently active branch(es) and trunk are cleary documented on the web-site and in SVN - I've seen a STATUS file used for this, or perhaps a REAME. This file needs to be at the top-level of trunk (and the contents should indicate that the latest version is always in trunk) For a long while in JMeter the trunk was not where the main dev was taking place, and this caused quite a few problems (as it was also not well documented ...). Thanks, guys. Regarding pool, there is no development right now going on toward the 2.0 stuff, so what makes sense for me is to move the 1.4 code back into trunk and change the pom version to 1.5-SNAPSHOT. I at least will be working bugs, responding to issues and looking at the fairness stuff discussed earlier there, so that makes sense to me. What I am stuck on is the best way to do it in svn. Any advice / suggestions would be appreciated. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] trunk?
On Jan 29, 2008 2:44 PM, Phil Steitz [EMAIL PROTECTED] wrote: On Jan 29, 2008 6:51 AM, sebb [EMAIL PROTECTED] wrote: I would prefer to see trunk used for the main development, and branches for experimental stuff, but of course this changes over time. What is important is that the currently active branch(es) and trunk are cleary documented on the web-site and in SVN - I've seen a STATUS file used for this, or perhaps a REAME. This file needs to be at the top-level of trunk (and the contents should indicate that the latest version is always in trunk) For a long while in JMeter the trunk was not where the main dev was taking place, and this caused quite a few problems (as it was also not well documented ...). Thanks, guys. Regarding pool, there is no development right now going on toward the 2.0 stuff, so what makes sense for me is to move the 1.4 code back into trunk and change the pom version to 1.5-SNAPSHOT. I at least will be working bugs, responding to issues and looking at the fairness stuff discussed earlier there, so that makes sense to me. What I am stuck on is the best way to do it in svn. Any advice / suggestions would be appreciated. TortoiseSVN which I use has a rename command - actually does copy/delete - but I would think that would be the best way to go: 1) Copy trunk to new POOL2 branch and then remove trunk and then 2) copy/delete your 1.4 branch back to trunk. If you want I can do this. Niall Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-deamon problem on linux x64
Hi, I'm trying to use commons-deamon on a suse x64 system. As running it with the 32bit java installation failed (configure detectes the os and looks for the 64 bit jvm), I switched to Sun's x64 java distribution. However, the latter distribution does not contain a client jvm library, so I get several messages like this: library /local/jdk1.6.0_04//lib/amd64/hotspot/libjvm.so 13172 jsvc debug: Cannot locate library for VM hotspot (skipping) I understand there is no 64bit jvm client, you have to use the 32 bit client and the 74 bit server. It looks like this is not supported by the config for commons-deamon. Is there an easy solution for this problem? Using the 32bit version would be ok, can I force config to use that one instead of looking for the one that is 64 bit??? Job - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for OSGi
I have created a JIRA ticket for the changes to the commons-parent pom to add the bundle plugin: https://issues.apache.org/jira/browse/COMMONSSITE-23 I have also tested out the plugin by generating the jars/manifest for all but three components: http://people.apache.org/~niallp/commons-osgi/ I'll leave the ticket open for a few days - but unless there are objections/issues raised I plan to apply the changes to commons-parent. Niall On Dec 19, 2007 2:38 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Hi, the products of commons are highly used throughout many projects. It would be great, if the projects here at Apche Commons could help those projects that are using OSGi. OSGi is based around the concept of a bundle - a bundle is a jar file with additional meta data like the packages it exports and a list of external packages it is using (please forgive me if I'm simplifying here too much). As many projects are using artifacts from Apache Commons, they need the specific jars as bundles. This is most often done by creating so called wrapper bundles: these are jars that have the same contents as the original library with the addition of the required meta data. You can find several examples here: http://svn.apache.org/repos/asf/felix/trunk/commons/ Now, it would be great, if the projects here at Apache Commons would already provide artifacs that can be directly used in an OSGi environment. All that has to be done is adding some entries to the manifest. This is usually a list of imported packages, a list of exported packages, a symbolic name for the bundle and a version. (There are some more but these are the most important ones). Adding these entries can be done by hand (not recommended) or with tools automatically. For example the Apache Felix maven bundleplugin requires just some lines of configuration and that's it. It would be great if some of the projects here could add these meta data as part of their next release. This will make the life of all projects using OSGi much much easier. So if you're interested in helping us, just let us know. We would be happy to make the required changes to the poms or whatever needs to be done. I cc'ed the Felix dev list as some Felix developers might not be subscribed to the commons dev list, so please keep them cross posted. Thanks Carsten -- Carsten Ziegeler [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: [pool] trunk?
On 1/29/08, sebb [EMAIL PROTECTED] wrote: On 29/01/2008, Niall Pemberton [EMAIL PROTECTED] wrote: On Jan 29, 2008 2:44 PM, Phil Steitz [EMAIL PROTECTED] wrote: On Jan 29, 2008 6:51 AM, sebb [EMAIL PROTECTED] wrote: I would prefer to see trunk used for the main development, and branches for experimental stuff, but of course this changes over time. What is important is that the currently active branch(es) and trunk are cleary documented on the web-site and in SVN - I've seen a STATUS file used for this, or perhaps a REAME. This file needs to be at the top-level of trunk (and the contents should indicate that the latest version is always in trunk) For a long while in JMeter the trunk was not where the main dev was taking place, and this caused quite a few problems (as it was also not well documented ...). Thanks, guys. Regarding pool, there is no development right now going on toward the 2.0 stuff, so what makes sense for me is to move the 1.4 code back into trunk and change the pom version to 1.5-SNAPSHOT. I at least will be working bugs, responding to issues and looking at the fairness stuff discussed earlier there, so that makes sense to me. What I am stuck on is the best way to do it in svn. Any advice / suggestions would be appreciated. TortoiseSVN which I use has a rename command - actually does copy/delete - but I would think that would be the best way to go: 1) Copy trunk to new POOL2 branch and then remove trunk and then 2) copy/delete your 1.4 branch back to trunk. If you want I can do this. Niall For renames, one can just use svn move: move (mv, rename, ren): Move and/or rename something in working copy or repository. usage: move SRC DST Note: this subcommand is equivalent to a 'copy' and 'delete'. Note: the --revision option has no use and is deprecated. SRC and DST can both be working copy (WC) paths or URLs: WC - WC: move and schedule for addition (with history) URL - URL: complete server-side rename. This can also be done in Eclipse and probably other IDEs. Although it is equivalent to copy/delete, it's probably safer to do it as one SVN command. Thanks and sorry for having to ask simple questions like this, but just to make sure, svn move and svn copy both preserve history, correct? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Translating Java commons Libs to C# commons libs
Definitely of interest I think - if components make sense being translated. Only a few would be directly ported I think - most of the others would be a case of using the general idea and writing from scratch. Hen On Jan 29, 2008 8:37 AM, Robert Johnson [EMAIL PROTECTED] wrote: No I have not tried IKVM yet. This is on my list of things to try. What I would like to do is start using my C# skills to actually create a translation of the code. I have quite a bit of time on my hands and would like to use my skill to contribute to the project. - Robert On Jan 29, 2008 11:24 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/1/29, Robert Johnson [EMAIL PROTECTED]: I would like to translate some of the Java commons libraries to IL libraries for C# to use with Mono .Net. Would this be of interest to the Apache commons community? OT question: did you try with IKVM? Antonio - 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]
