tra 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/apa
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
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
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
---
o 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
o 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
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,
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
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
-
runcated 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 additiona
e 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:
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-m
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
ing
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 Zitt
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 Zi
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 c
elease 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
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 compone
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
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
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
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
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 addit
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?
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
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
rhaps 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
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&
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
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.copy
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.
>
>
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 Z
#x27;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
vember. 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
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
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...@common
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
anch 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
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 projec
scussed 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
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-mai
n 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 unsubsc
ndbox/project-template
BR,
Jukka Zitting
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
n 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,
s 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
-
s 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-o
.
> 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 abou
pache/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
r
> 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]
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 calculatin
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]
> 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:
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: [EMAI
rs 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 incompatib
m 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]
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&quo
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
--
hat 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]
were byte-equal.
BR,
Jukka Zitting
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 rushe
imiter 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]
ly 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 unsubs
62 matches
Mail list logo
