Re: NOTICE required for JcrUtils from Jackrabbit 2.4.0?
Hi, Your assumption is correct. The NOTICE entry refers to code from the original Day Software grant that accompanied Jackrabbit's entry to the Incubator ( http://wiki.apache.org/incubator/JcrProposal). The JcrUtils class was contributed under normal CLA and thus doesn't need extra NOTICE entries. Best, Jukka Zitting On Mon, May 16, 2016 at 4:02 AM Stian Soiland-Reyes wrote: > Hi, > > In reviewing an RC for Apache Commons VFS 2.1 > > https://lists.apache.org/thread.html/Zjouqd6cpmohrj3 > > we wondered about a file > > > https://github.com/apache/commons-vfs/blob/trunk/core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java > > which we have adapted from Jackrabbit 2.4.0. > > Jackrabbit has a NOTICE which includes > > > Based on source code originally developed by > > Day Software (http://www.day.com/). > > > Looking at the git history > > > https://github.com/apache/jackrabbit/commits/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java > > I think this file was earliest added in JackRabbit in 2009 by Jukka > Zitting: > > > https://github.com/apache/jackrabbit/commit/0882a5cc1ed4ce1cf9d3c6b3a592f97c5772ce25 > > (first released in 1.6.0 and 2.0-alpha1 ) > > Is this correct, or was this file based on earlier code? > > > > As Jackrabbit graduated from the Incubator in 2006, am I right to > assume then that JcrUtils.java is NOT covered by the earlier "Day > Software" Software Grant and corresponding NOTICE attribution? > > That is, is Apache Commons free to not propagate your NOTICE for using > JcrUtils? > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons RDF (incubating) > http://orcid.org/-0001-9842-9718 >
Re: [VOTE] Release Commons Compress based on RC2
Hi, [x] +1 release it Reviewed commons-compress-1.1-src.tar.gz (SHA1: fd728ec4374380831dc906b27d77b589b555a791). BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Compress based on RC1
Hi, [x] +1 release it Tested with commons-compress-1.1-src.tar.gz (SHA1: eb2ae3125bae678a1615c0016e9bf7518771f26a) on Linux with Sun Java 1.6.0_16. Builds, passes all tests, and integrates well with Apache Tika. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [IO] encapsulating open/close
Hi,
On Fri, Aug 6, 2010 at 10:54 AM, wrote:
> My suggestion is providing an interface and a convenience method, which an
> expression of this interface als argument. In this method opening and
> closing will be done. I think, this would be the natural way in java. When
> closures came, the client code will look short.
OK, I see what you're after. Not sure though if there can be any clean
API (i.e. one that's less verbose than a "open(); try { ... } finally
{ close(); }" block) for that without language extensions. The best
solutions I've seen are the automatic resource management blocks [1]
proposed for Java 7 and the @Cleanup annotation [2] from Project
Lombok.
[1] http://mail.openjdk.java.net/pipermail/coin-dev/2009-April/001481.html
[2] http://projectlombok.org/features/Cleanup.html
BR,
Jukka Zitting
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] encapsulating open/close
Hi, On Wed, Aug 4, 2010 at 12:27 PM, wrote: > Wanted is a convenience method that hides the opening and closing of a file > connection. This would avoid redundancy and failures by accidently not > closing the file connection. I have implemented this before, but now I want > to use apache commons io and I am asking why this isn't there. I could > contribute this. Not sure if this is exactly what you're looking for, but have you seen the AutoCloseInputStream [1] class? [1] http://commons.apache.org/io/api-release/org/apache/commons/io/input/AutoCloseInputStream.html BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] encapsulating open/close
Hi, On Wed, Aug 4, 2010 at 12:27 PM, wrote: > Wanted is a convenience method that hides the opening and closing of a file > connection. This would avoid redundancy and failures by accidently not > closing the file connection. I have implemented this before, but now I want > to use apache commons io and I am asking why this isn't there. I could > contribute this. Not sure if this is exactly what you're looking for, but have you seen the AutoCloseInputStream [1] class? [1] http://commons.apache.org/io/api-release/org/apache/commons/io/input/AutoCloseInputStream.html BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] release 1.1?
Hi, On Tue, Jul 20, 2010 at 10:57 AM, Torsten Curdt wrote: > ...maybe then there is one more thing to squeeze in then Unless there's already a ready patch for this, I'd rather see the 1.1 release out than wait for a new improvement. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] New release soon?
Hi, On Sun, Apr 25, 2010 at 11:29 PM, Antoni Mylka wrote: > W dniu 2010-04-13 18:21, Christian Grobmeier pisze: >> Oh yes... thanks for the reminder. there is one code review open, then >> we can discuss to proceed. [...] > > Which code review do you have in mind? I've taken a look at the Jira and > there is 1 issue for 1.0 and 3 ones for 1.1. Of those four 2 are connected > with release-management issues (SHA1 files and acknowledgements in README). > The remaining two seem to be as good as fixed. Agreed. I postponed the acknowledgement issue to after 1.1 and the remaining two issues seem to be pretty much done already. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] New release soon?
Hi, On Fri, Feb 12, 2010 at 2:10 PM, Christian Grobmeier wrote: > Stefan has made several bugfixes - I wonder if we should do a 1.1 quite soon. > Since I have not done to much code changes lately due to other > project, I volunteer for preparing the 1.1 release in three weeks, if > we think its already time. And I think it is +1 We'd love to use a new commons-compress release in Tika. Re: 1.1 vs 1.0.1; There's new public API in the codebase, so we should call the release 1.1. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Commons - Commons Compress -
Hi, On Sun, Dec 13, 2009 at 6:39 PM, contin...@vmbuild.apache.org wrote: > Maven221MultiVolumeTest > testRead7ZipMultiVolumeArchiveForStream : > junit.framework.AssertionFailedError > junit.framework.AssertionFailedError: shouldn't be able to read another > entry from truncated file Fixed in revision 890110. I didn't expect FileInputStream.skip() to happily skip past the end of the file! BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[cli] (or [cli2]?) Plans for CLI 2.0 release?
Hi, Apache Mahout is moving to fully a Maven-based build/release process and they're having problems with the commons-cli 2.0 dependency which I believe they get through Hadoop. To solve the dependency issue, Mahout has deployed that snapshot to Maven central as org.apache.mahout.commons:commons-cli:2.0-mahout. This works for now, but is clearly not an ideal solution. So, are there plans for releasing CLI 2.0? The codebase is obviously already being used, so having an official release would be quite nice. If the API is still not final, would it make sense to release something like 2.0-alpha1 to make downstream projects happy without making strict backwards compatibility commitments? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] [PATCH]Commons IO New Functionality, Minor Patches
Hi, ... and please included "[io]" in the subject line to help people with filters on this list. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [PATCH]Commons IO New Functionality, Minor Patches
Hi, On Wed, Oct 28, 2009 at 4:42 AM, David Armstrong wrote: > The new functionality is a class that copies files, called FileCopier > and some helper classes. This class goes beyond the functionality of > the static methods included in the FileUtils class. It has the > following functionality: Sounds like an useful addition. Can you file a feature request about this in https://issues.apache.org/jira/browse/IO and attach the code there? It would be easier for us to review the code if you could provide it as a patch against the latest svn trunk. That way it would be clearer what parts you have changed and how. You can get a nicely formatted patch with "svn diff" after you've "svn add"ed all the new files you've created. > The patches I included are pretty minor. For FileUtils.java, I changed > the access for doCopyFile() from private to protected so that > FileCopier could make use of its functionality. For IOUtils.java, I > replaced the multiple closeQuietly() methods with one closeQuietly() > method that takes an object that implements Closeable as its argument. > If these patches are not acceptable, please let me know. The latter change sounds like something that could break binary backwards compatibility. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Filter suggestions
Hi, On Wed, Oct 21, 2009 at 3:50 PM, James Carman wrote: > Search for [IO]? Hmm, it turns out that Gmail search drops square brackets from search terms, which seems to be the root of my problems with filtering these lists... :-( Now that I realized this, I was able to construct the following reasonably accurate (95% or so) Gmail search pattern for Commons IO traffic: (list:(user.commons.apache.org OR dev.commons.apache.org) subject:io) OR (list:commits.commons.apache.org subject:proper/io) BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Filter suggestions
Hi, Does anyone know of any sane way to filter the commons mailing list in Gmail? I have no way to keep up with the daily torrent of mail here, and so far I haven't found any reliable way to pick for example just the messages about Commons IO. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Towards the 2.0 release
Hi, On Wed, Aug 19, 2009 at 10:47 AM, Jörg Schaible wrote: > The only concern I have are the new Broken(In/Out)putStream implementations. > IMHO those are somewhat out-of-scope for IO, you explicitly mention that > these implementations are for testing purposes. I'd rather see commons-test > reactivated than putting such code into a component that is normally used > in production code. If you feel strongly about this I guess we can do that or move the broken streams to src/test/java inside Commons IO where they are already used for testing the tagged stream classes (any downstream users would then need to copy the sources). But personally I don't understand the "normally used in production" argument. Test code benefits from reuse just as much as normal code. And there are a lot of test projects (TCKs, etc.) that are in production use. AFAIUI the purpose of Commons is to create reusable code, regardless of the scope or field of that reuse. And Commons IO is defined as "library of utilities to assist with developing IO functionality". IMHO utilities to help test IO code are clearly within this scope. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[io] Towards the 2.0 release
Hi, There's quite a lot of good new stuff in the Commons IO trunk and I'd like to start slowly (timescale: months) pushing towards the 2.0 release. Please make sure that any issues you want to see resolved before the release are tagged for 2.0 in Jira. Note that I removed the 1.5 release tag from Jira in favor of 2.0 as I don't believe there is much more interest in another 1.x release. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] Git mirror available
Hi, On Wed, May 27, 2009 at 4:34 PM, Russel Winder wrote: > Is it guaranteed that the Git read-only mirror repository will always be > exactly up to date to the Subversion repository? (i.e. will every commit > to the Subversion store cause a refresh of the Git read-only mirror?) Yes. The mirror is listening for commit notification messages and will automatically update itself whenever it sees commons-cli commits. The delay is typically just a few seconds. > However if there is potential delay in mirroring or if a committer wants > to use Git to commit to the Subversion repository using Git then a clone > of the read-only mirror needs to be retargetted to the Subversion store > directly. That's also possible, though the instructions [1] are still a bit sketchy. With that setup it's even possible to commit directly to the Subversion repository from your Git clone! > It would be good if this page explained how to retarget the clone taken > so that it can be kept up to date with Subversion directly. i.e. What > is the sequence of instructions that allow "git svn fetch" to refresh > the git clone from the Subversion repository and "git svn dcommit" will > commit to the Subversion repository. As mentioned by others, we'd love to see suggestions (better yet, patches) of improvements on the infrastructure-dev@ mailing list or in the INFRA Jira under the Git component. [1] http://wiki.apache.org/general/GitAtApache BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-compress-1.0 based on RC2 (Rev: 774630)
Hi, Sorry for being late... On Thu, May 14, 2009 at 7:54 AM, Christian Grobmeier wrote: > RC2 is based on SVN revision: 774630 [x] +1 release it (non-binding) Reviewed the commons-compress-1.0-src.tar.gz package with SHA1 sum e2cda720dd116a5172f56528a6c212fe56f372ef. Matches the svn tag (except for the PROPOSAL.txt and doap_compress.rdf files, why?), builds and passes tests on Vista with Java 6, works well with Apache Tika. The only concern I have are the extra entries in NOTICE.txt. As discussed earlier, I'd rather see them in a README file. No need to cancel 1.0 for this, but I filed COMPRESS-72 so we remember to fix this for future releases. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New sandbox project -- Apache Commons (Portable) Runtime
Hi, On Sat, Apr 4, 2009 at 9:21 AM, Mladen Turk wrote: > The project is completely different from other > commons projects, because it contains platform native > code beside java api. Commons Daemon already does that and seems to cover some of the same functionality. Would it make sense to merge these codebases? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[site] How is the Commons site built/deployed?
Hi, I'm setting up the JCR Commons subproject in Apache Jackrabbit, and I'd like to follow the example of Apache Commons in setting up the web site. However, I couldn't find where the sources of the Commons site are located (I can find the site sources of individual components, but what binds them together?) and how the site is built and deployed. Any pointers? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] Successful use in Apache Tika
Hi, I just made a patch (see TIKA-204 [1]) to Apache Tika where I replaced our custom copies of the Ant classes with a proper dependency to commons-compress 1.0-SNAPSHOT. Everything works fine and I was even able to get rid of the extra customization we did for the bzip reader in Ant not wanting to see the first two bytes of the stream. So, apart from tweaking the NOTICE file (see my other message), from my perspective the current compress trunk is ready for release. :-) [1] https://issues.apache.org/jira/browse/TIKA-204 BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] Code history in NOTICE
Hi, The commons-compress NOTICE file currently contains the following entries: Original BZip2 classes contributed by Keiron Liddle , Aftex Software to the Apache Ant project Original Tar classes from contributors of the Apache Ant project Original Zip classes from contributors of the Apache Ant project Original CPIO classes contributed by Markus Kuss and the jRPM project (jrpm.sourceforge.net) Since these are included in the NOTICE file, section 4.d of ALv2 requires that all downstream projects include a readable copy of that information. Is this something that we need to require, i.e. was this a requirement of the original contributions? If not, I'd rather move these notes to the README file. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Common location for DOAP files?
Hi, On Fri, May 23, 2008 at 3:54 AM, sebb wrote: > At present the doap files are in each project trunk, and therefore > presumably get copied to tags (and branches), where they don't really > make sense. They don't? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
Hi, On Fri, Mar 13, 2009 at 11:33 PM, Siegfried Goeschl wrote: > if Dennis has no time I can help out during Hackathon I'd be happy to help with any compress-related stuff on Tuesday during the Hackathon. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Promote Compress to Commons Proper
Hi, On Fri, Mar 13, 2009 at 4:58 AM, Stefan Bodewig wrote: > The compress component shall become a proper Commons component: [x] +1 Yes BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Promoting commons-compress to proper
Hi, On Mon, Mar 9, 2009 at 6:00 PM, Stefan Bodewig wrote: > We currently have three developers listed (Sebb, you may want to add > yourself) and two pretty active contributors as well as a request > for promotion/release by Jukka. Doesn't sound too bad to me. Yep. We'll probably start using the component in Tika as soon as a release is available, and through Tika the code will soon find it's way to wider use in projects like Solr and Jackrabbit. I wouldn't be surprised if these uses resulted in at least a few contributions trickling back to here. And perhaps Ant (and selected Maven plugins, etc.) would be interested in using the component too. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Schedule for a release?
Hi, On Thu, Feb 26, 2009 at 5:34 PM, Stefan Bodewig wrote: > On 2009-02-26, Jukka Zitting wrote: >> I looked at the compress component in the sandbox and it's exactly >> what we could use in Apache Tika, see [1]. > > If you pick up the latest code from Ant instead you'll see they are > the same 8-) Actually we're already using the code from Ant in Apache Tika (see subpackages of [1]) but I'd rather replace those classes with a proper dependency to somewhere where we can point people if they have problems parsing specific files. It's much better if such problems are fixed in a generic library instead of us maintaining the code just in Tika. Also, a dependency to a small and tightly scoped library like commons-compress would be much better than a dependency to Ant. [1] https://svn.eu.apache.org/repos/asf/lucene/tika/trunk/src/main/java/org/apache/tika/parser/pkg/ BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] Schedule for a release?
Hi, I looked at the compress component in the sandbox and it's exactly what we could use in Apache Tika, see [1]. What's the current status of the codebase? Any plans of graduation to Commons proper and of doing a 1.0 release? [1] https://issues.apache.org/jira/browse/TIKA-204 BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Binary compatible
Hi, On Sat, Feb 14, 2009 at 1:17 PM, Jukka Zitting wrote: > org.apache.commons.io: > Bad > method org.apache.commons.io.FileUtils.copyFileToDirectory(java.io.File, > java.io.File): type void in io-1.4, but type java.io.File in io-trunk > method org.apache.commons.io.FileUtils.copyFileToDirectory(java.io.File, > java.io.File, boolean): type void in io-1.4, but type java.io.File in > io-trunk I reopened IO-157 that introduced the new return value. > org.apache.commons.io.output: > Bad > method org.apache.commons.io.output.NullWriter.append(char): throws > java.io.IOException in io-1.4, but doesn't throw java.io.IOException > in io-trunk > method org.apache.commons.io.output.NullWriter.append(java.lang.CharSequence): > throws java.io.IOException in io-1.4, but doesn't throw > java.io.IOException in io-trunk > method org.apache.commons.io.output.NullWriter.append(java.lang.CharSequence, > int, int): throws java.io.IOException in io-1.4, but doesn't throw > java.io.IOException in io-trunk These don't break binary compatibility, and I don't believe that there is any affected source code out there (the affected code would be explicitly equivalent to a no-op). BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Binary compatible
Hi, On Sat, Feb 14, 2009 at 12:48 PM, Jukka Zitting wrote: > On Sat, Feb 14, 2009 at 12:12 PM, Stephen Colebourne > wrote: >> I reviewed some of HEAD of IO last night. It is currently binary >> incompatible with the 1.x series, yet the package name has not changed. > > What incompatibilities are there? Can we fix them? Japitools reports the following five issues: org.apache.commons.io: Bad method org.apache.commons.io.FileUtils.copyFileToDirectory(java.io.File, java.io.File): type void in io-1.4, but type java.io.File in io-trunk method org.apache.commons.io.FileUtils.copyFileToDirectory(java.io.File, java.io.File, boolean): type void in io-1.4, but type java.io.File in io-trunk org.apache.commons.io.output: Bad method org.apache.commons.io.output.NullWriter.append(char): throws java.io.IOException in io-1.4, but doesn't throw java.io.IOException in io-trunk method org.apache.commons.io.output.NullWriter.append(java.lang.CharSequence): throws java.io.IOException in io-1.4, but doesn't throw java.io.IOException in io-trunk method org.apache.commons.io.output.NullWriter.append(java.lang.CharSequence, int, int): throws java.io.IOException in io-1.4, but doesn't throw java.io.IOException in io-trunk All look like fairly simple things to fix. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Binary compatible
Hi, On Sat, Feb 14, 2009 at 12:12 PM, Stephen Colebourne wrote: > I reviewed some of HEAD of IO last night. It is currently binary > incompatible with the 1.x series, yet the package name has not changed. What incompatibilities are there? Can we fix them? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Version for Java 1.4
Hi, On Sun, Feb 8, 2009 at 8:54 PM, Henri Yandell wrote: > On Sun, Feb 8, 2009 at 5:04 AM, Niall Pemberton >> I think the new Java5 stuff in trunk should be released as IO 2.0 - so >> we could release a IO 1.5 version that is for JDK 1.4. Having said >> that JDK 1.4 is so old now I don't really think we should bother >> supporting it and just focus on getting a release of the latest stuff >> out. > > +1. 1.4 is too dead, move JackRabbit off it ;) Yeah. :-) Before Jackrabbit 2.0 later this year we'll probably still do at least one more minor Jackrabbit 1.x release based on Java 1.4, and it would be nice to have it depend on a recent Commons IO version. However, this itch is not big enough that I'd volunteer to manually backport changes to IO_1_4_BRANCH. A retrotranslated version of IO 2.0 would be nicer, or alternatively I'd copy and backport just the relevant classes into the Jackrabbit codebase. In any case I agree that having IO 2.0 out would be nice. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New committer: Paul Benedict
Hi, On Mon, Feb 9, 2009 at 3:48 AM, Henri Yandell wrote: > Welcoming Paul as a new committer to Commons. Realizing that we don't > announce this very publicly usually. > > Mark Thomas became a committer at the start of January and Ralph Goers > became a committer back in November. Dan Fabulich became a sandbox > committer a couple of days ago. Welcome to all! BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Commons - Commons IO -
Hi, On Fri, Feb 6, 2009 at 5:30 PM, Jukka Zitting wrote: > On Fri, Feb 6, 2009 at 4:36 PM, contin...@vmbuild.apache.org >> FilesystemObserverTestCase >> testFileCreate : >> junit.framework.AssertionFailedError >> junit.framework.AssertionFailedError: E[0 0 0 1 0 0]: No. of directories >> changed expected:<1> but was:<0> > > This doesn't seem related to the change I committed and I can't > reproduce the failure locally. Can someone with Continuum access check > what this is about? Looks like a random failure, as another unrelated commit fixed the problem. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] svn commit: r741531
Hi, On Sat, Feb 7, 2009 at 7:51 AM, Rahul Akolkar wrote: > eol-style wasn't set for the additions in this rev Thanks for catching this! I added the missing eol-style settings in revision 741859. > (but in a later rev, r741562, the prop came through with the adds). Looks like my new Eclipse install was not picking up my svn settings for revision 741531. I used the svn command line to commit revision 741562. I'll fix my Eclipse setup. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Commons - Commons IO -
Hi, On Fri, Feb 6, 2009 at 4:36 PM, contin...@vmbuild.apache.org wrote: > Online report : > http://vmbuild.apache.org/continuum/buildResult.action?buildId=141109&projectId=155 That page is read-protected even after I registered an account on the Continuum instance. > FilesystemObserverTestCase > testFileCreate : > junit.framework.AssertionFailedError > junit.framework.AssertionFailedError: E[0 0 0 1 0 0]: No. of directories > changed expected:<1> but was:<0> This doesn't seem related to the change I committed and I can't reproduce the failure locally. Can someone with Continuum access check what this is about? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[io] Version for Java 1.4
Hi, Commons IO trunk is already using Java 5 features (which is nice), but I was wondering about how we can make the next IO release usable in environments that still run Java 1.4. For example I've just added a few extra classes (see IO-192 and IO-193) that I'd like to start using in projects like Apache Jackrabbit that still target Java 1.4 as the base platform. One option that we use in Apache Tika is the Maven retrotranslator plugin. It produces an extra retrotranslated version of the jar artifact for use in Java 1.4 environments. Another option is to maintain a separate branch for a Java 1.4 (or older) version of Commons IO. Any thoughts on this? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposal: Commons SAX
Hi, On Wed, Dec 31, 2008 at 2:55 PM, Jukka Zitting wrote: > Until we come up with consensus on where (Commons, Xerces or Cocoon) > we should place this proposed library, I'd like to start putting some > bits together in the Commons Sandbox. I've now set up a project skeleton at https://svn.apache.org/repos/asf/commons/sandbox/xml. See below for the PROPOSAL I wrote for this effort. I'll be adding some initial code from various sources in the next few weeks. Feel free to jump in if you're interested. BR, Jukka Zitting Proposal for the Commons XML Package 0. Rationale Many Apache projects have implemented utility classes for working with XML documents and the Java API for XML Processing (JAXP) interfaces. These classes can encapsulate years of experience with XML processing, but they can be hard to find and reuse outside the originating project. It would be beneficial to have a well maintained shared library of such code. Various Apache projects like Xerces and Cocoon have been suggested as appropriate places where such a shared library could be developed and maintained. No clear consensus has however been reached on this matter. For now the plan is to just start collecting initial code and interested contributors in the Commons sandbox. We can revisit the question of the eventual location of this codebase once it is clearer what code will be included and who are most interested in developing and maintaining the code. 1. Scope of the Package The Commons XML package will contain utility code designed to make working with JAXP easier. The goal is to work with the existing JAXP infrastructure instead of trying to come up with an alternative. 1.5 Interaction With Other Packages The Commons XML package will depend only on the Java 5 platform and the JAXP interfaces included in it. No external dependencies or configuration files will be used. 2. Initial Source of the Package The initial code of the Commmons XML package will be collected from various Apache projects like Tika, Cocoon and Jackrabbit. The code will be placed within the org.apache.commons.xml package. Subpackages for specific types of code like SAX or DOM utilities will be created as appropriate. 3. Required Commons Resources - Version Control The Commons XML codebase is located in the "xml" directory inside the Commons Sandbox tree. The codebase can be found at: https://svn.apache.org/repos/asf/commons/sandbox/xml/trunk/ Mailing List Discussions about the Commons XML package will take place on the dev@commons.apache.org mailing list. The subject lines of related messages should prefixed with [xml]. Issue Tracker No issue tracker will be set up for now. We can decide where and how to track issues once the future location of the package becomes clearer. 4. Initial Committers - The proposal is currently being driven by Jukka Zitting, but any Apache committer is welcome to join the effort. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] Use of svn keywords in source files
Hi, Is there a particular reason why we use svn keywords like $Id$? I've personally never found them very useful (the version number in a jar file is much more informative), and the keywords often confuse diff and merge tools. I'm relatively new here, so this probably has been discussed at length before. Any pointers? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] How to link JIRA issues and commits
Hi, On Wed, Feb 4, 2009 at 6:30 AM, Rahul Akolkar wrote: > Due to this, noting the svn revision in a comment to the JIRA issue > can be considered optional (its good practice nevertheless). +1 on it being good practice Including the relevant revision number in a Jira comment can come in really handy in cases where there was a typo in the Jira key included in the commit message. (Been there, done that...) BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [sandbox] Project template
Hi, On Thu, Jan 29, 2009 at 11:41 PM, Rahul Akolkar wrote: > * Perhaps folks are indeed better off just looking at existing > components, rather than some templates (we actually have fairly simple > components in the build and release sense, and having the current m2 > support in parent etc. makes things even easier) Agreed, though it would still be helpful to have some guidelines on what's really expected versus what some components have just decided to include. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[sandbox] Project template
Hi, I'm about to set up a sandbox are for some further work on the Commons XML (originally SAX) idea that we discussed a few weeks ago. When looking for a good starting point I found the templates [1] and [2], but both seem a bit outdated (one uses Ant and the other Maven 1). Is there a more recent template somewhere, or should I come up with a patch that updates one of the templates (which one is better?) to the current state of the art as seen in other Commons components? [1] http://svn.apache.org/repos/asf/commons/sandbox/proposal [2] http://svn.apache.org/repos/asf/commons/sandbox/project-template BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposal: Commons SAX
Hi, Until we come up with consensus on where (Commons, Xerces or Cocoon) we should place this proposed library, I'd like to start putting some bits together in the Commons Sandbox. The Commons web page defines the Sandbox as "a place to try out new ideas and prepare for inclusion into the Commons portion of the project [*] or into another Apache project", which is exactly what I'm planning to do. [*] Is this wording a leftover from Jakarta days? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposal: Commons SAX
Hi, On Mon, Dec 29, 2008 at 9:56 AM, Carsten Ziegeler wrote: > In the Cocoon project we're about to refactor/move some of our common > xml stuff into an own sub project at Cocoon. This will be a small > reusable library. So maybe we could add the common stuff from Tika there > as well. We have a huge xml community already within the Cocoon project. That's another good option. How would Cocoon handle people who are interested in working on this code but not on other parts of Cocoon? BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Federated commons and JCR
Hi, In the Jackrabbit project we're thinking about setting up a "JCR Commons" subproject for some of our generic JCR tools that are not tightly coupled to the Jackrabbit content repository. See [1] for more background. It was suggested that we consider bringing those components to Apache Commons, but I'm not too excited about the idea at least for now. The Jackrabbit community had concerns about even a separate @jackrabbit.apache.org mailing list for the proposed subproject, and bringing the components to a separate TLP would cause an even greater split in our development efforts and community. (And quite frankly I find the d...@commons list really hard to keep track of without elaborate filtering rules.) I'd be more interested in pursuing Henri's recent idea on "federated commons" (see [2]). We'd for now keep the JCR Commons components in Jackrabbit, but could adopt some quality, branding, and release practices from Apache Commons (details to be worked out). Would this be a good idea? [1] http://markmail.org/message/qqlvlwpgi5oauak6 [2] http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposal: Commons SAX
Hi, On Thu, Dec 18, 2008 at 9:25 AM, Jeremias Maerki wrote: > Oversight/Responsibility over XML Commons has been transferred to the > Xerces PMC in November 2006. The XML project itself is subject to be > killed as soon as the last issues (AxKit & XIndice) have been dealt with. > Xerces is currently just using XML Commons to maintain the XML APIs. Not > much else is going on there. So if this is no good fit for Apache > Commons, we'd have to talk to the Xerces people. I pinged the Xerces people about this. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Proposal: Commons SAX
Hi, In the Apache Tika project [1] we use SAX quite a lot, and have written a set of quite useful general utility classes for SAX handling. For example, in org.apache.tika.sax [2] we have the following: * ContentHandlerDecorator - Convenient base class for writing ContentHandler decorators * EmbeddedContentHandler - Decorator that blocks startDocument() and endDocument() calls * TeeContentHandler - Forwards SAX events to multiple handlers * TextContentHandler - Decorator that blocks everything but character events (and start/endDocument) * WriteOutContentHandler - Writes the contents of all character events to a Writer In org.apache.tika.sax.xpath [3] we have a simple XPath subset implementation that supports streaming and filtering of SAX events. In other words, the implementation doesn't need a DOM tree to evaluate XPath statements. I believe this code would be useful also outside Tika, and I was thinking that it might perhaps make sense to create a Commons project for this. I also know of some SAX processing classes in Cocoon and Jackrabbit that could well be of interest to a wider audience. Do you think something like this would be interesting as a Commons project? Are there other similar efforts that I should know of? I looked at XML Commons in xml.apache.org, but it seems pretty dormant. [1] http://lucene.apache.org/tika/ [2] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/package-summary.html [3] http://lucene.apache.org/tika/apidocs/org/apache/tika/sax/xpath/package-summary.html BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all][nabla] proposition for a new project in sandbox
Hi, On Mon, Apr 14, 2008 at 9:27 PM, Luc Maisonobe <[EMAIL PROTECTED]> wrote: > Derivatives are computed by applying the classical exact differentiation > rules ((f*g)' = f'*g + f*g' and friends) and by using the exact derivatives > of all Math and StrictMath methods (including acosh, asinh and atanh which > are still not available in current versions of Java). The results are as > accurate as machine precision and errors propagation allow. That is to say > the derivative is computed with an accuracy that is tightly related to the > accuracy of the original function. OK, thanks for the details. I'm still not sure about the impact on error propagation, which often works in surprising ways especially for complex functions, but it sounds like you're already getting some good results. Also, have you thought about how to handle branch and loop structures within a function? > This part does work and the existing results show it. You will see them as > soon as I can upload the project somewhere. Sounds great! I'm looking forward to checking it out. > So you are right, vectors derivatives belong to the goal, but scalar > derivatives too and represent the first step. Excellent, then I think "nabla" is a great name! BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][nabla] proposition for a new project in sandbox
Hi, On Sun, Apr 13, 2008 at 11:57 PM, Phil Steitz <[EMAIL PROTECTED]> wrote: > The idea is interesting and I see how it could be useful assuming it > could be made to work reliably and the > byte code <-> original function > differentiated byte code <-> analytical derivative > mapping could be shown to lift with decent numerics and performance > for a decent range of original functions. That is not obvious to me, > but I have never thought about this kind of thing before. I share the concern. It doesn't seem obvious that the derivatives of the byte code operations would produce a computationally accurate derivative of the source function. Other than that the idea is interesting, and it would be cool to see how well it works in practice. Also, the name "nabla" would suggest that the component is designed for calculating derivatives of vector functions. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] ApacheCon EU 2008 - April 7 - 11
Hi, On Wed, Feb 20, 2008 at 9:12 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Anyone planning to be at ApacheCon EU 2008? I'll be there. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 12, 2008 12:27 AM, Gary Gregory <[EMAIL PROTECTED]> wrote: > Perhaps we should do the following in trunk: > > 1) Generify (I know, it's not a word and it is funny that my spellchecker > suggests 'gentrify')) everything > and keep backwards compatibility (this has started) > 2) Re-implement using Java 5 APIs where appropriate. For example, if we catch > and re-throw an > exception, make sure we pass the cause up the chain. > 3) See what it all looks like > 4) Discuss what old style APIs to remove if any. For example: Do we keep > foo(Type[]) when we > now have foo(List)) or foo(Iterable) +1 Sounds good to me. This discussion will be much more productive when we have concrete changes to look at. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 11, 2008 2:38 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote: > > I still don't see the need to overhaul the entire API. > > And I don't see the point why we shouldn't. Going from from java 1.4 > -> 1.5 usually means a bit overhaul. Perhaps usually, but for Commons IO? I see only a few isolated candidates for Java 5 improvements in the filefilter, input, and output subpackages, and the comparator package is mostly covered already by Niall's changes that AFAIUI are backwards compatible. In the main io package there are some methods that would benefit from Java 5 features, but they are also a minority. Do such isolated changes justify changing the entire API? Or do you have some other major changes in mind? BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 11, 2008 11:02 AM, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Additionally, nobody stops us from shipping an io compat library which > translates the > calls original io 1.x calls for io2. That one can be used as real replacement > of old 1.x > series, but offers the possibility to use as much Java 5 specifics as > possible in the > new API (varargs, new interfaces, generics, enums, ...). I still don't see the need to overhaul the entire API. Do we have some specific cases where switching to Java 5 features would be both backwards incompatible and worth making? BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 8, 2008 6:32 PM, Gary Gregory <[EMAIL PROTECTED]> wrote: > > You'd only need to upgrade to SomeClass2 if you actually need the new > > functionality, otherwise you could just keep using the old API when > > upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would > > need to update their code when upgrading even if no part of the API > > they touch has changed. > > I do not think this last paragraph is correct. The io2 package is > not only free to introduce generics in the API, it is also free to > use Java 5 features in its internal implementation. Perhaps I'm being dense, but I don't get why we couldn't use Java 5 features in the internal implementation of the current Commons IO API? If we declare Java 5 as a requirement for IO 2.x, then those Java 5 features should be available wherever you deploy the library and it shouldn't matter how the internals work as long as the public API remains backwards compatible. We can always backport fixes and new functionality that don't depend on Java 5 features to a 1.x branch that runs on earlier JVMs. There should be no problem to keep such backports upwards compatible, so that a 1.x client would remain functional when deployed with IO 2.x in a Java 5 environment. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 8, 2008 5:24 PM, James Carman <[EMAIL PROTECTED]> wrote: > On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > If there's a class or interface, say o.a.c.io.SomeClass, that needs to > > be changed extensively to match "Java 5 style", then I'd name the > > modified version o.a.c.io.SomeClass2 (or something better if > > possible). > > I don't know about that. Then, we could potentially have classes like > SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it > wouldn't be as easy to upgrade to a new version. If it were done the > other way, folks could just do a find/replace on the package name in > their code and be done. Why I should need the find/replace in the first place? A find/replace won't help with any fundamental API incompatibilities that would trigger the creation of SomeClass2. You'd only need to upgrade to SomeClass2 if you actually need the new functionality, otherwise you could just keep using the old API when upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would need to update their code when upgrading even if no part of the API they touch has changed. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 8, 2008 3:49 PM, James Carman <[EMAIL PROTECTED]> wrote: > So, you are suggesting having part of a release in the o.a.c.io > package and the other part in the o.a.c.io2? No. I'd keep everything in o.a.c.io. If there's a class or interface, say o.a.c.io.SomeClass, that needs to be changed extensively to match "Java 5 style", then I'd name the modified version o.a.c.io.SomeClass2 (or something better if possible). I assume such cases to be the exception rather than the rule, so I don't see the point in renaming the entire package. Java 5 is just an enabler of new features (generics, etc.), it doesn't magically make existing APIs obsolete. Sure, you probably want to adjust collection types, but that's just like any other API change request. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] 2.0 Moving to minimum of JDK 1.5
Hi, On Feb 6, 2008 1:51 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > So the changes are pretty minimal for IO - question is are these > incompatible changes with generics being erased? If not then perhaps > we can do this without breaking anything. +1 If there are cases where we can't avoid breaking backwards compatibility, then let's use the name2 pattern on individual classes or interfaces instead of the entire o.a.c.io package. There are large parts of Commons IO that don't need to change when upgrading to Java 5 and I don't see why a client that only uses those parts should be affected in any way by the upgrade. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons IO 1.4 based on RC3
Hi, I finally had a moment to review the release. Looks good, so: [x] +1 I support this release Checked signatures, reviewed license and notice files, built and tested using Maven 2 with Sun Java 1.6.0_03 and 1.4.2_16 on Windows Vista and with Sun Java 1.5.0_01 on Fedora Core. All OK. PS. A minor complaint, the -sources and -javadoc jars inside the -bin packages differ from the standalone versions. The only differences seem to be different create timestamps inside the files apparently because of separate passes to build the packages and the assemblies. It would be nicer if the jars were byte-equal. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Planning IO 1.4 release
Hi, On Jan 9, 2008 11:04 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Henri and Jukka expressed interest on IO-137 - do you guys > want to / have time to look at this? Let's move it to post-1.4. The reset() issue still needs some thought and probably shouldn't be rushed. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Planning IO 1.4 release
Hi, +1 to Commons IO 1.4! On Jan 6, 2008 4:58 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On Jan 6, 2008 2:23 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: > > I think we should deal with IO-137 as it's a minor enhancement and > > comes with tests. I'll volunteer to look at that. > > I looked at this a while back and using the baos buffers directly in > an InputStream raises a safety issue (if the baos is modified while > the InputStream is being read) - do we care about that? I kind of agree. I was thinking about proposing a "copy on write" flag to reset() that would start with a new set of buffers when there are InputStreams reading from the same buffers, but that seems too complex to me. Apart from that, I like the general idea in IO-137 (it's similar to my readFrom() proposal) so I'd like to see it in 1.4 if there's a consensus on what form the feature should take. I'm willing to invest some time to work out the details. > > IO-51 has tests, so worth a look at if that can be done before the > > others are resolved. ie) punt to post-1.4 iff it's the last one left. > > I had a brief look and my initial thought was the Limiter should just > be doing the throttling and the reading/writing should be in the > input/output implementations - but I haven't looked in detail. I looked at IO-51 a few months ago, and came to the same conclusion. The implementation isn't too modular and probably too complex (i.e. could be done with less code). Of course I didn't have time to come up with an alternative implementation. I like the feature though, and I have some use cases where it would come in handy, but I think it's better to improve the Limiter API before the feature gets released. > IO-148 is done from my PoV - I left it open in case anyone wanted to > object to me renaming it today. If Gary and Jukka are happy then we > can mark it as fixed. I'm happy. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RereadableInputStream
Hi, On 10/14/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I don't see anything in the javadocs for the mark/reset methods in > InputStream that prevent it from being used for streams of arbitrary > length. > [...] > Secondly, from a Commons IO perspective, we already have some of the > functionality for some parts of what you're trying to achieve: For the record, I have some existing code from previous projects that resembles what Niall outlined. The TeeInputStream I contributed is actually part of that codebase, and I'm planning to contribute also the rest to commons-io once I've cleaned it up. The use case that Keith is also coming from, is to be able to pass a stream to a process (a parser in Tika) that will read an unknown number of bytes from the stream and might even use mark/reset on it's own to manage the stream. For such cases the standard mark feature in java.io.InputStream is not enough. The solution I've been using is an application of the Memento pattern where you can "freeze" multiple states of the input stream and later restore the stream to such a frozen state. Each frozen state is essentially a growing buffer (optionally on disk) that keeps track of all bytes read from the stream, and restoring a state means rewinding the stream to the beginning of the buffer associated with that state. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
