[jira] Created: (VFS-161) Minimize using of LIST command in the FTP provider
Minimize using of LIST command in the FTP provider -- Key: VFS-161 URL: https://issues.apache.org/jira/browse/VFS-161 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.1 Reporter: Alex Crane Priority: Minor I have a big bis storage of files (about 10 TBytes). Path to file looks like /storage/storage1/node1/76423fds7g78df6gdf7hdfh/2384dg7sdfg8dfh.dat Existance checking and deleteing of files takes very long time because of LIST command: LIST /storage ... LIST /storage/storage1 ... LIST /storage/storage1/node1 LIST /storage/storage1/node1/76423fds7g78df6gdf7hdfh and so on. For example, there is no need to perform LIST command to delete file. I`m using FTPClients from commons.net and it works 1000x faster. -- 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: [IO] Move to a minimum of JDK 1.4?
My preference would be to support JDK1.3 and JDK1.5 versions, rather than JDK1.4. If desired, these calls can be implemented using reflection, so they work on JDK1.4 but not on JDK1.3. Stephen Niall Pemberton wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - 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]
[VOTE] Release commons-parent 3
Hi, I'd like to push out version 3 of the commons-parent project. The changes in maven-sources-plugin 2.0.3 allow to get rid of the maven-antrun hack and that's reason enough, IMO. I'd suggest to take revision 534137, change the version number in 3 and deploy that. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
On 5/18/07, Stephen Colebourne [EMAIL PROTECTED] wrote: My preference would be to support JDK1.3 and JDK1.5 versions, rather than JDK1.4. I do not understand your intention. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
+1 Niall On 5/18/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I'd like to push out version 3 of the commons-parent project. The changes in maven-sources-plugin 2.0.3 allow to get rid of the maven-antrun hack and that's reason enough, IMO. I'd suggest to take revision 534137, change the version number in 3 and deploy that. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons compress status?
On 18.05.2007, at 05:13, Bear Giles wrote: Thorbjørn Ravn Andersen wrote: I therefore suggest that the tar methods should be migrated to the vfs module (if suitable) and that the compress module should contain methods that can compress/uncompress streams (which is easily extendable to files, http connections etc). By doing so there will be a clear goal of this project. It looks like VFS has most of the concepts I was working on so it would be a waste of effort to do a parallel effort. I had skimmed the project earlier but only noticed the networked implementations. I agree that the 'compress' tar classes should be removed and a pointer left to the VFS project. Hm... seems like I disagree here. I want a simple library that deals with common compression and archive formats - tar - ar - cpio - gzip - bzip2 - zip VFS is a filesystem abstraction layer. It may use the library but should not provide the implementation IMO. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons compress status?
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: VFS is a filesystem abstraction layer. It may use the library but should not provide the implementation IMO. +1, compression is a rather important topic in itself. -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
Ehm... could we first sort out the repository question I brought up? ...and preferably also the related release process? We should also add the version numbers to the plugins. I'd say: let's work this out over the weekend and re-start the vote in a couple of days. cheers -- Torsten On 18.05.2007, at 09:46, Jochen Wiedmann wrote: Hi, I'd like to push out version 3 of the commons-parent project. The changes in maven-sources-plugin 2.0.3 allow to get rid of the maven-antrun hack and that's reason enough, IMO. I'd suggest to take revision 534137, change the version number in 3 and deploy that. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - 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-parent 3
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: Ehm... could we first sort out the repository question I brought up? ...and preferably also the related release process? We should also add the version numbers to the plugins. I'd say: let's work this out over the weekend and re-start the vote in a couple of days. I do think, that introducing a new deployment mechanism is a larger disruption than the changes made so far in 3-SNAPSHOT. In other words, I'd prefer to see this in a separate release. Apart from that, what prevents us from publishing version 3 now and a version 4, if the above questions are resolved? I do not understand this oh, just wait until I've got my favourite feature in whenever it comes to a release of the commons-parent. This thing doesn't need exhaustive QA or something like that, and it's not like we weren't able to manage 12 releases of it every year. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] parent pom repositories
On 5/17/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/17/07, Torsten Curdt [EMAIL PROTECTED] wrote:
So it should be
idrc/id
repositories
repository
idrc/id
urlhttp://people.apache.org/builds/commons/$
{project.name}/${project.version}/m2-staging-repository/url
snapshotsenabledfalse/enabled/snapshots
releasesenabledtrue/enabled/releases
/repository
/repositories
${project.name} is likely to be something like Commons Math not the
commons-math that would be more appropriate in a directory name. If
you can't find something suitable in the pom, you may want to
introduce an arbitrary property in each project's pom and use that in
the url. (I think $artifactId would only work for single-module
projects.)
How about using a property which defaults to $artifactId in the parent
pom - then only the multi-modules components need override it in their
main pom?
Niall
mvn stage:copy \
-Dsource=http://people.apache.org/builds/commons/$
{project.name}/${project.version}/m2-staging-repositoryg \
-Dtarget=scp://people.apache.org/www/people.apache.org/repo/
m2-ibiblio-rsync-repository \
-Dversion=${project.version}
Any chance to have the project name and version injected
automatically there?
Not afaik. You should know what you're promoting. :)
The latest release of the gpg plugin will prompt for a passphrase if
one is not supplied.
Great ...last time I tried it did not work for me (although it was
supposed to according to the docs)
Specify a version in the pom to make sure you're really using the
latest. Open a bug if it's not working... I gave up and just put the
passphrase in settings.xml. (You may not like being prompted-- I have
a feeling it's going to prompt more than once!)
Signing the release distributions... The gpg plugin will sign them if
you deploy them to the repository (attached assemblies). There's a
bit of renaming and copying to do that I haven't figured out how to
automate yet.
WDYM? ...seems like the signing worked just fine for the jci RC1.
Then you have to decide if you want the distributions
in the Maven repo.
WDYM? The usual artifacts? Sure!
No, the .zip and .tar.gz release distributions, the assemblies.
Not so sure what to do with the bin/src dists from the assembly though.
Right. :)
Take a look at the last section of my Archiva release page, under
'Release Distribution':
http://wiki.wsmoak.net/cgi-bin/wiki.pl?Archiva09Alpha2Release
The assemblies get deployed under their artifactIds, not the final
name that we want for the public distribution. Plus Maven's checksum
files aren't formatted correctly for md5sum -c.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-165) Simplify use of EstimationProblem
Simplify use of EstimationProblem
Key: MATH-165
URL: https://issues.apache.org/jira/browse/MATH-165
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
The use of the EstimationProblem interface could be simplified by providing a
helper (abstract) class that would implement
the getMeasurements getAllParameters and getUnboundParameters methods.
Currently, each new implementation of the interface has to do it even if they
are typically only called from the Estimator class (and not by the user code).
That same helper class could also take care of storing the partial derivatives.
A skeleton for the requested class could be as follows:
public abstract class SimpleEstimationProblem
implements EstimationProblem {
// ... storage for measurements and partial derivatives ...
protected void addParameter(EstimatedParameter p,
ComputableFunction partial,
boolean isBound) {
// ...
}
protected void addParameter(EstimatedParameter p,
ComputableFunction partial) {
addParameter(p, partial, false);
}
protected double getPartial(EstimatedParameter p,
double x) {
// ...
}
protected void addMeasurement(WeightedMeasurement m) {
_observations.add(m);
}
public WeightedMeasurement[] getMeasurements() {
// ...
}
public EstimatedParameter[] getAllParameters() {
// ...
}
public EstimatedParameter[] getUnboundParameters() {
// ...
}
}
Best,
Gilles
--
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: [VOTE] Release commons-parent 3
On 18.05.2007, at 10:44, Jochen Wiedmann wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: Ehm... could we first sort out the repository question I brought up? ...and preferably also the related release process? We should also add the version numbers to the plugins. I'd say: let's work this out over the weekend and re-start the vote in a couple of days. I do think, that introducing a new deployment mechanism is a larger disruption than the changes made so far in 3-SNAPSHOT. In other words, I'd prefer to see this in a separate release. Apart from that, what prevents us from publishing version 3 now and a version 4, if the above questions are resolved? I do not understand this oh, just wait until I've got my favourite feature in whenever it comes to a release of the commons-parent. This thing doesn't need exhaustive QA or something like that, and it's not like we weren't able to manage 12 releases of it every year. I am with you on the release often ...but I on the other hand fixating the plugin versions and a working release setup is a bit of blocker for me ATM. So if you want to release now - fine. But I'd like to have another release that fixes those things ASAP anyway. So I was just wondering whether waiting a few more days would make such a big difference. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LAUNCHER-7) Use entities for and in javadoc comments
[ https://issues.apache.org/jira/browse/LAUNCHER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LAUNCHER-7. Resolution: Fixed Fix Version/s: 1.2 Assignee: Niall Pemberton Use entities for and in javadoc comments Key: LAUNCHER-7 URL: https://issues.apache.org/jira/browse/LAUNCHER-7 Project: Commons Launcher Issue Type: Bug Affects Versions: 1.1 Environment: Gentoo Linux [EMAIL PROTECTED] ~ $ java -version java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode) Reporter: Petteri Räty Assigned To: Niall Pemberton Fix For: 1.2 Attachments: javadoc.patch javadoc: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.commons.launcher... [javadoc] Loading source files for package org.apache.commons.launcher.types... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.5.0_11 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] java.util.MissingResourceException: Can't find resource for bundle com.sun.tools.doclets.formats.html.resources.standard, key doclet.malformed_html_link_tag [javadoc] at java.util.ResourceBundle.getObject(ResourceBundle.java:325) [javadoc] at java.util.ResourceBundle.getString(ResourceBundle.java:285) [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:114) [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:92) [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:81) [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.warning(MessageRetriever.java:290) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.redirectRelativeLinks(HtmlDocletWriter.java:1526) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.commentTagsToString(HtmlDocletWriter.java:1438) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:126) [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:91) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [javadoc] at java.lang.reflect.Method.invoke(Method.java:585) [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:128) [javadoc] at com.sun.tools.javadoc.Main.execute(Main.java:41) [javadoc] at com.sun.tools.javadoc.Main.main(Main.java:31) This is a bug in Sun javadoc: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082928 But any way it would be better to use entitites. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [IO] Move to a minimum of JDK 1.4?
On 5/18/07, Stephen Colebourne [EMAIL PROTECTED] wrote: My preference would be to support JDK1.3 and JDK1.5 versions, rather than JDK1.4. When you say support do you mean two active versions under development or the moving the main development to JDK 1.5 with a JDK 1.3 branch mainly for bug fixes? I don't have a problem with moving to JDK 1.5 - but are you talking evolutionary or revolutionaty (i.e. binary incompatible, package name change etc.) here? Like Jochen IMO it would be better if you expand on your intention. If desired, these calls can be implemented using reflection, so they work on JDK1.4 but not on JDK1.3. They could, but Its not something I'd be interested in doing. Niall Stephen Niall Pemberton wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539349 - in /jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types: ArgumentSet.java ConditionalArgument.java
Author: niallp Date: Fri May 18 02:47:21 2007 New Revision: 539349 URL: http://svn.apache.org/viewvc?view=revrev=539349 Log: Fix for LAUNCHER-7 - Use entities for and in javadoc comments - thanks to Petteri Räty for the patch Modified: jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ArgumentSet.java jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ConditionalArgument.java Modified: jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ArgumentSet.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ArgumentSet.java?view=diffrev=539349r1=539348r2=539349 == --- jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ArgumentSet.java (original) +++ jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ArgumentSet.java Fri May 18 02:47:21 2007 @@ -19,7 +19,7 @@ /** - * A class that represents a set of nested arg elements. + * A class that represents a set of nested lt;arggt; elements. * * @author Patrick Luby */ Modified: jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ConditionalArgument.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ConditionalArgument.java?view=diffrev=539349r1=539348r2=539349 == --- jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ConditionalArgument.java (original) +++ jakarta/commons/proper/launcher/trunk/src/java/org/apache/commons/launcher/types/ConditionalArgument.java Fri May 18 02:47:21 2007 @@ -25,7 +25,7 @@ import org.apache.tools.ant.types.Path; /** - * A class that represents nested arg or jvmarg elements. This class + * A class that represents nested lt;arggt; or lt;jvmarggt; elements. This class * provides the same functionality as the class that represents these same * elements in a java task. In addition, this class supports conditional if * and unless attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutils] commons collection classes
G... why oh why are commmons collection classes inside beanutils?! @[EMAIL PROTECTED]@ -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: G... why oh why are commmons collection classes inside beanutils?! http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Niall @[EMAIL PROTECTED]@ -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
The real question is why didn't we change the package names so as to not collide with the real classes if you have them in your classpath also. I realize that it was required by the public API, but I think having people change an import statement here and there would be accepted more readily than having them chase down a classloading issue where they're using the Buffer impl in the beanutils jar rather than collections jar. On 5/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: G... why oh why are commmons collection classes inside beanutils?! http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Niall @[EMAIL PROTECTED]@ -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
Yepp! We should change the package name and push out a new release. cheers -- Torsten On 18.05.2007, at 13:10, James Carman wrote: The real question is why didn't we change the package names so as to not collide with the real classes if you have them in your classpath also. I realize that it was required by the public API, but I think having people change an import statement here and there would be accepted more readily than having them chase down a classloading issue where they're using the Buffer impl in the beanutils jar rather than collections jar. On 5/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: G... why oh why are commmons collection classes inside beanutils?! http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Niall @[EMAIL PROTECTED]@ -- Torsten - 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: [beanutils] commons collection classes
I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. Niall On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: Yepp! We should change the package name and push out a new release. cheers -- Torsten On 18.05.2007, at 13:10, James Carman wrote: The real question is why didn't we change the package names so as to not collide with the real classes if you have them in your classpath also. I realize that it was required by the public API, but I think having people change an import statement here and there would be accepted more readily than having them chase down a classloading issue where they're using the Buffer impl in the beanutils jar rather than collections jar. On 5/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: G... why oh why are commmons collection classes inside beanutils?! http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Niall @[EMAIL PROTECTED]@ -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539441 - in /jakarta/commons/proper/httpclient/trunk: release_notes.txt src/java/org/apache/commons/httpclient/HttpMethodBase.java
Author: oglueck Date: Fri May 18 05:56:55 2007 New Revision: 539441 URL: http://svn.apache.org/viewvc?view=revrev=539441 Log: Improved API Doc regarding response buffering. PR: HTTPCLIENT-651 Contributed by: Ortwin Glück Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/release_notes.txt?view=diffrev=539441r1=539440r2=539441 == --- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original) +++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Fri May 18 05:56:55 2007 @@ -1,5 +1,8 @@ Changes since 3.1 RC 1 +* [HTTPCLIENT-651] - Improved API Doc regarding response buffering. + Contributed by Ortwin Glück oglueck at apache.org + * [HTTPCLIENT-645] - Cookie#compare() changed to do a simple case-sensitive string comparison when comparing path attributes instead of using a static instance of RuleBasedCollator Contributed by Oleg Kalnichevski olegk at apache.org Modified: jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java?view=diffrev=539441r1=539440r2=539441 == --- jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java (original) +++ jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java Fri May 18 05:56:55 2007 @@ -655,7 +655,9 @@ /** * Returns the response body of the HTTP method, if any, as an array of bytes. - * If response body is not available or cannot be read, returns ttnull/tt + * If response body is not available or cannot be read, returns ttnull/tt. + * Buffers the response and this method can be called several times yielding + * the same result each time. * * Note: This will cause the entire response body to be buffered in memory. A * malicious server may easily exhaust all the VM memory. It is strongly @@ -698,7 +700,9 @@ /** * Returns the response body of the HTTP method, if any, as an array of bytes. - * If response body is not available or cannot be read, returns ttnull/tt + * If response body is not available or cannot be read, returns ttnull/tt. + * Buffers the response and this method can be called several times yielding + * the same result each time. * * Note: This will cause the entire response body to be buffered in memory. This method is * safe if the content length of the response is unknown, because the amount of memory used @@ -755,7 +759,9 @@ /** * Returns the response body of the HTTP method, if any, as an [EMAIL PROTECTED] InputStream}. - * If response body is not available, returns ttnull/tt + * If response body is not available, returns ttnull/tt. If the response has been + * buffered this method returns a new stream object on every call. If the response + * has not been buffered the returned stream can only be read once. * * @return The response body or codenull/code. * @@ -778,7 +784,8 @@ * Returns the response body of the HTTP method, if any, as a [EMAIL PROTECTED] String}. * If response body is not available or cannot be read, returns ttnull/tt * The string conversion on the data is done using the character encoding specified - * in ttContent-Type/tt header. + * in ttContent-Type/tt header. Buffers the response and this method can be + * called several times yielding the same result each time. * * Note: This will cause the entire response body to be buffered in memory. A * malicious server may easily exhaust all the VM memory. It is strongly @@ -806,7 +813,8 @@ * Returns the response body of the HTTP method, if any, as a [EMAIL PROTECTED] String}. * If response body is not available or cannot be read, returns ttnull/tt * The string conversion on the data is done using the character encoding specified - * in ttContent-Type/tt header.p + * in ttContent-Type/tt header. Buffers the response and this method can be + * called several times yielding the same result each time./p * * Note: This will cause the entire response body to be buffered in memory. This method is * safe if the content length of the response is unknown, because the amount of memory used - To unsubscribe, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-278) Remove copied Collections classes
[ https://issues.apache.org/jira/browse/BEANUTILS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-278: -- Attachment: Beanutils-278.patch Attaching patch which shows impact of removing FastHashMap from BeanUtils. Not necessarily proposing that this change be applied - but its a good indicator of the impact Remove copied Collections classes - Key: BEANUTILS-278 URL: https://issues.apache.org/jira/browse/BEANUTILS-278 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Niall Pemberton Attachments: Beanutils-278.patch The following 4 Commons Collections classes were copied into BeanUtils so that the dependency on Commons Collections could be removed (these were included in the BeanUtils 1.7.0 release) ArrayStack.java Buffer.java BufferUnderflowException.java FastHashMap.java See the following thread for the original reasoning: http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Recent discussion thread on this issue is here: http://tinyurl.com/2vyuk8 Of the above four classes only FastHashMap is used within BeanUtils (and is part of the public API) - not sure why the other classes were included, but it may be because downstream systems such as Struts depend on them (which also removed its Commons Collections when it moved to BeanUtils 1.7.0). Some (but not all) of the BeanUtils public API which exposes FastHashMap was deprecated in the BeanUtils 1.7.0 release. -- 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: (BEANUTILS-278) Remove copied Collections classes
Remove copied Collections classes - Key: BEANUTILS-278 URL: https://issues.apache.org/jira/browse/BEANUTILS-278 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Niall Pemberton The following 4 Commons Collections classes were copied into BeanUtils so that the dependency on Commons Collections could be removed (these were included in the BeanUtils 1.7.0 release) ArrayStack.java Buffer.java BufferUnderflowException.java FastHashMap.java See the following thread for the original reasoning: http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Recent discussion thread on this issue is here: http://tinyurl.com/2vyuk8 Of the above four classes only FastHashMap is used within BeanUtils (and is part of the public API) - not sure why the other classes were included, but it may be because downstream systems such as Struts depend on them (which also removed its Commons Collections when it moved to BeanUtils 1.7.0). Some (but not all) of the BeanUtils public API which exposes FastHashMap was deprecated in the BeanUtils 1.7.0 release. -- 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: (JXPATH-84) reserved word enum is used
[
https://issues.apache.org/jira/browse/JXPATH-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
peter snowdon updated JXPATH-84:
Attachment: XPathParser.java
I changes it to enumerator. Not original.
reserved word enum is used
--
Key: JXPATH-84
URL: https://issues.apache.org/jira/browse/JXPATH-84
Project: Commons JXPath
Issue Type: Bug
Reporter: peter snowdon
Priority: Minor
Attachments: XPathParser.java
line 3671 in XPathParser uses enum:
for (java.util.Enumeration enum = jj_expentries.elements();
enum.hasMoreElements();) {
which fails under java5.
--
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: (JXPATH-84) reserved word enum is used
reserved word enum is used
--
Key: JXPATH-84
URL: https://issues.apache.org/jira/browse/JXPATH-84
Project: Commons JXPath
Issue Type: Bug
Reporter: peter snowdon
Priority: Minor
line 3671 in XPathParser uses enum:
for (java.util.Enumeration enum = jj_expentries.elements();
enum.hasMoreElements();) {
which fails under java5.
--
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: r539475 - in /jakarta/commons/proper/beanutils/trunk/optional/bean-collections: build.xml project.xml
Author: niallp
Date: Fri May 18 07:08:48 2007
New Revision: 539475
URL: http://svn.apache.org/viewvc?view=revrev=539475
Log:
Fix version numbers and build
Modified:
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/build.xml
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/project.xml
Modified:
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/optional/bean-collections/build.xml?view=diffrev=539475r1=539474r2=539475
==
--- jakarta/commons/proper/beanutils/trunk/optional/bean-collections/build.xml
(original)
+++ jakarta/commons/proper/beanutils/trunk/optional/bean-collections/build.xml
Fri May 18 07:08:48 2007
@@ -49,10 +49,10 @@
!-- == Derived Values --
!-- The pathname of the collections classes JAR file --
- property name=commons-collections.jar
value=${commons-collections.home}/commons-collections-3.0-dev.jar/
+ property name=commons-collections.jar
value=${commons-collections.home}/commons-collections-3.2.jar/
!-- The pathname of the collections testframework classes JAR file --
- property name=commons-collections-testframework.jar
value=${commons-collections.home}/commons-collections-testframework-3.0-dev.jar/
+ property name=commons-collections-testframework.jar
value=${commons-collections.home}/commons-collections-testframework-3.2.jar/
!-- The pathname of the logging classes JAR file --
@@ -75,7 +75,7 @@
property name=component.title value=Bean Utilities Bean
Collections/
!-- The current version number of this component --
- property name=component.version value=1.7.1-dev/
+ property name=component.version value=1.8.0-SNAPSHOT/
!-- The base directory for compilation targets --
property name=build.home value=target/
@@ -235,9 +235,11 @@
jarjarfile=${dist.home}/commons-beanutils-bean-collections.jar
basedir=${build.home}/classes
manifest=${build.home}/conf/MANIFEST.MF/
+!--
jarjarfile=../../dist/commons-beanutils.jar
basedir=${build.home}/classes
update='true'/
+--
/target
Modified:
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/optional/bean-collections/project.xml?view=diffrev=539475r1=539474r2=539475
==
---
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/project.xml
(original)
+++
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/project.xml
Fri May 18 07:08:48 2007
@@ -20,7 +20,7 @@
pomVersion3/pomVersion
artifactIdcommons-beanutils-bean-collections/artifactId
nameBeanUtils Bean Collections/name
- currentVersion1.7.1-SNAPSHOT/currentVersion
+ currentVersion1.8.0-SNAPSHOT/currentVersion
inceptionYear2000/inceptionYear
shortDescriptionCommons BeanUtils Bean Collections/shortDescription
descriptionExtensions of commons collections focussing on collections of
beans/description
@@ -31,23 +31,23 @@
dependency
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
- version1.0.3/version
+ version1.0.4/version
/dependency
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
- version3.0/version
+ version3.2/version
/dependency
dependency
groupIdcommons-beanutils/groupId
artifactIdcommons-beanutils/artifactId
- version1.6/version
+ version1.8.0-SNAPSHOT/version
/dependency
!-- Test Only --
dependency
artifactIdcommons-collections-testframework/artifactId
groupIdcommons-collections/groupId
- versionSNAPSHOT/version
+ version3.2/version
properties
scopetest/scope
/properties
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. I've created a Jira ticket for this and attached a patch which shows where the copied classes are used - its actually only FastHashMap. Some changes have zero impact, so I'll apply those parts. Then its a case of deciding what to do - IMO we should just delete the 3 unused classes. FastHashMap could either be removed or re-packaged. When I have time I'll have a look at the impact on Struts - since I think thats probably the reason for the 3 unused classes. Forgot the link to the Jira ticket: https://issues.apache.org/jira/browse/BEANUTILS-278 Niall cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. I've created a Jira ticket for this and attached a patch which shows where the copied classes are used - its actually only FastHashMap. Some changes have zero impact, so I'll apply those parts. Then its a case of deciding what to do - IMO we should just delete the 3 unused classes. FastHashMap could either be removed or re-packaged. When I have time I'll have a look at the impact on Struts - since I think thats probably the reason for the 3 unused classes. Niall cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JXPATH-84) reserved word enum is used
[
https://issues.apache.org/jira/browse/JXPATH-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-84.
---
Resolution: Fixed
Fix Version/s: 1.3
This was fixed in http://svn.apache.org/viewvc?view=revrevision=374128 .
reserved word enum is used
--
Key: JXPATH-84
URL: https://issues.apache.org/jira/browse/JXPATH-84
Project: Commons JXPath
Issue Type: Bug
Reporter: peter snowdon
Priority: Minor
Fix For: 1.3
Attachments: XPathParser.java
line 3671 in XPathParser uses enum:
for (java.util.Enumeration enum = jj_expentries.elements();
enum.hasMoreElements();) {
which fails under java5.
--
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-92) Add DeferredPeriodicOutputStream
[ https://issues.apache.org/jira/browse/IO-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Mazzucco updated IO-92: --- Attachment: DeferredPeriodicOutputStreamTest.java DeferredPeriodicOutputStream.java I've updated the class because of a bug which happens when one tries to write a chunk of data (altogether) which is bigger than the threshold. In this case the temporary arrays grows, while it shouldn't. I've fixed the problem by overriding the write(byte[] b) and write(byte[] b, int off, int len) methods. p.s. I've implemented also a version which uses a ByteBuffer attached to a FileChannel, but I've found out that it generally performs worst. Add DeferredPeriodicOutputStream Key: IO-92 URL: https://issues.apache.org/jira/browse/IO-92 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Environment: Windows XP SP2, jdk 1.5 Reporter: Michele Mazzucco Fix For: 1.4 Attachments: DeferredPeriodicOutputStream.java, DeferredPeriodicOutputStream.java, DeferredPeriodicOutputStream.java, DeferredPeriodicOutputStreamTest.java, DeferredPeriodicOutputStreamTest.java, DeferredPeriodicOutputStreamTest.java I've extended the ThresholdingOutputStream class with a new class which behaves different from DeferredFileOutputStream: - when the stream is closed, the content stored in memory is *always* flushed to disk (in DeferredFileOutputStream, instead, if the treshold is not reached data is lost) - DeferredFileOutputStream maintains data in memory only until the treshold value has been reached, then it immediately writes every byte to disk. This new implementation, instead, caches treshold bytes in memory, and every time that value is reached (that is, treshold, 2 * threshold, etc), it flushes data to disk. In other words it acts as a cache. - It implements the java.io.DataOutput interface, that is, it provides utility methods to write all primitive types (e.g. short, byte, char, int, float, long, double and String in different formats) -- 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: r539508 - in /jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils: DynaBeanUtilsTestCase.java converters/ClassConverterTestCase.java
Author: niallp
Date: Fri May 18 08:57:59 2007
New Revision: 539508
URL: http://svn.apache.org/viewvc?view=revrev=539508
Log:
Fix m2 problems
Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaBeanUtilsTestCase.java
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/ClassConverterTestCase.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaBeanUtilsTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaBeanUtilsTestCase.java?view=diffrev=539508r1=539507r2=539508
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaBeanUtilsTestCase.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaBeanUtilsTestCase.java
Fri May 18 08:57:59 2007
@@ -106,6 +106,8 @@
*/
public void setUp() throws Exception {
+ConvertUtils.deregister();
+
// Instantiate a new DynaBean instance
DynaClass dynaClass = createDynaClass();
bean = dynaClass.newInstance();
Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/ClassConverterTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/ClassConverterTestCase.java?view=diffrev=539508r1=539507r2=539508
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/ClassConverterTestCase.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/ClassConverterTestCase.java
Fri May 18 08:57:59 2007
@@ -128,8 +128,9 @@
// Test Array Class to String
assertEquals(Array to String, [Ljava.lang.Boolean;,
converter.convert(String.class, Boolean[].class));
+// *** N.B. for some reason the following works on m1, but not m2
// Test String to Array Class
-assertEquals(String to Array, Boolean[].class,
converter.convert(Class.class, [Ljava.lang.Boolean;));
+// assertEquals(String to Array, Boolean[].class,
converter.convert(Class.class, [Ljava.lang.Boolean;));
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
No votes yet, so I wanted to ask what your thoughts were on including: http://issues.apache.org/jira/browse/IO-117 in 1.3.2? Hen On 5/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have fixed the issues with the file permissions and added license headers to most of the files, with the only exception of MANIFEST.MF. Now, I'd like to call for another vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - 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]
[jira] Commented: (MATH-165) Simplify use of EstimationProblem
[
https://issues.apache.org/jira/browse/MATH-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496925
]
Luc Maisonobe commented on MATH-165:
This seems a great idea to me. It could be easily implemented for 1.2 we are
going to release.
Simplify use of EstimationProblem
Key: MATH-165
URL: https://issues.apache.org/jira/browse/MATH-165
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assigned To: Luc Maisonobe
Priority: Minor
The use of the EstimationProblem interface could be simplified by providing
a helper (abstract) class that would implement
the getMeasurements getAllParameters and getUnboundParameters methods.
Currently, each new implementation of the interface has to do it even if they
are typically only called from the Estimator class (and not by the user
code).
That same helper class could also take care of storing the partial
derivatives.
A skeleton for the requested class could be as follows:
public abstract class SimpleEstimationProblem
implements EstimationProblem {
// ... storage for measurements and partial derivatives ...
protected void addParameter(EstimatedParameter p,
ComputableFunction partial,
boolean isBound) {
// ...
}
protected void addParameter(EstimatedParameter p,
ComputableFunction partial) {
addParameter(p, partial, false);
}
protected double getPartial(EstimatedParameter p,
double x) {
// ...
}
protected void addMeasurement(WeightedMeasurement m) {
_observations.add(m);
}
public WeightedMeasurement[] getMeasurements() {
// ...
}
public EstimatedParameter[] getAllParameters() {
// ...
}
public EstimatedParameter[] getUnboundParameters() {
// ...
}
}
Best,
Gilles
--
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: (MATH-165) Simplify use of EstimationProblem
[
https://issues.apache.org/jira/browse/MATH-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe updated MATH-165:
---
Fix Version/s: 1.2
Simplify use of EstimationProblem
Key: MATH-165
URL: https://issues.apache.org/jira/browse/MATH-165
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assigned To: Luc Maisonobe
Priority: Minor
Fix For: 1.2
The use of the EstimationProblem interface could be simplified by providing
a helper (abstract) class that would implement
the getMeasurements getAllParameters and getUnboundParameters methods.
Currently, each new implementation of the interface has to do it even if they
are typically only called from the Estimator class (and not by the user
code).
That same helper class could also take care of storing the partial
derivatives.
A skeleton for the requested class could be as follows:
public abstract class SimpleEstimationProblem
implements EstimationProblem {
// ... storage for measurements and partial derivatives ...
protected void addParameter(EstimatedParameter p,
ComputableFunction partial,
boolean isBound) {
// ...
}
protected void addParameter(EstimatedParameter p,
ComputableFunction partial) {
addParameter(p, partial, false);
}
protected double getPartial(EstimatedParameter p,
double x) {
// ...
}
protected void addMeasurement(WeightedMeasurement m) {
_observations.add(m);
}
public WeightedMeasurement[] getMeasurements() {
// ...
}
public EstimatedParameter[] getAllParameters() {
// ...
}
public EstimatedParameter[] getUnboundParameters() {
// ...
}
}
Best,
Gilles
--
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: (BEANUTILS-278) Remove copied Collections classes
[ https://issues.apache.org/jira/browse/BEANUTILS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496930 ] Niall Pemberton commented on BEANUTILS-278: --- Commons Digester needs the ArrayStack class (which uses Buffer and BufferUnderflowException) - Struts 1.3 doesn't appear to need any of the classes - except thru' its dependency on Digester Remove copied Collections classes - Key: BEANUTILS-278 URL: https://issues.apache.org/jira/browse/BEANUTILS-278 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Niall Pemberton Attachments: Beanutils-278.patch The following 4 Commons Collections classes were copied into BeanUtils so that the dependency on Commons Collections could be removed (these were included in the BeanUtils 1.7.0 release) ArrayStack.java Buffer.java BufferUnderflowException.java FastHashMap.java See the following thread for the original reasoning: http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Recent discussion thread on this issue is here: http://tinyurl.com/2vyuk8 Of the above four classes only FastHashMap is used within BeanUtils (and is part of the public API) - not sure why the other classes were included, but it may be because downstream systems such as Struts depend on them (which also removed its Commons Collections when it moved to BeanUtils 1.7.0). Some (but not all) of the BeanUtils public API which exposes FastHashMap was deprecated in the BeanUtils 1.7.0 release. -- 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: [beanutils] commons collection classes
Leaving this like it is breaks commons-collections, potentially, though. If beanutils is in the classpath before commons collections (alphabetically it is, so that is the likely scenario), you'll get the beanutils flavor of those classes. Not a good idea. On 5/18/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Torsten Curdt wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. Whilst it may have frustrated you recently, the current situation really isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on [collections] in a simple manner. The copy was permitted as there were few classes involved, and they were very stable. Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. In summary, I am currently -1 to any change here, except possibly producing a commons-beanutils-without-collections.jar file, perhaps as a 1.7.1. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-278) Remove copied Collections classes
[ https://issues.apache.org/jira/browse/BEANUTILS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-278: -- Attachment: (was: Beanutils-278.patch) Remove copied Collections classes - Key: BEANUTILS-278 URL: https://issues.apache.org/jira/browse/BEANUTILS-278 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Niall Pemberton Attachments: Beanutils-278-2.patch The following 4 Commons Collections classes were copied into BeanUtils so that the dependency on Commons Collections could be removed (these were included in the BeanUtils 1.7.0 release) ArrayStack.java Buffer.java BufferUnderflowException.java FastHashMap.java See the following thread for the original reasoning: http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Recent discussion thread on this issue is here: http://tinyurl.com/2vyuk8 Of the above four classes only FastHashMap is used within BeanUtils (and is part of the public API) - not sure why the other classes were included, but it may be because downstream systems such as Struts depend on them (which also removed its Commons Collections when it moved to BeanUtils 1.7.0). Some (but not all) of the BeanUtils public API which exposes FastHashMap was deprecated in the BeanUtils 1.7.0 release. -- 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: (BEANUTILS-278) Remove copied Collections classes
[ https://issues.apache.org/jira/browse/BEANUTILS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-278: -- Attachment: Beanutils-278-2.patch I removed the references to FastHashMap that have no impact on the API (and almost no performance impact IMO) - so that its easier to see where the issue(s) lie Remove copied Collections classes - Key: BEANUTILS-278 URL: https://issues.apache.org/jira/browse/BEANUTILS-278 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Niall Pemberton Attachments: Beanutils-278-2.patch The following 4 Commons Collections classes were copied into BeanUtils so that the dependency on Commons Collections could be removed (these were included in the BeanUtils 1.7.0 release) ArrayStack.java Buffer.java BufferUnderflowException.java FastHashMap.java See the following thread for the original reasoning: http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Recent discussion thread on this issue is here: http://tinyurl.com/2vyuk8 Of the above four classes only FastHashMap is used within BeanUtils (and is part of the public API) - not sure why the other classes were included, but it may be because downstream systems such as Struts depend on them (which also removed its Commons Collections when it moved to BeanUtils 1.7.0). Some (but not all) of the BeanUtils public API which exposes FastHashMap was deprecated in the BeanUtils 1.7.0 release. -- 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: (BEANUTILS-278) Remove copied Collections classes
[ https://issues.apache.org/jira/browse/BEANUTILS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496945 ] Niall Pemberton commented on BEANUTILS-278: --- Struts 1.2 still has a dependency on FastHashMap - used for the dataSources Map in ActionServlet Remove copied Collections classes - Key: BEANUTILS-278 URL: https://issues.apache.org/jira/browse/BEANUTILS-278 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Niall Pemberton Attachments: Beanutils-278.patch The following 4 Commons Collections classes were copied into BeanUtils so that the dependency on Commons Collections could be removed (these were included in the BeanUtils 1.7.0 release) ArrayStack.java Buffer.java BufferUnderflowException.java FastHashMap.java See the following thread for the original reasoning: http://tinyurl.com/yvma2q http://tinyurl.com/2hs3hp Recent discussion thread on this issue is here: http://tinyurl.com/2vyuk8 Of the above four classes only FastHashMap is used within BeanUtils (and is part of the public API) - not sure why the other classes were included, but it may be because downstream systems such as Struts depend on them (which also removed its Commons Collections when it moved to BeanUtils 1.7.0). Some (but not all) of the BeanUtils public API which exposes FastHashMap was deprecated in the BeanUtils 1.7.0 release. -- 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: [beanutils] commons collection classes
Torsten Curdt wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. Whilst it may have frustrated you recently, the current situation really isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on [collections] in a simple manner. The copy was permitted as there were few classes involved, and they were very stable. Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. In summary, I am currently -1 to any change here, except possibly producing a commons-beanutils-without-collections.jar file, perhaps as a 1.7.1. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. Needs to be fixed in Digester too/first: http://issues.apache.org/jira/browse/DIGESTER-115 Niall cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DIGESTER-115) Digester depends on BeanUtils copies of Collections classes
Digester depends on BeanUtils copies of Collections classes --- Key: DIGESTER-115 URL: https://issues.apache.org/jira/browse/DIGESTER-115 Project: Commons Digester Issue Type: Bug Affects Versions: 1.8 Reporter: Niall Pemberton This is related to issue# BEANUTILS-278 Digester uses 3 classes (ArrayStack, Buffer and BufferUnderflowException) from commons BeanUtils which were copied from Commons Collections and BEANUTILS-278 proposes removing them. ArrayStack.java Buffer.java BufferUnderflowException.java -- 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: r539519 - in /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils: BeanUtils.java ConvertUtilsBean.java WrapDynaClass.java
Author: niallp
Date: Fri May 18 09:50:40 2007
New Revision: 539519
URL: http://svn.apache.org/viewvc?view=revrev=539519
Log:
BEANUTILS-278 Remove references to FastHashMap that have no impact on the API
(and very little performance impact)
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtils.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/WrapDynaClass.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtils.java?view=diffrev=539519r1=539518r2=539519
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtils.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/BeanUtils.java
Fri May 18 09:50:40 2007
@@ -21,7 +21,6 @@
import java.lang.reflect.InvocationTargetException;
import java.util.Map;
-import org.apache.commons.collections.FastHashMap;
/**
@@ -45,15 +44,6 @@
// -- Private Variables
-
-/**
- * Dummy collection from the Commons Collections API, to force a
- * ClassNotFoundException if commons-collections.jar is not present in the
- * runtime classpath, and this class is the first one referenced.
- * Otherwise, the ClassNotFoundException thrown by ConvertUtils or
- * PropertyUtils can get masked.
- */
-private static final FastHashMap dummy = new FastHashMap();
/**
* The debugging detail level for this component.
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java?view=diffrev=539519r1=539518r2=539519
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Fri May 18 09:50:40 2007
@@ -27,6 +27,9 @@
import java.sql.Date;
import java.sql.Time;
import java.sql.Timestamp;
+import java.util.Collections;
+import java.util.Map;
+import java.util.HashMap;
import org.apache.commons.beanutils.converters.BigDecimalConverter;
import org.apache.commons.beanutils.converters.BigIntegerConverter;
import org.apache.commons.beanutils.converters.BooleanConverter;
@@ -53,7 +56,6 @@
import org.apache.commons.beanutils.converters.StringConverter;
import org.apache.commons.beanutils.converters.StringArrayConverter;
import org.apache.commons.beanutils.converters.URLConverter;
-import org.apache.commons.collections.FastHashMap;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -151,7 +153,7 @@
* The set of [EMAIL PROTECTED] Converter}s that can be used to convert
Strings
* into objects of a specified Class, keyed by the destination Class.
*/
-private FastHashMap converters = new FastHashMap();
+private Map converters = Collections.synchronizedMap(new HashMap());
/**
* The codeLog/code instance for this class.
@@ -162,9 +164,7 @@
/** Construct a bean with standard converters registered */
public ConvertUtilsBean() {
-converters.setFast(false);
deregister();
-converters.setFast(true);
}
// - Public Methods
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/WrapDynaClass.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/WrapDynaClass.java?view=diffrev=539519r1=539518r2=539519
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/WrapDynaClass.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/WrapDynaClass.java
Fri May 18 09:50:40 2007
@@ -277,7 +277,7 @@
if (regulars == null) {
regulars = new PropertyDescriptor[0];
}
-HashMap mappeds =
+Map mappeds =
PropertyUtils.getMappedPropertyDescriptors(beanClass);
if (mappeds == null) {
mappeds = new HashMap();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 18.05.2007, at 18:37, Stephen Colebourne wrote: Torsten Curdt wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. Whilst it may have frustrated you recently, the current situation really isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on [collections] in a simple manner. Basically promoting class path clashes is not that bad I personally think that dropping a dependency because of size does not really make too much sense these days. If someone is concerned there are tools to solve these needs http://mojo.codehaus.org/minijar-maven-plugin/usage.html http://proguard.sourceforge.net/ The copy was permitted as there were few classes involved, and they were very stable. Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. Now this is the part that I don't understand. Why would that have been an incompatible change? The changes should have been internal to beanutils. Because BeanUtils exposes FastHashMap in its public API (and Digester does the same with ArrayStack) - its the return type from four methods. The bad news was that an implementation (rather than Map) was exposed in the API in the first place. It does seem pretty minor to me changing that API from FastHashMap -- Map in only 4 places that probably aren't used outside BeanUtils. Having said that - the current situation has been in place for over 2 years and there haven't been complaints until now. Just out of interest which of the 4 classes caused you a problem? Niall We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. We could release ueberjars with unused classes removed and just would no longer have to care. cheers -- Torsten - 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: commons compress status?
Torsten Curdt wrote: Hm... seems like I disagree here. I want a simple library that deals with common compression and archive formats - tar - ar - cpio - gzip - bzip2 - zip VFS is a filesystem abstraction layer. It may use the library but should not provide the implementation IMO. Compression and archive are really only related by a USES relationship and there's no reason why they -have- to remain in the same package. CAB (windows) is an additional format, and you can make an argument for the Debian and Red Hat package formats as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Henri Yandell [EMAIL PROTECTED] wrote: No votes yet, so I wanted to ask what your thoughts were on including: http://issues.apache.org/jira/browse/IO-117 in 1.3.2? Fine with me, if you apply it to both branch and trunk. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539521 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Author: niallp Date: Fri May 18 10:11:09 2007 New Revision: 539521 URL: http://svn.apache.org/viewvc?view=revrev=539521 Log: Woops, my bad introduced additional synchronization - original FastHashMap was u nsynchronized once the ConvertUtilsBean was constructed - that was pretty much a waste of time anyway Modified: jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java Modified: jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java?view=diffrev=539521r1=539520r2=539521 == --- jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java (original) +++ jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java Fri May 18 10:11:09 2007 @@ -27,7 +27,6 @@ import java.sql.Date; import java.sql.Time; import java.sql.Timestamp; -import java.util.Collections; import java.util.Map; import java.util.HashMap; import org.apache.commons.beanutils.converters.BigDecimalConverter; @@ -153,7 +152,7 @@ * The set of [EMAIL PROTECTED] Converter}s that can be used to convert Strings * into objects of a specified Class, keyed by the destination Class. */ -private Map converters = Collections.synchronizedMap(new HashMap()); +private Map converters = new HashMap(); /** * The codeLog/code instance for this class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 18.05.2007, at 18:37, Stephen Colebourne wrote: Torsten Curdt wrote: On 18.05.2007, at 13:57, Niall Pemberton wrote: I wasn't part of the decision at the time, but (at least some if not all) these classes are in the BeanUtils public API so changing the package would have (and still will) broken binary compatibility (to remove the dependency on Collections 'coz of its incompatibility between versions!) - they were copied and (AFAIK) the parts of the public API deprecated with the intention of removing them in the next release - but there hasn't been one since that was done and 1.7.0 released. I am not pointing fingers. But whatever it takes - having those classes in there like this is not acceptable and needs to be fixed ASAP. Whilst it may have frustrated you recently, the current situation really isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on [collections] in a simple manner. Basically promoting class path clashes is not that bad I personally think that dropping a dependency because of size does not really make too much sense these days. If someone is concerned there are tools to solve these needs http://mojo.codehaus.org/minijar-maven-plugin/usage.html http://proguard.sourceforge.net/ The copy was permitted as there were few classes involved, and they were very stable. Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. Now this is the part that I don't understand. Why would that have been an incompatible change? The changes should have been internal to beanutils. We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. We could release ueberjars with unused classes removed and just would no longer have to care. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ Having said that - the current situation has been in place for over 2 years and there haven't been complaints until now. snap/ Yup, and I don't perceive any urgency here (not that I'd want us to recommend this again). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
On 5/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? snip/ Sounds good. I've read the rest of the thread -- probably good to branch regardless of whether both lines are under active (evolutionary, in my mind) development or not. If someone shows up with desire to do a point / bugfix release for JDK 1.3 etc. -Rahul Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
Was there a response to my comment [1] about r518770? -Rahul (long, possibly fragmented URL below) [1] http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Rahul Akolkar [EMAIL PROTECTED] wrote: Was there a response to my comment [1] about r518770? Sorry, I wasn't reading your comment. But, to be honest, I have to admit that after reading it, I do not understand what you propose as a better solution? Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails
[ https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved JXPATH-80. --- Resolution: Invalid Hi--sorry it took me so long to get back to this issue. After much tail-chasing I have come to the conclusion that this issue is a red herring. Your test attachment isn't performing boolean conversions but equality comparisons. A boolean conversion is accomplished by calling the built-in boolean() function, and these seem to perform as expected. equality comparisons do not automatically convert between types in the way you are expecting. See http://www.w3.org/TR/xpath#booleans for more information about how these comparisons are specified. boolean conversion of javabean getter values returning NULL fails - Key: JXPATH-80 URL: https://issues.apache.org/jira/browse/JXPATH-80 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0-b105 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) Client VM Reporter: Nico Max Priority: Minor Attachments: patch.patch, patch.patch, test.java According to the JXPath User Guide a Javabean Getter returning NULL, regadless of the type, will be converted bo Boolean FALSE. But trying to build a boolean expression from this fails as the attached testcase shows. It seems that the type the bean getter returns matters, as a NULL String for example works as expected. -- 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: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 5/18/07, Rahul Akolkar [EMAIL PROTECTED] wrote: Was there a response to my comment [1] about r518770? Sorry, I wasn't reading your comment. But, to be honest, I have to admit that after reading it, I do not understand what you propose as a better solution? snip/ I'm proposing to declare the FileCleaningTracker in DiskFileItem to be transient. FileCleaningTracker is currently returning a brand new instance after a round trip (its not really being serialized, it shouldn't be declared Serializable IMO). I'm away this weekend, and probably won't be able to respond further till Monday, sorry about that. -Rahul Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
Stephen Colebourne skrev den 18-05-2007 18:37: Changing the package name would have been, and still is, backwards incompatible. As such it is unacceptable for such a widely used package as [beanutils]. I am -1 to arbitrarily changing the package name. We really need a prime directive in commons. Don't break backwards compatibility. Every time we do we cause problems down the line - its simple due to our status as the lowest of low libraries. And again, this also emphasises that each commons library works much better when it stands alone - no dependencies. I agree that it is important, actually crucial. People trust in these modules, and _if_ they break something when upgrading it is very prominently displayed on the download page etc. I think it would be a bad idea to deliberatly introduce such things. I suggest marking the offending methods as deprecated for the 1.x series, and schedule them for removal in the 2.x series. -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
RE: [IO] Move to a minimum of JDK 1.4?
It seems like a nice coincidence that IO 1.3 is based on JRE 1.3, and we could have IO 1.4 based on JRE 1.4, IO 1.5 on JRE 1.5 ;) Thank you, Gary -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 1:10 PM To: Jakarta Commons Developers List Subject: Re: [IO] Move to a minimum of JDK 1.4? On 5/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? snip/ Sounds good. I've read the rest of the thread -- probably good to branch regardless of whether both lines are under active (evolutionary, in my mind) development or not. If someone shows up with desire to do a point / bugfix release for JDK 1.3 etc. -Rahul Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - 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]
svn commit: r539632 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/EndianUtils.java test/org/apache/commons/io/EndianUtilsTest.java
Author: bayard
Date: Fri May 18 16:37:59 2007
New Revision: 539632
URL: http://svn.apache.org/viewvc?view=revrev=539632
Log:
Applying Hiroshi's test from IO-117 with my fix. Fixes negative number
possibilities in EndianUtils.readSwappedUnsignedInteger()
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/EndianUtilsTest.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java?view=diffrev=539632r1=539631r2=539632
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/EndianUtils.java
Fri May 18 16:37:59 2007
@@ -182,10 +182,13 @@
* @return the value read
*/
public static long readSwappedUnsignedInteger(byte[] data, int offset) {
-return ( ( ( data[ offset + 0 ] 0xff ) 0 ) +
-( ( data[ offset + 1 ] 0xff ) 8 ) +
-( ( data[ offset + 2 ] 0xff ) 16 ) +
-( ( data[ offset + 3 ] 0xff ) 24 ) );
+long low = ( ( ( data[ offset + 0 ] 0xff ) 0 ) +
+ ( ( data[ offset + 1 ] 0xff ) 8 ) +
+ ( ( data[ offset + 2 ] 0xff ) 16 ) );
+
+long high = data[ offset + 3 ] 0xff;
+
+return (high 24) + (0xL low);
}
/**
@@ -368,10 +371,13 @@
int value3 = read( input );
int value4 = read( input );
-return ( ( value1 0xff ) 0 ) +
-( ( value2 0xff ) 8 ) +
-( ( value3 0xff ) 16 ) +
-( ( value4 0xff ) 24 );
+long low = ( ( ( value1 0xff ) 0 ) +
+ ( ( value2 0xff ) 8 ) +
+ ( ( value3 0xff ) 16 ) );
+
+long high = value4 0xff;
+
+return (high 24) + (0xL low);
}
/**
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/EndianUtilsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/EndianUtilsTest.java?view=diffrev=539632r1=539631r2=539632
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/EndianUtilsTest.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/EndianUtilsTest.java
Fri May 18 16:37:59 2007
@@ -263,4 +263,17 @@
}
}
+// tests #IO-117
+public void testUnsignedOverrun() throws Exception {
+byte[] target = new byte[] { 0, 0, 0, (byte)0x80 };
+long expected = 0x8000L;
+
+long actual = EndianUtils.readSwappedUnsignedInteger(target, 0);
+assertEquals(readSwappedUnsignedInteger(byte[], int) was incorrect,
expected, actual);
+
+ByteArrayInputStream in = new ByteArrayInputStream(target);
+actual = EndianUtils.readSwappedUnsignedInteger(in);
+assertEquals(readSwappedUnsignedInteger(InputStream) was incorrect,
expected, actual);
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539638 - in /jakarta/commons/proper/io/branches/b1_3/src: java/org/apache/commons/io/EndianUtils.java test/org/apache/commons/io/EndianUtilsTest.java
Author: bayard
Date: Fri May 18 16:44:30 2007
New Revision: 539638
URL: http://svn.apache.org/viewvc?view=revrev=539638
Log:
Applying Hiroshi's test from IO-117 with my fix. Fixes negative number
possibilities in EndianUtils.readSwappedUnsignedInteger()
Modified:
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/EndianUtils.java
jakarta/commons/proper/io/branches/b1_3/src/test/org/apache/commons/io/EndianUtilsTest.java
Modified:
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/EndianUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/EndianUtils.java?view=diffrev=539638r1=539637r2=539638
==
---
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/EndianUtils.java
(original)
+++
jakarta/commons/proper/io/branches/b1_3/src/java/org/apache/commons/io/EndianUtils.java
Fri May 18 16:44:30 2007
@@ -182,10 +182,13 @@
* @return the value read
*/
public static long readSwappedUnsignedInteger(byte[] data, int offset) {
-return ( ( ( data[ offset + 0 ] 0xff ) 0 ) +
-( ( data[ offset + 1 ] 0xff ) 8 ) +
-( ( data[ offset + 2 ] 0xff ) 16 ) +
-( ( data[ offset + 3 ] 0xff ) 24 ) );
+long low = ( ( ( data[ offset + 0 ] 0xff ) 0 ) +
+ ( ( data[ offset + 1 ] 0xff ) 8 ) +
+ ( ( data[ offset + 2 ] 0xff ) 16 ) );
+
+long high = data[ offset + 3 ] 0xff;
+
+return (high 24) + (0xL low);
}
/**
@@ -368,10 +371,13 @@
int value3 = read( input );
int value4 = read( input );
-return ( ( value1 0xff ) 0 ) +
-( ( value2 0xff ) 8 ) +
-( ( value3 0xff ) 16 ) +
-( ( value4 0xff ) 24 );
+long low = ( ( ( value1 0xff ) 0 ) +
+ ( ( value2 0xff ) 8 ) +
+ ( ( value3 0xff ) 16 ) );
+
+long high = value4 0xff;
+
+return (high 24) + (0xL low);
}
/**
Modified:
jakarta/commons/proper/io/branches/b1_3/src/test/org/apache/commons/io/EndianUtilsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/test/org/apache/commons/io/EndianUtilsTest.java?view=diffrev=539638r1=539637r2=539638
==
---
jakarta/commons/proper/io/branches/b1_3/src/test/org/apache/commons/io/EndianUtilsTest.java
(original)
+++
jakarta/commons/proper/io/branches/b1_3/src/test/org/apache/commons/io/EndianUtilsTest.java
Fri May 18 16:44:30 2007
@@ -263,4 +263,17 @@
}
}
+// tests #IO-117
+public void testUnsignedOverrun() throws Exception {
+byte[] target = new byte[] { 0, 0, 0, (byte)0x80 };
+long expected = 0x8000L;
+
+long actual = EndianUtils.readSwappedUnsignedInteger(target, 0);
+assertEquals(readSwappedUnsignedInteger(byte[], int) was incorrect,
expected, actual);
+
+ByteArrayInputStream in = new ByteArrayInputStream(target);
+actual = EndianUtils.readSwappedUnsignedInteger(in);
+assertEquals(readSwappedUnsignedInteger(InputStream) was incorrect,
expected, actual);
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 5/18/07, Henri Yandell [EMAIL PROTECTED] wrote: No votes yet, so I wanted to ask what your thoughts were on including: http://issues.apache.org/jira/browse/IO-117 in 1.3.2? Fine with me, if you apply it to both branch and trunk. Done. Fix version set to 1.3.2. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-117) EndianUtils.readSwappedUnsignedInteger() may return a negative number
[ https://issues.apache.org/jira/browse/IO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed IO-117. Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.2 Committed to both trunk (539632) and the 1.3.x branch(539638). My understanding is that this is in time for 1.3.2. EndianUtils.readSwappedUnsignedInteger() may return a negative number - Key: IO-117 URL: https://issues.apache.org/jira/browse/IO-117 Project: Commons IO Issue Type: Bug Affects Versions: 1.3.1 Reporter: Hiroshi Ikeda Fix For: 1.3.2 Attachments: EndianUtilsTest.java, IO-117.patch Methods about reading unsigned-integer in class EndianUtils may return a negative number, due to casting int to long. Calculations with operator etc. are under integer in these methods so its results are integer, then implicit casting the results to long keeps its positive/negative sign. -- 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: r539650 - /jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt
Author: bayard Date: Fri May 18 17:45:35 2007 New Revision: 539650 URL: http://svn.apache.org/viewvc?view=revrev=539650 Log: Updating release notes with IO-117 fix Modified: jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt Modified: jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt?view=diffrev=539650r1=539649r2=539650 == --- jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/branches/b1_3/RELEASE-NOTES.txt Fri May 18 17:45:35 2007 @@ -48,7 +48,9 @@ - Some tests, which are implicitly assuming a Unix-like file system, are now skipped on Windows. [IO-115] - +- EndianUtils + - Both readSwappedUnsignedInteger(...) methods could return negative +numbers due to int/long casting. [IO-117] Bug fixes from 1.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539651 - /jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
Author: bayard Date: Fri May 18 17:46:29 2007 New Revision: 539651 URL: http://svn.apache.org/viewvc?view=revrev=539651 Log: Moving release notes to 1.4. 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=diffrev=539651r1=539650r2=539651 == --- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Fri May 18 17:46:29 2007 @@ -1,7 +1,7 @@ $Id$ Commons IO Package - Version 1.3.1 + Version 1.4 Release Notes @@ -15,23 +15,17 @@ and endian transformation classes. -Compatibility with 1.3 --- -Binary compatible - No - See [IO-113] +Compatibility with 1.3.2 + +Binary compatible - ? -Source compatible - No - See [IO-113] +Source compatible - ? -Semantic compatible - Yes +Semantic compatible - ? -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] +Bug fixes from 1.3.2 + Feedback - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539656 - in /jakarta/commons/proper/io/branches/b1_3/src: changes/changes.xml site/site.xml
Author: niallp Date: Fri May 18 18:15:53 2007 New Revision: 539656 URL: http://svn.apache.org/viewvc?view=revrev=539656 Log: Update changes report and correct project name in site.xml Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml jakarta/commons/proper/io/branches/b1_3/src/site/site.xml Modified: jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml?view=diffrev=539656r1=539655r2=539656 == --- jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/src/changes/changes.xml Fri May 18 18:15:53 2007 @@ -49,6 +49,10 @@ version of the FileCleaner, which can be controlled by the user. /action + action dev=bayard type=fix issue=IO-117 due-to=Hiroshi Ikeda +EndianUtils - both readSwappedUnsignedInteger(...) methods could +return negative numbers due to int/long casting. + /action /release /body /document Modified: jakarta/commons/proper/io/branches/b1_3/src/site/site.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/branches/b1_3/src/site/site.xml?view=diffrev=539656r1=539655r2=539656 == --- jakarta/commons/proper/io/branches/b1_3/src/site/site.xml (original) +++ jakarta/commons/proper/io/branches/b1_3/src/site/site.xml Fri May 18 18:15:53 2007 @@ -15,7 +15,7 @@ See the License for the specific language governing permissions and limitations under the License. -- -project name=Validator +project name=Commons IO bannerRight nameCommons IO/name src/images/io-logo-white.png/src - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539657 - in /jakarta/commons/proper/io/trunk/src: changes/changes.xml site/site.xml
Author: niallp Date: Fri May 18 18:16:23 2007 New Revision: 539657 URL: http://svn.apache.org/viewvc?view=revrev=539657 Log: Update changes report and correct project name in site.xml Modified: jakarta/commons/proper/io/trunk/src/changes/changes.xml jakarta/commons/proper/io/trunk/src/site/site.xml Modified: jakarta/commons/proper/io/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/changes/changes.xml?view=diffrev=539657r1=539656r2=539657 == --- jakarta/commons/proper/io/trunk/src/changes/changes.xml (original) +++ jakarta/commons/proper/io/trunk/src/changes/changes.xml Fri May 18 18:16:23 2007 @@ -49,6 +49,10 @@ version of the FileCleaner, which can be controlled by the user. /action + action dev=bayard type=fix issue=IO-117 due-to=Hiroshi Ikeda +EndianUtils - both readSwappedUnsignedInteger(...) methods could +return negative numbers due to int/long casting. + /action /release /body /document Modified: jakarta/commons/proper/io/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/site/site.xml?view=diffrev=539657r1=539656r2=539657 == --- jakarta/commons/proper/io/trunk/src/site/site.xml (original) +++ jakarta/commons/proper/io/trunk/src/site/site.xml Fri May 18 18:16:23 2007 @@ -15,7 +15,7 @@ See the License for the specific language governing permissions and limitations under the License. -- -project name=Validator +project name=Commons IO bannerRight nameCommons IO/name src/images/io-logo-white.png/src - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539664 - in /jakarta/commons/proper/io/trunk: PROPOSAL.html STATUS.html build.xml doap_io.rdf xdocs/navigation.xml xdocs/style/project.css
Author: niallp Date: Fri May 18 18:28:33 2007 New Revision: 539664 URL: http://svn.apache.org/viewvc?view=revrev=539664 Log: Merge changes to keep RAT plugin happy back into trunk Modified: jakarta/commons/proper/io/trunk/PROPOSAL.html jakarta/commons/proper/io/trunk/STATUS.html jakarta/commons/proper/io/trunk/build.xml jakarta/commons/proper/io/trunk/doap_io.rdf jakarta/commons/proper/io/trunk/xdocs/navigation.xml jakarta/commons/proper/io/trunk/xdocs/style/project.css Modified: jakarta/commons/proper/io/trunk/PROPOSAL.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/PROPOSAL.html?view=diffrev=539664r1=539663r2=539664 == --- jakarta/commons/proper/io/trunk/PROPOSAL.html (original) +++ jakarta/commons/proper/io/trunk/PROPOSAL.html Fri May 18 18:28:33 2007 @@ -1,4 +1,20 @@ !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- html head titleProposal for IO Package/title Modified: jakarta/commons/proper/io/trunk/STATUS.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/STATUS.html?view=diffrev=539664r1=539663r2=539664 == --- jakarta/commons/proper/io/trunk/STATUS.html (original) +++ jakarta/commons/proper/io/trunk/STATUS.html Fri May 18 18:28:33 2007 @@ -1,4 +1,20 @@ !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- html head titleStatus File for Jakarta Commons IO Component/title Modified: jakarta/commons/proper/io/trunk/build.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/build.xml?view=diffrev=539664r1=539663r2=539664 == --- jakarta/commons/proper/io/trunk/build.xml (original) +++ jakarta/commons/proper/io/trunk/build.xml Fri May 18 18:28:33 2007 @@ -1,6 +1,23 @@ ?xml version=1.0 encoding=UTF-8? !-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- + +!-- Based on maven generated file on date October 1 2005 Added overview to javadoc Include license in jar Modified: jakarta/commons/proper/io/trunk/doap_io.rdf URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/doap_io.rdf?view=diffrev=539664r1=539663r2=539664 == --- jakarta/commons/proper/io/trunk/doap_io.rdf (original) +++ jakarta/commons/proper/io/trunk/doap_io.rdf Fri May 18 18:28:33 2007 @@ -1,4 +1,20 @@ ?xml version=1.0? +!-- + Licensed to the Apache Software Foundation
