[GUMP@brutus]: Project commons-io (in module jakarta-commons) success
To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-io *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-io/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jakarta-commons-io-27112004.jar] identifier set to project name -INFO- No license on redistributable project with outputs. The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-io/gump_work/build_jakarta-commons_commons-io.html Work Name: build_jakarta-commons_commons-io (Type: Build) Work ended in a state of : Success Elapsed: 58 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=jakarta-commons-io-27112004 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/io] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/io/target/classes:/usr/local/gump/public/workspace/jakarta-commons/io/target/test-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-27112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - javadoc: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/io/dist/docs/api [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.commons.io... [javadoc] Loading source files for package org.apache.commons.io.filefilter... [javadoc] Loading source files for package org.apache.commons.io.find... [javadoc] Loading source files for package org.apache.commons.io.input... [javadoc] Loading source files for package org.apache.commons.io.output... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.4.2_05 [javadoc] Building tree for all the packages and classes... [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/AndFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/OrFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/AndFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/OrFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/AndFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/OrFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] Building index for all the packages and classes... [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/AndFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/OrFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] Building index for all classes... [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/AndFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc] /home/gump/workspaces2/public/workspace/jakarta-commons/io/src/java/org/apache/commons/io/filefilter/OrFileFilter.java:36: warning - Tag @link: reference not found: FileFilter [javadoc]
RE: [email] rm -r lib/*.jar
I did some fixes to the Maven Ant plugin to deal better with overrides. I'll take what you sort out in build.xml and then see if I can support it in the Maven Ant plugin. As long as Email is built primarily by Maven, we will always have problems keeping the Ant script up to date without automation (or lots of attention to detail!). Thanks for the assist.. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 8:05 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [email] rm -r lib/*.jar We appreciate all the help we can get :-) -Corey On Fri, 26 Nov 2004 11:35:04 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Fri, 26 Nov 2004 11:14:28 +0100, Eric Pugh [EMAIL PROTECTED] wrote: But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. If the Ant script had properties to define the source URLs for these two JARs, I could point them at my local copies. The license on the JARs in question allows them to be distributed as *part* of a larger package, so my building my own copy into the nightlies is fine ... the license also says you cannot make them available *separately*, which is why having them in CVS doesn't work. Would you guys mind if I hand patched the build.xml file to see if I can get that to work? Eric Craig - 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] website
Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-resources (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-resources has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Pre-Build Failed'. For reference only, the following projects are affected by this: - commons-resources : Commons resources Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-resources-27112004.jar] identifier set to project name -INFO- Failed with reason pre-build failed -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2427112004, brutus:brutus-public:2427112004 Gump E-mail Identifier (unique within run) #24. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - 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 4 projects, and has been outstanding for 45 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) - maven : Project Management Tools 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-27112004.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: 6 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-27112004 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-27112004.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-27112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-27112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-27112004.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-27112004.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-27112004.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/commons-jelly-tags-util-27112004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-27112004.jar - [junit] Testcase: readWriteIn took 0.192 sec [junit] Testcase: startUpReadWrite took 0.124 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
DO NOT REPLY [Bug 32410] New: - [email] tests fail on Unix c/o port settings
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=32410. 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=32410 Summary: [email] tests fail on Unix c/o port settings Product: Commons Version: 1.0 Alpha Platform: Macintosh OS/Version: Mac OS X 10.0 Status: NEW Severity: normal Priority: P2 Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] this bug was patched and has sneaked in again. Port testings during tests weren't being set to the values set in EmailConfiguration. Submitting a patch that fixes this. -- 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]
DO NOT REPLY [Bug 32410] - [email] tests fail on Unix c/o port settings
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=32410. 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=32410 --- Additional Comments From [EMAIL PROTECTED] 2004-11-27 11:13 --- Created an attachment (id=13554) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13554action=view) [email] smtp port setting *nix during tests -- 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: [convert] a different approach...
Comments below... - Original Message - From: Ron Blaschke [EMAIL PROTECTED] To: Matt Sgarlata [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 26, 2004 6:47 PM Subject: Re: [convert] a different approach... I've taken a quick look at your description and the source, which looks quite promising. Correct me if I am getting things wrong, but I think we try to solve different problems, which is acutally a good thing (as they might even complement each other). If I get things right, you try to provide a framework for passing bean like structures around, and convert them to their various representations, as every library provides its own. My focus is on trying to provide a generic conversion framework, with primary focus on the type. Eg, some libraries like to use int, others prefer short, which makes not much of a difference if all values are, say, between 0 and 1000. While this conversion is quite simple for some types, it can be cumbersome for others, eg if you got a short[], but the library prefers an int[]. Actually I'm taking on every problem that Convert was planning to take on, so short[] - int[] is one type of conversion Morph will be able to perform. I do have a large focus in the code so far on bean like structures, as you put it, but I definitely will be focusing on container like structures as well, such as Arrays and Collections. I have been doing some fairly major refactorings this weekend, and I hope to be able to complete a 0.3 release soon. There will be more attention to container like structures in the upcoming 0.3 release. I depart from Convert by also providing a Context notion as seen in the Chain package, and a Language notion, which will support languages like Velocity, JSTL EL, etc. Since Morph makes working with bean like structures so easy, I thought the Context and Language abstractions would be good to include. Context I definitely want in version 1.0, but Language may wait for a later release. I want to get 1.0 out-the-door as quickly as possible so we can all start using it :) Ron Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] target Java version?
the new io package provides a means to checking the charsets supported by a given jvm, problem its a 1.4 thing. Does commons email need to support 1.3 ? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] target Java version?
Yes. Many corporates still use 1.3 (and a fair few are still on 1.2) Stephen - Original Message - From: Mark Lowe [EMAIL PROTECTED] To: Commons dev list [EMAIL PROTECTED] Sent: Saturday, November 27, 2004 3:11 PM Subject: [email] target Java version? the new io package provides a means to checking the charsets supported by a given jvm, problem its a 1.4 thing. Does commons email need to support 1.3 ? Mark - 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] website
For one, email is overriding the default Jakarta Commons Style, we would prefer it to maintain the style of the rest of the commons. There are some simple rules to accomplish this. I'll take a look at whats currently there. This is probably why the style is breaking when it was moved the existing overide is probably interfering with the Jakarta templates. -Mark Matthias Wessendorf wrote: Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - 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]
[io] Exact meaning of getPath, esp. on UNIX?
getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. - Are there lots of filenames on unix that have no dot extension? - Do we need to have two methods to cope with this situation? - Or should we change the method so that it only strips the end if it finds a dot after the last separator? The question affects various methods in FilenameUtils. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/email/xdocs/style project.css
mdiggory2004/11/27 08:54:32
Modified:emailproject.xml project.properties
email/xdocs navigation.xml
Removed: email/xdocs/style project.css
Log:
Fixes to correct site generation and Jakarta Commons style.
1.) removed project.css
2.) adjusted relative paths to commons-build
3.) corrected logo in project.xml
4.) added greybar links back to Commons Home page and Jakarta Homepage
Revision ChangesPath
1.3 +0 -2 jakarta-commons/email/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/email/project.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.xml 25 Nov 2004 11:36:24 - 1.2
+++ project.xml 27 Nov 2004 16:54:32 - 1.3
@@ -23,8 +23,6 @@
shortDescriptionCommons Email/shortDescription
descriptionCommons Email provides a simple wrapper over the Java Mail
API/description
currentVersion1.0-dev/currentVersion
-
- logo/logo
packageorg.apache.commons.mail/package
gumpRepositoryIdjakarta-commons/gumpRepositoryId
1.2 +3 -3 jakarta-commons/email/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/email/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties25 Nov 2004 09:56:56 - 1.1
+++ project.properties27 Nov 2004 16:54:32 - 1.2
@@ -33,8 +33,8 @@
maven.test.failure.ignore=true
# Standard settings
-maven.xdoc.jsl=../../jakarta-commons/commons-build/commons-site.jsl
-maven.xdoc.date=bottom
+maven.xdoc.jsl=../commons-build/commons-site.jsl
+maven.xdoc.date=left
maven.xdoc.poweredby.image=maven-feather.png
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
1.3 +7 -1 jakarta-commons/email/xdocs/navigation.xml
Index: navigation.xml
===
RCS file: /home/cvs/jakarta-commons/email/xdocs/navigation.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- navigation.xml25 Nov 2004 14:00:53 - 1.2
+++ navigation.xml27 Nov 2004 16:54:32 - 1.3
@@ -15,10 +15,16 @@
limitations under the License.
--
-!DOCTYPE org.apache.commons.menus SYSTEM
'../../../commons-build/menus/menus.dtd'
+!DOCTYPE project SYSTEM '../../commons-build/menus/menus.dtd'
project name=Commons#xA0;Email
titleCommons#xA0;Email/title
body
+links
+ item name=Jakarta
+href=http://jakarta.apache.org/
+ item name=Jakarta Commons
+href=http://jakarta.apache.org/commons//
+/links
menu name=Commons#xA0;Email
item name=Overview href=/index.html/
item name=Examples href=/examples.html/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FilenameUtils.java
scolebourne2004/11/27 09:00:51
Modified:io/src/test/org/apache/commons/io FilenameUtilsTestCase.java
io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Rewrite catPath, renaming to concat
Revision ChangesPath
1.22 +32 -13
jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java
Index: FilenameUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- FilenameUtilsTestCase.java27 Nov 2004 01:22:05 - 1.21
+++ FilenameUtilsTestCase.java27 Nov 2004 17:00:51 - 1.22
@@ -82,18 +82,6 @@
}
//---
-public void testCatPath() {
-// TODO StringIndexOutOfBoundsException thrown if file doesn't
contain slash.
-// Is this acceptable?
-//assertEquals(, FilenameUtils.catPath(a, b));
-
-assertEquals(/a + File.separator + c,
FilenameUtils.catPath(/a/b, c));
-assertEquals(/a + File.separator + d,
FilenameUtils.catPath(/a/b/c, ../d));
-assertEquals(C:\\a + File.separator + c,
FilenameUtils.catPath(C:\\a\\b, c));
-assertEquals(C:\\a + File.separator + d,
FilenameUtils.catPath(C:\\a\\b\\c, ../d));
-}
-
-//---
public void testNormalize() throws Exception {
assertEquals(null, FilenameUtils.normalize(null));
assertEquals(null, FilenameUtils.normalize(:));
@@ -213,6 +201,37 @@
assertEquals(null, FilenameUtils.normalize(//server/../a));
assertEquals(null, FilenameUtils.normalize(//server/..));
assertEquals(SEP + SEP + server + SEP + ,
FilenameUtils.normalize(//server/));
+}
+
+//---
+public void testConcat() {
+assertEquals(null, FilenameUtils.concat(, null));
+assertEquals(null, FilenameUtils.concat(null, null));
+assertEquals(null, FilenameUtils.concat(null, ));
+assertEquals(null, FilenameUtils.concat(null, a));
+assertEquals(SEP + a, FilenameUtils.concat(null, /a));
+
+assertEquals(null, FilenameUtils.concat(, :)); // invalid prefix
+assertEquals(null, FilenameUtils.concat(:, )); // invalid prefix
+
+assertEquals(f, FilenameUtils.concat(, f/));
+assertEquals(f, FilenameUtils.concat(, f));
+assertEquals(a + SEP + f, FilenameUtils.concat(a/, f/));
+assertEquals(a + SEP + f, FilenameUtils.concat(a, f));
+assertEquals(a + SEP + b + SEP + f,
FilenameUtils.concat(a/b/, f/));
+assertEquals(a + SEP + b + SEP + f,
FilenameUtils.concat(a/b, f));
+
+assertEquals(a + SEP + f, FilenameUtils.concat(a/b/, ../f/));
+assertEquals(a + SEP + f, FilenameUtils.concat(a/b, ../f));
+assertEquals(a + SEP + c + SEP + g,
FilenameUtils.concat(a/b/../c/, f/../g/));
+assertEquals(a + SEP + c + SEP + g,
FilenameUtils.concat(a/b/../c, f/../g));
+
+assertEquals(a + SEP + c.txt + SEP + f,
FilenameUtils.concat(a/c.txt, f));
+
+assertEquals(SEP + f, FilenameUtils.concat(, /f/));
+assertEquals(SEP + f, FilenameUtils.concat(, /f));
+assertEquals(SEP + f, FilenameUtils.concat(a/, /f/));
+assertEquals(SEP + f, FilenameUtils.concat(a, /f));
}
//---
1.30 +71 -47
jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java
Index: FilenameUtils.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- FilenameUtils.java27 Nov 2004 01:22:05 - 1.29
+++ FilenameUtils.java27 Nov 2004 17:00:51 - 1.30
@@ -31,13 +31,28 @@
* lithe base name - file/li
* lithe extension - txt/li
* /ul
- * The class only supports Unix and Windows style names.
+ * The class only supports Unix and Windows style names. Prefixes are
matched as follows:
+ * pre
+ * Windows style:
+ * a\b\c.txt -- -- relative
+ * \a\b\c.txt -- \ -- drive relative
+ * C:\a\b\c.txt-- C:\ -- absolute
+ * \\server\a\b\c.txt -- \\server\ -- UNC
+ *
+ * Unix style:
+ * a/b/c.txt -- -- relative
+ * /a/b/c.txt -- / -- absolute
+ * ~/a/b/c.txt -- ~/
cvs commit: jakarta-commons/email project.xml
mdiggory2004/11/27 09:09:59
Modified:emailproject.xml
Log:
Setting appropriate site generation path,it was never set, or was attempted
to be inherited from commons-build. Something I do not beleive we do anymore
due to the problems with building src distribution tarballs.
Revision ChangesPath
1.4 +22 -2 jakarta-commons/email/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/email/project.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- project.xml 27 Nov 2004 16:54:32 - 1.3
+++ project.xml 27 Nov 2004 17:09:59 - 1.4
@@ -24,8 +24,28 @@
descriptionCommons Email provides a simple wrapper over the Java Mail
API/description
currentVersion1.0-dev/currentVersion
packageorg.apache.commons.mail/package
- gumpRepositoryIdjakarta-commons/gumpRepositoryId
-
+ gumpRepositoryIdjakarta/gumpRepositoryId
+ siteAddressjakarta.apache.org/siteAddress
+
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
+
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
+ repository
+connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}/connection
+
urlhttp://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substring(8)}//url
+ /repository
+ mailingLists
+mailingList
+ nameCommons Dev List/name
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/unsubscribe
+ archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
+/mailingList
+mailingList
+ nameCommons User List/name
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/unsubscribe
+ archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
+/mailingList
+ /mailingLists
developers
developer
namedIon Gillard/name
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] website
Eric, I made some adjustments to the email site generation to correct some problems. You have all the permissions on /www/jakarta.apache.org/commons/email/.. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: For one, email is overriding the default Jakarta Commons Style, we would prefer it to maintain the style of the rest of the commons. There are some simple rules to accomplish this. I'll take a look at whats currently there. This is probably why the style is breaking when it was moved the existing overide is probably interfering with the Jakarta templates. -Mark Matthias Wessendorf wrote: Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - 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]
cvs commit: jakarta-commons/email project.xml
mdiggory2004/11/27 09:27:22 Modified:emailproject.xml Log: No longer inheriting commons-build. Something I do not beleive we do anymore due to the problems with building src distribution tarballs. Revision ChangesPath 1.5 +0 -1 jakarta-commons/email/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/email/project.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- project.xml 27 Nov 2004 17:09:59 - 1.4 +++ project.xml 27 Nov 2004 17:27:22 - 1.5 @@ -15,7 +15,6 @@ limitations under the License. -- project - extend../commons-build/project.xml/extend nameCommons Email/name idcommons-email/id logo/images/email-logo-white.png/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/resources project.properties project.xml
mdiggory2004/11/27 09:38:26
Modified:resources/xdocs navigation.xml
resources project.properties project.xml
Log:
Correction issues with commons site generation.
Revision ChangesPath
1.8 +1 -1 jakarta-commons/resources/xdocs/navigation.xml
Index: navigation.xml
===
RCS file: /home/cvs/jakarta-commons/resources/xdocs/navigation.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- navigation.xml24 May 2004 22:35:04 - 1.7
+++ navigation.xml27 Nov 2004 17:38:25 - 1.8
@@ -15,7 +15,7 @@
limitations under the License.
--
-!DOCTYPE org.apache.commons.menus SYSTEM
'../../../jakarta-commons/commons-build/menus/menus.dtd'
+!DOCTYPE project SYSTEM '../../commons-build/menus/menus.dtd'
project name=Commons#xA0;Resources
titleCommons#xA0;Resources/title
body
1.10 +1 -1 jakarta-commons/resources/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/resources/project.properties,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- project.properties25 Nov 2004 23:16:39 - 1.9
+++ project.properties27 Nov 2004 17:38:26 - 1.10
@@ -16,7 +16,7 @@
##
# commons site LF
##
-maven.xdoc.jsl=../../jakarta-commons/commons-build/commons-site.jsl
+maven.xdoc.jsl=../commons-build/commons-site.jsl
maven.xdoc.date=left
maven.xdoc.poweredby.image=
maven.xdoc.version=${pom.currentVersion}
1.19 +37 -3 jakarta-commons/resources/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/resources/project.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- project.xml 25 Nov 2004 23:16:39 - 1.18
+++ project.xml 27 Nov 2004 17:38:26 - 1.19
@@ -1,7 +1,6 @@
?xml version=1.0 encoding=UTF-8?
project
- extend../commons-build/project.xml/extend
nameCommons Resources/name
idcommons-resources/id
logo/images/logo.png/logo
@@ -9,11 +8,46 @@
inceptionYear2002/inceptionYear
packageorg.apache.commons.resources/package
shortDescriptionCommons Resources/shortDescription
-
description
Resources is a resources component.
/description
-
+
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
+ packageorg.apache.commons.${pom.artifactId.substring(8)}/package
+ organization
+nameThe Apache Software Foundation/name
+urlhttp://jakarta.apache.org/url
+logohttp://jakarta.apache.org/images/original-jakarta-logo.gif/logo
+ /organization
+ licenses
+license
+ nameThe Apache Software License, Version 2.0/name
+ url/LICENSE.txt/url
+ distributionrepo/distribution
+/license
+ /licenses
+ gumpRepositoryIdjakarta/gumpRepositoryId
+ siteAddressjakarta.apache.org/siteAddress
+
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
+
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
+ repository
+connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}/connection
+
urlhttp://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substring(8)}//url
+ /repository
+ mailingLists
+mailingList
+ nameCommons Dev List/name
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/unsubscribe
+ archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
+/mailingList
+mailingList
+ nameCommons User List/name
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/unsubscribe
+ archivehttp://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]/archive
+/mailingList
+ /mailingLists
+
developers
developer
nameMartin Cooper/name
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] website
Martin, As well, I've done some minor changes to resources. The same permissions issue exists in the /www/jakarta.apache.org/commons/resources/.. under your name. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: Eric, I made some adjustments to the email site generation to correct some problems. You have all the permissions on /www/jakarta.apache.org/commons/email/.. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: For one, email is overriding the default Jakarta Commons Style, we would prefer it to maintain the style of the rest of the commons. There are some simple rules to accomplish this. I'll take a look at whats currently there. This is probably why the style is breaking when it was moved the existing overide is probably interfering with the Jakarta templates. -Mark Matthias Wessendorf wrote: Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Volunteer for SVN migration management? Was: Migrate to SVN?
From a Jakarta level view, I really want to push for: jakarta/subproject/whatever... Other than that, I'll work with anything :) (Which I just noticed Velocity haven't done, so will see if I can get them to change). On Fri, 26 Nov 2004 21:52:22 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Sat, 27 Nov 2004 00:35:14 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: Martin, I'm available if you need help. Thanks, I appreciate that. One thing to flesh out is structure - here are some proposals: Summarising my preferred versions of your alternatives, we might have: jakarta/ commons/ proper/ ... digester/ branches/ tags/ trunk/ ... site/ branches/ tags/ trunk/ sandbox/ ... bzip2/ branches/ tags/ trunk/ ... This gives each component its own branches and tags, which makes more sense to me than having Commons-wide tagging and branching. As mentioned, it also makes 'site' its own thing, rather than pretending that it's a component. Comments? -- Martin Cooper Commons Proper Components 1. /jakarta/commons/digester/[tags|branches|trunk] 2. /jakarta/commons/proper/digester/[tags|branches|trunk] Commons Sandbox Components (just using bzip2 because it is there) 1. /jakarta/commons-sandbox/bzip2/[tags|branches|trunk] 2. /jakarta/commons/sandbox/bzip2/[tags|branches|trunk] Anybody have other options? I look at the existing velocity project, and part of me just wishes they had combined all velocity related modules under a velocity directory. If everything commons where under a commons directory, then we could have a separate directory for the commons site - something like /jakarta/commons/site. site would then not be a sibling to a real project. Tim 2 cents O'Brien -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 11:11 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? On Fri, 26 Nov 2004 13:31:27 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Do we have a volunteer to organise the move of Commons to SVN? Sure, I'll step up, unless someone else has a strong desire to do it. (which is probably some combination of: vote, plan, liaise with infra) Yep, I expect I'll be doing all three at once. ;-) -- Martin Cooper Hen On Fri, 26 Nov 2004 10:54:37 -0500, Phil Steitz [EMAIL PROTECTED] wrote: +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman 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: commons-dev- [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
Re: [email] website
Sorry about that. I've chmod'ed the files. Thanks! -- Martin Cooper On Sat, 27 Nov 2004 12:38:33 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: Martin, As well, I've done some minor changes to resources. The same permissions issue exists in the /www/jakarta.apache.org/commons/resources/.. under your name. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: Eric, I made some adjustments to the email site generation to correct some problems. You have all the permissions on /www/jakarta.apache.org/commons/email/.. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: For one, email is overriding the default Jakarta Commons Style, we would prefer it to maintain the style of the rest of the commons. There are some simple rules to accomplish this. I'll take a look at whats currently there. This is probably why the style is breaking when it was moved the existing overide is probably interfering with the Jakarta templates. -Mark Matthias Wessendorf wrote: Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - 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: [io] Exact meaning of getPath, esp. on UNIX?
Stephen Colebourne wrote: getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. - Are there lots of filenames on unix that have no dot extension? Yes. Many executables in unix distros have no dot extensions, for example. IIRC, even Windows allows files with no extensions. - Do we need to have two methods to cope with this situation? - Or should we change the method so that it only strips the end if it finds a dot after the last separator? The question affects various methods in FilenameUtils If the argument is a string, you need to do a file system lookup of some kind to determine whether the whole string represents a file or a directory if you want the methods to behave differently for these cases. Looks like File.isDirectory / isFile will do this, but that may a long way around the barn. Phil Stephen - 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: Volunteer for SVN migration management? Was: Migrate to SVN?
http://wiki.apache.org/jakarta/Migrating_20to_20Subversion exists by the way. Hen On Sat, 27 Nov 2004 12:55:57 -0500, Henri Yandell [EMAIL PROTECTED] wrote: From a Jakarta level view, I really want to push for: jakarta/subproject/whatever... Other than that, I'll work with anything :) (Which I just noticed Velocity haven't done, so will see if I can get them to change). On Fri, 26 Nov 2004 21:52:22 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Sat, 27 Nov 2004 00:35:14 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: Martin, I'm available if you need help. Thanks, I appreciate that. One thing to flesh out is structure - here are some proposals: Summarising my preferred versions of your alternatives, we might have: jakarta/ commons/ proper/ ... digester/ branches/ tags/ trunk/ ... site/ branches/ tags/ trunk/ sandbox/ ... bzip2/ branches/ tags/ trunk/ ... This gives each component its own branches and tags, which makes more sense to me than having Commons-wide tagging and branching. As mentioned, it also makes 'site' its own thing, rather than pretending that it's a component. Comments? -- Martin Cooper Commons Proper Components 1. /jakarta/commons/digester/[tags|branches|trunk] 2. /jakarta/commons/proper/digester/[tags|branches|trunk] Commons Sandbox Components (just using bzip2 because it is there) 1. /jakarta/commons-sandbox/bzip2/[tags|branches|trunk] 2. /jakarta/commons/sandbox/bzip2/[tags|branches|trunk] Anybody have other options? I look at the existing velocity project, and part of me just wishes they had combined all velocity related modules under a velocity directory. If everything commons where under a commons directory, then we could have a separate directory for the commons site - something like /jakarta/commons/site. site would then not be a sibling to a real project. Tim 2 cents O'Brien -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 11:11 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? On Fri, 26 Nov 2004 13:31:27 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Do we have a volunteer to organise the move of Commons to SVN? Sure, I'll step up, unless someone else has a strong desire to do it. (which is probably some combination of: vote, plan, liaise with infra) Yep, I expect I'll be doing all three at once. ;-) -- Martin Cooper Hen On Fri, 26 Nov 2004 10:54:37 -0500, Phil Steitz [EMAIL PROTECTED] wrote: +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman 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: commons-dev- [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
cvs commit: jakarta-commons/resources project.xml project.properties
mdiggory2004/11/27 10:18:48
Modified:resources project.xml project.properties
Log:
Inserting site info for proper javadoc generation.
Revision ChangesPath
1.20 +3 -4 jakarta-commons/resources/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/resources/project.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- project.xml 27 Nov 2004 17:38:26 - 1.19
+++ project.xml 27 Nov 2004 18:18:48 - 1.20
@@ -114,10 +114,6 @@
/contributor
/contributors
- reports
-reportmaven-developer-activity-plugin/report
- /reports
-
dependencies
dependency
@@ -173,6 +169,9 @@
build
+nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress
+sourceDirectorysrc/java/sourceDirectory
+unitTestSourceDirectorysrc/test/unitTestSourceDirectory
!-- Unit test classes --
unitTest
includes
1.11 +8 -1 jakarta-commons/resources/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/resources/project.properties,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- project.properties27 Nov 2004 17:38:26 - 1.10
+++ project.properties27 Nov 2004 18:18:48 - 1.11
@@ -18,7 +18,7 @@
##
maven.xdoc.jsl=../commons-build/commons-site.jsl
maven.xdoc.date=left
-maven.xdoc.poweredby.image=
+#maven.xdoc.poweredby.image=
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
@@ -49,5 +49,12 @@
maven.checkstyle.ignore.public.in.interface = true
maven.linkcheck.enable=false
+
+maven.javadoc.links = http://java.sun.com/j2se/1.4.2/docs/api/,\
+ http://jakarta.apache.org/commons/collections/api/,\
+ http://jakarta.apache.org/commons/beanutils/api/,\
+ http://jakarta.apache.org/commons/lang/api/,\
+ http://jakarta.apache.org/commons/discovery/api/,\
+ http://jakarta.apache.org/commons/logging/api/
resources.repository=scm:cvs:pserver:[EMAIL
PROTECTED]:/home/cvspublic:jakarta-commons/resources/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] website
Thanks, resources is now updated. -Mark Martin Cooper wrote: Sorry about that. I've chmod'ed the files. Thanks! -- Martin Cooper On Sat, 27 Nov 2004 12:38:33 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: Martin, As well, I've done some minor changes to resources. The same permissions issue exists in the /www/jakarta.apache.org/commons/resources/.. under your name. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: Eric, I made some adjustments to the email site generation to correct some problems. You have all the permissions on /www/jakarta.apache.org/commons/email/.. can you either regenerate the site or chmod the permissions so I can. -Mark Mark R. Diggory wrote: For one, email is overriding the default Jakarta Commons Style, we would prefer it to maintain the style of the rest of the commons. There are some simple rules to accomplish this. I'll take a look at whats currently there. This is probably why the style is breaking when it was moved the existing overide is probably interfering with the Jakarta templates. -Mark Matthias Wessendorf wrote: Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - 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] -- 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]
[vote][math] Release Math 1.0
There have been no bug reports against commons-math-1.0-RC2, which has been out for a couple of weeks now. I propose that we release commons-math-1.0, based on CVS HEAD, tagged and renamed for 1.0. There have been no changes to [math] since 1.0-RC2 was cut, which is available here: http://www.apache.org/~psteitz/commons-math-1.0-RC2/dist/ Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +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 +1. -- Phil Steitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Exact meaning of getPath, esp. on UNIX?
Stephen Colebourne wrote: getPath is currently coded so that: /a/b/c.txt -- /a/b this is of course correct. However, it is also coded to do: /a/b/c -- /a/b which seems a little odd (for me with a windows background). ie. the method treats 'c' as a file not a folder. This method seems to behave the same as the 'dirname' command in Unix. It returns the directory containing the item, whether the item is a file or a folder. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] a different approach...
Saturday, November 27, 2004, 1:46:28 PM, Matt Sgarlata wrote: Actually I'm taking on every problem that Convert was planning to take on, so short[] - int[] is one type of conversion Morph will be able to perform. Uups, sorry for getting things wrong. Sounds all the more interesting. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Volunteer for SVN migration management? Was: Migrate to SVN?
+/-0 for giving site tags, branches, and trunk. It might be nice to have the site built from site/tags/PRODUCTION so we could have some sort of a release cycle for the site, but (OTOH) it might be nice to keep it simple and just have content under site. Anyone? Tim -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 11:56 AM To: Jakarta Commons Developers List; Martin Cooper Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? From a Jakarta level view, I really want to push for: jakarta/subproject/whatever... Other than that, I'll work with anything :) (Which I just noticed Velocity haven't done, so will see if I can get them to change). On Fri, 26 Nov 2004 21:52:22 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Sat, 27 Nov 2004 00:35:14 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: Martin, I'm available if you need help. Thanks, I appreciate that. One thing to flesh out is structure - here are some proposals: Summarising my preferred versions of your alternatives, we might have: jakarta/ commons/ proper/ ... digester/ branches/ tags/ trunk/ ... site/ branches/ tags/ trunk/ sandbox/ ... bzip2/ branches/ tags/ trunk/ ... This gives each component its own branches and tags, which makes more sense to me than having Commons-wide tagging and branching. As mentioned, it also makes 'site' its own thing, rather than pretending that it's a component. Comments? -- Martin Cooper Commons Proper Components 1. /jakarta/commons/digester/[tags|branches|trunk] 2. /jakarta/commons/proper/digester/[tags|branches|trunk] Commons Sandbox Components (just using bzip2 because it is there) 1. /jakarta/commons-sandbox/bzip2/[tags|branches|trunk] 2. /jakarta/commons/sandbox/bzip2/[tags|branches|trunk] Anybody have other options? I look at the existing velocity project, and part of me just wishes they had combined all velocity related modules under a velocity directory. If everything commons where under a commons directory, then we could have a separate directory for the commons site - something like /jakarta/commons/site. site would then not be a sibling to a real project. Tim 2 cents O'Brien -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 11:11 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? On Fri, 26 Nov 2004 13:31:27 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Do we have a volunteer to organise the move of Commons to SVN? Sure, I'll step up, unless someone else has a strong desire to do it. (which is probably some combination of: vote, plan, liaise with infra) Yep, I expect I'll be doing all three at once. ;-) -- Martin Cooper Hen On Fri, 26 Nov 2004 10:54:37 -0500, Phil Steitz [EMAIL PROTECTED] wrote: +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman 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: commons-dev- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][math] Release Math 1.0
+0 as I can not help not having any cvs system set up. Cheers, Kim --- [ ] +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 --- -- http://www.kimvdlinde.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32414] New: - updated docs for example.html page (select AS)
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=32414. 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=32414 Summary: updated docs for example.html page (select AS) Product: Commons Version: Nightly Builds Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: DbUtils AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Below is the CVS diff (I can not fiogure out how to do an attachment): --- START --- Index: examples.xml === RCS file: /home/cvspublic/jakarta-commons/dbutils/xdocs/examples.xml,v retrieving revision 1.6 diff -u -r1.6 examples.xml --- examples.xml19 Mar 2004 00:25:39 - 1.6 +++ examples.xml27 Nov 2004 20:22:43 - @@ -149,6 +149,39 @@ your application. The provided implementation delegates datatype conversion to the JDBC driver. /p + +pUsing the BeanHandler potentially adds a new requirement - it +requires that the names of the column in the database match the +property names defined of the JavaBean. In the above example, that +means that if the columns in the database table Person were +PERSON_ID, NAME, FIRST_NAME, and LAST_NAME, then the +properties of the JavaBean Person.java must be person_id, +name, first_name, and last_name. (Note that the case does +not have to match.) Such a situation is a real world reality in +that many DBAs, er, iencourage/i a naming schema that contains +only capital letters and where each word is separated by the +underscore character./p + +pThere are at least three potential solutions to this issue: +ol +liChange the database column names to match the JavaBean property names./li +liChange the JavaBean property names to match the database column names./li +liModify the SELECT statement to use the codeAS/code SQL keyword/li +/ol +/p + +pThe first two options presented are usually not feasible. The +third option has you change the SQL statement. So, given a JavaBean +with properties person_id, name, first_name, and last_name, +the SELECT statement would need to be changed to codeSELECT +PERSON_ID AS personId, NAME, FIRST_NAME AS firstName, LAST_NAME +AS lastName FROM Person WHERE name=?/code. (Note that the AS +keyword is not used with the column named NAME since it matches the +JavaBean property name.)/p + +pA fourth option, as mentioned above, would involve implementing +a customized codeRowProcessor/code/p + /section /body --- END --- This is based on the following email exchange: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 10:24 AM To: Jakarta Commons Users List Subject: Re: [DbUtils] documentation update overloading BeanHandler constructor The reason we made mapColumnsToProperties protected was to allow you to handle the mapping any way you like including removing underscores so I'm not to eager to add a boolean parameter to the constructor. I personally just alias the column names to something reasonable in the sql so I don't have to mess with the code. Opening a bugzilla ticket and attaching a cvs diff -u formatted patch for the documentation is the best way to propose changes. SQL is case insensitive so you can call the column first_name or FIRST_name or FIRST_NAME; it doesn't really matter. David --- Markus Khouri [EMAIL PROTECTED] wrote: Dear dbutil folks, I am a newbie to this package. I was really excited because I do not know much about databases and was hoping that this package could hide most of the details from me. (Yes, I know I should understand everything, but I simply do not have the time.) I spent a pretty good amount of time grappling with how to get this utility to work with my existing database table and my existing JavaBean. The issue I was running into was that the column names did not match the JavaBean property names. I finally found the answer in the forums, but guessing that my situation is not unique, I was wondering if you might possibly add some additional documentation to the Example page, at the end of the ResultSetHandler Implementations section. Below I have provided a first draft. Since I do not know what the submission process is, I am willing to work with the editor if need be. (I figured I spent some time with this issue and, if possible, might as well try to save others some time.) In addition, I am wondering if it might be possible to overload the BeanHandler constructor so that it also takes a boolean argument. This argument would be a flag to indicate if the underscore
DO NOT REPLY [Bug 32414] - updated docs for example.html page (select AS)
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=32414. 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=32414 --- Additional Comments From [EMAIL PROTECTED] 2004-11-27 21:38 --- Created an attachment (id=13559) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13559action=view) the patch file i figured out how to add an attachment. (Perhaps a note could be added to the initial paeg that attachments can be added in the following step.) -- 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/email build.xml
craigmcc2004/11/27 13:07:11
Modified:emailbuild.xml
Log:
Hand patch to the Maven generated build.xml file to declare Ant properties
for the JavaMail and Java Activation Framework JAR files. This allows us
to declare file: URLs pointing to a locally installed copy of these
packages.
With this change, Commons Email now compiles again; however, there are still
test failures on my system (Linux) that prevent the ant clean dist executed
by the nightly build from completing successfully.
Revision ChangesPath
1.3 +9 -0 jakarta-commons/email/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/email/build.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.xml 25 Nov 2004 20:41:16 - 1.2
+++ build.xml 27 Nov 2004 21:07:11 - 1.3
@@ -4,6 +4,9 @@
on date November 23 2004, time 1811--
project default=jar name=commons-email basedir=.
+ !-- Load local properties in the usual way --
+ property file=build.properties/
+ property file=${user.home}/build.properties/
property name=defaulttargetdir value=target
/property
property name=libdir value=target/lib
@@ -148,9 +151,15 @@
/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
+!-- Replace following two GETs because of license issues
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}/javamail-1.3.2.jar usetimestamp=true
ignoreerrors=true src=${javamail-1.3.2.url}
+/get
+get dest=${libdir}/activation-1.0.2.jar usetimestamp=true
ignoreerrors=true src=${activation-1.0.2.url}
/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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-167) add 'public JellyContext newEmptyJellyContext()' to JellyContext
[ http://nagoya.apache.org/jira/browse/JELLY-167?page=comments#action_55940 ] Hans Gilde commented on JELLY-167: -- newJellyContext exists so that you can override it. The idea is that a subclass Of JellyContext might want to implement certain behavior when creating a child context or a context to run in another thread. I'm not in favor of adding this method to JellyContext because it's not used by the core Jelly API. If you want to copy a context in a particular way, why not just create a new static method for yourself (outside of the Jelly API): public static JellyContext cloneContext(JellyContext cloneMe) 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]
[announce] [convert] Morph 0.3.1 released
Morph 0.3.1 is available at http://morph.sourceforge.net. Major changes in this release - Introduced new Transformer abstraction, which is a common super-interface for Converters and Copiers - Removed isConvertible, isCopiable and isReflectable in favor of getDestinationClasses, getSourceClasses, and getReflectableClasses. This was done primarily to support the ChainConverter - Broke up the IndexedReflector interface into several smaller interfaces that each define pieces of functionality that a container of items might have If you have any questions or would like to be a committer for Morph, please just let me know! Matt
DO NOT REPLY [Bug 32260] - [email] byte array attachments
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=32260. 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=32260 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13524|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-11-28 08:16 --- Created an attachment (id=13563) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13563action=view) New patch against commons (not commons-sandbox), no other changes -- 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]
