Re: [VOTE] Release Commons Configuration 1.4 based on RC1
1.4 is missing from the downloads page. Couple of checkstyle errors (no idea if they matter). Minor nitpick on the Runtime Dependencies page - 'couple' means 2, not 7 :) Clirr in the xml format is even less readable than the txt format - "-s text" RELEASE_NOTES.txt has an odd character between 'first' and 'whether' Unpacking the source, the ant and m1 builds work fine, but the m2 build fails because it can't find: javax.sql:jdbc-stdext:jar:2.0 Hen On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: The files of the first release candidate for Configuration 1.4, including the site and a Clirr report, are available for inspection at http://people.apache.org/~oheger/commons-configuration-1.4rc1/ [ ] +1 Go ahead and release it [ ] -1 Don't release it because... Vote will close on Saturday night (CET). Oliver - 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: VOTE: Release commons-fileupload 1.2 (3rd attempt)
On 2/7/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote: LICENSE and NOTICE missing from -sources.jar and -javadoc.jar Shouldn't be hard for Jochen to fix this prior to release. Website has lost a lot of stuff compared to existing website A lot of stuff. An odd logo for Commons, missing logo for FileUpload, missing ApacheCon advert, missing Commons items on the LHS. The .pom file is an M2 pom, so we need to make sure it goes to the m2 ibiblio repo and not the m1 ibiblio repo [I'm sure you know that Jochen, just stating the obvious as it never hurts]. PGP sig checks out. MD5s are good. The build.xml is odd - it gets jars from repo1.maven.org (good) and then tries to get them from the apache snapshot repo. That's odd - I'm guessing this is a bug in the Maven build.xml plugin? Not a blocker. Src rebuilds happily under ant, maven1 + maven2. The checkstyle report has 2 'errors'. I don't see the clirr report. Blockers: * Site * Clirr report Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/7/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I made a stab of defining the current status for Commons for the Jakarta board report: http://wiki.apache.org/jakarta/JakartaBoardReport-current Here's the summary. Any thoughts on the ?? marks and the dormancy candidates? Feel free to add things to the wiki page. I've not added all of this yet. Attributes - Needs a new release, after that a dormancy candidate. BeanUtils - Inactive. 1.8.0 slowly being worked on. Betwixt - Just released. Chain - ?? CLI - Inactive. Dormancy candidate? Codec - Inactive. Collections - Inactive - new releases discussed but not much movement. Configuration - Active. Daemon - ?? Dormancy candidate? DBCP - 1.2.2 release in the works. DbUtils - 1.1 release made. No plans for 1.2. Digester - ?? Discovery - 0.4 release made, nothing new planned. Dormancy candidate. EL - ?? Dormancy candidate? Email - Maybe a 1.1 release in the works. Not much activity yet. FileUpload - 1.2 release in the works. IO - 1.3 just released. Jelly - ?? Dormancy candidate? Again, little ongoing hard core development, but a little fix work and experimentation happens. Jexl - ?? Dormancy candidate? Jexl gets a little bit of development here and there and has been reasonably stable recently. We keep threatening to start Jexl 2. JXPath - ?? Dormancy candidate? Lang - 2.3 release in the works. Launcher - Inactive. Dormancy candidate. Logging - Needs a 1.1.1 release, no plans beyond that. Math - Slow activity. Modeler - Inactive - dormancy? Net - New JDK 1.5 version in the works. Pool - New version in the works. Primitives - Inactive. Dormancy candidate? SCXML - Active, just released. Transaction - Release being discussed. Validator - Active. VFS - Active and releasing. Dormant - Nothing likely to leave dormancy. Sandbox - Nothing that looks like moving to proper anytime soon. Some for dormancy (finder, id). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ Rule of Acquisition #91: Hear all, trust nothing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] jira fix up
Hi, I was browsing the JIRA for commons-configuration and noticed the versions were 'upside down' - so I reversed them in the admin section. The roadmap now shows the next 3 versions correctly (1.4, 1.5, 2.0) instead of previously listing them as (Nightly, 2.0, 1.5). I placed nightly between 1.3 and 1.4. Hope that's ok - let me know if it causes any problems. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/8/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 2/8/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 2/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > > > On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > Digester - ?? > > > > > > > > > > > > Recently had a 1.8 release to clean up memory leaks and a few other > > > bugs. > > > > For a 1.x release it seems like you could call it stable. But the > > > > architectural approach (including its dependence on the six year old > > > > BeanUtils architecture) could certainly use a remodel. > > > > > > Do you have a suggestion/idea on what you would replace BeanUtils > with? > > > > > > I'm biased by my own experience, of course :-), but any implementation > of an > > expression language has to solve the same set of problems that BeanUtils > > solves, plus a whole lot more. Coupled with the fact that the JSP/JSF > > expression language APIs are being split out into a separate spec so you > > could have implementations of it that have nothing to do with the web > tier, > > if I were building Digester today I would likely think about mapping the > > property setter type rules to EL evaluations. > > I went "looking for el" today - had to first work out what spec > versions were related. > > So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0. > The independant EL Craig's talking about relates to Servlet 2.5 / JSP > 2.1 and will feature in Tomcat 6 (currently beta). > > Unfortunately it seems that the Tomcat project has developed the > independant EL for Tomcat 6 "in house" as part of their project - > rather than building a new version of Commons EL here. This seems a > shame - both from a Commons EL PoV since its now a legacy/dormant > component and for the type of thing Craig is suggesting - using EL > independantly of a servlet environment. > > I wonder if we could entice the Tomcat folks to do the development of > EL here rather than in their repo - if they haven't already got commit > access here (which I'm sure at least some have) - I'd be happy for > them to have it. Anyone else think this has merit or should we just > let EL lapse? I think it would indeed be useful ... but as usual in life there will be complications. The EL spec itself defines basic APIs like ELContext and ELResolver, plus some factory and configuration methods to glue them together and get instances. On top of that, JSF and JSP provide a whole pile of resolvers that provide the default functionality you need in that environment (for example, the gadget that makes managed bean creation happen) on top of it. From the viewpoint of the Tomcat folks, this might indeed be reasonable to keep in their own repository ... while perhaps moving the generic part here. I posted a message to the Tomcat Dev list[1] about this - so have to see what (if any) interest there is from their side. [1] http://tinyurl.com/2hozrg In addition to Tomcat, I know that Facelets and MyFaces both have some stuff in this area, and Geronimo will eventually have to do something (although they'll probably start by inheriting from whatever JSF and JSP implementations they choose). Come to think of it, Shale's test framework has started implementing mocks for these classes so you can unit test JSF 1.2 based apps. But you have to build so much of the infrastructure to make this actually work that it's pretty close to implementing the generic part of the EL APIs. It'd be interesting to think about moving that part over so it can be shared. Niall Craig > (Of course, because we're dealing with XML directly here, XPath > expressions > > might be another choice ... but they will be less familiar to Java > > developers.) > > > > 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]
Re: [VOTE] IO 1.3.1 (RC1)
Henri Yandell <[EMAIL PROTECTED]> wrote: > I screwed up the 1.3 release, so here's a 1.3.1 release: > > http://people.apache.org/~bayard/commons-io/1.3.1-rc1/ +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] IO 1.3.1 (RC1)
I screwed up the 1.3 release, so here's a 1.3.1 release: http://people.apache.org/~bayard/commons-io/1.3.1-rc1/ The only differences are the following two issues: http://issues.apache.org/jira/browse/IO-112 http://issues.apache.org/jira/browse/IO-113 IO-113 is the reason for the release. We'd like to get 1.3.1 out quickly so the fact that 1.3.1 is not binary compatible with 1.3 will not inconvenience many people. [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r505137 - /jakarta/commons/proper/io/trunk/xdocs/navigation.xml
Author: bayard Date: Thu Feb 8 18:13:36 2007 New Revision: 505137 URL: http://svn.apache.org/viewvc?view=rev&rev=505137 Log: Preparing for 1.3.1 Modified: jakarta/commons/proper/io/trunk/xdocs/navigation.xml Modified: jakarta/commons/proper/io/trunk/xdocs/navigation.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/xdocs/navigation.xml?view=diff&rev=505137&r1=505136&r2=505137 == --- jakarta/commons/proper/io/trunk/xdocs/navigation.xml (original) +++ jakarta/commons/proper/io/trunk/xdocs/navigation.xml Thu Feb 8 18:13:36 2007 @@ -15,7 +15,7 @@ - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r505130 - in /jakarta/commons/proper/io/trunk: build.xml pom.xml project.xml
Author: bayard Date: Thu Feb 8 17:59:29 2007 New Revision: 505130 URL: http://svn.apache.org/viewvc?view=rev&rev=505130 Log: Setting version to 1.3.1 Modified: jakarta/commons/proper/io/trunk/build.xml jakarta/commons/proper/io/trunk/pom.xml jakarta/commons/proper/io/trunk/project.xml Modified: jakarta/commons/proper/io/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/build.xml?view=diff&rev=505130&r1=505129&r2=505130 == --- jakarta/commons/proper/io/trunk/build.xml (original) +++ jakarta/commons/proper/io/trunk/build.xml Thu Feb 8 17:59:29 2007 @@ -26,7 +26,7 @@ - + @@ -272,7 +272,7 @@ - + Modified: jakarta/commons/proper/io/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/pom.xml?view=diff&rev=505130&r1=505129&r2=505130 == --- jakarta/commons/proper/io/trunk/pom.xml (original) +++ jakarta/commons/proper/io/trunk/pom.xml Thu Feb 8 17:59:29 2007 @@ -27,7 +27,7 @@ 4.0.0 commons-io commons-io - 1.4-SNAPSHOT + 1.3.1 IO 2002 Modified: jakarta/commons/proper/io/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/project.xml?view=diff&rev=505130&r1=505129&r2=505130 == --- jakarta/commons/proper/io/trunk/project.xml (original) +++ jakarta/commons/proper/io/trunk/project.xml Thu Feb 8 17:59:29 2007 @@ -21,7 +21,7 @@ IO commons-io commons-io - 1.4-SNAPSHOT + 1.3.1 2002 Commons IO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r505129 - /jakarta/commons/proper/io/trunk/xdocs/index.xml
Author: bayard Date: Thu Feb 8 17:59:18 2007 New Revision: 505129 URL: http://svn.apache.org/viewvc?view=rev&rev=505129 Log: Adding 1.3.1 to the list of javadoc Modified: jakarta/commons/proper/io/trunk/xdocs/index.xml Modified: jakarta/commons/proper/io/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/xdocs/index.xml?view=diff&rev=505129&r1=505128&r2=505129 == --- jakarta/commons/proper/io/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/io/trunk/xdocs/index.xml Thu Feb 8 17:59:18 2007 @@ -46,7 +46,8 @@ The JavaDoc API documents are available online: -The current release 1.3 +The current release 1.3.1 +The previous version 1.3 The previous version 1.2 The previous version 1.1 The latest SVN - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r505126 - in /jakarta/commons/proper/io/trunk/xdocs: building.xml index.xml upgradeto1_3_1.xml
Author: bayard Date: Thu Feb 8 17:58:19 2007 New Revision: 505126 URL: http://svn.apache.org/viewvc?view=rev&rev=505126 Log: Adding upgrade notes for 1.3.1 Added: jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_1.xml (with props) Modified: jakarta/commons/proper/io/trunk/xdocs/building.xml jakarta/commons/proper/io/trunk/xdocs/index.xml Modified: jakarta/commons/proper/io/trunk/xdocs/building.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/xdocs/building.xml?view=diff&rev=505126&r1=505125&r2=505126 == --- jakarta/commons/proper/io/trunk/xdocs/building.xml (original) +++ jakarta/commons/proper/io/trunk/xdocs/building.xml Thu Feb 8 17:58:19 2007 @@ -29,6 +29,7 @@ You may also be interested in the upgrade notes: + Upgrade from 1.3 to 1.3.1 Upgrade from 1.2 to 1.3 Upgrade from 1.1 to 1.2 Upgrade from 1.0 to 1.1 Modified: jakarta/commons/proper/io/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/xdocs/index.xml?view=diff&rev=505126&r1=505125&r2=505126 == --- jakarta/commons/proper/io/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/io/trunk/xdocs/index.xml Thu Feb 8 17:58:19 2007 @@ -59,9 +59,9 @@ -The latest version is v1.3. - +The latest version is v1.3.1. - http://jakarta.apache.org/site/downloads/downloads_commons-io.cgi";>Download now! -The upgrade notes are also available. +The upgrade notes are also available. Added: jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_1.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_1.xml?view=auto&rev=505126 == --- jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_1.xml (added) +++ jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_1.xml Thu Feb 8 17:58:19 2007 @@ -0,0 +1,60 @@ + + + + + Upgrade from 1.3 to 1.3.1 + Commons Documentation Team + + + + + +These are the release notes and advice for upgrading Commons-IO from +version 1.3 to version 1.3.1. + +Commons IO is a package of Java utility classes for java.io's hierarchy. +Classes in this package are considered to be so standard and of such high +reuse as to justify existence in java.io. + +Commons IO contains utility classes, stream implementations, file filters, +and endian transformation classes. + + +Compatibility with 1.3 +-- +Binary compatible - No + See [IO-112] + +Source compatible - No + See [IO-112] + +Semantic compatible - Yes + + +Bug fixes from 1.3 +-- + +- FileUtils + - NPE in openOutputStream(File) when file has no parent in path [IO-112] + - readFileToString(File) is not static [IO-113] + + + + + + Propchange: jakarta/commons/proper/io/trunk/xdocs/upgradeto1_3_1.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r505124 - /jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
Author: bayard Date: Thu Feb 8 17:55:01 2007 New Revision: 505124 URL: http://svn.apache.org/viewvc?view=rev&rev=505124 Log: Updating release notes Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?view=diff&rev=505124&r1=505123&r2=505124 == --- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Thu Feb 8 17:55:01 2007 @@ -1,7 +1,7 @@ $Id$ Commons IO Package - Version 1.3 + Version 1.3.1 Release Notes @@ -15,191 +15,23 @@ and endian transformation classes. -Compatibility with 1.2 +Compatibility with 1.3 -- -Binary compatible - Yes +Binary compatible - No + See [IO-112] -Source compatible - Yes +Source compatible - No + See [IO-112] Semantic compatible - Yes - Check the bug fixes section for semantic bug fixes -Deprecations from 1.2 -- -- WildcardFilter deprecated, replaced by WildcardFileFilter - - old class only accepted files, thus had a confusing dual purpose - -- FileSystemUtils.freeSpace deprecated, replaced by freeSpaceKb - - freeSpace returns a result that varies by operating system and -thus isn't that useful - - freeSpaceKb returns much better and more consistent results - - freeSpaceKb existed in v1.2, so this is a gentle cutover - - -Bug fixes from 1.2 +Bug fixes from 1.3 -- -- LineIterator now implements Iterator - - It was always supposed to... - -- FileSystemUtils.freeSpace/freeSpaceKb [IO-83] - - These should now work on AIX and HP-UX - -- FileSystemUtils.freeSpace/freeSpaceKb [IO-90] - - Avoid infinite looping in Windows - - Catch more errors with nice messages - -- FileSystemUtils.freeSpace [IO-91] - - This is now documented not to work on SunOS 5 - -- FileSystemUtils [IO-93] - - Fixed resource leak leading to 'Too many open files' error - - Previously did not destroy Process instances (as JDK Javadoc is so poor) - - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4801027 - -- FileUtils.touch [IO-100] - - The touch method previously gave no indication when the file could not -be touched successfully (such as due to access restrictions) - it now -throws an IOException if the last modified date cannot be changed - -- FileCleaner - - This now handles the situation where an error occurs when deleting the file - -- IOUtils.copy [IO-84] - - Copy methods could return inaccurate byte/char count for large streams - - The copy(InputStream, OutputStream) method now returns -1 if the count is greater than an int - - The copy(Reader, Writer) method now throws now returns -1 if the count is greater than an int - - Added a new copyLarge(InputStream, OutputStream) method that returns a long - - Added a new copyLarge(Reader, Writer) method that returns a long - -- CountingInputStream/CountingOutputStream [IO-84] - - Methods were declared as int thus the count was innacurate for large streams - - new long based methods getByteCount()/resetByteCount() added - - existing methods changed to throw an exception if the count is greater than an int - -- FileBasedTestCase - - Fixed bug in compare content methods identified by GNU classpath - -- EndianUtils.writeSwappedLong(byte[], int) [IO-101] - - An int overrun in the bit shifting when it should have been a long - -- EndianUtils.writeSwappedLong(InputStream) [IO-102] - - The return of input.read(byte[]) was not being checked to ensure all 8 bytes were read - -Enhancements from 1.2 -- -- DirectoryWalker [IO-86] - - New class designed for subclassing to walk through a set of files. -DirectoryWalker provides the walk of the directories, filtering of -directories and files, and cancellation support. The subclass must provide -the specific behaviour, such as text searching or image processing. - -- IOCase - - New class/enumeration for case-sensitivity control - -- FilenameUtils - - New methods to handle case-sensitivity - - wildcardMatch - new method that has IOCase as a parameter - - equals - new method that has IOCase as a parameter - -- FileUtils [IO-108] - new default encoding methods for: - - readFileToString(File) - - readLines(File) - - lineIterator(File) - - writeStringToFile(File, String) - - writeLines(File, Collection) - - writeLines(File, Collection, String) - -- FileUtils.openOutputStream [IO-107] - - new method to open a FileOutputStream, creating parent directories if required -- FileUtils.touch -- FileUtils.copyURLToFile -- FileUtils.writeStringToFile -- FileUtils.writeByteArrayToFile -- FileUtils.writeLines - - enhanced to create parent directories if required -- FileUtils.openInp
svn commit: r505122 - /jakarta/commons/proper/io/trunk/doap_io.rdf
Author: bayard Date: Thu Feb 8 17:52:08 2007 New Revision: 505122 URL: http://svn.apache.org/viewvc?view=rev&rev=505122 Log: Adding info on the 1.3 release Modified: jakarta/commons/proper/io/trunk/doap_io.rdf Modified: jakarta/commons/proper/io/trunk/doap_io.rdf URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/doap_io.rdf?view=diff&rev=505122&r1=505121&r2=505122 == --- jakarta/commons/proper/io/trunk/doap_io.rdf (original) +++ jakarta/commons/proper/io/trunk/doap_io.rdf Thu Feb 8 17:52:08 2007 @@ -30,6 +30,11 @@ 2006-03-19 1.2 + +commons-io +2007-01-30 +1.3 + http://jakarta.apache.org/site/mail2.html#Commons"/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell resolved IO-113. -- Resolution: Fixed I'll build a 1.3.1 tonight. It'll contain this issue and IO-112. > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.3.1 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-112) NPE in FileUtils.openOutputStream(File) when file has no parent in path.
[
https://issues.apache.org/jira/browse/IO-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated IO-112:
-
Fix Version/s: (was: 1.4)
1.3.1
> NPE in FileUtils.openOutputStream(File) when file has no parent in path.
>
>
> Key: IO-112
> URL: https://issues.apache.org/jira/browse/IO-112
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 1.3
> Environment: Sun Java 1.4.2_13.
> Windows XP SP2 + current patches.
> Eclipse 3.3M4.
>Reporter: Gary Gregory
> Assigned To: Gary Gregory
> Fix For: 1.3.1
>
>
> -Original Message-
> From: deng xinzi [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 04, 2007 6:19 AM
> To: commons-dev@jakarta.apache.org
> Subject: [bug]commons-io 1.3 FileUtils.openOutputStream(File file)
> NullPointException
> FileUtils.openOutputStream(File file)
> When the file = new File( "abc.txt" );
> There will be a NullPointerException throw.
> Cause
> file = new File("abc.txt")
> file.getParentFile() returns null.
> So I suggest adding the null check code like this.
> File parent = file.getParentFile();
> if( parent != null ) { // ADD THIS!!!
> if (parent.exists() == false) {
> if (parent.mkdirs() == false) {
> throw new IOException("File '" + file + "' could not be
> created");
> }
> }
> }
>Xinzi ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated IO-113: - Fix Version/s: (was: 1.4) 1.3.1 > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.3.1 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471523 ] Stephen Colebourne commented on IO-113: --- I think that we can probably get away with option (b) if we are quick enough. > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-111) FileSystemUtils.freeDiskSpaceUnix does not work if df is not in the shell path
[ https://issues.apache.org/jira/browse/IO-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471517 ] Henri Yandell commented on IO-111: -- I think it should be expected in the path, so my vote here is wontfix. > FileSystemUtils.freeDiskSpaceUnix does not work if df is not in the shell path > -- > > Key: IO-111 > URL: https://issues.apache.org/jira/browse/IO-111 > Project: Commons IO > Issue Type: Bug >Affects Versions: 1.2, 1.3 > Environment: Solaris >Reporter: Xavier Soudan >Priority: Minor > > if the df command is not in the path, the method freeSpaceUnix throws an > exception: > java.io.IOException: df: not found > at java.lang.UNIXProcess.forkAndExec(Native Method) > at java.lang.UNIXProcess.(UNIXProcess.java:53) > at java.lang.ProcessImpl.start(ProcessImpl.java:65) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) > at java.lang.Runtime.exec(Runtime.java:591) > at java.lang.Runtime.exec(Runtime.java:464) > at > org.apache.commons.io.FileSystemUtils.openProcessStream(FileSystemUtils.java:357) > at > org.apache.commons.io.FileSystemUtils.freeSpaceUnix(FileSystemUtils.java:298) > Rather than expecting df is in the path, it should be searched in the > following standard location: > /usr/bin/df > /usr/sbin/df > /bin/df > /sbin/df > /usr/ucb/df > /usr/xpg4/bin/df -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/8/07, sebb <[EMAIL PROTECTED]> wrote: On 07/02/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > I made a stab of defining the current status for Commons for the > Jakarta board report: > > http://wiki.apache.org/jakarta/JakartaBoardReport-current > > Here's the summary. Any thoughts on the ?? marks and the dormancy > candidates? Feel free to add things to the wiki page. I've not added > all of this yet. > > Attributes - Needs a new release, after that a dormancy candidate. > BeanUtils - Inactive. 1.8.0 slowly being worked on. > Betwixt - Just released. > Chain - ?? > CLI - Inactive. Dormancy candidate? JMeter is currently using the same code as the Avalon CLI - which is mixed up in the rest of CLI2. There have been no reported problems for the CLI in JMeter for a long time now. It is not the same animal as CLI and CLI2, so perhaps it should be moved somewhere else? Can it be made a separate mini project in Commons? Seems a shame that the only use of the code is in JMeter at present. Once it has been released, it can remain happily in maintenance mode... I'm happy to do the work. Split off from CLI2 a while ago :) http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/ > Jexl - ?? Dormancy candidate? We're using it in JMeter. I think a lot of people are. Maybe we need a better name than Dormancy, it seems to imply dead to people when in fact the idea is that things wake up from dormancy if someone wants to be active on it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 07/02/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I made a stab of defining the current status for Commons for the Jakarta board report: http://wiki.apache.org/jakarta/JakartaBoardReport-current Here's the summary. Any thoughts on the ?? marks and the dormancy candidates? Feel free to add things to the wiki page. I've not added all of this yet. Attributes - Needs a new release, after that a dormancy candidate. BeanUtils - Inactive. 1.8.0 slowly being worked on. Betwixt - Just released. Chain - ?? CLI - Inactive. Dormancy candidate? JMeter is currently using the same code as the Avalon CLI - which is mixed up in the rest of CLI2. There have been no reported problems for the CLI in JMeter for a long time now. It is not the same animal as CLI and CLI2, so perhaps it should be moved somewhere else? Can it be made a separate mini project in Commons? Seems a shame that the only use of the code is in JMeter at present. Once it has been released, it can remain happily in maintenance mode... I'm happy to do the work. Codec - Inactive. Collections - Inactive - new releases discussed but not much movement. Configuration - Active. Daemon - ?? Dormancy candidate? DBCP - 1.2.2 release in the works. DbUtils - 1.1 release made. No plans for 1.2. Digester - ?? Discovery - 0.4 release made, nothing new planned. Dormancy candidate. EL - ?? Dormancy candidate? Email - Maybe a 1.1 release in the works. Not much activity yet. FileUpload - 1.2 release in the works. IO - 1.3 just released. Jelly - ?? Dormancy candidate? Jexl - ?? Dormancy candidate? We're using it in JMeter. JXPath - ?? Dormancy candidate? Lang - 2.3 release in the works. Launcher - Inactive. Dormancy candidate. Logging - Needs a 1.1.1 release, no plans beyond that. Math - Slow activity. Modeler - Inactive - dormancy? Net - New JDK 1.5 version in the works. Pool - New version in the works. Primitives - Inactive. Dormancy candidate? SCXML - Active, just released. Transaction - Release being discussed. Validator - Active. VFS - Active and releasing. Dormant - Nothing likely to leave dormancy. Sandbox - Nothing that looks like moving to proper anytime soon. Some for dormancy (finder, id). - 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]
Lang 2.3 problems Was: [VOTE] Lang 2.3 (RC2)
On 2/8/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: Hi Hen, Henri Yandell wrote: > Here's the 2nd release candidate for Lang 2.3: > > http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ > > Clirr, Jardiff + Site included. > > [ ] +1 > [ ] -1 > > Vote to close on Saturday if it gets that far. DateFormatUtils.testLang312 still fail for me, now at the last assert: === %< Testsuite: org.apache.commons.lang.time.TimeTestSuite Tests run: 62, Failures: 1, Errors: 0, Time elapsed: 11,174 sec - Standard Output --- WARNING: JDK test failed - testLang312() - --- Testcase: testLang312(org.apache.commons.lang.time.DateFormatUtilsTest): FAILED expected:<...9...> but was:<...8...> junit.framework.ComparisonFailure: expected:<...9...> but was:<...8...> at org.apache.commons.lang.time.DateFormatUtilsTest.testLang31 (DateFormatUtilsTest.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) === %< It seems that we cannot format correctly also if the JDK fails. :-/ Ack :( What kind of environment are you in? timezone/platform/jdk version/locale? BTW: What happened with the navigation? http://people.apache.org/~joehni/navi.gif ApacheCon advert by the look of it. I'm guessing however its done, isn't supported in your browser? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi, in addition to the points Stephen has already mentioned: - The source distro deflates into the same directory as the binary distro. It is common practice to name the directory "commons-fileupload-1.2rc3-src". - I tested the builds with maven 1, 2, and ant. They all work, but when building with ant the LICENSE is missing from the jar and the manifest does not contain the usual entries. I don't think these points are show stoppers, but they should be easy to fix. Oliver Jochen Wiedmann wrote: On 2/7/07, Oliver Heger <[EMAIL PROTECTED]> wrote: Hm, I probably did not follow this thread in the past, so can you please point me to where I find the files of this rc? Awfully sorry, and thanks for asking. The files are available from http://people.apache.org/~jochen/commons-fileupload/dist/ A file rat.txt (RAT report) is included. The proposed site is at http://people.apache.org/~jochen/commons-fileupload/site/ Clirr and checkstyle reports are included in the site. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC2)
Hi Hen, Henri Yandell wrote: > Here's the 2nd release candidate for Lang 2.3: > > http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ > > Clirr, Jardiff + Site included. > > [ ] +1 > [ ] -1 > > Vote to close on Saturday if it gets that far. DateFormatUtils.testLang312 still fail for me, now at the last assert: === %< Testsuite: org.apache.commons.lang.time.TimeTestSuite Tests run: 62, Failures: 1, Errors: 0, Time elapsed: 11,174 sec - Standard Output --- WARNING: JDK test failed - testLang312() - --- Testcase: testLang312(org.apache.commons.lang.time.DateFormatUtilsTest): FAILED expected:<...9...> but was:<...8...> junit.framework.ComparisonFailure: expected:<...9...> but was:<...8...> at org.apache.commons.lang.time.DateFormatUtilsTest.testLang31 (DateFormatUtilsTest.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) === %< It seems that we cannot format correctly also if the JDK fails. :-/ BTW: What happened with the navigation? http://people.apache.org/~joehni/navi.gif - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-62: -- Description: Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings when building commons-email on JDK >= 1.5. (was: Suppresses spurious 1.5 type safety warnings when building commons-email on JDK >= 1.5. Attaching patch shortly...) Summary: [email] Build patches to enforce source 1.4 and target 1.4 when compiling (was: Build patches to enforce source 1.4 and target 1.4 when compiling) > [email] Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings > when building commons-email on JDK >= 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471465 ] Raul Acevedo commented on IO-113: - That's silly. I would have kept the API clean and made Velocity owners complain to the writers of that tool to fix it, since that is a bug in the tool. It shouldn't be reflected in the API. Anyway, thanks for the help! When will this fix be released? > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EMAIL-62) Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-62: -- Attachment: project.properties.patch Oops. Maybe I'll attach the patch instead of the whole file. :) > Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Suppresses spurious 1.5 type safety warnings when building commons-email on > JDK >= 1.5. Attaching patch shortly... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EMAIL-62) Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-62: -- Attachment: project.properties > Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Suppresses spurious 1.5 type safety warnings when building commons-email on > JDK >= 1.5. Attaching patch shortly... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EMAIL-62) Build patches to enforce source 1.4 and target 1.4 when compiling
[ https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-62: -- Summary: Build patches to enforce source 1.4 and target 1.4 when compiling (was: Ant patch to enforce source 1.4 and target 1.4 when compiling) Changing summary since I'm about to attach another patch to enforce 1.4 source/target in the Maven build... > Build patches to enforce source 1.4 and target 1.4 when compiling > - > > Key: EMAIL-62 > URL: https://issues.apache.org/jira/browse/EMAIL-62 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Ben Speakmon > Fix For: 1.1 > > Attachments: build.xml.patch, project.properties, > project.properties.patch > > > Suppresses spurious 1.5 type safety warnings when building commons-email on > JDK >= 1.5. Attaching patch shortly... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471461 ] Henri Yandell commented on IO-113: -- For tools that don't allow static invocation. Velocity was the main reason why we add an empty constructor with warnings not to use it to each XxxUtils class we have. > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-14) [email] not support content charset gb2312
[
https://issues.apache.org/jira/browse/EMAIL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471456
]
Ben Speakmon commented on EMAIL-14:
---
I've submitted a patch for this issue in EMAIL-54.
> [email] not support content charset gb2312
> ---
>
> Key: EMAIL-14
> URL: https://issues.apache.org/jira/browse/EMAIL-14
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: locka
> Attachments: commons-email-utf8.patch.txt, patch.java
>
>
> when i try the example :
> Email email=new SimpleEmail();
> email.setHostName("129.1.1.129");
> email.setAuthentication("admin","1");
> email.addTo("[EMAIL PROTECTED]", "wjq");
> email.setFrom("[EMAIL PROTECTED]", "Me");
> email.setCharset("gb2312");
> email.setSubject("²âÊÔ¼òµ¥Óʼþ");
> email.setMsg("ÕâÊDzâÊÔ¼òµ¥Óʼþ");
> email.send();
> the received mail content like "" ,when change Email.TEXT_PLAIN
> = "text/plain" to TEXT_PLAIN = "text/plain;charset=gb2312" , all are right
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EMAIL-25) [email] Address char-set can not be individually set
[ https://issues.apache.org/jira/browse/EMAIL-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471455 ] Ben Speakmon commented on EMAIL-25: --- I've submitted a patch for this issue in EMAIL-54. > [email] Address char-set can not be individually set > > > Key: EMAIL-25 > URL: https://issues.apache.org/jira/browse/EMAIL-25 > Project: Commons Email > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: James Huang >Priority: Critical > > The commons-email-1.0 release API has a critical flaw: you can't specify char- > set for individual addresses. This is the case with some Japanese mail > systems. > Currently, org.apache.commons.mail.Email class only has methods like >add(String email, String name); > but no such methods: >addXXX(String email, String name, String charset); > In addition, I believe the API should allow >addXXX(javax.mail.internt.InternetAddress); > If you want to hide InternetAddress, I don't mind to even have a > addXXX(Object). > Thanks, > -James Huang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EMAIL-54) [email] Add new class Charset
[ https://issues.apache.org/jira/browse/EMAIL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-54: -- Attachment: charset-support.patch Attaching a patch and updated test cases for better charset support. * adds addTo(), addCc(), addReplyTo(), addBcc() overloads which take parameters (email, name, charset) and creates InternetAddresses that get encoded using the specified charset. This fixes EMAIL-25. * All charset names are now passed to java.nio.charset.Charset.forName(), which confirms that the requested charset is available in the current JVM and returns the canonical name for it. Invalid charset names will be detected and the proper exception thrown. This fixes EMAIL-14. * Finally, delegating charset handling to the JVM means we don't need a separate Charset class or create a need to maintain some kind of registry of correct names. A couple of comments on the charset issues request specific charsets; now, if the JVM supports it, we don't need to do anything else. > [email] Add new class Charset > - > > Key: EMAIL-54 > URL: https://issues.apache.org/jira/browse/EMAIL-54 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: Piero Ottuzzi >Priority: Minor > Attachments: charset-support.patch, Charset.java, Email.java.patch > > > Add new class Charset the let the whole thing extensible and less error prone -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471436 ] Raul Acevedo commented on IO-113: - You mean keep it binary compatible? :) That works for me. Why does this class have a public constructor anyway? > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EMAIL-1) [email] setCharset() in Email does not set the charset for the message content
[ https://issues.apache.org/jira/browse/EMAIL-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon updated EMAIL-1: - Attachment: email-1.patch Here's a patch to address this. It includes a fix and tests for three scenarios: 1) setContent() with a text content type *without* any specific charset. If a charset has been previously set, it is automatically applied to the content type. (This fixes the actual issue.) 2) setContent() with a text content type *with* a specific charset. The content type charset will override any previously set charset and will change the Email's default charset to itself. (This is current behavior.) 3) setContent() with a non-text content type. Any charset already set in the message will be ignored, since we don't want to declare encodings for binary types. Besides, they'll either come with their own encodings or will be left to the underlying platform. (This is also current behavior, but this ensures that the fix for #1 doesn't inadvertently break other types of content. > [email] setCharset() in Email does not set the charset for the message content > -- > > Key: EMAIL-1 > URL: https://issues.apache.org/jira/browse/EMAIL-1 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0 > Environment: Operating System: other > Platform: Other >Reporter: James Mc Millan > Attachments: email-1.patch > > > Hello > More accurately, the charset is not used in buildMimeMessage() as it is not > part > of the contentType used when calling message.setContent(). Since > setContentType() updates the charset, I think it makes for setCharset() to > update the contentType? > James -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504988 - /jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/utils.c
Author: mturk
Date: Thu Feb 8 10:17:32 2007
New Revision: 504988
URL: http://svn.apache.org/viewvc?view=rev&rev=504988
Log:
Fix overrun bug. Thanks to Rohit S. Singh for spotting the bug, although I made
a fix different from his patch.
Modified:
jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/utils.c
Modified: jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/utils.c
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/utils.c?view=diff&rev=504988&r1=504987&r2=504988
==
--- jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/utils.c
(original)
+++ jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/utils.c Thu
Feb 8 10:17:32 2007
@@ -850,16 +850,17 @@
l = __apxGetMultiSzLengthW(szStr, &c);
b = rv = apxPoolCalloc(hPool, (l + c + 2) * sizeof(WCHAR));
-do {
+
+while (c > 0) {
if (*p)
*b++ = *p;
else {
*b++ = L'\r';
*b++ = L'\n';
+c--;
}
p++;
-} while( *p || *(p + 1));
-
+}
return rv;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504987 - /jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/javajni.c
Author: mturk
Date: Thu Feb 8 10:16:24 2007
New Revision: 504987
URL: http://svn.apache.org/viewvc?view=rev&rev=504987
Log:
Remove dependency of JNI 1.1 args. Java6 does not support that any more.
Modified:
jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/javajni.c
Modified:
jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/javajni.c
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/javajni.c?view=diff&rev=504987&r1=504986&r2=504987
==
--- jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/javajni.c
(original)
+++ jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/src/javajni.c Thu
Feb 8 10:16:24 2007
@@ -26,7 +26,11 @@
#endif
#ifdef JNI_VERSION_1_4
+#ifdef JNI_VERSION_1_6
+#define JNI_VERSION_DEFAULT JNI_VERSION_1_6
+#else
#define JNI_VERSION_DEFAULT JNI_VERSION_1_4
+#endif
#else
#define JNI_VERSION_DEFAULT JNI_VERSION_1_2
#endif
@@ -315,7 +319,6 @@
DWORD dwSs)
{
LPAPXJAVAVM lpJava;
-JDK1_1InitArgs vmArgs11;
JavaVMInitArgs vmArgs;
JavaVMOption*lpJvmOptions;
DWORD i, nOptions, sOptions = 2;
@@ -348,22 +351,7 @@
else {
CHAR iB[3][64];
LPSTR szCp;
-vmArgs11.version = JNI_VERSION_DEFAULT;
-if (DYNLOAD_FPTR(JNI_GetDefaultJavaVMInitArgs)(&vmArgs11) != JNI_OK) {
-/* fall back to version 1.2 */
-if (JNI_VERSION_DEFAULT != JNI_VERSION_1_2) {
-vmArgs11.version = JNI_VERSION_1_2;
-if (DYNLOAD_FPTR(JNI_GetDefaultJavaVMInitArgs)(&vmArgs11) !=
JNI_OK)
-return FALSE;
-}
-else
-return FALSE;
-}
-/* we need at least 1.2 JNI */
-if ((lpJava->iVersion = vmArgs11.version) < JNI_VERSION_1_2) {
-apxLogWrite(APXLOG_MARK_ERROR "Unsupported JNI version %d",
vmArgs11.version);
-return FALSE;
-}
+lpJava->iVersion = JNI_VERSION_DEFAULT;
if (dwMs)
++sOptions;
if (dwMx)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r504986 - in /jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps: apsvcmgr/apsvcmgr.h apsvcmgr/apsvcmgr.rc prunmgr/prunmgr.h prunmgr/prunmgr.rc prunsrv/prunsrv.h prunsrv/prunsr
Author: mturk Date: Thu Feb 8 10:15:01 2007 New Revision: 504986 URL: http://svn.apache.org/viewvc?view=rev&rev=504986 Log: Update version number to 2.0.2 because of Java6 missing JNI 1.1 arguments Modified: jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.h jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.rc jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.h jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.rc jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunsrv/prunsrv.h jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunsrv/prunsrv.rc Modified: jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.h URL: http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.h?view=diff&rev=504986&r1=504985&r2=504986 == --- jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.h (original) +++ jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.h Thu Feb 8 10:15:01 2007 @@ -15,7 +15,7 @@ */ #undef PRG_VERSION -#define PRG_VERSION"2.0.1.0" +#define PRG_VERSION"2.0.2.0" #define NUMTOOLBUTTONS 17 #define IDC_TOOLBAR 2000 Modified: jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.rc URL: http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.rc?view=diff&rev=504986&r1=504985&r2=504986 == --- jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.rc (original) +++ jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/apsvcmgr/apsvcmgr.rc Thu Feb 8 10:15:01 2007 @@ -248,9 +248,9 @@ STRINGTABLE BEGIN IDS_APPLICATION RSTR_ASM -IDS_APPVERSION "Version 1.0.0" +IDS_APPVERSION "Version 2.0.2" IDS_APPFULLNAME RSTR_ASM " Version " PRG_VERSION -IDS_APPCOPYRIGHT"Copyright © 2000-2003 The Apache Software Foundation" +IDS_APPCOPYRIGHT"Copyright © 2000-2007 The Apache Software Foundation" IDS_APPDESCRIPTION "Apache NT Service Management Tool" IDS_HSSTART RSTR_SCMATS "start the following service ..." IDS_HSSTOP RSTR_SCMATS "stop the following service ..." @@ -279,8 +279,8 @@ 1 VERSIONINFO - FILEVERSION 2,0,1,0 - PRODUCTVERSION 2,0,1,0 + FILEVERSION 2,0,2,0 + PRODUCTVERSION 2,0,2,0 FILEFLAGSMASK 0x3fL #if defined(_DEBUG) FILEFLAGS 0x03L @@ -300,7 +300,7 @@ VALUE "FileDescription", RSTR_ASM "\0" VALUE "FileVersion", PRG_VERSION VALUE "InternalName", RSTR_ASM "\0" - VALUE "LegalCopyright", "Copyright © 2000-2006 The Apache Software Foundation.\0" + VALUE "LegalCopyright", "Copyright © 2000-2007 The Apache Software Foundation.\0" VALUE "OriginalFilename", "apsvcmgr.exe\0" VALUE "ProductName", RSTR_ASM "\0" VALUE "ProductVersion", PRG_VERSION Modified: jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.h URL: http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.h?view=diff&rev=504986&r1=504985&r2=504986 == --- jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.h (original) +++ jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.h Thu Feb 8 10:15:01 2007 @@ -25,7 +25,7 @@ #define _PRUNMGR_H #undef PRG_VERSION -#define PRG_VERSION"2.0.1.0" +#define PRG_VERSION"2.0.2.0" #define PRG_REGROOT L"Apache Software Foundation\\Procrun 2.0" #define IDM_TM_EXIT 2000 Modified: jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.rc URL: http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.rc?view=diff&rev=504986&r1=504985&r2=504986 == --- jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.rc (original) +++ jakarta/commons/proper/daemon/trunk/src/native/nt/procrun/apps/prunmgr/prunmgr.rc Thu Feb 8 10:15:01 2007 @@ -227,9 +227,9 @@ STRINGTABLE BEGIN IDS_APPLICATION RSTR_PSM -IDS_APPVERSION "Version 1.0.0" +IDS_APPVERSION "Version 2.0.2" IDS_APPFULLNAME RSTR_PSM " Version " PRG_VERSION -IDS_APPCOPYRIGHT"Copyright © 2000-2004 The Apache Software Foundation" +IDS_APPCOPYRIGHT"Copyright © 2000-2007 The Apache Software Foundation" IDS_APPDESCRIPT
Re: [all] Status of components
On 2/8/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 2/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > Digester - ?? > > > > > > > > > Recently had a 1.8 release to clean up memory leaks and a few other > > bugs. > > > For a 1.x release it seems like you could call it stable. But the > > > architectural approach (including its dependence on the six year old > > > BeanUtils architecture) could certainly use a remodel. > > > > Do you have a suggestion/idea on what you would replace BeanUtils with? > > > I'm biased by my own experience, of course :-), but any implementation of an > expression language has to solve the same set of problems that BeanUtils > solves, plus a whole lot more. Coupled with the fact that the JSP/JSF > expression language APIs are being split out into a separate spec so you > could have implementations of it that have nothing to do with the web tier, > if I were building Digester today I would likely think about mapping the > property setter type rules to EL evaluations. I went "looking for el" today - had to first work out what spec versions were related. So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0. The independant EL Craig's talking about relates to Servlet 2.5 / JSP 2.1 and will feature in Tomcat 6 (currently beta). Unfortunately it seems that the Tomcat project has developed the independant EL for Tomcat 6 "in house" as part of their project - rather than building a new version of Commons EL here. This seems a shame - both from a Commons EL PoV since its now a legacy/dormant component and for the type of thing Craig is suggesting - using EL independantly of a servlet environment. I wonder if we could entice the Tomcat folks to do the development of EL here rather than in their repo - if they haven't already got commit access here (which I'm sure at least some have) - I'd be happy for them to have it. Anyone else think this has merit or should we just let EL lapse? I think it would indeed be useful ... but as usual in life there will be complications. The EL spec itself defines basic APIs like ELContext and ELResolver, plus some factory and configuration methods to glue them together and get instances. On top of that, JSF and JSP provide a whole pile of resolvers that provide the default functionality you need in that environment (for example, the gadget that makes managed bean creation happen) on top of it. From the viewpoint of the Tomcat folks, this might indeed be reasonable to keep in their own repository ... while perhaps moving the generic part here. In addition to Tomcat, I know that Facelets and MyFaces both have some stuff in this area, and Geronimo will eventually have to do something (although they'll probably start by inheriting from whatever JSF and JSP implementations they choose). Come to think of it, Shale's test framework has started implementing mocks for these classes so you can unit test JSF 1.2 based apps. But you have to build so much of the infrastructure to make this actually work that it's pretty close to implementing the generic part of the EL APIs. It'd be interesting to think about moving that part over so it can be shared. Niall Craig (Of course, because we're dealing with XML directly here, XPath expressions > might be another choice ... but they will be less familiar to Java > developers.) > > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (IO-113) FileUtils.readFileToString is not static
[ https://issues.apache.org/jira/browse/IO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened IO-113: -- We could keep the instance method and make it deprecated. That would keep it binary incompatible. > FileUtils.readFileToString is not static > > > Key: IO-113 > URL: https://issues.apache.org/jira/browse/IO-113 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.3 >Reporter: Raul Acevedo > Fix For: 1.4 > > > FileUtils.readFileToString isn't static. It should be; since the constructor > for FileUtils says "Instances should NOT be constructed in standard > programming", this makes readFileToString unusable. Right now I'm using > FileUtils.readBytesToByteArray(file).toString(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DAEMON-94) Don't support freebsd 6.x
[ https://issues.apache.org/jira/browse/DAEMON-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nemo Liu updated DAEMON-94: --- Attachment: config.log > Don't support freebsd 6.x > - > > Key: DAEMON-94 > URL: https://issues.apache.org/jira/browse/DAEMON-94 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: freebsd 6.0 release > freebsd 6.2 release >Reporter: Nemo Liu > Attachments: config.log > > > configure log > *** Current host *** > checking build system type... i386-unknown-freebsd6.2 > checking host system type... i386-unknown-freebsd6.2 > checking cached host system type... ok > *** C-Language compilation tools *** > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for ranlib... ranlib > *** Host support *** > checking C flags dependant on host system type... failed > configure: error: Unsupported operating system "freebsd6.2" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DAEMON-94) Don't support freebsd 6.x
Don't support freebsd 6.x - Key: DAEMON-94 URL: https://issues.apache.org/jira/browse/DAEMON-94 Project: Commons Daemon Issue Type: Bug Affects Versions: 1.0.1 Environment: freebsd 6.0 release freebsd 6.2 release Reporter: Nemo Liu configure log *** Current host *** checking build system type... i386-unknown-freebsd6.2 checking host system type... i386-unknown-freebsd6.2 checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Host support *** checking C flags dependant on host system type... failed configure: error: Unsupported operating system "freebsd6.2" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
If you could add that to the board report, me will be very happy ;) Mvgr, Martin Matt Benson wrote: > --- Henri Yandell <[EMAIL PROTECTED]> wrote: > >> I made a stab of defining the current status for >> Commons for the >> Jakarta board report: >> >> > http://wiki.apache.org/jakarta/JakartaBoardReport-current > [SNIP] > > JXPath seems to have been effectively abandoned, but > is overall quite stable. It is, IMHO, very close to > being ready for a 1.3 release (a couple of JIRA issues > still need attention). After 1.3 is released it can > likely languish in the "maintenance mode" that IIRC > was proposed by Niall on this thread. My intent is to > act as curator for this project. However all that > condenses into a summary status. ;) > > -Matt > > > > > > Bored stiff? Loosen up... > Download and play hundreds of games for free on Yahoo! Games. > http://games.yahoo.com/games/front > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 2/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > Digester - ?? > > > > > > Recently had a 1.8 release to clean up memory leaks and a few other > bugs. > > For a 1.x release it seems like you could call it stable. But the > > architectural approach (including its dependence on the six year old > > BeanUtils architecture) could certainly use a remodel. > > Do you have a suggestion/idea on what you would replace BeanUtils with? I'm biased by my own experience, of course :-), but any implementation of an expression language has to solve the same set of problems that BeanUtils solves, plus a whole lot more. Coupled with the fact that the JSP/JSF expression language APIs are being split out into a separate spec so you could have implementations of it that have nothing to do with the web tier, if I were building Digester today I would likely think about mapping the property setter type rules to EL evaluations. I went "looking for el" today - had to first work out what spec versions were related. So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0. The independant EL Craig's talking about relates to Servlet 2.5 / JSP 2.1 and will feature in Tomcat 6 (currently beta). Unfortunately it seems that the Tomcat project has developed the independant EL for Tomcat 6 "in house" as part of their project - rather than building a new version of Commons EL here. This seems a shame - both from a Commons EL PoV since its now a legacy/dormant component and for the type of thing Craig is suggesting - using EL independantly of a servlet environment. I wonder if we could entice the Tomcat folks to do the development of EL here rather than in their repo - if they haven't already got commit access here (which I'm sure at least some have) - I'd be happy for them to have it. Anyone else think this has merit or should we just let EL lapse? Niall (Of course, because we're dealing with XML directly here, XPath expressions might be another choice ... but they will be less familiar to Java developers.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Launcher project status
Hi Henri, first off thanks for getting back to me. Your comments particularly about shepherding are useful. Henri Yandell wrote: > ... We've not yet broached the subject of moving released components into dormancy, but I think the time has come. Discovery, Attributes, Launcher and Daemon all strike me as inactive and not something anyone has an itch to be supporting. Rather than pushing projects into Dormancy straight away, would it not be better to put out an official list of projects which are in need of maintainers and direction? This might give such projects a new chance of life if they are publicly acknowledged as being in danger of falling into dormancy. I'm thinking that Apache could run something similar to the Unmaintained Free Software Wiki: http://www.unmaintained-free-software.org/ Though I have not used Commons Daemon, it appears to also be a useful project addressing a need which only one other project I know of addresses, the Java Service Wrapper. Does anyone know whether the original developers are still active and/or contactable? I don't think any are active within Commons. I don't think Launcher is used in Tomcat anymore and that was its main area of use. > What is the best way to go about getting the feature requests and bug fixes I speak of addressed? Also If I were to manage to find the time to address the bug I speak of how would I go about getting the changes committed? It's essential to find a person on the mailing list who is active and is prepared to be your hands. If you have that, then you can pretty easily drive a component but if you're just getting silence then it's impossible and forking is your only choice. My suggested plan for that is: * Create issues in JIRA * Attach patches to issues in JIRA (beyond your own). Write unit tests and attach to JIRA. * Hassle the list at a point where a) you've got enough critical mass in JIRA to show you are serious, and b) you've expended your first burst of energy/time. Your goal here is to find someone who can shepherd your patches, offer advice and apply the commits. * Use the wiki to create a plan of what you think should go in the next release and what shouldn't (see: http://wiki.apache.org/jakarta-taglibs/Standard_1%2e1%2e3 ). * Repeat the above until commit access is granted. The person shepherding the patches is the one to nudge about when that time is right. If no one steps up to shepherd though - I'd either give up the ghost or fork the project depending on how tied you are to it. The general community view is that we'd love to see you getting involved and driving the project on, that we'd love it to be within Commons, and that we're hoping someone can find the time to shepherd. In many ways I find it hard to believe that Launcher isn't used more. Is there another more popular alternative that I am not aware of? Not that I know of. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] RCs and version numbers
Phil Steitz wrote on Wednesday, February 07, 2007 9:05 PM: [snip] > Could be this is the direction that we need to go for the > heavily reused > components. I cut an RC1 for [dbcp] a couple of weeks ago > and published > the RC1 snap to the snapshot repo so people could download > and test. I was > afraid to do what I would have liked to - make it a "public" > RC as we used > to do, announcing it on tomcat-user, Jakarta general, etc, > but I really > think that is the right way to go. Testing RCs is an important part of > getting to GA, IMHO and if it offends the gods to put RCs out > for general > consumption, then I think we need to move to the initial release, GA > labelling. I don't like the idea of having people download and test > *different* jars with the same names / artifact ids and I don't like > releasing components that have not been tested. > > The problem with the release-then-fix approach is it leads to lots of > dot-different release jars out in production use, some of > them potentially > bugged, and I don't see that as good in a mavenized world or > for heavily > reused libraries in general. It works OK for "top predators" > like Struts, > Tomcat, HTTPd, but could get dicey lower down in the food > chain, IMHO. I > could be cracked here - pls let me know if I am the only one > thinking this > way. > > I'm strongly in favour of 2). It's safer and it makes the release >> easier. The only negatives are: >> >> 1) There's a chance that someone might take a jar from the rc1/ >> directory in ~bayard and charge off to use it. So be it - that's >> there risk. >> >> 2) I don't like leaving svn in a state of having a release version, >> so I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the >> release. An alternative might be to branch 1.4 off for the release >> and have a 1.4-release branch for preparing the release on, but that >> a) still makes me uncomfortable to have a release version in and b) >> will be messy having one of those for every release. > > > If we have to do things this way, I would use a release > branch, but I still > don't yet see the compelling need to reverse history - i.e., > what problem > exactly are we needing to solve here? What exactly is illegal about > publishing release candidates and having people test them? We publish > nightlies now and the "RC" designation, which is clear and in > all of the > names, tells users that the artifacts are not yet official > releases. I am > not trying to be difficult here, just want to understand what > the issue is. +1 It should not be a problem to make a final release after a RC has passed the vote. If you don't trust your build tool to (re)create the same artifact now with the final revision number, it seems it is more a question of trusting that build tool ... :D - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Dennis, Dennis Lundberg wrote on Wednesday, February 07, 2007 9:39 PM: [snip] >>> I put together this document when I was trying to pull through the >>> whole groupId change last time: >>> >>>http://maven.apache.org/guides/mini/guide-relocation.html >>> >>> There is never a good time to change the groupId. My view is that we >>> should do it when we move to M2, both as a build tool and as the >>> target repository. >> >> Yes, I tried to use this description for a M1 -> M2 situation. In >> the end Carlos' advice was to ignore all the old versions and simply >> start with the new M2 releases also to use the new groupId and add >> for those releases only a relocation POM. > > That is a much easier way to do it. I'm starting to think > that this is > the way to go for Commons. Just change the groupId when we release > with M2 and don't relocate older versions. Yep. If we agree all on this, we can immediately start to use the new groupId. It's just, that the release & deploy process will not automatically create those relocation POMs. >> The problem with adjusting the old releases is, that the >> location for the relocation POMs is already occupied by the >> automatically generated POMs for M2 on the global M2 repo (see >> > http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/ > commons-logging/1.1/). >> And since they're already published, they cannot be changed anymore. > > I think you are allowed to add a relocation section to an already > published pom. I vaguely remember discussing this with Carlos back > then. Well, it seems, they become more strict since then. I got definitely a negative answer from him as to replace the old POMs from ibiblio with the ones including the relocation section available on a synchronized site. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
