Re: [transaction] Preparing a release
On 7/24/06, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: Hi folks! I have already uploaded the files for a 1.2 release candidate to http://people.apache.org/~ozeigermann/tx-1.2rc1/ Have you read the Releasing Components webpages? Few things to change: .MD5 to .md5 .tgz to .tar.gz zips and tar.gz's should unzip to a directory with the same name as the archive (ie: it shouldn't make a mess when unpacked) include a jar for the Maven repository (and a .pom) gpg sign all files Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
eclipse customisation files for commons ?
Hello, Are there customisation files available (formatter profile, editor preferences, templates ...) for the Eclipse IDE tailored to the commons style ? Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425265 - in /jakarta/commons/proper/attributes/trunk: RELEASE.txt RELEASE_NOTES.txt
Author: bayard Date: Mon Jul 24 20:14:59 2006 New Revision: 425265 URL: http://svn.apache.org/viewvc?rev=425265&view=rev Log: Renaming the release notes in accordance with other components Added: jakarta/commons/proper/attributes/trunk/RELEASE_NOTES.txt - copied unchanged from r425263, jakarta/commons/proper/attributes/trunk/RELEASE.txt Removed: jakarta/commons/proper/attributes/trunk/RELEASE.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12423215
]
Niall Pemberton commented on IO-89:
---
OK so this needs re-thinking. IMO it should be easy to use any of the five
compare operators (i.e. <, <=, =, >=, >) with the size or age filters.
So maybe we should have a constructor which takes the size and operator - and
deprecate the existing boolean parameter constructors:
public SizeFileFilter(long size, boolean acceptLarger) {
this(size, acceptLarger ? ">=" : "<");
}
public SizeFileFilter(long size, String operator) {
this.size = size;
this.operator = operator;
}
public boolean accept(File file) {
if ("<".equals(operator)) {
return file.length() < size;
} else if ("<=".equals(operator)) {
return file.length() <= size;
} else if ("=".equals(operator)) {
return file.length() == size;
} else if (">=".equals(operator)) {
return file.length() >= size;
} else if (">".equals(operator)) {
return file.length() > size;
}
}
When I get time I'll put together a patch for review
> Inconsistency in SizeFileFilter and AgeFileFilter implementations
> -
>
> Key: IO-89
> URL: http://issues.apache.org/jira/browse/IO-89
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.2
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 1.3
>
>
> Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
> AgeFileFilter.
> In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
> files with a size equal to and larger, whereas
> specifying an "acceptLarger" parameter of false only accepts smaller files.
> The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
> actually accepts files either the same age or older, whereas
> specifying an "acceptOlder" parameter of false only accepts newer files.
> A big benefit of resolving these inconsistencies would mean that creating
> filters for any condition (i.e. <, >, <=, >= or =) becomes
> alot easier. For example if the AgeFileFilter did only do either newer or
> older, then creating a filters for "the same age or older"
> or "the same age or younger" could be done in the following way:
> IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
> false));
> IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
> true));
> For SizeFileFilter I propose changing the logic to the following:
> if (acceptLarger) {
> return file.length() >= size;
> } else {
> return file.length() <= size;
> }
> (This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
> I have added isOlderFile() methods to FileUtils and propose that
> AgeFileFilter is changed to the following:
> if (acceptOlder) {
> return FileUtils.isFileOlder(file, cutoff);
> } else {
> return FileUtils.isFileNewer(file, cutoff);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425252 - in /jakarta/commons/proper/logging/trunk: commons-logging-README.txt pom.xml
Author: skitching
Date: Mon Jul 24 18:37:50 2006
New Revision: 425252
URL: http://svn.apache.org/viewvc?rev=425252&view=rev
Log:
Initial attempt at building commons-logging using maven2; not fully functional
yet.
Added:
jakarta/commons/proper/logging/trunk/commons-logging-README.txt (with
props)
jakarta/commons/proper/logging/trunk/pom.xml
Added: jakarta/commons/proper/logging/trunk/commons-logging-README.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/commons-logging-README.txt?rev=425252&view=auto
==
--- jakarta/commons/proper/logging/trunk/commons-logging-README.txt (added)
+++ jakarta/commons/proper/logging/trunk/commons-logging-README.txt Mon Jul 24
18:37:50 2006
@@ -0,0 +1,6 @@
+The Logging package is an ultra-thin bridge between different logging
implementations. A library that uses the commons-logging API can be used with
any logging implementation at runtime. Commons-logging comes with support for a
number of popular logging implementations, and writing adapters for others is a
reasonably simple task.
+
+See RELEASE-NOTES.txt for details on the current release.
+
+
+Note: The maven2 pom.xml file is affected by the presence or absence of this
file. See the comments in that file for details.
Propchange: jakarta/commons/proper/logging/trunk/commons-logging-README.txt
--
svn:eol-style = native
Added: jakarta/commons/proper/logging/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/pom.xml?rev=425252&view=auto
==
--- jakarta/commons/proper/logging/trunk/pom.xml (added)
+++ jakarta/commons/proper/logging/trunk/pom.xml Mon Jul 24 18:37:50 2006
@@ -0,0 +1,361 @@
+
+ 4.0.0
+ commons-logging
+ commons-logging
+ Logging
+ 1.1.1
+ Commons Logging is a thin adapter allowing configurable
bridging to other,
+well known logging systems.
+ http://jakarta.apache.org/commons/logging
+
+
+http://issues.apache.org/jira/
+
+
+
+
+
+
+ commons-dev@jakarta.apache.org
+
+
+
+
+
+ 2001
+
+
+
+ Commons Dev List
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+
http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/
+
+
http://www.mail-archive.com/commons-dev%40jakarta.apache.org/
+
+
+
+ Commons User List
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/
+
+
http://www.mail-archive.com/commons-user%40jakarta.apache.org/
+
+
+
+
+
+ morgand
+ Morgan Delagrange
+ morgand at apache dot org
+ Apache
+
+Java Developer
+
+
+
+ rwaldhoff
+ Rodney Waldhoff
+ rwaldhoff at apache org
+ Apache Software Foundation
+
+
+ craigmcc
+ Craig McClanahan
+ craigmcc at apache org
+ Apache Software Foundation
+
+
+ sanders
+ Scott Sanders
+ sanders at apache dot org
+ Apache Software Foundation
+
+
+ rdonkin
+ Robert Burrell Donkin
+ rdonkin at apache dot org
+ Apache Software Foundation
+
+
+ donaldp
+ Peter Donald
+ donaldp at apache dot org
+
+
+
+ costin
+ Costin Manolache
+ costin at apache dot org
+ Apache Software Foundation
+
+
+ rsitze
+ Richard Sitze
+ rsitze at apache dot org
+ Apache Software Foundation
+
+
+ baliuka
+ Juozas Baliuka
+ [EMAIL PROTECTED]
+
+
+Java Developer
+
+
+
+ skitching
+ Simon Kitching
+ [EMAIL PROTECTED]
+ Apache Software Foundation
+
+
+ dennisl
+ Dennis Lundberg
+ [EMAIL PROTECTED]
+ Apache Software Foundation
+
+
+ bstansberry
+ Brian Stansberry
+
+
+
+
+
+ The Apache Software License, Version 2.0
+ /LICENSE.txt
+
+
+
+
+
scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk
+
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk
+
+
+
+The Apache Software Foundation
+http://jakarta.apache.org
+
+
+
+src/java
+src/test
+
+
+
+
+maven-jar-plugin
+
+
+apijar
+package
+
+ jar
+
+
+ ${project.artifactId}-api-${project.version}
+
+
org/apache/commons/logging/impl/Log4JLogger.class
+
+
+
+
+adaptersjar
+package
+
+
${project.artifactId}-adapters-${project.version}
+
svn commit: r425250 - /jakarta/commons/proper/logging/trunk/project.xml
Author: skitching
Date: Mon Jul 24 18:32:04 2006
New Revision: 425250
URL: http://svn.apache.org/viewvc?rev=425250&view=rev
Log:
Replace confusing variable use with plain text. There's no need for flexibility
here as the
artifact id is really unlikely to change, and if it does we can just
search-and-replace.
Modified:
jakarta/commons/proper/logging/trunk/project.xml
Modified: jakarta/commons/proper/logging/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/project.xml?rev=425250&r1=425249&r2=425250&view=diff
==
--- jakarta/commons/proper/logging/trunk/project.xml (original)
+++ jakarta/commons/proper/logging/trunk/project.xml Mon Jul 24 18:32:04 2006
@@ -32,8 +32,8 @@
/images/logo.png
- http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/
- org.apache.commons.${pom.artifactId.substring(8)}
+ http://jakarta.apache.org/commons/logging
+ org.apache.commons.logging
The Apache Software Foundation
@@ -52,13 +52,12 @@
jakarta
http://issues.apache.org/jira/
people.apache.org
-
/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}/
-
/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}/
+ /www/jakarta.apache.org/commons/logging/
+
/www/jakarta.apache.org/builds/jakarta-commons/logging
-
-
scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk
-
http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk
+
scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk
+
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425249 - in /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging: config/ jdk14/ log4j/log4j12/ logkit/ security/ servlet/ simple/ tccl/ tccl/log/ tccl/logfactory/
Author: skitching
Date: Mon Jul 24 18:30:16 2006
New Revision: 425249
URL: http://svn.apache.org/viewvc?rev=425249&view=rev
Log:
Make unit tests compatible with maven2 Surefire plugin.
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/PriorityConfigTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigAPITestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/jdk14/CustomConfigFullTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/log4j/log4j12/ApiClasspathStandardTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/log4j/log4j12/AppClasspathStandardTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/log4j/log4j12/ChildClasspathStandardTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/log4j/log4j12/ParentClasspathStandardTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/logkit/StandardTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/security/SecurityAllowedTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/security/SecurityForbiddenTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/simple/CustomConfigTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/simple/DateTimeCustomConfigTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/simple/DefaultConfigTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/BadTCCLTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/log/TcclDisabledTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/log/TcclEnabledTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/logfactory/TcclDisabledTestCase.java
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/tccl/logfactory/TcclEnabledTestCase.java
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java?rev=425249&r1=425248&r2=425249&view=diff
==
---
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/FirstPriorityConfigTestCase.java
Mon Jul 24 18:30:16 2006
@@ -55,7 +55,7 @@
// class through a dummy loader though this is not absolutely
// necessary...
PathableClassLoader dummy = new PathableClassLoader(null);
-dummy.useSystemLoader("junit.");
+dummy.useExplicitLoader("junit.", Test.class.getClassLoader());
dummy.addLogicalLib("testclasses");
dummy.addLogicalLib("commons-logging");
@@ -70,7 +70,7 @@
// so we can check that the first one in the classpath is
// used.
PathableClassLoader containerLoader = new PathableClassLoader(null);
-containerLoader.useSystemLoader("junit.");
+containerLoader.useExplicitLoader("junit.",
Test.class.getClassLoader());
containerLoader.addLogicalLib("commons-logging");
PathableClassLoader webappLoader = new
PathableClassLoader(containerLoader);
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/PriorityConfigTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/PriorityConfigTestCase.java?rev=425249&r1=425248&r2=425249&view=diff
==
---
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/PriorityConfigTestCase.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/config/PriorityConfigTestCase.java
Mon Jul 24 18:30:16 2006
@@ -62,7 +62,7 @@
// class through a dummy loader though this is not absolutely
// necessary...
PathableClassLoader dummy = new PathableClassLoader(null);
-dummy.useSystemLoader("junit.");
+dummy.useExplicitLoader("junit.", Test.class.getCla
svn commit: r425247 - /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
Author: skitching
Date: Mon Jul 24 18:26:37 2006
New Revision: 425247
URL: http://svn.apache.org/viewvc?rev=425247&view=rev
Log:
Add javadoc about setExplicitLoader/addLogicalLib.
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
Modified:
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java?rev=425247&r1=425246&r2=425247&view=diff
==
---
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
(original)
+++
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
Mon Jul 24 18:26:37 2006
@@ -72,9 +72,27 @@
* See setParentFirst.
*/
private boolean parentFirst = true;
-
+
/**
* Constructor.
+ *
+ * Often, null is passed as the parent, ie the parent of the new
+ * instance is the bootloader. This ensures that the classpath is
+ * totally clean; nothing but the standard java library will be
+ * present.
+ *
+ * When using a null parent classloader with a junit testcase, it *is*
+ * necessary for the junit library to also be visible. In this case, it
+ * is recommended that the following code be used:
+ *
+ * pathableLoader.useExplicitLoader(
+ * "junit.",
+ * junit.framework.Test.class.getClassLoader());
+ *
+ * Note that this works regardless of whether junit is on the system
+ * classpath, or whether it has been loaded by some test framework that
+ * creates its own classloader to run unit tests in (eg maven2's
+ * Surefire plugin).
*/
public PathableClassLoader(ClassLoader parent) {
super(NO_URLS, parent);
@@ -125,6 +143,28 @@
/**
* Specify a classloader to use for specific java packages.
+ *
+ * The specified classloader is normally a loader that is NOT
+ * an ancestor of this classloader. In particular, this loader
+ * may have the bootloader as its parent, but be configured to
+ * see specific other classes (eg the junit library loaded
+ * via the system classloader).
+ *
+ * The differences between using this method, and using
+ * addLogicalLib are:
+ *
+ * If code calls getClassLoader on a class loaded via
+ * "lookaside", then traces up its inheritance chain, it
+ * will see the "real" classloaders. When the class is remapped
+ * into this classloader via addLogicalLib, the classloader
+ * chain seen is this object plus ancestors.
+ * If two different jars contain classes in the same
+ * package, then it is not possible to load both jars into
+ * the same "lookaside" classloader (eg the system classloader)
+ * then map one of those subsets from here. Of course they could
+ * be loaded into two different "lookaside" classloaders and
+ * then a prefix used to map from here to one of those classloaders.
+ *
*/
public void useExplicitLoader(String prefix, ClassLoader loader) {
if (lookasides == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (IO-87) Provide a convenience mehod in FileFilterUtils to create a Size Range filter
[ http://issues.apache.org/jira/browse/IO-87?page=all ] Niall Pemberton resolved IO-87. --- Resolution: Fixed OK I've changed the parameter names as requested. Also renamed the method and made the javadoc clearer. Thanks for the feedback. P.S. I don't think you're a dimwit - my impression of IO is that the quality is v.high and I put that down to the care and attention to detail people like youself have put into it :-) > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > > > Key: IO-87 > URL: http://issues.apache.org/jira/browse/IO-87 > Project: Commons IO > Issue Type: New Feature > Components: Filters >Affects Versions: 1.2 >Reporter: Niall Pemberton > Assigned To: Niall Pemberton >Priority: Minor > Fix For: 1.3 > > > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > - by combining two SizeFileFilter's (one >= minimum and the other <= maximum) > with an AndFileFilter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425240 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/filefilter/FileFilterUtils.java src/test/org/apache/commons/io/filefilter/FileFilterTestCase
Author: niallp
Date: Mon Jul 24 17:51:57 2006
New Revision: 425240
URL: http://svn.apache.org/viewvc?rev=425240&view=rev
Log:
IO-87 - change parameter names and javadoc to make it more explicit that the
maximum/minimum values are inclusive. Also rename method to indicate its a
"range" filter.
Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=425240&r1=425239&r2=425240&view=diff
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Mon Jul 24 17:51:57 2006
@@ -87,7 +87,7 @@
- The old INSTANCE constants are still present and have not been deprecated
- FileFilterUtils
- - new sizeFileFilter(long minimumSize, long maximumSize) method which
+ - new sizeRangeFileFilter(long minimumSize, long maximumSize) method which
creates a filter that accepts files within the specified size range.
- FileUtils
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java?rev=425240&r1=425239&r2=425240&view=diff
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/filefilter/FileFilterUtils.java
Mon Jul 24 17:51:57 2006
@@ -317,17 +317,17 @@
}
/**
- * Returns a filter that returns true if the file size is within
- * the specified range.
+ * Returns a filter that accepts files whose size is >= minimum size
+ * and <= maximum size.
*
- * @param minimumSize the minimum file size
- * @param maximumSize the maximum file size
+ * @param minSizeInclusive the minimum file size (inclusive)
+ * @param maxSizeInclusive the maximum file size (inclusive)
* @return an appropriately configured IOFileFilter
* @since Commons IO 1.3
*/
-public static IOFileFilter sizeFileFilter(long minimumSize, long
maximumSize) {
-IOFileFilter minimumFilter = new SizeFileFilter(minimumSize, true);
-IOFileFilter maximumFilter = new SizeFileFilter(maximumSize + 1L,
false);
+public static IOFileFilter sizeRangeFileFilter(long minSizeInclusive, long
maxSizeInclusive ) {
+IOFileFilter minimumFilter = new SizeFileFilter(minSizeInclusive,
true);
+IOFileFilter maximumFilter = new SizeFileFilter(maxSizeInclusive + 1L,
false);
return new AndFileFilter(minimumFilter, maximumFilter);
}
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java?rev=425240&r1=425239&r2=425240&view=diff
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java
Mon Jul 24 17:51:57 2006
@@ -637,11 +637,11 @@
assertFiltering(filter3, largeFile, false);
// size range tests
-IOFileFilter filter4 = FileFilterUtils.sizeFileFilter(33, 127);
-IOFileFilter filter5 = FileFilterUtils.sizeFileFilter(32, 127);
-IOFileFilter filter6 = FileFilterUtils.sizeFileFilter(33, 128);
-IOFileFilter filter7 = FileFilterUtils.sizeFileFilter(31, 129);
-IOFileFilter filter8 = FileFilterUtils.sizeFileFilter(128, 128);
+IOFileFilter filter4 = FileFilterUtils.sizeRangeFileFilter(33, 127);
+IOFileFilter filter5 = FileFilterUtils.sizeRangeFileFilter(32, 127);
+IOFileFilter filter6 = FileFilterUtils.sizeRangeFileFilter(33, 128);
+IOFileFilter filter7 = FileFilterUtils.sizeRangeFileFilter(31, 129);
+IOFileFilter filter8 = FileFilterUtils.sizeRangeFileFilter(128, 128);
assertFiltering(filter4, smallFile, false);
assertFiltering(filter4, largeFile, false);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Broken links in tag reference
I don't think the tag reference is complete. On 7/25/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi The links under "Tag Reference" are all broken. That is all except "All tags". http://jakarta.apache.org/commons/jelly/tag-reference/index.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ "If you even dream of beating me you'd better wake up and apologize" - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12423209
]
Stephen Colebourne commented on IO-89:
--
I'm behind on reviewing commits, but the key thing is backwards compatability.
The internal implementation (number of classes/flexibility) is less important.
> Inconsistency in SizeFileFilter and AgeFileFilter implementations
> -
>
> Key: IO-89
> URL: http://issues.apache.org/jira/browse/IO-89
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.2
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 1.3
>
>
> Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
> AgeFileFilter.
> In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
> files with a size equal to and larger, whereas
> specifying an "acceptLarger" parameter of false only accepts smaller files.
> The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
> actually accepts files either the same age or older, whereas
> specifying an "acceptOlder" parameter of false only accepts newer files.
> A big benefit of resolving these inconsistencies would mean that creating
> filters for any condition (i.e. <, >, <=, >= or =) becomes
> alot easier. For example if the AgeFileFilter did only do either newer or
> older, then creating a filters for "the same age or older"
> or "the same age or younger" could be done in the following way:
> IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
> false));
> IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
> true));
> For SizeFileFilter I propose changing the logic to the following:
> if (acceptLarger) {
> return file.length() >= size;
> } else {
> return file.length() <= size;
> }
> (This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
> I have added isOlderFile() methods to FileUtils and propose that
> AgeFileFilter is changed to the following:
> if (acceptOlder) {
> return FileUtils.isFileOlder(file, cutoff);
> } else {
> return FileUtils.isFileNewer(file, cutoff);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-87) Provide a convenience mehod in FileFilterUtils to create a Size Range filter
[ http://issues.apache.org/jira/browse/IO-87?page=comments#action_12423208 ] Stephen Colebourne commented on IO-87: -- Feel free to tink of me as a dimwit, but minSize and maxSize don't always mean inclusive in my brain. hats why I always like to spell it out very explicitly. I use the parameter names to do this, as then IDE autocompletes pick it up rapidly. I guess its just a coding standard I've got into, and it certainy doesnt harm. > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > > > Key: IO-87 > URL: http://issues.apache.org/jira/browse/IO-87 > Project: Commons IO > Issue Type: New Feature > Components: Filters >Affects Versions: 1.2 >Reporter: Niall Pemberton > Assigned To: Niall Pemberton >Priority: Minor > Fix For: 1.3 > > > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > - by combining two SizeFileFilter's (one >= minimum and the other <= maximum) > with an AndFileFilter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add FileFinder back into Commons IO
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12423207
]
Stephen Colebourne commented on IO-86:
--
One role for FileFinder would be if it had lots of set methods to setup the
file filters to use. I'm not sure how viable that would be (random idea...)
I agree with the change to Collection.
For the handleDirectoryEnd(), I wonder if we should add a handleDirectory()
method which returns the boolean. Thus the calls would be:
if (handleDirectory == true) {
handleDirectoryStart
...
handleDirectoryEnd
}
> Add FileFinder back into Commons IO
> ---
>
> Key: IO-86
> URL: http://issues.apache.org/jira/browse/IO-86
> Project: Commons IO
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Niall Pemberton
> Fix For: 1.3
>
> Attachments: FileFinder.java, FileFinderTestCase.java,
> io-filefinder-start-end.patch
>
>
> I'd like to propose adding a "FileFinder" back into Commons IO. This is a
> simplified version of what was recently moved out of Commons IO into the
> "finder" component currently in the sandbox.
> I believe this is a simpler, more generic implementation than the finder
> component and therefore would be considered suitable for inclusion in Commons
> IO. Although simpler it could be used as the basis for achieving the finder
> component's aims - namely to emulate the unix find command.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: old style html in javadoc Was: [jira] Commented: (IO-86) Add FileFinder back into Commons IO
Simon Kitching wrote: I'm with Stephen here; simple is good. Javadoc isn't expected to be processed by anything other than the javadoc tool, and that handles as a separator fine, so why clutter things with ? Just to clarify my POV - if I was writing a web page inmy day job, I would use XHTML. There are many good reasons for that, including the possibility to validate XHTML along the way and parse moe quickly in the browser. However, as Simon points out, Javadoc isn't the same. Its just a tool for programmers, and the simple separator approach is cleaner (IMO) while having exactly the same result within the javadoc. Javadoc isn't really html. It's a java-specific doc format (like perl POD etc) that happens to resemble html. There are many markup formats that use the "separator" approach rather than the "container" approach. In practice, I think that either is bearable, so new files should follow whatever convention the project already has. Yeh. I have to live with containers in lang, but io and collections use separator :-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425232 - /jakarta/commons/sandbox/finder/trunk/src/test/org/apache/commons/finder/FileFinderTest.java
Author: niallp
Date: Mon Jul 24 16:55:03 2006
New Revision: 425232
URL: http://svn.apache.org/viewvc?rev=425232&view=rev
Log:
Exclude directories from FileFinderTest.testFindSize() - nightly build was
failing as it was finding 2 files rather than 1. Henri worked out that on
vmbuild the dir size is 4096 (same as test file size). So excluding directories
from the test
Modified:
jakarta/commons/sandbox/finder/trunk/src/test/org/apache/commons/finder/FileFinderTest.java
Modified:
jakarta/commons/sandbox/finder/trunk/src/test/org/apache/commons/finder/FileFinderTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/src/test/org/apache/commons/finder/FileFinderTest.java?rev=425232&r1=425231&r2=425232&view=diff
==
---
jakarta/commons/sandbox/finder/trunk/src/test/org/apache/commons/finder/FileFinderTest.java
(original)
+++
jakarta/commons/sandbox/finder/trunk/src/test/org/apache/commons/finder/FileFinderTest.java
Mon Jul 24 16:55:03 2006
@@ -96,7 +96,13 @@
assertEquals(1, files.length);
}
+/**
+ * N.B. dir size on vmbuild is 4k which caused this test to fail in that
+ * environment (incl. nightly build) - so excluding directories.
+ * TODO - currently just one 4k file - need non-4k files for proper
test
+ */
public void testFindSize() {
+options.put(Finder.FILE, null);
options.put(Finder.SIZE, "4k");
File[] files = finder.find(new File(dir, "size"), options);
assertEquals(1, files.length);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
Simon Kitching wrote: One problem is that of temporarily unsubscribing. We've all regularly seen what happens when someone goes on holiday for a few weeks and sets their email to auto-respond "out of office" without unsubscribing from these lists first. When there are 4 commons lists, how are people going to manage this? Depends if we have 4 lists or not. I'd prefer two dev and auto, which would be a little easier. Not that I ever unsubscribe Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Attributes 2.2
+1 Nit - I'd prefer RELEASE.txt be RELEASE-NOTES.txt Stephen Henri Yandell wrote: This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] Broken links in tag reference
Hi The links under "Tag Reference" are all broken. That is all except "All tags". http://jakarta.apache.org/commons/jelly/tag-reference/index.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
On 24/07/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On 7/24/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Sat, 2006-07-22 at 21:53 -0700, Henri Yandell wrote: > > I had a thought just now on the multiple list concept - and a positive > > reason for splitting the lists in general. By having lists for > > commits, jira, wiki, ci etc filters become a lot, lot easier. Much > > easier for someone to come up with a list of commits they're > > interested in and we can have people who are interested in their own > > defined groupings while having to still see the general dev > > discussions as they come through. > > One problem is that of temporarily unsubscribing. We've all regularly > seen what happens when someone goes on holiday for a few weeks and sets > their email to auto-respond "out of office" without unsubscribing from > these lists first. > > When there are 4 commons lists, how are people going to manage this? > > I believe one commonly used mailing list system provides a web page > where you can "suspend" your subscriptions to all lists in one go. As > far as I know, though, the apache system doesn't provide this. Don't use your work email for open source mailing lists :) I can only I'm surprised at how many companies (large ones too) let OOO e-mails outside their company boundaries. These can provide valuable information for social engineering purposes... see the out of office making sense if its a work email - otherwise I'd expect people to continue checking their mail or just let it build up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
Simon Kitching wrote: On Sat, 2006-07-22 at 21:53 -0700, Henri Yandell wrote: I had a thought just now on the multiple list concept - and a positive reason for splitting the lists in general. By having lists for commits, jira, wiki, ci etc filters become a lot, lot easier. Much easier for someone to come up with a list of commits they're interested in and we can have people who are interested in their own defined groupings while having to still see the general dev discussions as they come through. One problem is that of temporarily unsubscribing. We've all regularly seen what happens when someone goes on holiday for a few weeks and sets their email to auto-respond "out of office" without unsubscribing from these lists first. This depends on how the mail server is set up. At my day job the auto-responder only kicks in if the mail is addressed directly to me. If the To: header contains something other than my address, for example the address of a mailing list, it just doesn't send an auto-reply. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] UriParser '#' in file names
My 2p observing this thread... don't make the same error as dom4j here: they simply said you can't make a URL out of a filename with a # hence open a new FileInputStream preventing any relative resolution. I think the guilty method is file.toURL()... that one should convert the # sign to its equivalent %xx escape. paul Filip Defoort wrote: Done, I added both issues to JIRA. Cheers, - Filip Mario Ivankovits wrote: Hi Filip! I found one more 'bug' (undesired effect...): VFS can't seem to handle files with '#' in their name (don't ask.. I know, but I actually had a user that created those...) How bad. VFS itself can handle the file without any hassle. So the filename to uri conversion needs to be done somehow smarted. Could you please file a JIRA ticket on this. smime.p7s Description: S/MIME Cryptographic Signature
Re: [all] Splitting the mailing list
On 7/24/06, Simon Kitching <[EMAIL PROTECTED]> wrote: On Sat, 2006-07-22 at 21:53 -0700, Henri Yandell wrote: > I had a thought just now on the multiple list concept - and a positive > reason for splitting the lists in general. By having lists for > commits, jira, wiki, ci etc filters become a lot, lot easier. Much > easier for someone to come up with a list of commits they're > interested in and we can have people who are interested in their own > defined groupings while having to still see the general dev > discussions as they come through. One problem is that of temporarily unsubscribing. We've all regularly seen what happens when someone goes on holiday for a few weeks and sets their email to auto-respond "out of office" without unsubscribing from these lists first. When there are 4 commons lists, how are people going to manage this? I believe one commonly used mailing list system provides a web page where you can "suspend" your subscriptions to all lists in one go. As far as I know, though, the apache system doesn't provide this. Don't use your work email for open source mailing lists :) I can only see the out of office making sense if its a work email - otherwise I'd expect people to continue checking their mail or just let it build up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
On Sat, 2006-07-22 at 21:53 -0700, Henri Yandell wrote: > I had a thought just now on the multiple list concept - and a positive > reason for splitting the lists in general. By having lists for > commits, jira, wiki, ci etc filters become a lot, lot easier. Much > easier for someone to come up with a list of commits they're > interested in and we can have people who are interested in their own > defined groupings while having to still see the general dev > discussions as they come through. One problem is that of temporarily unsubscribing. We've all regularly seen what happens when someone goes on holiday for a few weeks and sets their email to auto-respond "out of office" without unsubscribing from these lists first. When there are 4 commons lists, how are people going to manage this? I believe one commonly used mailing list system provides a web page where you can "suspend" your subscriptions to all lists in one go. As far as I know, though, the apache system doesn't provide this. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: old style html in javadoc Was: [jira] Commented: (IO-86) Add FileFinder back into Commons IO
On Sun, 2006-07-23 at 21:30 -0700, Henri Yandell wrote: > On 7/23/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > The concept that XML (XHTML in this case) is human readable is highly > > dubious, and has > > become accepted wisdom far too easily. > > Agreed, a .properties file is far more readable but that's not in > question here. Bad HTML is less readable than good HTML because the > eye is used to precompiling what's being typed. > > > The first point is that it isn't 'bad' HTML, its just normal HTML. Every > > HTML tool going has to be > > able to cope with this sort of layout so any tool arguments fail pretty > > quickly. > > I don't agree - it was bad HTML in the mid 90s and it's bad HTML now. > A decade of misuse doesn't make it right. > > > So it comes down to readability, which is much more of a stylistic choice. > > Personally, I strive to > > avoid unecessary clutter, only including unecessary things (eg. additionl > > brackets) if I judge it > > aids understanding. > > +1. I'm with Stephen here; simple is good. Javadoc isn't expected to be processed by anything other than the javadoc tool, and that handles as a separator fine, so why clutter things with ? Javadoc isn't really html. It's a java-specific doc format (like perl POD etc) that happens to resemble html. There are many markup formats that use the "separator" approach rather than the "container" approach. In practice, I think that either is bearable, so new files should follow whatever convention the project already has. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12423156
]
Niall Pemberton commented on IO-89:
---
I tried it out that way first (I have the changes ready to commit) with
SizeFileFilter - but in my mind having the limits included seems slightly more
suitable - for example up to and including 2MB or 2MB and over seems more
desirable as the default behaviour. It also makes the "size range" filter
simpler (uses 3 filters, rather than 4).
Having said that, if others agree with you then I'm not strongly fixed to this
pov. I expected the issue to be more over backwards compatibility - which would
be a shame since the main issue is consistency of behaviour and what it will
allow if they are consistent.
> Inconsistency in SizeFileFilter and AgeFileFilter implementations
> -
>
> Key: IO-89
> URL: http://issues.apache.org/jira/browse/IO-89
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.2
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 1.3
>
>
> Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
> AgeFileFilter.
> In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
> files with a size equal to and larger, whereas
> specifying an "acceptLarger" parameter of false only accepts smaller files.
> The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
> actually accepts files either the same age or older, whereas
> specifying an "acceptOlder" parameter of false only accepts newer files.
> A big benefit of resolving these inconsistencies would mean that creating
> filters for any condition (i.e. <, >, <=, >= or =) becomes
> alot easier. For example if the AgeFileFilter did only do either newer or
> older, then creating a filters for "the same age or older"
> or "the same age or younger" could be done in the following way:
> IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
> false));
> IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
> true));
> For SizeFileFilter I propose changing the logic to the following:
> if (acceptLarger) {
> return file.length() >= size;
> } else {
> return file.length() <= size;
> }
> (This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
> I have added isOlderFile() methods to FileUtils and propose that
> AgeFileFilter is changed to the following:
> if (acceptOlder) {
> return FileUtils.isFileOlder(file, cutoff);
> } else {
> return FileUtils.isFileNewer(file, cutoff);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-86) Add FileFinder back into Commons IO
[ http://issues.apache.org/jira/browse/IO-86?page=comments#action_12423131 ] Niall Pemberton commented on IO-86: --- I've deleted the FileFinder implementation and re-named FileFinderTestCase to DirectoryWalkerTestCase. I've also made the following changes to DirectoryWalker: - Change DirectoryWalker methods to use a Collection rather than List for the results - Move the handleDirectoryEnd() method within the "process" check - Change method signature for "walk" to walk(File, Collection) - that way the implementation used for results is not fixed by DirectoryWalker > Add FileFinder back into Commons IO > --- > > Key: IO-86 > URL: http://issues.apache.org/jira/browse/IO-86 > Project: Commons IO > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Niall Pemberton > Fix For: 1.3 > > Attachments: FileFinder.java, FileFinderTestCase.java, > io-filefinder-start-end.patch > > > I'd like to propose adding a "FileFinder" back into Commons IO. This is a > simplified version of what was recently moved out of Commons IO into the > "finder" component currently in the sandbox. > I believe this is a simpler, more generic implementation than the finder > component and therefore would be considered suitable for inclusion in Commons > IO. Although simpler it could be used as the basis for achieving the finder > component's aims - namely to emulate the unix find command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
[ http://issues.apache.org/jira/browse/IO-89?page=comments#action_12423130
]
Rahul Akolkar commented on IO-89:
-
Agreed, thanks for your time. My only comment is since
FileUtils.isFileNewer/Older are exclusive, perhaps we should have
SizeFileFilter be exclusive as well (so < instead of <= etc.), that way there
is consistency across filters as well.
> Inconsistency in SizeFileFilter and AgeFileFilter implementations
> -
>
> Key: IO-89
> URL: http://issues.apache.org/jira/browse/IO-89
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 1.2
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 1.3
>
>
> Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
> AgeFileFilter.
> In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
> files with a size equal to and larger, whereas
> specifying an "acceptLarger" parameter of false only accepts smaller files.
> The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
> actually accepts files either the same age or older, whereas
> specifying an "acceptOlder" parameter of false only accepts newer files.
> A big benefit of resolving these inconsistencies would mean that creating
> filters for any condition (i.e. <, >, <=, >= or =) becomes
> alot easier. For example if the AgeFileFilter did only do either newer or
> older, then creating a filters for "the same age or older"
> or "the same age or younger" could be done in the following way:
> IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
> false));
> IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
> true));
> For SizeFileFilter I propose changing the logic to the following:
> if (acceptLarger) {
> return file.length() >= size;
> } else {
> return file.length() <= size;
> }
> (This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
> I have added isOlderFile() methods to FileUtils and propose that
> AgeFileFilter is changed to the following:
> if (acceptOlder) {
> return FileUtils.isFileOlder(file, cutoff);
> } else {
> return FileUtils.isFileNewer(file, cutoff);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425158 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/ test/org/apache/commons/io/
Author: niallp
Date: Mon Jul 24 12:41:29 2006
New Revision: 425158
URL: http://svn.apache.org/viewvc?rev=425158&view=rev
Log:
IO-86 DirectoryWalker modifications, delete FileFinder and rename
FileFinderTestCase to DirectoryWalkerTestCase:
- Change DirectoryWalker methods to use a Collection rather than List
- Move the handleDirectoryEnd() method within the "process" check
- Change walk() method signature to take a Collection and not return anything
Added:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/DirectoryWalkerTestCase.java
- copied, changed from r425115,
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileFinderTestCase.java
Removed:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileFinder.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileFinderTestCase.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java?rev=425158&r1=425157&r2=425158&view=diff
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/DirectoryWalker.java
Mon Jul 24 12:41:29 2006
@@ -17,42 +17,44 @@
import java.io.File;
import java.io.FileFilter;
-import java.util.ArrayList;
-import java.util.List;
-
-import org.apache.commons.io.filefilter.IOFileFilter;
+import java.util.Collection;
/**
* Abstract class that walks through a directory hierarchy and provides
* subclasses with convenient hooks to add specific behaviour.
*
- * This class operates with a [EMAIL PROTECTED] IOFileFilter file filter} and
maximum
- * depth to limit the files and direcories visited. Commons IO supplies many
- * common filter implementations in the filefilter package.
+ * This class operates with a [EMAIL PROTECTED] FileFilter} and maximum depth
to
+ * limit the files and direcories visited.
+ * Commons IO supplies many common filter implementations in the
+ * filefilter package.
*
- * This class is extended within Commons IO to provide a file finder facility.
- * However there are many other possible extensions. For example, to delete all
+ * There are many possible extensions, for example, to delete all
* files and '.svn' directories, and return a list of deleted files:
*
* public class FileCleaner extends DirectoryWalker {
*
- *public List clean(File startDirectory) {
- * return walk(startDirectory);
+ *public FileCleaner() {
+ * super(null, -1);
*}
*
- *protected boolean handleDirectoryStart(File directory, int depth, List
results) {
- * // skip contents of svn directories
- * return !".svn".equals(directory.getName());
+ *public List clean(File startDirectory) {
+ * List results = new ArrayList();
+ * walk(startDirectory, results);
+ * return results;
*}
*
- *protected void handleDirectoryEnd(File directory, int depth, List
results) {
- * // delete svn directories
+ *protected boolean handleDirectoryStart(File directory, int depth,
Collection results) {
+ * // delete svn directories and then skip
* if (".svn".equals(directory.getName())) {
*directory.delete();
+ *return false;
+ * } else {
+ *return true;
* }
+ *
*}
*
- *protected void handleFile(File file, int depth, List results) {
+ *protected void handleFile(File file, int depth, Collection results) {
* // delete file and add to list of deleted
* file.delete();
* results.add(file);
@@ -98,14 +100,12 @@
* The event methods have the prefix handle.
*
* @param startDirectory the directory to start from
- * @return the collection of result objects, typically File objects
+ * @param results the collection of result objects, may be updated
*/
-protected List walk(File startDirectory) {
-List results = new ArrayList();
+protected void walk(File startDirectory, Collection results) {
handleStart(startDirectory, results);
walk(startDirectory, 0, results);
handleEnd(results);
-return results;
}
/**
@@ -113,9 +113,9 @@
*
* @param directory the directory to examine
* @param depth the directory level (starting directory = 0)
- * @return the collection of result objects
+ * @param results the collection of result objects, may be updated
*/
-private void walk(File directory, int depth, List results) {
+private void walk(File directory, int depth, Collection results) {
boolean process = handleDirectoryStart(directory, depth, results
[jira] Created: (VFS-73) FileObject.moveTo() destroys data when changing case
FileObject.moveTo() destroys data when changing case
Key: VFS-73
URL: http://issues.apache.org/jira/browse/VFS-73
Project: Commons VFS
Issue Type: Bug
Environment: any filesystem that's case insensitive but case
preserving (windows, osx)
Reporter: Filip Defoort
Priority: Critical
When you try to change the case of a file via FileObject.moveTo(), VFS first
deletes the target
file, which in a case-insentive FS is the same as the original and is left with
nothing no files
anymore..
For example:
StandardFileSystemManager fileSystemManager
= new StandardFileSystemManager();
fileSystemManager.setCacheStrategy(CacheStrategy.ON_RESOLVE);
fileSystemManager.init();
FileSystemOptions fileoptions = new FileSystemOptions();
FileObject root = fileSystemManager.resolveFile("/tmp/",
fileoptions);
File dummy = new File("/tmp/test.txt");
dummy.createNewFile();
Writer w = new FileWriter(dummy);
w.write("Some text");
w.close();
long size = dummy.length();
FileObject fo = root.resolveFile("test.txt");
FileObject fo2 = root.resolveFile("TeST.txt");
fo.moveTo(fo2);
At the end of the test, neither test.txt nor TeST.txt exists...
Cheers,
- Filip
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] UriParser '#' in file names
Done, I added both issues to JIRA. Cheers, - Filip Mario Ivankovits wrote: Hi Filip! I found one more 'bug' (undesired effect...): VFS can't seem to handle files with '#' in their name (don't ask.. I know, but I actually had a user that created those...) How bad. VFS itself can handle the file without any hassle. So the filename to uri conversion needs to be done somehow smarted. Could you please file a JIRA ticket on this. Ciao, Mario - 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] Created: (VFS-72) UriParser can't handle '#' in file names
UriParser can't handle '#' in file names - Key: VFS-72 URL: http://issues.apache.org/jira/browse/VFS-72 Project: Commons VFS Issue Type: Bug Environment: any. Reporter: Filip Defoort VFS can't handle a file that contains a '#' character. Don't ask me why these would be usefull but I've had a user create those and break my application. The culprit seems to be the UriParser that interpretes the part after the '#' mark to be a reference part in a URL; which results in FileObject.getURL() giving the wrong result. Cheers, - Filip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-87) Provide a convenience mehod in FileFilterUtils to create a Size Range filter
[ http://issues.apache.org/jira/browse/IO-87?page=comments#action_12423093 ] Niall Pemberton commented on IO-87: --- IMO minimumSize and maximumSize indicate that both are "inclusive" and therefore its unecessary to rename the parameters. I agree that the javadoc could be clearer in the method description and will fix that. Something like /** * Returns a filter that accepts files whose size is <= minimum size * and >= maximum size. */ Currently this method implementation adds 1 to the maximumSize specified to achieve the <= maximum - but I've just opened a bug (IO-89) relating to the inconsistency in SizeFileFilter (and AgeFileFilter) which it would be good to resolve before fixing this. > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > > > Key: IO-87 > URL: http://issues.apache.org/jira/browse/IO-87 > Project: Commons IO > Issue Type: New Feature > Components: Filters >Affects Versions: 1.2 >Reporter: Niall Pemberton > Assigned To: Niall Pemberton >Priority: Minor > Fix For: 1.3 > > > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > - by combining two SizeFileFilter's (one >= minimum and the other <= maximum) > with an AndFileFilter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425113 - /jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
Author: niallp Date: Mon Jul 24 09:28:28 2006 New Revision: 425113 URL: http://svn.apache.org/viewvc?rev=425113&view=rev Log: Update the release notes Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=425113&r1=425112&r2=425113&view=diff == --- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Mon Jul 24 09:28:28 2006 @@ -58,22 +58,27 @@ - New IOFileFilter implementation - Accepts files where File.isFile() is true - In other words it filters out directories + - Singleton instance provided (FILE) - CanReadFileFilter - New IOFileFilter implementation - Accepts files where File.canRead() is true + - Singleton instances provided (CAN_READ/CANNOT_READ/READ_ONLY) - CanWriteFileFilter - New IOFileFilter implementation - Accepts files where File.canWrite() is true + - Singleton instances provided (CAN_WRITE/CANNOT_WRITE) - HiddenFileFilter - New IOFileFilter implementation - Accepts files where File.isHidden() is true + - Singleton instances provided (HIDDEN/VISIBLE) - EmptyFileFilter - New IOFileFilter implementation - Accepts files or directories that are empty + - Singleton instances provided (EMPTY/NO_EMPTY) - TrueFileFilter/FalseFileFilter/DirectoryFileFilter - New singleton instance constants (TRUE/FALSE/DIRECTORY) @@ -81,14 +86,23 @@ (whereas if everything uses INSTANCE, then they just clash) - The old INSTANCE constants are still present and have not been deprecated +- FileFilterUtils + - new sizeFileFilter(long minimumSize, long maximumSize) method which +creates a filter that accepts files within the specified size range. + +- FileUtils + - add methods to check if a file is older (i.e. isFileOlder()) - counterparts +to the existing isFileNewer() methods. + + Feedback Open source works best when you give feedback: http://jakarta.apache.org/commons/io/ -Please direct all bug reports to Bugzilla (prefix bug reports by [io]) -http://issues.apache.org/bugzilla/buglist.cgi?product=Commons&component=IO +Please direct all bug reports to JIRA +http://issues.apache.org/jira/browse/IO Or subscribe to the commons-user mailing list (prefix emails by [io]) http://jakarta.apache.org/site/mail.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-89) Inconsistency in SizeFileFilter and AgeFileFilter implementations
Inconsistency in SizeFileFilter and AgeFileFilter implementations
-
Key: IO-89
URL: http://issues.apache.org/jira/browse/IO-89
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 1.2
Reporter: Niall Pemberton
Priority: Minor
Fix For: 1.3
Theres an inconsistency (bug?) in the implementation of SizeFileFilter and
AgeFileFilter.
In SizeFileFilter, using an "acceptLarger" parameter of true actually accepts
files with a size equal to and larger, whereas
specifying an "acceptLarger" parameter of false only accepts smaller files.
The same is true for AgeFileFilter, using an "acceptOlder" parameter of true
actually accepts files either the same age or older, whereas
specifying an "acceptOlder" parameter of false only accepts newer files.
A big benefit of resolving these inconsistencies would mean that creating
filters for any condition (i.e. <, >, <=, >= or =) becomes
alot easier. For example if the AgeFileFilter did only do either newer or
older, then creating a filters for "the same age or older"
or "the same age or younger" could be done in the following way:
IOFileFilter equalOlder = new NotFileFilter(new AgeFileFilter(cutoff,
false));
IOFileFilter equalYounger = new NotFileFilter(new AgeFileFilter(cutoff,
true));
For SizeFileFilter I propose changing the logic to the following:
if (acceptLarger) {
return file.length() >= size;
} else {
return file.length() <= size;
}
(This would mean that "new SizeFileFilter(cutoff)" would operate the same way)
I have added isOlderFile() methods to FileUtils and propose that AgeFileFilter
is changed to the following:
if (acceptOlder) {
return FileUtils.isFileOlder(file, cutoff);
} else {
return FileUtils.isFileNewer(file, cutoff);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425111 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/FileUtils.java test/org/apache/commons/io/FileUtilsTestCase.java
Author: niallp
Date: Mon Jul 24 09:23:45 2006
New Revision: 425111
URL: http://svn.apache.org/viewvc?rev=425111&view=rev
Log:
IO-88 Add isFileOlder() methods to FileUtils (counterparts to existing
isFileNewer() methods)
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java?rev=425111&r1=425110&r2=425111&view=diff
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java
Mon Jul 24 09:23:45 2006
@@ -1291,4 +1291,70 @@
return file.lastModified() > timeMillis;
}
+
+//---
+/**
+ * Tests if the specified File is older than the reference
+ * File.
+ *
+ * @param file the File of which the modification date must
+ * be compared, not null
+ * @param reference the File of which the modification date
+ * is used, not null
+ * @return true if the File exists and has been modified
before
+ * the reference File
+ * @throws IllegalArgumentException if the file is null
+ * @throws IllegalArgumentException if the reference file is null or
doesn't exist
+ */
+ public static boolean isFileOlder(File file, File reference) {
+if (reference == null) {
+throw new IllegalArgumentException("No specified reference file");
+}
+if (!reference.exists()) {
+throw new IllegalArgumentException("The reference file '"
++ file + "' doesn't exist");
+}
+return isFileOlder(file, reference.lastModified());
+}
+
+/**
+ * Tests if the specified File is older than the specified
+ * Date.
+ *
+ * @param file the File of which the modification date
+ * must be compared, not null
+ * @param date the date reference, not null
+ * @return true if the File exists and has been modified
+ * before the given Date.
+ * @throws IllegalArgumentException if the file is null
+ * @throws IllegalArgumentException if the date is null
+ */
+public static boolean isFileOlder(File file, Date date) {
+if (date == null) {
+throw new IllegalArgumentException("No specified date");
+}
+return isFileOlder(file, date.getTime());
+}
+
+/**
+ * Tests if the specified File is older than the specified
+ * time reference.
+ *
+ * @param file the File of which the modification date must
+ * be compared, not null
+ * @param timeMillis the time reference measured in milliseconds since the
+ * epoch (00:00:00 GMT, January 1, 1970)
+ * @return true if the File exists and has been modified
before
+ * the given time reference.
+ * @throws IllegalArgumentException if the file is null
+ */
+ public static boolean isFileOlder(File file, long timeMillis) {
+if (file == null) {
+throw new IllegalArgumentException("No specified file");
+}
+if (!file.exists()) {
+return false;
+}
+return file.lastModified() < timeMillis;
+}
}
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java?rev=425111&r1=425110&r2=425111&view=diff
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsTestCase.java
Mon Jul 24 09:23:45 2006
@@ -23,6 +23,7 @@
import java.net.URL;
import java.util.Arrays;
import java.util.Collection;
+import java.util.Date;
import java.util.GregorianCalendar;
import java.util.HashMap;
import java.util.Iterator;
@@ -353,11 +354,110 @@
FileUtils.sizeOfDirectory(file));
}
-// isFileNewer
+// isFileNewer / isFileOlder
+public void testIsFileNewerOlder() throws Exception {
+File reference = new File(getTestDirectory(),
"FileUtils-reference.txt");
+File oldFile = new File(getTestDirectory(), "FileUtils-old.txt");
+File newFile = new File(getTestDirectory(), "FileUtils-new.txt");
+File invalidFile = new File(getTestDirectory(),
"FileUtils-invalid-file.txt");
+
+// Create Files
+createFile(oldFile, 0);
+spin(oldFile.lastModified());
+long now = System
[jira] Created: (IO-88) Add isFileOlder() methods to FileUtils (counterparts to existing isFileNewer() methods)
Add isFileOlder() methods to FileUtils (counterparts to existing isFileNewer() methods) --- Key: IO-88 URL: http://issues.apache.org/jira/browse/IO-88 Project: Commons IO Issue Type: New Feature Reporter: Niall Pemberton Assigned To: Niall Pemberton Fix For: 1.3 Add isFileOlder() methods to FileUtils (counterparts to existing isFileNewer() methods) Also add Test cases for isFileNewer() which are are missing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [blog] Observations :)
On 7/23/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote: Hi everyone, I have been following the blog closely and it's a nice concept (and probably usable outside commons as well). Although I can see the humor in "Interviewing myself again", it would be nice if someone else did that :) To give to right example, I would like to interview Rahul Akolkar about SCXML. I will ping Rahul (unless he really doesn't want to), when I have the questions (currently have a deadline, so will probably do that after wednesday).. Glad to answer any. IMO, there are many domains where [scxml] can make contributions after its released, it will be good to get the word out. Shale, Felix, Spring is probably the starter set in my mind. -Rahul If preferred we can also wait till version 0.5 has been released :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425099 - /jakarta/commons/proper/scxml/trunk/KEYS
Author: rahul Date: Mon Jul 24 08:56:10 2006 New Revision: 425099 URL: http://svn.apache.org/viewvc?rev=425099&view=rev Log: We should really have one KEYS file for Commons, if not Jakarta, IMO. Thanks Hen for the reminder. Added: jakarta/commons/proper/scxml/trunk/KEYS (with props) Added: jakarta/commons/proper/scxml/trunk/KEYS URL: http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/KEYS?rev=425099&view=auto == --- jakarta/commons/proper/scxml/trunk/KEYS (added) +++ jakarta/commons/proper/scxml/trunk/KEYS Mon Jul 24 08:56:10 2006 @@ -0,0 +1,54 @@ +This file contains the PGP keys of various Apache developers. +Please don't use them for email unless you have to. Their main +purpose is code signing. + +Apache users: pgp < KEYS +Apache developers: +(pgpk -ll && pgpk -xa ) >> this file. + or +(gpg --fingerprint --list-sigs + && gpg --armor --export ) >> this file. + +Apache developers: please ensure that your key is also available via the +PGP keyservers (such as pgpkeys.mit.edu). + + +pub 1024D/58812457 2005-07-19 +uid Rahul Akolkar (Sign jakarta.apache.org distributions) <[EMAIL PROTECTED]> +sig 358812457 2005-07-19 Rahul Akolkar (Sign jakarta.apache.org distributions) <[EMAIL PROTECTED]> +sub 2048g/BBB9168D 2005-07-19 +sig 58812457 2005-07-19 Rahul Akolkar (Sign jakarta.apache.org distributions) <[EMAIL PROTECTED]> + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.4.1 (MingW32) + +mQGiBELdY8cRBACEN8KuZtEOAREEeVmiPF3rrF5mCXnIFaZwBHOa43pe8tUo0Rxc +lwhWydL6FkxniZfXUpbxP9umJ7NAJ3w3kGYIFjaVOdYdx+dkvb+hNwrsaBJaFfHz +3XUzDXvQ9feWRO3+k3zFT+fJYjLmRfj5/0wQVoqCYfhvVJ9YV+auV75WHwCgq7db +LbujmyVPqZI9HbKB8siRSZsD/j7LnuaTdy11NORvRBHOtX0U+WqYPjTlwY6Zjf3w +TzFv95sZlKEjRuDSrUDAjLJ27q3uZU+MNoY+C+diRQOYbqKYED33IjmRD/pDjKFu +rwjsiUGf+mslNgrKW65iokRN2rziJreCL8+mpq77ibqOxKQhsu6lPaLdCaOw7uk/ +WXpRBACChTD9fWXlpNmSU6QsgICh4Vz1UlqG1AnldnF93LhHcLdGWeG59NMz7CHF +16nsR1PUSn+UIq5K/uWBbiLEY94mZ6aLafrgqR1+lXZQBhVLJ46rVz+5oYyXa+Ic +ltqaoxIR56t0edAyIuhZTAFm/mL3PxFdfdEoGpCqZ1Y4JyFlqLRIUmFodWwgQWtv +bGthciAoU2lnbiBqYWthcnRhLmFwYWNoZS5vcmcgZGlzdHJpYnV0aW9ucykgPHJh +aHVsQGFwYWNoZS5vcmc+iF4EExECAB4FAkLdY8cCGwMGCwkIBwMCAxUCAwMWAgEC +HgECF4AACgkQUL3OIliBJFd+LQCfY6jNIFHbvdzAeHmDhvRlKjPV5XUAn2vMRjtW +Wu6sBhzXrgrKUz6R4L/GuQINBELdY9cQCADZ2DQIXGjjyPZswkO5nQYGSVf1mSms +SyioIpYiWTx0UGQbWeVXb2QIhPQ1Ti6wBsFSSmx1EDb9HXE9GzPbjrq/c5+tz39h +IzZNwZ1ddQ11z8h9JBoIZ8e46645ak9Wa5GjHX7nJ01fGmncnT72rQc1X7IsJQAj +oikiQlVpIeHJZHC3PLgwfppjiD9RSWzrMQhIe1pAKxMvW44rTV4ZaC8HlwRxLVWO +2l3OSFL0ggwMAePH2xzsWT3AEz4oz7vIon9IcvoonE5nmN97aJDbSk+Iy979awLI +TfLYf5slIHpv7mg23FYvXrIqVdGcc8fxijzClBM/DUZHW9xqX6Ydjoq3AAMHB/42 +82229hxAOzXCj2i0kZHe1EMZJYvA9JTv6OideupkPL3fkkSY2BTXKQYe44ICmHUz +/vr4jGULpte7VMTLOJIX8fCb1mzWjhpWGkqIbLMCFVowRphzE5svj6Va5mNDpZwL +WI1/7AZeYss8mFztLJe5l7njzj4s1mBH9WcvSL7LQjQnqmS8mkywt7oEZLQxZ9Ib +5slgr74UXgq502uQXwsAxIOeEXUCjphVpwggvBnSXBxgXT96N4U3OKXMswWItqPC +FJZZuF4PrImYImQGfWHP0M8JlS8ywAixtmCHKghvrW1ZA1+stA7tYsD/vK8qsxhC +Fupr5ytIA3Gv3TVGupQ1iEkEGBECAAkFAkLdY9cCGwwACgkQUL3OIliBJFdFywCf +TpBnwib73+MI+nazOyU++sNWjsgAoJCVKCTVWoEC3XvF4repMXT9Bxm7 +=PT52 +-END PGP PUBLIC KEY BLOCK- + + + Propchange: jakarta/commons/proper/scxml/trunk/KEYS -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425097 - in /jakarta/commons/proper/scxml/trunk: pom.xml project.xml
Author: rahul Date: Mon Jul 24 08:53:12 2006 New Revision: 425097 URL: http://svn.apache.org/viewvc?rev=425097&view=rev Log: Add Niall to contributors section. Thanks for the many suggestions and changes related to the 0.5 RCs (I tend to think that adding to the developers section is your call). Modified: jakarta/commons/proper/scxml/trunk/pom.xml jakarta/commons/proper/scxml/trunk/project.xml Modified: jakarta/commons/proper/scxml/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/pom.xml?rev=425097&r1=425096&r2=425097&view=diff == --- jakarta/commons/proper/scxml/trunk/pom.xml (original) +++ jakarta/commons/proper/scxml/trunk/pom.xml Mon Jul 24 08:53:12 2006 @@ -89,6 +89,9 @@ Heiko Eichberger + + Niall Pemberton + Modified: jakarta/commons/proper/scxml/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/project.xml?rev=425097&r1=425096&r2=425097&view=diff == --- jakarta/commons/proper/scxml/trunk/project.xml (original) +++ jakarta/commons/proper/scxml/trunk/project.xml Mon Jul 24 08:53:12 2006 @@ -95,6 +95,9 @@ Heiko Eichberger + + Niall Pemberton + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Preparing a release
On 7/24/06, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: Hi folks! I have already uploaded the files for a 1.2 release candidate to http://people.apache.org/~ozeigermann/tx-1.2rc1/ Not quite sure where to go from here. Do we need a vote for the release candidate? Its your judgement call on how long you give people to review the release candidate before calling a vote. I would typically give it at least a week before calling a vote for a first RC. If you have to roll subsequent RC then possibly a shorter timescale depending on the amount of change and how trivial/non-trivial the changes are from the previous RC - but again its your judgement call. If you state the planned timescale and anyone doesn't like it, they can always shout. Where to put the files for the release candidate for public inspection? Putting them in your personal space (as you have done) is the norm. Thanks in advance for any hints and cheers I think the hard part is usually getting a RC to pass a vote - satisfying the issues raised/nit picks. Once you get through that and the vote has passed, its just a case of following the "cutting a release" guidelines: http://jakarta.apache.org/commons/releases/release.html I'll try to review rc1 soon and give you my feedback (hopefully not much as I committed my transaction nit picks a week or two ago). Niall Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [compress] Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niall Pemberton wrote: > Slightly OT for this thread, but compress now has a nightly build: > http://people.apache.org/builds/jakarta-commons/nightly/commons-compress/ That's great :-) > Will email my fax number to Torsten/Chris and see if I can a) receive fax from Chris and b) give it to Jim at OSCON. I'll resend the fax this evening. Cheers, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExNn7kv8rKBUE/T4RAv5kAJ4yPNHE9z8QKksaZe/i1O/4htrOBACgjs+O nvYsJqSNwYTiswk+5qn7d9I= =8G1W -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [compress] Status
Slightly OT for this thread, but compress now has a nightly build: http://people.apache.org/builds/jakarta-commons/nightly/commons-compress/ Niall On 7/24/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On 7/19/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 7/18/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: > > > It's high time we just committed these changes and moved on from there, > > > I think. > > > > Yepp! That was what Mario I thought, too ...we are only waiting for > > Jim to acknowledge the software grant. (*sigh*) > > Gotya, which hasn't been received yet. > > I'll ask Jim tomorrow if he has a backlog to put in (presuming he's > online and that it was a fax). Otherwise, probably need to resend. Jim > gets a fair number of unreadable transmissions. Nothing from Jim this week. Will email my fax number to Torsten/Chris and see if I can a) receive a fax from Chris and b) give it to Jim at OSCON. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 81 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24072006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at or
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 81 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24072006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24072006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at or
[transaction] Preparing a release
Hi folks! I have already uploaded the files for a 1.2 release candidate to http://people.apache.org/~ozeigermann/tx-1.2rc1/ Not quite sure where to go from here. Do we need a vote for the release candidate? Where to put the files for the release candidate for public inspection? Thanks in advance for any hints and cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r425012 - in /jakarta/commons/proper/transaction/trunk: build.xml project.xml
Author: ozeigermann
Date: Mon Jul 24 04:15:16 2006
New Revision: 425012
URL: http://svn.apache.org/viewvc?rev=425012&view=rev
Log:
Preparation for 1.2 release
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
jakarta/commons/proper/transaction/trunk/project.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?rev=425012&r1=425011&r2=425012&view=diff
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Mon Jul 24 04:15:16 2006
@@ -20,7 +20,7 @@
-
+
Modified: jakarta/commons/proper/transaction/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?rev=425012&r1=425011&r2=425012&view=diff
==
--- jakarta/commons/proper/transaction/trunk/project.xml (original)
+++ jakarta/commons/proper/transaction/trunk/project.xml Mon Jul 24 04:15:16
2006
@@ -9,7 +9,7 @@
Commons Transaction
Commons Transaction
- 1.1.1-SNAPSHOT
+ 1.2-rc1
http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/
org.apache.commons.${pom.artifactId.substring(8)}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Attributes 2.2
I've checked the docs once more. It's looking good. There was a typo on the index.xml page that I fixed. I also noticed that there is a big "IMPORTANT" sign on the overview page of the Javadocs [1]. I think this should be removed from api/src/java/overview.html prior to release and then it can be put back in again. Oh, and remember to add the correct date for the 2.2 release under the News section of index.xml. So I say go! +1 [1]http://people.apache.org/~bayard/commons-attributes/docs/api/index.html -- Dennis Lundberg Henri Yandell wrote: This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r424985 - /jakarta/commons/proper/attributes/trunk/site/xdocs/index.xml
Author: dennisl Date: Mon Jul 24 02:48:21 2006 New Revision: 424985 URL: http://svn.apache.org/viewvc?rev=424985&view=rev Log: Fix typo in A Quick Sample. Modified: jakarta/commons/proper/attributes/trunk/site/xdocs/index.xml Modified: jakarta/commons/proper/attributes/trunk/site/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/attributes/trunk/site/xdocs/index.xml?rev=424985&r1=424984&r2=424985&view=diff == --- jakarta/commons/proper/attributes/trunk/site/xdocs/index.xml (original) +++ jakarta/commons/proper/attributes/trunk/site/xdocs/index.xml Mon Jul 24 02:48:21 2006 @@ -138,7 +138,7 @@ } /** - * Add a Myattribute with value 0.8. + * Add a MyAttribute with value 0.8. * * @@MyAttribute( 0.8 ) */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Attributes 2.2
+1 Let's get it out the door. Thank you for doing the release, Henri. /LS On 7/24/06, Henri Yandell <[EMAIL PROTECTED]> wrote: This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-87) Provide a convenience mehod in FileFilterUtils to create a Size Range filter
[ http://issues.apache.org/jira/browse/IO-87?page=comments#action_12423008 ] Stephen Colebourne commented on IO-87: -- The parameters need to specify whether they are inclusive or exclusive, for example @param minSizeInclusive @param maxSizeExclusive This then needs adding to release notes, and the call closing. > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > > > Key: IO-87 > URL: http://issues.apache.org/jira/browse/IO-87 > Project: Commons IO > Issue Type: New Feature > Components: Filters >Affects Versions: 1.2 >Reporter: Niall Pemberton > Assigned To: Niall Pemberton >Priority: Minor > Fix For: 1.3 > > > Provide a convenience mehod in FileFilterUtils to create a Size Range filter > - by combining two SizeFileFilter's (one >= minimum and the other <= maximum) > with an AndFileFilter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-compress has an issue affecting its community integration. This issue affects 13 projects, and has been outstanding for 56 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. - logging-log4j-chainsaw : Chainsaw log viewer Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-compress-24072006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/gump_work/build_jakarta-commons-sandbox_commons-compress.html Work Name: build_jakarta-commons-sandbox_commons-compress (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: maven-xdoc-plugin-1.9.2.jar (try downloading from http://maven.apache.org/reference/plugins/xdoc/) Total time: 4 seconds Finished at: Mon Jul 24 01:18:48 PDT 2006 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2224072006, vmgump.apache.org:vmgump-public:2224072006 Gump E-mail Identifier (unique within run) #24. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-compress (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-compress has an issue affecting its community integration. This issue affects 13 projects, and has been outstanding for 56 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-compress : Commons Compression Package - commons-vfs : Jakarta commons - excalibur-fortress-bean : Repository of reusable components. - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-fortress-container-test : Repository of reusable components. - excalibur-fortress-examples : Repository of reusable components. - excalibur-fortress-migration : Repository of reusable components. - excalibur-fortress-platform : Repository of reusable components. - excalibur-fortress-testcase : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - excalibur-xmlutil : Repository of reusable components. - logging-log4j-chainsaw : Chainsaw log viewer Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-compress-24072006.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/project.properties -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/gump_work/build_jakarta-commons-sandbox_commons-compress.html Work Name: build_jakarta-commons-sandbox_commons-compress (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/compress] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: maven-xdoc-plugin-1.9.2.jar (try downloading from http://maven.apache.org/reference/plugins/xdoc/) Total time: 4 seconds Finished at: Mon Jul 24 01:18:48 PDT 2006 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-compress/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2224072006, vmgump.apache.org:vmgump-public:2224072006 Gump E-mail Identifier (unique within run) #24. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] UriParser '#' in file names
Hi Filip! > I found one more 'bug' (undesired effect...): VFS can't seem to handle > files with '#' in their > name (don't ask.. I know, but I actually had a user that created > those...) How bad. VFS itself can handle the file without any hassle. So the filename to uri conversion needs to be done somehow smarted. Could you please file a JIRA ticket on this. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Attributes 2.2
+1 from a nightly build user. Henri Yandell a écrit : This is a vote for releasing Commons Attribetus 2.2 based on RC2. RC2 is here: http://people.apache.org/~bayard/commons-attributes --- [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... Vote will close Friday evening (PST). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
