Re: [email][gump] Currently email is failing in gump
On Wed, 24 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I'll take a look at trying to get dumbster to build in gump from source. When Stefano installed dumbster on brutus he did so because the source was not available from a public repository. I think he already had the dependencies and Ant invocations correct (just no source tree), just look through older revisions of the dumbster.xml file. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-io (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-io has an issue affecting its community integration. This issue affects 124 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. 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 - bootstrap-ojb : ObjectRelationalBridge - 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-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - 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-linotype : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : 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-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-fw : 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-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-woody : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-fileupload : Commons File Upload Package - commons-io : Commons I/O Utility Package - commons-jelly-tags-ojb : A variety of tags for working with the ObjectBridge persiste... - commons-jelly-tags-quartz : This is a Jelly interface for the Quartz Scheduler. - db-ojb : ObjectRelationalBridge - db-torque : Persistence Layer - forrest : Apache Forrest is an XML standards-oriented documentation fr... - fulcrum-bsf : Services Framework - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-crypto : Services Framework - fulcrum-dvsl : Services Framework - fulcrum-factory : Services Framework - fulcrum-hsqldb : Services Framework - fulcrum-intake : Services Framework - fulcrum-localization : Services Framework - fulcrum-mimetype : Services Framework - fulcrum-naming : Services Framework - fulcrum-osworkflow : Services Framework - fulcrum-parser : Services Framework - fulcrum-pool : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-adapter-turbine : Services Framework - fulcrum-security-api : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - fulcrum-testcontainer : Services Framework - fulcrum-upload : Services Framework - fulcrum-xmlrpc : Services Framework - fulcrum-xslt : Services Framework -
[GUMP@brutus]: Project commons-email (in module jakarta-commons-sandbox) 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-email has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-25112004.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-email/gump_work/build_jakarta-commons-sandbox_commons-email.html Work Name: build_jakarta-commons-sandbox_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/email] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-25112004.jar:/usr/local/gump/packages/dumbster1.3/build/dumbster.jar:/usr/local/gump/packages/javamail-1.3.2/mail.jar:/usr/local/gump/packages/javamail-1.3.2/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.0.1/activation.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 Plugin 'maven-deploy-plugin' in project 'Commons Email' is not available build:start: java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/classes [javac] Compiling 6 source files to /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/classes java:jar-resources: Copying 2 files to /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/classes Copying 1 file to /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/classes/META-INF test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/test-reports test:test-resources: test:compile: [javac] Compiling 13 source files to /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/target/test-classes /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/src/test/org/apache/commons/mail/BaseEmailTestCase.java:138: cannot resolve symbol symbol : method getReceivedEmailSize () location: class com.dumbster.smtp.SimpleSmtpServer assertTrue(this.fakeMailServer.getReceivedEmailSize() = intMsgNo); ^ /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/email/src/test/org/apache/commons/mail/BaseEmailTestCase.java:207: cannot resolve symbol symbol : method getReceivedEmailSize () location: class com.dumbster.smtp.SimpleSmtpServer assertTrue(mailServer.getReceivedEmailSize() == 1); ^ 2 errors BUILD FAILED File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... javac Line.. 52 Column 46 Compile failed; see the compiler error output for details. Total time: 5 seconds Finished at: Thu Nov 25 00:58:14 PST 2004 - To subscribe to this information via syndicated feeds: - RSS:
cvs commit: jakarta-commons-sandbox/email build-gump.xml
epugh 2004/11/25 01:10:17 Removed: emailbuild-gump.xml Log: No longer used - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Chain 1.0
While I didn't use the approach that Mailreader-chain used, I found it very *key* to selling me on Chain. So make sure the docs all point to the example in struts-sandbox. Eric -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 11:59 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Chain 1.0 Does the head include the apps subdirectory? I just checked-in the Mailreader-Chain application to the Struts sandbox, since we'll be using Chain there soon. We could delete MailReader before the 1.0.0 release, but I don't want to do anything to spoil the vote. The other application, Agility, is just a stub at this point. The end-game here would be to show using Chain from a plain-vanilla servlet application. -Ted. On Sun, 21 Nov 2004 15:01:02 -0800 (PST), Martin Cooper wrote: I believe Chain is now sufficiently complete and stable to warrant an official 1.0 release. There are no outstanding bug reports, and the component is already in use in a number of projects. The plan is to release HEAD as Commons Chain 1.0 on completion of a successful vote. I will be the release manager. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons - -- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: commons-dev- [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: [email][gump] Currently email is failing in gump
Okay, the change was made. Can you possible remove the older dumbster.jar file as an installed package? Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:23 AM To: [EMAIL PROTECTED] Subject: Re: [email][gump] Currently email is failing in gump On Wed, 24 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I'll take a look at trying to get dumbster to build in gump from source. When Stefano installed dumbster on brutus he did so because the source was not available from a public repository. I think he already had the dependencies and Ant invocations correct (just no source tree), just look through older revisions of the dumbster.xml file. 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]
[Jakarta Commons Wiki] Updated: TheSandbox
Date: 2004-11-25T01:18:15 Editor: EricPugh [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -7,7 +7,6 @@ * Clazz - no community, code stable. * Compress - code extracted from Ant, currently dormant. * Convert - various conversion ideas extracted from BeanUtils, currently in development. - * Email - The code (mainly from Turbine) is stable and has a user base but is unreleased. Currently lacking maintainers. * Events - currently in slow development. * Functor * Id - parts from Lang, parts new, currently in-development. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email][gump] Currently email is failing in gump
On Thu, 25 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: Can you possible remove the older dumbster.jar file as an installed package? Once I see success with building it, yes ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email - Imported sources
epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuthenticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttachment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.java N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-ant (in module jelly-tags) 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-ant has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 37 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-ant : This is a Jelly interface for Ant. - commons-jelly-tags-fmt : This is a set of Jelly i18n tags. - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/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-ant-25112004.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/gump_work/build_jelly-tags_commons-jelly-tags-ant.html Work Name: build_jelly-tags_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-ant-25112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/classes:/usr/local/gump/public/workspace/jelly-tags/ant/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-25112004.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-25112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-25112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-25112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-25112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-25112004.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/commons-jelly-tags-util-25112004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-25112004.jar - [junit] Testcase: readWriteIn took 0.191 sec [junit] Testcase: startUpReadWrite took 0.123 sec [junit] Testcase: copy took 0.123 sec [junit] Caused an ERROR [junit] file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] org.apache.commons.jelly.JellyTagException: file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:680) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at
Re: cvs commit: jakarta-commons/email - Imported sources
Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuthenticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttachment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.java N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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]
cvs commit: jakarta-commons/commons-build/parts sandbox-table.ent components-table.ent
epugh 2004/11/25 02:45:09 Modified:commons-build/menus components-items.ent sandbox-items.ent commons-build/parts sandbox-table.ent components-table.ent Log: [email] promoted out of sandbox. Revision ChangesPath 1.5 +1 -0 jakarta-commons/commons-build/menus/components-items.ent Index: components-items.ent === RCS file: /home/cvs/jakarta-commons/commons-build/menus/components-items.ent,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- components-items.ent 18 Nov 2004 23:46:07 - 1.4 +++ components-items.ent 25 Nov 2004 10:45:09 - 1.5 @@ -12,6 +12,7 @@ item name=Digester href=http://jakarta.apache.org/commons/digester// item name=Discovery href=http://jakarta.apache.org/commons/discovery// item name=EL href=http://jakarta.apache.org/commons/el// +item name=Email href=http://jakarta.apache.org/commons/email// item name=FileUpload href=http://jakarta.apache.org/commons/fileupload// item name=HttpClient href=http://jakarta.apache.org/commons/httpclient// item name=IO href=http://jakarta.apache.org/commons/io// 1.9 +0 -1 jakarta-commons/commons-build/menus/sandbox-items.ent Index: sandbox-items.ent === RCS file: /home/cvs/jakarta-commons/commons-build/menus/sandbox-items.ent,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- sandbox-items.ent 18 Nov 2004 23:46:07 - 1.8 +++ sandbox-items.ent 25 Nov 2004 10:45:09 - 1.9 @@ -3,7 +3,6 @@ item name=Compress href=http://jakarta.apache.org/commons/sandbox/compress// item name=Contract href=http://jakarta.apache.org/commons/sandbox/contract// item name=Convert href=http://jakarta.apache.org/commons/sandbox/convert// -item name=Email href=http://jakarta.apache.org/commons/sandbox/email// item name=Events href=http://jakarta.apache.org/commons/sandbox/events// item name=Feedparser href=http://jakarta.apache.org/commons/sandbox/feedparser// item name=Functor href=http://jakarta.apache.org/commons/sandbox/functor// 1.10 +0 -6 jakarta-commons/commons-build/parts/sandbox-table.ent Index: sandbox-table.ent === RCS file: /home/cvs/jakarta-commons/commons-build/parts/sandbox-table.ent,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- sandbox-table.ent 18 Nov 2004 23:39:23 - 1.9 +++ sandbox-table.ent 25 Nov 2004 10:45:09 - 1.10 @@ -33,12 +33,6 @@ /td /tr tr -tda href=http://jakarta.apache.org/commons/sandbox/email/;Email/a/td -td - Email provides a simple library for sending e-mail from Java. -/td -/tr -tr tda href=http://jakarta.apache.org/commons/sandbox/events/;Events/a/td td Commons-Events provides additional classes for firing and handling 1.7 +6 -0 jakarta-commons/commons-build/parts/components-table.ent Index: components-table.ent === RCS file: /home/cvs/jakarta-commons/commons-build/parts/components-table.ent,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- components-table.ent 18 Nov 2004 23:39:23 - 1.6 +++ components-table.ent 25 Nov 2004 10:45:09 - 1.7 @@ -96,6 +96,12 @@ /td /tr tr +tda href=http://jakarta.apache.org/commons/email/;Email/a/td +td + Email provides a simple library for sending e-mail from Java. +/td +/tr +tr tda href=http://jakarta.apache.org/commons/fileupload/;FileUpload/a/td td FileUpload makes it easy to add robust, high-performance, file upload - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/file FileResourceManager.java
ozeigermann2004/11/25 02:57:16 Modified:transaction/src/java/org/apache/commons/transaction/file FileResourceManager.java Log: Removed wrong statement about isolation levels (serializable is possible as well) Revision ChangesPath 1.7 +4 -5 jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java Index: FileResourceManager.java === RCS file: /home/cvs/jakarta-commons-sandbox/transaction/src/java/org/apache/commons/transaction/file/FileResourceManager.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- FileResourceManager.java 5 Aug 2004 08:03:45 - 1.6 +++ FileResourceManager.java 25 Nov 2004 10:57:16 - 1.7 @@ -67,7 +67,6 @@ * liNumber of simultaneuously open resources is limited to the number of available file descriptors * liIt does not scale a bit * liPessimistic transaction and locking scheme - * liIsolation level currently is restricted to emread committed/em and emrepeated read/em (which is not that bad) * /ul * * emImportant/em: If possible you should have the work and store directory located in the - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.java N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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]
cvs commit: jakarta-commons/email build.properties.sample
epugh 2004/11/25 03:14:13 Removed: emailbuild.properties.sample Log: No longer required. Maven generated build.xml using latest Ant plugin deals with overridden jars properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test - New directory
epugh 2004/11/25 03:14:42 jakarta-commons/email/src/test - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org - New directory
epugh 2004/11/25 03:14:42 jakarta-commons/email/src/test/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache/commons/mail - New directory
epugh 2004/11/25 03:14:42 jakarta-commons/email/src/test/org/apache/commons/mail - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache/commons - New directory
epugh 2004/11/25 03:14:42 jakarta-commons/email/src/test/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache - New directory
epugh 2004/11/25 03:14:42 jakarta-commons/email/src/test/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache/commons/mail/settings EmailConfiguration.java
epugh 2004/11/25 03:14:53 Added: email/src/test/org/apache/commons/mail SendWithAttachmentsTest.java HtmlEmailTest.java EmailAttachmentTest.java BaseEmailTestCase.java DefaultAuthenticatorTest.java EmailTest.java SimpleEmailTest.java MultiPartEmailTest.java email/src/test/org/apache/commons/mail/mocks MockSimpleEmail.java MockHtmlEmailConcrete.java MockEmailConcrete.java MockMultiPartEmailConcrete.java email/src/test/org/apache/commons/mail/settings EmailConfiguration.java Log: Somehow missed all test code when importing Revision ChangesPath 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/SendWithAttachmentsTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/SendWithAttachmentsTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/HtmlEmailTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/HtmlEmailTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/EmailAttachmentTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/EmailAttachmentTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/BaseEmailTestCase.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/BaseEmailTestCase.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/DefaultAuthenticatorTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/DefaultAuthenticatorTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/EmailTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/EmailTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/SimpleEmailTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/SimpleEmailTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/MultiPartEmailTest.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/MultiPartEmailTest.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockSimpleEmail.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockSimpleEmail.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockHtmlEmailConcrete.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockHtmlEmailConcrete.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockEmailConcrete.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockEmailConcrete.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockMultiPartEmailConcrete.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/mocks/MockMultiPartEmailConcrete.java?rev=1.1 1.1 jakarta-commons/email/src/test/org/apache/commons/mail/settings/EmailConfiguration.java http://cvs.apache.org/viewcvs/jakarta-commons/email/src/test/org/apache/commons/mail/settings/EmailConfiguration.java?rev=1.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs/images - New directory
epugh 2004/11/25 03:16:12 jakarta-commons/email/xdocs/images - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs/style - New directory
epugh 2004/11/25 03:16:12 jakarta-commons/email/xdocs/style - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs/style project.css
epugh 2004/11/25 03:16:30
Added: email/xdocs/images email-logo-white.xcf email-logo-white.png
email/xdocs/style project.css
Log:
Missing image and style as well when importing..
Revision ChangesPath
1.1 jakarta-commons/email/xdocs/images/email-logo-white.xcf
Binary file
1.1 jakarta-commons/email/xdocs/images/email-logo-white.png
Binary file
1.1 jakarta-commons/email/xdocs/style/project.css
Index: project.css
===
#banner, #banner td {
background: #fff;
color: #000;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache/commons/mail/mocks - New directory
epugh 2004/11/25 03:14:43 jakarta-commons/email/src/test/org/apache/commons/mail/mocks - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/src/test/org/apache/commons/mail/settings - New directory
epugh 2004/11/25 03:14:43 jakarta-commons/email/src/test/org/apache/commons/mail/settings - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
cool! Eric, I just *surfed* cvs, we lost the cvs-log from sandbox, isn't it? -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:10 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: cvs commit: jakarta-commons/email - Imported sources Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail. java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.jav a N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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]
cvs commit: jakarta-commons/email project.xml
epugh 2004/11/25 03:36:24 Modified:emailproject.xml Log: extend regular commons project Revision ChangesPath 1.2 +2 -2 jakarta-commons/email/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/email/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 25 Nov 2004 09:56:56 - 1.1 +++ project.xml 25 Nov 2004 11:36:24 - 1.2 @@ -15,7 +15,7 @@ limitations under the License. -- project - extend../sandbox-build/project.xml/extend + extend../commons-build/project.xml/extend nameCommons Email/name idcommons-email/id logo/images/email-logo-white.png/logo @@ -26,7 +26,7 @@ logo/logo packageorg.apache.commons.mail/package - gumpRepositoryIdjakarta-commons-sandbox/gumpRepositoryId + gumpRepositoryIdjakarta-commons/gumpRepositoryId developers developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cleanup questions from importing email
Hi all, A couple questions about updating the site... 1) Is updating the main commons site automated or not? 2) in jakarta-commons/BUILD_DOCS.txt are some instructions, but they appear to be just to build the main page, correct? I think, but am not sure, that they are out of date, and have been replaced with just running maven site from commons-build? 3) The ASF logo on the top left of the commons site seems to have gone missing, this is an error right? 4) Once I generate the site into /jakarta-commons/commons-build/target/docs then I need to copy the content to jakarta-commons/docs and commit it. What about though the extra files generated by maven that aren't in jakarta-commons/docs. Should they just come over as well. 5) Should the maven site goal copy the new content for you into jakarta-commons/docs? 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. I'll update the wiki based on the feedback I get. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
Possibly.. I just followed the directions in the wiki. I also didn't manage to import properly the /src/test tree and the /xdocs/ tree as well. Not sure why. The cvs-log should still be in the jakarta-commons-sandbox project, correct? Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:22 PM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-commons/email - Imported sources cool! Eric, I just *surfed* cvs, we lost the cvs-log from sandbox, isn't it? -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:10 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: cvs commit: jakarta-commons/email - Imported sources Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail. java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.jav a N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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: cvs commit: jakarta-commons/email - Imported sources
No idea, as we moved (MyFaces) from SF to Apache. I loaded a tar-ball did local cvs (on my box) renamed the packages and removed the sf-links. after that I checked it in localy. created a Tar-ball for the new. That guy was imported to apache cvs by the incubator-guys, I guess. BTW. perhaps you saw my accident yesterday. I saw some clazzes without @version etc. I submitted by accident $LOG (for CVS) I guess it is not common inside of Jakarta? In myFaces we still use this feature. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 1:13 PM To: Matthias Wessendorf Cc: Commons-Dev Subject: RE: cvs commit: jakarta-commons/email - Imported sources Possibly.. I just followed the directions in the wiki. I also didn't manage to import properly the /src/test tree and the /xdocs/ tree as well. Not sure why. The cvs-log should still be in the jakarta-commons-sandbox project, correct? Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:22 PM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-commons/email - Imported sources cool! Eric, I just *surfed* cvs, we lost the cvs-log from sandbox, isn't it? -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:10 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: cvs commit: jakarta-commons/email - Imported sources Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.jav a N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmai l. java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.j av a N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/email - Imported sources
On Thu, 25 Nov 2004, Matthias Wessendorf [EMAIL PROTECTED] wrote: created a Tar-ball for the new. That guy was imported to apache cvs by the incubator-guys, I guess. Probably you are using Subversion and not CVS for Myfaces, so it ran through cvs2svn which preserved history. cvs import doesn't preserve history. If you wanted to do that, you'd have to move the *,v files of the server around (which you did in the MyFaces case). I submitted by accident $LOG (for CVS) I guess it is not common inside of Jakarta? I've never seen any Apache code base use it, but that doesn't mean much. I personally don't like it, but its a matter of taste. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
Probably you are using Subversion and not CVS for Myfaces, so it ran through cvs2svn which preserved history. no, we are using CVS. cvs import doesn't preserve history. If you wanted to do that, you'd have to move the *,v files of the server around (which you did in the MyFaces case). yes, thats true! I submitted by accident $LOG (for CVS) I guess it is not common inside of Jakarta? I've never seen any Apache code base use it, but that doesn't mean much. I personally don't like it, but its a matter of taste. I can understand that point! ;-) Matthias 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]
[transaction] improved logging interface.
Hello Oliver, I would like to improve the LoggerFacade interface with methods like, logFiner(String message, Object param1); logFiner(String message, Object param1, Object param2); logFine(String message, Object param1); ... to avoid the frequently used calls like logFine(anyObject1 + any string + anyObject2); This would reduce the overhead if logging is disabled. Changing the interfaces before the first release would be good, I think. What do you think? Regards, Stefan -- Stefan Lützkendorf -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs index.xml
epugh 2004/11/25 05:57:45 Modified:email/xdocs index.xml Log: No longer in sandbox! Revision ChangesPath 1.2 +2 -7 jakarta-commons/email/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/email/xdocs/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 25 Nov 2004 09:56:56 - 1.1 +++ index.xml 25 Nov 2004 13:57:45 - 1.2 @@ -59,7 +59,7 @@ subsection name=Status p ul - liThis code is in the commons isandbox/i/li + liThis code has been recently promoted from commons isandbox/i/li liThe code is unreleased/li liMethods and classes can and will appear and disappear without warning/li liIf you like the code and want to push it towards a release, join the mailing list!/li @@ -73,17 +73,12 @@ p ul liThe a href=apidocs/index.htmlJavadoc/a of the latest CVS/li - liThe a href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/email/;CVS repository/a can be browsed./li + liThe a href=http://cvs.apache.org/viewcvs/jakarta-commons/email/;CVS repository/a can be browsed./li /ul /p /section -section name=Releases -p -None. This is a isandbox/i component. -/p -/section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs downloads.xml navigation.xml
epugh 2004/11/25 06:00:53 Modified:email/xdocs downloads.xml navigation.xml Log: No longer in sandbox! Revision ChangesPath 1.2 +2 -2 jakarta-commons/email/xdocs/downloads.xml Index: downloads.xml === RCS file: /home/cvs/jakarta-commons/email/xdocs/downloads.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- downloads.xml 25 Nov 2004 09:56:56 - 1.1 +++ downloads.xml 25 Nov 2004 14:00:53 - 1.2 @@ -27,7 +27,7 @@ pThere has not yet been a release of commons-email./p p The CVS repository for ememail/em can be -a href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/email/;browsed online/a +a href=http://cvs.apache.org/viewcvs/jakarta-commons/email/;browsed online/a or a href=http://jakarta.apache.org/site/cvsindex.html;downloaded using a CVS client/a. /p 1.2 +2 -2 jakarta-commons/email/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/email/xdocs/navigation.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- navigation.xml25 Nov 2004 09:56:56 - 1.1 +++ navigation.xml25 Nov 2004 14:00:53 - 1.2 @@ -15,7 +15,7 @@ limitations under the License. -- -!DOCTYPE org.apache.commons.menus SYSTEM '../../../jakarta-commons/commons-build/menus/menus.dtd' +!DOCTYPE org.apache.commons.menus SYSTEM '../../../commons-build/menus/menus.dtd' project name=Commons#xA0;Email titleCommons#xA0;Email/title body @@ -25,7 +25,7 @@ item name=Javadoc href=apidocs/index.html/ item name=Mailing lists href=/mail-lists.html/ item name=Team href=/team-list.html/ - item name=CVS href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/email// + item name=CVS href=http://cvs.apache.org/viewcvs/jakarta-commons/email// /menu common-menus; /body - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/lib - New directory
epugh 2004/11/25 06:22:32 jakarta-commons/email/lib - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/lib activation-1.0.2.jar javamail-1.3.2.jar
epugh 2004/11/25 06:22:59 Added: email/lib activation-1.0.2.jar javamail-1.3.2.jar Log: add missing jars Revision ChangesPath 1.1 jakarta-commons/email/lib/activation-1.0.2.jar Binary file 1.1 jakarta-commons/email/lib/javamail-1.3.2.jar Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/conf HEADER.txt checkstyle.xml
epugh 2004/11/25 06:23:07
Added: email/conf HEADER.txt checkstyle.xml
Log:
Missing configuration files for build
Revision ChangesPath
1.1 jakarta-commons/email/conf/HEADER.txt
Index: HEADER.txt
===
/*
* Copyright 2001-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
1.1 jakarta-commons/email/conf/checkstyle.xml
Index: checkstyle.xml
===
?xml version=1.0?
!DOCTYPE module PUBLIC
-//Puppy Crawl//DTD Check Configuration 1.1//EN
http://www.puppycrawl.com/dtds/configuration_1_1.dtd;
!-- Checkstyle configuration that checks the commons-configuration coding
conventions --
module name=Checker
property name=localeLanguage value=en/
!-- Checks that a package.html file exists for each package. --
!-- See http://checkstyle.sf.net/config_javadoc.html#PackageHtml --
module name=PackageHtml/
!-- Checks whether files end with a new line.--
!-- See http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile --
module name=NewlineAtEndOfFile/
!-- Checks that property files contain the same keys. --
!-- See http://checkstyle.sf.net/config_misc.html#Translation --
module name=Translation/
module name=TreeWalker
property name=cacheFile value=${checkstyle.cache.file}/
!-- Checks for Javadoc comments. --
!-- See http://checkstyle.sf.net/config_javadoc.html --
module name=JavadocMethod
property name=allowUndeclaredRTE value=true/
/module
module name=JavadocType
property name=authorFormat value=\S/
/module
module name=JavadocVariable/
!-- Checks for Naming Conventions. --
!-- See http://checkstyle.sf.net/config_naming.html --
module name=ConstantName/
module name=LocalFinalVariableName/
module name=LocalVariableName/
module name=MemberName/
module name=MethodName/
module name=PackageName/
module name=ParameterName/
module name=StaticVariableName/
module name=TypeName/
!-- Checks for Headers --
!-- See http://checkstyle.sf.net/config_header.html --
module name=Header
property name=headerFile value=${basedir}/conf/HEADER.txt/
property name=ignoreLines value=2/
/module
!-- Following interprets the header file as regular expressions. --
!-- module name=RegexpHeader/--
!-- Checks for imports --
!-- See http://checkstyle.sf.net/config_import.html --
module name=AvoidStarImport/
module name=IllegalImport/ !-- defaults to sun.* packages --
module name=RedundantImport/
module name=UnusedImports/
!-- Checks for Size Violations.--
!-- See http://checkstyle.sf.net/config_sizes.html --
module name=FileLength/
module name=LineLength
property name=max value=120/
/module
module name=MethodLength/
module name=ParameterNumber/
!-- Checks for whitespace --
!-- See http://checkstyle.sf.net/config_whitespace.html --
module name=EmptyForIteratorPad/
module name=NoWhitespaceAfter/
module name=NoWhitespaceBefore/
module name=OperatorWrap/
module name=ParenPad/
module name=TabCharacter/
module name=WhitespaceAfter/
module name=WhitespaceAround/
!-- Modifier Checks--
!-- See http://checkstyle.sf.net/config_modifiers.html --
module name=ModifierOrder/
module name=RedundantModifier/
!-- Checks for blocks. You know, those {}'s --
!-- See http://checkstyle.sf.net/config_blocks.html --
module name=AvoidNestedBlocks/
module name=EmptyBlock/
module
cvs commit: jakarta-commons/email/conf - New directory
epugh 2004/11/25 06:23:01 jakarta-commons/email/conf - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Créée: (JELLY-167) add 'public JellyContext newEmptyJellyContext()' to JellyContext
add 'public JellyContext newEmptyJellyContext()' to JellyContext Key: JELLY-167 URL: http://nagoya.apache.org/jira/browse/JELLY-167 Project: jelly Type: Wish Components: core / taglib.core Versions: 1.0-beta-5 Reporter: Marc DeXeT method 'public JellyContext newJellyContext()' uses 'public JellyContext(JellyContext parent)'. This constructor copies parent properties AND parent variables. To create variables quenched context, you have to clear variables or to set inherit to false. I wish to have a new method 'public JellyContext newEmptyJellyContext()' which copies all root context properties (as tag caching) but DOESN'T copy variables map. Even if you could do the same with inherit or variable map clearing or other methods, it would be more meaningful to use a assigned method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleanup questions from importing email
A couple of comments and additions below. On Thu, 25 Nov 2004 12:47:02 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, A couple questions about updating the site... 1) Is updating the main commons site automated or not? No, it's not. 2) in jakarta-commons/BUILD_DOCS.txt are some instructions, but they appear to be just to build the main page, correct? I think, but am not sure, that they are out of date, and have been replaced with just running maven site from commons-build? I confess to being out of date on knowing the Commons website generaton process, so someone else is going to have to deal with that kind of question. 3) The ASF logo on the top left of the commons site seems to have gone missing, this is an error right? 4) Once I generate the site into /jakarta-commons/commons-build/target/docs then I need to copy the content to jakarta-commons/docs and commit it. What about though the extra files generated by maven that aren't in jakarta-commons/docs. Should they just come over as well. 5) Should the maven site goal copy the new content for you into jakarta-commons/docs? 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. I'll update the wiki based on the feedback I get. Eric Additional items: (7) Switch nightly builds to run from Commons Proper instead of sandbox. -- I switched as of tonight's run (20041126), but I'm still getting failures in the tests (can't start the server) that cause the overall ant dist build to fail. (8) Adjust CVS access karma for any email committers that had access to the sandbox but not to Commons Proper. -- Please let me know if that applies to anyone here, and I will adjust the karma. Graduating sandbox packages take their committers with them. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migrate to SVN?
6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
We've started doing Jakarta projects over to SVN, but we've been doing the easy stuff first to get into the hang of it. I think a pretty fair target for Jakarta is to be fully in SVN by the end of next year; unless there are reasons to move quicker. One thing to work out with Commons is whether we should move the whole lot in one go; should do commons-proper then sandbox later; or do individual components one at a time as it fits their release cycles etc. Hen On Thu, 25 Nov 2004 14:07:39 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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]
cvs commit: jakarta-commons/logging/optional/src/java/org/apache/commons/logging/impl WeakHashtable.java
rdonkin 2004/11/25 12:09:53 Modified:logging/optional/src/java/org/apache/commons/logging/impl WeakHashtable.java Log: Class level documentation. Contributed by Brian Stansberry Revision ChangesPath 1.5 +27 -2 jakarta-commons/logging/optional/src/java/org/apache/commons/logging/impl/WeakHashtable.java Index: WeakHashtable.java === RCS file: /home/cvs/jakarta-commons/logging/optional/src/java/org/apache/commons/logging/impl/WeakHashtable.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- WeakHashtable.java17 Nov 2004 23:23:21 - 1.4 +++ WeakHashtable.java25 Nov 2004 20:09:53 - 1.5 @@ -35,9 +35,34 @@ * p * strongUsage:/strong typical use case is as a drop-in replacement * for the codeHashtable/code use in codeLogFactory/code for J2EE enviroments - * running 1.3+ JVMs. Use of this class will allow classloaders to be collected by - * the garbage collector without the need to call release. + * running 1.3+ JVMs. Use of this class iin most cases/i (see below) will + * allow classloaders to be collected by the garbage collector without the need + * to call [EMAIL PROTECTED] org.apache.commons.logging.LogFactory#release(ClassLoader) LogFactory.release(ClassLoader)}. * /p + * p + * In a particular usage scenario, use of codeWeakHashtable/code alone will + * be insufficent to allow garbage collection of a classloader without a call to + * coderelease/code. If the abstract class codeLogFactory/code is + * loaded by a parent classloader and a concrete subclass implementation of + * codeLogFactory/code is loaded by a child classloader, the concrete + * implementation will have a strong reference to the child classloader via the + * chain codegetClass().getClassLoader()/code. The codeWeakHashtable/code + * will have a strong reference to the codeLogFactory/code implementation as + * one of the values in its map. This chain of references will prevent + * collection of the child classloader. + * /p + * p + * Such a situation would typically only occur if commons-logging.jar were + * loaded by a parent classloader (e.g. a server level classloader in a + * servlet container) and a custom codeLogFactory/code implementation were + * loaded by a child classloader (e.g. a web app classloader). If use of + * a custom codeLogFactory/code subclass is desired, ensuring that the + * custom subclass is loaded by the same classloader as codeLogFactory/code + * will prevent problems. In normal deployments, the standard implementations + * of codeLogFactory/code found in package codeorg.apache.commons.logging.impl/code + * will be loaded by the same classloader that loads codeLogFactory/code + * itself, so use of the standard codeLogFactory/code implementations + * should not pose problems. * * @author Brian Stansberry */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
Henri Yandell wrote: I think a pretty fair target for Jakarta is to be fully in SVN by the end of next year; unless there are reasons to move quicker. End of NEXT year?! I do hope you're kidding. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31286] - [logging] Memory leaks in JBoss due to LogFactory cache
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=31286. 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=31286 --- Additional Comments From [EMAIL PROTECTED] 2004-11-25 21:14 --- Another good patch. Committed. Many thanks. I think that it should be possible to simplify the code in the way you suggest (by using simple strong references) without effecting the function. My next priority will be to work on the documentation build and the user guide. Then push towards a 1.0.5 release. I'll leave this bug open until that's done in case you find time. Robert -- 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: Migrate to SVN?
On Thu, 25 Nov 2004 14:07:39 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? +1000! I've actually been contemplating proposing this recently, but you beat me to it. ;-) As for whether we do it in one go, or piecemeal, I have a strong preference for the former. However, if not everyone is ready to sign up for such a move, I would be more than happy to lead the charge for the components I'm involved with. -- Martin Cooper A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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 to SVN?
Now, for this cvs-to-svn (whichever its name is) should be working well. The only experience I had were pretty dark. If someone else manages this well, I'd be happy to switch to svn as a developer. I am using this myself already much. Has anyone experienced maven's svn support ? paul Le 25 nov. 04, à 21:04, Henri Yandell a écrit : One thing to work out with Commons is whether we should move the whole lot in one go; should do commons-proper then sandbox later; or do individual components one at a time as it fits their release cycles etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
On Thu, 25 Nov 2004 15:04:37 -0500, Henri Yandell [EMAIL PROTECTED] wrote: We've started doing Jakarta projects over to SVN, but we've been doing the easy stuff first to get into the hang of it. I think a pretty fair target for Jakarta is to be fully in SVN by the end of next year; unless there are reasons to move quicker. Couldn't we be done by the end of THIS year? The sooner we're done, the sooner people only have one source control system to worry about. (We'd also help free up the infra@ folks to get on with their plans for a CVS-free world. :) -- Martin Cooper One thing to work out with Commons is whether we should move the whole lot in one go; should do commons-proper then sandbox later; or do individual components one at a time as it fits their release cycles etc. Hen On Thu, 25 Nov 2004 14:07:39 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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: [jelly] Building 1.0-RC1
On 22 Nov 2004, at 04:55, Brett Porter wrote: Jelly doesn't have an Ant build file AFAIK, which this documentation assumes. documenting the mavenized process has been awaiting a volunteer for a long time now :) Reading through those documents, Maven's prepare/perform release cycle does every step except for PGP signing which I do manually for distribution releases but is a planned feature (and obviously the sanity checks that things ended up in a certain web server). Some newer stuff may not be setup for Jelly (like being able to use announcement:mail to mail the announcement if you are happy with what was in changes.xml). This document covers the process: http://maven.apache.org/reference/developers/releasing-plugins.html I am currently rewriting the Maven documentation and will make this a bit more general so it can be used for other Maven projects. cool :) it'd be useful if anchors were available in the maven documentation for other projects to link to. that way, it should be an easy job just to add links to the corresponding steps for mavenized components. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
On Thu, 25 Nov 2004 15:13:41 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote: Henri Yandell wrote: I think a pretty fair target for Jakarta is to be fully in SVN by the end of next year; unless there are reasons to move quicker. End of NEXT year?! I do hope you're kidding. All of Jakarta, not just Commons. It involves getting lots of disparate groups of people to move in the same direction and unless there's a need to rush (which there may be), I planned to be asking for a handful of projects each quarter. We've 19 to move. 17 now I guess with ORO and Velocity over. ORO seemed to go over easily enough; did Velocity have any problems do you know? Need to ask them. Also need to decide whether HttpClient would go over in Commons, or become a jakarta/ subproject at that point, same for JCS. Also whether various subprojects of Jakarta that are talking about TLP would go straight to TLP in SVN. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
Henri Yandell wrote: Noel J. Bergman wrote: Henri Yandell wrote: I think a pretty fair target for Jakarta is to be fully in SVN by the end of next year; unless there are reasons to move quicker. End of NEXT year?! I do hope you're kidding. All of Jakarta, not just Commons. I knew what you meant. Same response. Also need to decide whether HttpClient would go over in Commons, or become a jakarta/ subproject at that point, same for JCS. Makes no difference. Once in SVN, it is trivial to reorganize. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
It gave me pain; as has installing an svn server, client, Subclipse (Eclipse plugin), tagging in svn and generally maintaining the Berkley DB (it can get corrupted). The ASF though has much more experience with the svn server-side; so the only ones that would really worry me are installing a client, Subclipse and tagging. Once I figured it out, the client installed on Linux okay. On Windows it's a doddle, and on the Mac you do it the same way as on Linux; the fink install was crappy. It might be usable now, or maybe there's a Mac package for it. I've not heard that IDE plugins are any better, but I don't use them so it's not a biggy for me. The more painful tagging in svn is made up for by the advantages of svn, so I'm happy to embrace it. Hen On Thu, 25 Nov 2004 21:18:28 +0100, Paul Libbrecht [EMAIL PROTECTED] wrote: Now, for this cvs-to-svn (whichever its name is) should be working well. The only experience I had were pretty dark. If someone else manages this well, I'd be happy to switch to svn as a developer. I am using this myself already much. Has anyone experienced maven's svn support ? paul Le 25 nov. 04, à 21:04, Henri Yandell a écrit : One thing to work out with Commons is whether we should move the whole lot in one go; should do commons-proper then sandbox later; or do individual components one at a time as it fits their release cycles etc. - 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]
cvs commit: jakarta-commons/email build.xml
bayard 2004/11/25 12:41:16
Modified:emailbuild.xml
Log:
sun licensing does not let us keep the javamail and activation jars in the
cvs repo, so I have put this back to the default broken attempt to get it from
Maven
Revision ChangesPath
1.2 +5 -5 jakarta-commons/email/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/email/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 25 Nov 2004 09:56:56 - 1.1
+++ build.xml 25 Nov 2004 20:41:16 - 1.2
@@ -148,10 +148,10 @@
/setproxy
get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar;
/get
-copy todir=${libdir} file=lib/javamail-1.3.2.jar
-/copy
-copy todir=${libdir} file=lib/activation-1.0.2.jar
-/copy
+get dest=${libdir}/javamail-1.3.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/java-mail/jars/javamail-1.3.2.jar;
+/get
+get dest=${libdir}/activation-1.0.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/activation/jars/activation-1.0.2.jar;
+/get
get dest=${libdir}/dumbster-1.5.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/dumbster/jars/dumbster-1.5.jar;
/get
/target
@@ -161,4 +161,4 @@
unjar dest=${maven.home} src=${user.home}/maven-install-latest.jar
/unjar
/target
-/project
\ No newline at end of file
+/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
On Thu, 25 Nov 2004 15:37:42 -0500, Henri Yandell [EMAIL PROTECTED] wrote: It gave me pain; as has installing an svn server, client, Subclipse (Eclipse plugin), tagging in svn and generally maintaining the Berkley DB (it can get corrupted). The ASF though has much more experience with the svn server-side; so the only ones that would really worry me are installing a client, Subclipse and tagging. Once I figured it out, the client installed on Linux okay. On Windows it's a doddle, and on the Mac you do it the same way as on Linux; the fink install was crappy. It might be usable now, or maybe there's a Mac package for it. I've not heard that IDE plugins are any better, but I don't use them so it's not a biggy for me. The more painful tagging in svn is made up for by the advantages of svn, so I'm happy to embrace it. Hmm, I actually found tagging and branching in SVN just as easy as in CVS. Just: svn copy URL1 URL2 A doddle, as you might say. ;-) -- Martin Cooper Hen On Thu, 25 Nov 2004 21:18:28 +0100, Paul Libbrecht [EMAIL PROTECTED] wrote: Now, for this cvs-to-svn (whichever its name is) should be working well. The only experience I had were pretty dark. If someone else manages this well, I'd be happy to switch to svn as a developer. I am using this myself already much. Has anyone experienced maven's svn support ? paul Le 25 nov. 04, à 21:04, Henri Yandell a écrit : One thing to work out with Commons is whether we should move the whole lot in one go; should do commons-proper then sandbox later; or do individual components one at a time as it fits their release cycles etc. - 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] rm -r lib/*.jar
Apologies for treading on people's toes here, but I wanted to get the problem solved quickly, even if it causes a bad build etc. Making sure we're good licence-wise is crucial. Craig raised the issue on the PMC list that the email component had the activation.jar and the javamail.jar in the cvs repository. We're allowed to ship them in distributions, but not to offer them separately (correct me if that's wrong somebody?). Having them in CVS is effectively offering them separately. I've rm-r'd them on the cvs server and modified the build.xml to do the same thing the project.xml does; attempt to grab them from ibiblio and fail. I used rm -r as opposed to cvs remove as they'd still be available with cvs remove. Sorry for not just waiting for the main email committers to read Craig's email from this morning. Given the time of year I'd hate for it to turn out that the 2 or 3 people most likely to fix it are in the US and out late at thanksgiving dinners. Feel free to flame :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
Le 25 nov. 04, à 21:37, Henri Yandell a écrit : and on the Mac you do it the same way as on Linux; the fink install was crappy. It might be usable now, or maybe there's a Mac package for it. It worked fine for me, both server and client. Do note that it is now in the stable tree, svn version 1.0.6... maybe you tested in darker times... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
The problems I've hit are: 1/ No easy way to do 'cvs status -v project.xml' and list the tags that have been applied to a component. Instead I've switched to using an alias with: svn list http://svn.osjava.org/svn/osjava/releases | grep $1 | sed 's/\/$//' 2/ Have to change the mindset for doing releases without a piece of work. Say [io] doesn't want to release the find sub-package. The way I'd normally do this in CVS is to check it out; remove the find package and do a cvs tag. With SVN I think I would tag the whole thing; then check the tag out and treat it like a branch, removing files from it to get the right thing. I'm not sure if this is any worse; might just be a mental change. 3/ URLs. Definitely more of a pain to come up with the two long urls to tag with etc :) I wonder how well the IDE plugins do with this. How do you train them to understand your tag/branch/release strategy. 4/ Tagging multiple entities. With maven (or ant I guess), when using a shared super-build file (ie commons-build/project.xml), you should tag both your component and the super-build file. In Commons we've got around this by only using the super-build file for site generation, but I've a project where I use it for building too. To tag the right files, I have to create a new directory in releases/, commit that into svn, then svn copy various things into it. A little bit of a pain, more so if you screw up and do an update in releases/ :) Overall though I've adapted and am dealing with it. My only worries with SVN are the pains the berkeley db has given me, including some bug in viewcvs which corrupted the svn repo to the extent that the rescue scripts failed and whether IDE plugins will be good enough whenever I can afford a powerful enough laptop :) The only one that would affect the ASF for other people I think is whether their current method of using CVS is supported in SVN and how loudly they want to cry if it isn't. Hen On Thu, 25 Nov 2004 12:44:21 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 25 Nov 2004 15:37:42 -0500, Henri Yandell [EMAIL PROTECTED] wrote: The more painful tagging in svn is made up for by the advantages of svn, so I'm happy to embrace it. Hmm, I actually found tagging and branching in SVN just as easy as in CVS. Just: svn copy URL1 URL2 A doddle, as you might say. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Promote Resources to Commons Proper
The vote to promote Resources resulted in 5 +1s and one -0. I'll go ahead with the promotion and web site updates shortly. The vote thread is here: http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=60551 -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] a different approach...
On 18 Nov 2004, at 23:18, Matt Sgarlata wrote: Hi Robert, thanks for your comments : ) My responses are below... why not start a little project on source forge...? Already registered on SF this morning... I probably will create a SF project this weekend :) My tentative project name is Morph. make sure you add a link to the wiki so everyone can find morph :) i don't see any real harm announcing releases and stuff on the mailing lists though it'd probably be wiser not to phrase any posts so as not raise the temperature unnecessary. (it's a temptation when you're the new project on the block to push general claims of superiority but often it's better to focus on individuality: what the project does better) - In place of BeanUtils.copyProperties there is a Copier interface. It is very similar to the Converter interface, but it's original intent was different: to copy data from one location to another, where creating a new object doesn't make sense. For example, let's say we want to store information from a Map or an object graph as separate attributes in an HTTP request. We can't just create a new HTTP request object... it already exists! So we use a Copier. Basically, Converters are for the simple stuff like primitives, Dates, etc and Copiers are for fancier things like Object[] - List. You can always take something that is written with the Copier interface and expose it as a Converter but not vice-versa (The net.sf.morph.converters.CopierConverter class exposes a Copier as a Converter). - While working on Copiers, I realized I needed to be able to pull information out of various different types of things: objects and maps are simple examples, but I might also want to be able to pull info from HTTP request parameters, etc. This is what Reflectors are for. They help Copiers get the job done. hmmm sounds frameworkish... Well yes and no. You are free to implement the Copier interface directly, which is just as simple as the Converter interface (both have 2 very simple methods, isConvertible/isCopiable and convert/copy). Reflectors are getting frameworkish because they are allowing you to plug into the Copiers that come out-of-the-box with Morph. They are basically a mechanism to allow you to treat any weird type of object as a regular object that has properties. So they provide a universal API for accessing the properties of Objects, Maps, DynaBeans, HttpRequest parameters, HttpRequest attributes, HttpSession attributes, or perhaps even RDBMS schemas or XML DOMs. The problem with BeanUtils.copyProperties, is the types of things that are considered to have properties are fixed. They are Objects, Maps and DynaBeans -- no more, no less. that's true enough. there's nothing wrong with frameworks but IMHO it's important to stop good libraries becoming poor frameworks. your reasoning seems sound enough and so i'd say that there's space for a framework... - The Language interface is interesting, but a little out there. Basically once we have Reflectors written, we can easily implement simple languages like the JSTL EL. The nice thing about how Reflectors are setup though, is that you could easily define a reflector for a DynaBean or for some other arbitrary object type. This lets you extend your Language very easily. getting the bean query language at the right level of abstraction is key I'm not sure I follow... any ideas of things I should take a look at? JSTL (see EL), JEXL, XPath, velocity, jelly (and many, many more projects) all contain bean query languages. there are a lot of different approaches. one of the real pains with beanutils is that the bean query language is deeply embedded in the component and cannot be easily changed. it became clear whilst working on beanutils that really one bean query language (no matter how good) really isn't suitable for all use cases. the key is getting the right level of abstraction for the bean query language: close enough to take advantage of features in the introspection layer but abstract enough to allow radically different query languages to be used. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug report normalization
On 24 Nov 2004, at 17:50, Rory Winston wrote: Agreed. I think a better long-term solution would be to include the subcomponent name in the mail templates. Is it possible to do this going forward? Who administers the BZ installation? a little bit of a sore point, this one. apache infrastructure is very short of volunteers (with the right karma). the infrastructure list is open to committers but it'd probably be appreciated if people posted with offers of help for tasks they propose. alternatively, this is something that could be brought up on general at jakarta. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Promote Resources to Commons Proper
I know I speak for many when I say thanks for your contributions, talents and efforts. .V Martin Cooper wrote: The vote to promote Resources resulted in 5 +1s and one -0. I'll go ahead with the promotion and web site updates shortly. The vote thread is here: http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=60551 -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
I'm not really committing frequently in commons, but I'm in favour of this happening. Has anyone experienced maven's svn support ? The scm plugin is probably the only thing not supporting it, and that's just a time issue. If it were a priority, it could be done reasonably quickly. Other than that, I think that it should be fine. I'd be happy to address any issues that arise as a priority. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: Digester/TODO
Date: 2004-11-25T15:11:42 Editor: SimonKitching [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: Digester/TODO URL: http://wiki.apache.org/jakarta-commons/Digester/TODO Add TODO item re DynaBeans and SetNextRule Change Log: -- @@ -69,6 +69,15 @@ See: http://www.mail-archive.com/commons-user@jakarta.apache.org/msg07607.html +=== Provide better support for DynaBean in SetNextRule === + +The jakarta commons !BeanUtils library provides a '!DynaBean' class, which acts rather like a java class whose properties can be altered at runtime. The reflection functionality provided by the !BeanUtils library knows about !DynaBeans, and essentially makes them appear to be ordinary javabean classes when performing reflection. + +Most Digester rules handle !DynaBeans just like ordinary bean classes, because they use the !BeanUtils reflection methods. + +However it has been reported that the !SetNextRule doesn't handle !DynaBeans well (see mail archives for 2004-11-25, subject '!DynaBean Hierarchy'). +It would be nice to fix this if an elegant solution can be found (and fix any other rules that might not work well with !DynaBeans). + == Possible == === Refactor CallParamRule === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/resources project.properties project.xml
martinc 2004/11/25 15:16:40 Modified:resources project.properties project.xml Log: Resources has moved to Commons Proper. Revision ChangesPath 1.9 +1 -1 jakarta-commons/resources/project.properties Index: project.properties === RCS file: /home/cvs/jakarta-commons/resources/project.properties,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- project.properties8 Sep 2004 14:21:07 - 1.8 +++ project.properties25 Nov 2004 23:16:39 - 1.9 @@ -50,4 +50,4 @@ maven.linkcheck.enable=false -resources.repository=scm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons-sandbox/resources/ +resources.repository=scm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons/resources/ 1.18 +1 -1 jakarta-commons/resources/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/resources/project.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- project.xml 3 Nov 2004 04:38:28 - 1.17 +++ project.xml 25 Nov 2004 23:16:39 - 1.18 @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=UTF-8? project - extend../sandbox-build/project.xml/extend + extend../commons-build/project.xml/extend nameCommons Resources/name idcommons-resources/id logo/images/logo.png/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/parts components-table.ent sandbox-table.ent
martinc 2004/11/25 15:17:21 Modified:commons-build/menus components-items.ent sandbox-items.ent commons-build/parts components-table.ent sandbox-table.ent Log: Resources has moved to Commons Proper. Revision ChangesPath 1.6 +1 -0 jakarta-commons/commons-build/menus/components-items.ent Index: components-items.ent === RCS file: /home/cvs/jakarta-commons/commons-build/menus/components-items.ent,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- components-items.ent 25 Nov 2004 10:45:09 - 1.5 +++ components-items.ent 25 Nov 2004 23:17:21 - 1.6 @@ -28,6 +28,7 @@ item name=Net href=http://jakarta.apache.org/commons/net// item name=Pool href=http://jakarta.apache.org/commons/pool// item name=Primitives href=http://jakarta.apache.org/commons/primitives// +item name=Resources href=http://jakarta.apache.org/commons/resources// item name=Transaction href=http://jakarta.apache.org/commons/transaction// item name=Validator href=http://jakarta.apache.org/commons/validator// 1.10 +0 -1 jakarta-commons/commons-build/menus/sandbox-items.ent Index: sandbox-items.ent === RCS file: /home/cvs/jakarta-commons/commons-build/menus/sandbox-items.ent,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- sandbox-items.ent 25 Nov 2004 10:45:09 - 1.9 +++ sandbox-items.ent 25 Nov 2004 23:17:21 - 1.10 @@ -12,7 +12,6 @@ item name=Mapper href=http://jakarta.apache.org/commons/sandbox/mapper// item name=Messenger href=http://jakarta.apache.org/commons/sandbox/messenger// item name=Pipeline href=http://jakarta.apache.org/commons/sandbox/pipeline// -item name=Resources href=http://jakarta.apache.org/commons/sandbox/resources// item name=Scaffold href=http://jakarta.apache.org/commons/sandbox/scaffold// item name=SQL href=http://jakarta.apache.org/commons/sandbox/sql// item name=ThreadPool href=http://jakarta.apache.org/commons/sandbox/threadpool// 1.8 +9 -1 jakarta-commons/commons-build/parts/components-table.ent Index: components-table.ent === RCS file: /home/cvs/jakarta-commons/commons-build/parts/components-table.ent,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- components-table.ent 25 Nov 2004 10:45:09 - 1.7 +++ components-table.ent 25 Nov 2004 23:17:21 - 1.8 @@ -215,7 +215,15 @@ /td /tr tr -tda href=http://jakarta.apache.org/commons/sandbox/transaction/;Transaction/a/td +tda href=http://jakarta.apache.org/commons/resources/;Resources/a/td +td + Resources provides a lightweight framework for defining and looking up + internationalized message strings keyed by a java.util.Locale and a + message key. +/td +/tr +tr +tda href=http://jakarta.apache.org/commons/transaction/;Transaction/a/td td Commons Transaction provides implementations for multi level locks, transactional collections and transactional file access and some other utility classes commonly used in transacional Java programming. /td 1.11 +0 -8 jakarta-commons/commons-build/parts/sandbox-table.ent Index: sandbox-table.ent === RCS file: /home/cvs/jakarta-commons/commons-build/parts/sandbox-table.ent,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- sandbox-table.ent 25 Nov 2004 10:45:09 - 1.10 +++ sandbox-table.ent 25 Nov 2004 23:17:21 - 1.11 @@ -96,14 +96,6 @@ /td /tr tr -tda href=http://jakarta.apache.org/commons/sandbox/resources/;Resources/a/td -td - Resources provides a lightweight framework for defining and looking up - internationalized message strings keyed by a java.util.Locale and a - message key. -/td -/tr -tr tda href=http://jakarta.apache.org/commons/sandbox/scaffold/;Scaffold/a/td td Scaffold is a toolkit for building web applications. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] Updating the Commons common web site
The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/email build.xml
Sun licensing doesn't allow it to be kept at ibiblio either, right?
On 25 Nov 2004 20:41:16 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
bayard 2004/11/25 12:41:16
Modified:emailbuild.xml
Log:
sun licensing does not let us keep the javamail and activation jars in the
cvs repo, so I have put this back to the default broken attempt to get it
from Maven
Revision ChangesPath
1.2 +5 -5 jakarta-commons/email/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/email/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 25 Nov 2004 09:56:56 - 1.1
+++ build.xml 25 Nov 2004 20:41:16 - 1.2
@@ -148,10 +148,10 @@
/setproxy
get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar;
/get
-copy todir=${libdir} file=lib/javamail-1.3.2.jar
-/copy
-copy todir=${libdir} file=lib/activation-1.0.2.jar
-/copy
+get dest=${libdir}/javamail-1.3.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/java-mail/jars/javamail-1.3.2.jar;
+/get
+get dest=${libdir}/activation-1.0.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/activation/jars/activation-1.0.2.jar;
+/get
get dest=${libdir}/dumbster-1.5.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/dumbster/jars/dumbster-1.5.jar;
/get
/target
@@ -161,4 +161,4 @@
unjar dest=${maven.home}
src=${user.home}/maven-install-latest.jar
/unjar
/target
-/project
\ No newline at end of file
+/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Updating the Commons common web site
I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/email build.xml
Right, which is why it's not at iBiblio.
However, the project.xml effectively points to iBiblio and so my
change was just to make them be broken in the same way. What should
happen in the build.xml I guess is that it has a if not in lib,
output a message telling the user to download the javamail/ibiblio
separately bit.
I'll take a stab at that tomorrow if anyone wants me to.
An automated build system (gump?) could handle this by having a
private repository that isn't published.
Hen
On Fri, 26 Nov 2004 14:05:40 +1100, Dion Gillard [EMAIL PROTECTED] wrote:
Sun licensing doesn't allow it to be kept at ibiblio either, right?
On 25 Nov 2004 20:41:16 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
bayard 2004/11/25 12:41:16
Modified:emailbuild.xml
Log:
sun licensing does not let us keep the javamail and activation jars in
the cvs repo, so I have put this back to the default broken attempt to get
it from Maven
Revision ChangesPath
1.2 +5 -5 jakarta-commons/email/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/email/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 25 Nov 2004 09:56:56 - 1.1
+++ build.xml 25 Nov 2004 20:41:16 - 1.2
@@ -148,10 +148,10 @@
/setproxy
get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.0.jar;
/get
-copy todir=${libdir} file=lib/javamail-1.3.2.jar
-/copy
-copy todir=${libdir} file=lib/activation-1.0.2.jar
-/copy
+get dest=${libdir}/javamail-1.3.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/java-mail/jars/javamail-1.3.2.jar;
+/get
+get dest=${libdir}/activation-1.0.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/activation/jars/activation-1.0.2.jar;
+/get
get dest=${libdir}/dumbster-1.5.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/dumbster/jars/dumbster-1.5.jar;
/get
/target
@@ -161,4 +161,4 @@
unjar dest=${maven.home}
src=${user.home}/maven-install-latest.jar
/unjar
/target
-/project
\ No newline at end of file
+/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
-
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: [general] Updating the Commons common web site
On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? Thanks! -- Martin Cooper -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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]
cvs commit: jakarta-commons/digester/src/conf MANIFEST.MF
skitching2004/11/25 20:12:52 Modified:digester/src/conf MANIFEST.MF Log: Removed quotes around numeric quantities, as per bugzilla #31330 Revision ChangesPath 1.5 +2 -2 jakarta-commons/digester/src/conf/MANIFEST.MF Index: MANIFEST.MF === RCS file: /home/cvs/jakarta-commons/digester/src/conf/MANIFEST.MF,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- MANIFEST.MF 22 Apr 2004 05:12:20 - 1.4 +++ MANIFEST.MF 26 Nov 2004 04:12:52 - 1.5 @@ -1,8 +1,8 @@ Extension-Name: org.apache.commons.digester Specification-Title: Jakarta Commons Digester Specification-Vendor: Apache Software Foundation -Specification-Version: 1.6 +Specification-Version: 1.6 Implementation-Title: org.apache.commons.digester Implementation-Vendor: Apache Software Foundation -Implementation-Version: 1.6 +Implementation-Version: 1.6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31330] - [digester] Specification-version in MANIFEST.MF not numerical
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=31330. 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=31330 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 05:14 --- Fixed - thanks for the bug report. -- 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]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/parser XercesParser.java
skitching2004/11/25 20:41:45
Modified:digester/src/java/org/apache/commons/digester/parser
XercesParser.java
Log:
Fix java 1.5 warnings.
Revision ChangesPath
1.8 +3 -3
jakarta-commons/digester/src/java/org/apache/commons/digester/parser/XercesParser.java
Index: XercesParser.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/parser/XercesParser.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- XercesParser.java 10 May 2004 06:37:22 - 1.7
+++ XercesParser.java 26 Nov 2004 04:41:45 - 1.8
@@ -102,8 +102,8 @@
Class.forName(org.apache.xerces.impl.Version);
// Will return Xerces-J 2.x.0
Method method =
-versionClass.getMethod(getVersion, null);
-String version = (String)method.invoke(null,null);
+versionClass.getMethod(getVersion, (Class[])null);
+String version = (String)method.invoke(null, (Object[])null);
versionNumber = version.substring( Xerces-J.length() ,
version.lastIndexOf(.) );
} catch (Exception ex){
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: TheSandbox
Date: 2004-11-25T22:29:59 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -3,17 +3,17 @@ (Published means that the sandbox component is on the Jakarta Commons website) * Cache - * Chain - needed for Struts 1.3.x, ready for promotion? + * CommonsChain - needed for Struts 1.3.x, undergoing promotion * Clazz - no community, code stable. * Compress - code extracted from Ant, currently dormant. - * Convert - various conversion ideas extracted from BeanUtils, currently in development. + * CommonsConvert - various conversion ideas extracted from BeanUtils, currently in development. * Events - currently in slow development. * Functor * Id - parts from Lang, parts new, currently in-development. * JJar - ready to die as superseded by Apache Depot. * Mapper * Messenger - * Resources - needed for Struts 1.3.x, ready for promotion? + * Resources - needed for Struts 1.3.x, undergoing promotion * [http://jakarta.apache.org/commons/sandbox/scaffold/ Scaffold] is a toolkit for building web applications, to complement web application frameworks (such as Struts). * SQL * ThreadPool - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] New: CommonsChain
Date: 2004-11-25T22:32:21 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: CommonsChain URL: http://wiki.apache.org/jakarta-commons/CommonsChain no comment New Page: ##language:en = chain Overview = || http://jakarta.apache.org/commons/chain/images/chain-logo-white.png || [http://jakarta.apache.org/commons/chain/ Commons-chain] (add chain discription).[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/chain/ chain website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || = External Resources = One potential discussion is for a change of the Context interface in v1.1 or later. MatthewSgarlata suggests use of the [http://morph.sourceforge.net Morph] framework = FAQ = ||Add your questions/answers here.|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] New: MatthewSgarlata
Date: 2004-11-25T22:34:49 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: MatthewSgarlata URL: http://wiki.apache.org/jakarta-commons/MatthewSgarlata no comment New Page: ##language:en == Your Name == Email: [[MailTo(matthew.sgarlata at verizon dot net)]] ... CategoryHomepage - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: CommonsChain
Date: 2004-11-25T22:36:34 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: CommonsChain URL: http://wiki.apache.org/jakarta-commons/CommonsChain no comment Change Log: -- @@ -1,7 +1,11 @@ ##language:en = chain Overview = -|| http://jakarta.apache.org/commons/chain/images/chain-logo-white.png || [http://jakarta.apache.org/commons/chain/ Commons-chain] (add chain discription).[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/chain/ chain website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || +|| http://jakarta.apache.org/commons/chain/images/chain-logo-white.png || [http://jakarta.apache.org/commons/chain/ Commons-chain] A popular technique for organizing the execution of complex processing flows is the Chain of Responsibility pattern, as described (among many other places) in the classic Gang of Four design patterns book. Although the fundamental API contracts required to implement this design patten are extremely simple, it is useful to have a base API that facilitates using the pattern, and (more importantly) encouraging composition of command implementations from multiple diverse sources. + +Towards that end, the Chain API models a computation as a series of commands that can be combined into a chain. The API for a command consists of a single method (execute()), which is passed a context parameter containing the dynamic state of the computation, and whose return value is a boolean that determines whether or not processing for the current chain has been completed (true), or whether processing should be delegated to the next command in the chain (false). + +[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/chain/ chain website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || = External Resources = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] New: CommonsConvert
Date: 2004-11-25T22:39:10 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: CommonsConvert URL: http://wiki.apache.org/jakarta-commons/CommonsConvert no comment New Page: ##language:en = Convert Overview = || http://jakarta.apache.org/commons/convert/images/convert-logo-white.png || [http://jakarta.apache.org/commons/convert/ Commons-convert] (add convert discription).[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/convert/ convert website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || = External Resources = Base on the ideas that have come out of work on Convert over the past year, MatthewSgarlata has created the [http://morph.sourceforge.net Morph] framework. The framework is still in pre-alpha, but there is Apache 2.0-licensed source available. = FAQ = ||Add your questions/answers here.|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: CommonsConvert
Date: 2004-11-25T22:41:54 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: CommonsConvert URL: http://wiki.apache.org/jakarta-commons/CommonsConvert no comment Change Log: -- @@ -1,7 +1,7 @@ ##language:en = Convert Overview = -|| http://jakarta.apache.org/commons/convert/images/convert-logo-white.png || [http://jakarta.apache.org/commons/convert/ Commons-convert] (add convert discription).[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/convert/ convert website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || +|| http://jakarta.apache.org/commons/sandbox/convert/images/convert-logo-white.png || [http://jakarta.apache.org/commons/sandbox/convert/ Commons-convert] Commons-Convert aims to provide a single library dedicated to the task of converting an object of one type to another. The first stage will focus on Object to String and String to Object conversions.[[BR]] A lot of information is available on the [http://jakarta.apache.org/commons/convert/ convert website]. If you don't find the information you need you can always contact us using one of the [http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. || = External Resources = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: FrontPage
Date: 2004-11-25T22:46:44 Editor: MatthewSgarlata [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: FrontPage URL: http://wiki.apache.org/jakarta-commons/FrontPage no comment Change Log: -- @@ -45,6 +45,7 @@ == Third Party Resources == * [JakartaCommonsResources] + * [http://morph.sourceforge.net Morph] - pre-alpha framework based on ideas from BeanUtils, CommonsConvert and CommonsChain == Developer Documentation == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] a different approach...
make sure you add a link to the wiki so everyone can find morph :) Done to the best of my ability. I apologize in advance if I abused the Wiki in any way! i don't see any real harm announcing releases and stuff on the mailing lists though it'd probably be wiser not to phrase any posts so as not raise the temperature unnecessary. (it's a temptation when you're the new project on the block to push general claims of superiority but often it's better to focus on individuality: what the project does better) Thanks for the pointers and the invitation to post release notices :) I'm hoping for a 0.3 release this weekend that will have a revised API. JSTL (see EL), JEXL, XPath, velocity, jelly (and many, many more projects) all contain bean query languages. there are a lot of different approaches. one of the real pains with beanutils is that the bean query language is deeply embedded in the component and cannot be easily changed. it became clear whilst working on beanutils that really one bean query language (no matter how good) really isn't suitable for all use cases. the key is getting the right level of abstraction for the bean query language: close enough to take advantage of features in the introspection layer but abstract enough to allow radically different query languages to be used. I'll try to keep this advice in mind, and I will definitely seek your advice once I have thought this through some more. Thanks again for your help! - robert Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IO] FilenameUtils#getPrefixLength is broken on Unix
Hi,
this is the manual version of what Gump is trying to tell you 8-)
FilenameUtils.getPrefixLength fails on Unix if you pass a string of
length one as argument since it unconditionally tries to access the
second character (just to never use it). Therefore the test case
fails since it tests /.
The trivial patch appended fixes this problem
It will not fix the build since the tests still fails, but I'm not
sure whether the code ot the test is wrong. The test failure
remaining is
[junit] Testcase: testNormalize took 0,02 sec
[junit] FAILED
[junit] Check if '/../' normalized to 'null', was '' expected:null but
was:
[junit] junit.framework.ComparisonFailure: Check if '/../' normalized to
'null', was '' expected:null but was:
Cheers
Stefan
Index: io/src/java/org/apache/commons/io/FilenameUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.27
diff -u -r1.27 FilenameUtils.java
--- io/src/java/org/apache/commons/io/FilenameUtils.java23 Nov 2004
00:04:29 - 1.27
+++ io/src/java/org/apache/commons/io/FilenameUtils.java26 Nov 2004
07:51:24 -
@@ -416,7 +416,6 @@
}
} else {
char ch0 = filename.charAt(0);
-char ch1 = filename.charAt(1);
if (ch0 == '~') {
if (len == 1) {
return -1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
