On 2009-09-15, Gump iss...@commons.apache.org wrote:
Project commons-collections has an issue affecting its community integration.
...
[javac]
/srv/gump/public/workspace/apache-commons/collections/src/test/org/apache/commons/collections/TestCollectionUtils.java:275:
cannot find symbol
Hi all,
as expected, Gump found a few projects that have been broken by the
recent merge in Collections - that's what it's there fore anyway.
The first ones I have found (there will be more, I'm sure are):
Torque: uses FastArrayList and OrderedMap#orderedMapIterator()
Jelly: uses BeanMap
On 2009-09-17, Henri Yandell flame...@gmail.com wrote:
Though it wouldn't make Gump's life any easier. In fact life would get
worse until they set up a separate v3 version anyway. Which I think is
what's happened for Lang.
Yes this is what we did - and likely will do for collections.
So the
On 2009-09-18, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-17, Henri Yandell flame...@gmail.com wrote:
Though it wouldn't make Gump's life any easier. In fact life would get
worse until they set up a separate v3 version anyway. Which I think is
what's happened for Lang.
Yes
On 2009-09-18, Henri Yandell flame...@gmail.com wrote:
On Thu, Sep 17, 2009 at 9:08 PM, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-18, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-17, Henri Yandell flame...@gmail.com wrote:
Though it wouldn't make Gump's life any easier
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-openpgp has an issue affecting its community integration.
This issue
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-cli has an issue affecting its community integration,
and has been
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-cli has an issue affecting its community integration,
and has been
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-math has an issue affecting its community integration.
This issue
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-math has an issue affecting its community integration.
This issue
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-net has an issue affecting its community integration.
This issue affects
On Tue, 5 Feb 2008, Simon Kitching [EMAIL PROTECTED] wrote:
In my experience these weird execute bits are quite common; if a
unix text file gets this bit set on it for some reason, then svn add
will helpfully set the executable flag.
Many times the Cygwin svn client is to blame, it seems to
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-daemon has an issue affecting its community integration.
This issue
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-xmlio has an issue affecting its community integration.
This issue
my fault, I introduced a dependency cycle in Gump which should be
fixed now.
sorry for the noise
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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-net has an issue affecting its community integration.
This issue affects
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-net has an issue affecting its community integration.
This issue affects
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-net has an issue affecting its community integration.
This issue affects
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-net has an issue affecting its community integration.
This issue affects
On Thu, 03 Apr 2008, [EMAIL PROTECTED] wrote:
+ available property=dom.available classname=w3c.dom.Node /
I think you mean org.w3c.dom.Node (missing org.).
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
The descriptor said maven which is Maven1, I changed it to mvn
(Gump speak for Maven2) so I hope it will work better on the next run.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
On 2014-08-18, sebb wrote:
I suspect just using a volatile enum would be sufficient as enums are
thread-safe so it is just necessary to ensure safe publication.
I went with the volatile route since the code never used compareAndSet
or one of its friends anyway.
Stefan
On 2014-08-20, Benedikt Ritter wrote:
I've committed a new mojo to the commons build plugin, which generates a
README.md file for a component [1].
Without looking at the code, do you plan to make it so that projects can
override the default README.md with a template of their own - much like
we
On 2014-08-20, Benedikt Ritter wrote:
2014-08-20 13:13 GMT+02:00 Stefan Bodewig bode...@apache.org:
On 2014-08-20, Benedikt Ritter wrote:
I've committed a new mojo to the commons build plugin, which generates a
README.md file for a component [1].
Without looking at the code, do you plan
On 2014-08-22, Benedikt Ritter wrote:
Okay... TBH, I don't like that BCEL is treated special. Looks like a
different versioning schema to me. Also other groupId and artifactId. But
if you RM, it's your decision :-) I won't block a release because of this
if BCEL was always released like this.
Hi all
I was just browsing the security pages of some ASF projects and the
guidelines set by our security team[1] (preparing a talk, not because
there was any issue) and realized Commons didn't have a page describing
how to report security issues.
Since I'm the one who created the page for
On 2014-08-31, Gary Gregory wrote:
Great idea!
Every Commons component should have such a page indeed, can be a link
to the same page for all of Commons IMO.
Some changes though are needed.
It should be made clearer that there is an important distinction
between undisclosed and disclosed
Hi all,
I've put together a security page for Commons so people have a place to
get information quickly, it is based on the recommendations by our
security team[1] and the existing page of Compress[2].
http://commons.staging.apache.org/security.html
this one is still in staging so we
On 2014-08-31, Gary Gregory wrote:
I get a 404...
strange. Take note of staging in the URL
http://commons.staging.apache.org/security.html
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
Hi all
it's only four issues we've closed since the 1.8.1 release but I
consider COMPRESS-286 pretty serious - it looks as if reading 7z
archives using LZMA (not LZMA2) was in trouble.
One thing that bothers me is COMPRESS-284 as I simply cannot reproduce
it - and don't see the bug by reading
On 2014-09-01, sebb wrote:
Might be useful to add a link to the security page under General
Information.
Right.
The page mentions denial of service - not sure that applies to any of
the Commons components?
The one issue with Compress could be used for a DoS attack.
Stefan
On 2014-09-01, sebb wrote:
On 1 September 2014 04:53, Stefan Bodewig bode...@apache.org wrote:
On 2014-09-01, sebb wrote:
The page mentions denial of service - not sure that applies to any of
the Commons components?
The one issue with Compress could be used for a DoS attack.
I think
On 2014-09-02, sebb wrote:
Propchange: commons/cms-site/trunk/content/xdoc/security.xml
--
svn:mime-type = application/xml
-1 (for the property)
SVN treats that mime-type as binary; either drop it or use
[on the original topic: I personally like git but would leave the
decision to move on to the components]
On 2014-09-10, Gilles wrote:
[The advantages of git must be somewhere else.]
Not sure about the advantage, but let me show you an example where a
DVCS (any DVCS) would have been really
Hi
I've just added a link to the security page inside the main navigation,
see
http://commons.staging.apache.org/security.html
The page is inside the staging area only, but I'd like to publish it
sooner rather than later - and update the commons parent to include the
same link.
Should the
On 2014-09-10, Gary Gregory wrote:
Hm... The requested URL /security.html was not found on this server.
I copy pasted the link from my browser. The page has been there for
almost two weeks now, so we can rule out stale caches.
Are you sure you are trying the URL that contains staging inside
+1
could see the signature on my Win7 VM and Windows seemed to like it.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2014-09-27, Gary Gregory wrote:
Still closing in on 1.9 ;-)
Stefan, are you ready to cut a released?
Distracted by real life, might get around to it tomorrow, but it is
quite possible I'll have to push it off to the next weekend.
Stefan
On 2014-09-27, Gary Gregory wrote:
What is the status of this VOTE?
http://mail-archives.apache.org/mod_mbox/commons-dev/201409.mbox/%3C541FF178.1030204%40apache.org%3E
Stefan
-
To unsubscribe, e-mail:
Hi all,
nothing big this time but a few accumulated bug fixes and support for
raw DEFLATE streams.
Compress 1.9 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 6728)
Maven artifacts are here:
Just a note on the GPG key, it might be a good idea to upgrade to a
stronger one. 1024 bits keys are discouraged nowadays.
http://www.apache.org/dev/release-signing
I know, but leaving behind a key that has accumulated signatures over
more than ten years is hard ...
Stefan
On 2014-10-06, Emmanuel Bourg wrote:
Le 06/10/2014 09:16, Stefan Bodewig a écrit :
I know, but leaving behind a key that has accumulated signatures over
more than ten years is hard ...
My suggestion was actually a subtle plan to get you to invite us to
drink a beer and sign your new key
On 2014-10-06, sebb wrote:
On 6 October 2014 08:16, Stefan Bodewig bode...@apache.org wrote:
Just a note on the GPG key, it might be a good idea to upgrade to a
stronger one. 1024 bits keys are discouraged nowadays.
http://www.apache.org/dev/release-signing
I know, but leaving behind
On 2014-10-06, Stefan Bodewig wrote:
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. after 0530
GMT 09-October 2014
My own +1
Stefan
-
To unsubscribe, e-mail
Hi all
with +1s by Emmanuel, Gary, Jörg and myself the vote has passed. I'll
take the next steps of the release process and wait for the mirrors to
catch up before sending the announcement - as usual.
Many thanks to all who reviewed the release.
Stefan
, or suggestions for improvement,
see the Apache Commons Compress website:
http://commons.apache.org/compress/
Stefan Bodewig, on behalf of the Apache Commons community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlQ4Bi0ACgkQohFa4V9ri3JTfgCePodWpLt1EAh0S0qPfl0IN3sC
On 2014-10-23, Damjan Jovanovic wrote:
I've been hoping to steal commons-compress's cleaner and faster LZW
decompressor, and use it in commons-imaging for TIFF and GIF files,
and I've finally managed to make a patch to that effect.
Cool.
This requires moving LZWInputStream to a
Hi
a few days ago Compress' pom was changed to use the newest PMD plugin
version 3.2, this one depends on PMD 5.1.2. When I built the site
locally it claimed to find about ten instances of unused private
functions - all of them false positives.
Since the changelog of PMD 5.1.3 [1] lists at
Hi all
Gump builds commons-collection's 3.x branch since it is a dependency of
Forrest and the XML Graphics projects that still enjoy using Gump.
After we've switched to using Java8 we found Collections 3.x cannot be
built on Java8 because of some addition to the Map interface.
default boolean
Hi
I wanted to write a few additional unit test for BitInputStream and
maybe later replace the zip package's BitStream with it (IMPLODE uses
that under the covers).
A while ago I had already added a guard to ensure nobody tried to read
more than 32 bits since bits are accumulated inside an int -
Apart from EOF handling there also is the byte-order case.
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
Should byte order imply we are always reading bytes in chunks of a given
number?
Right now I
On 2014-11-12, Stefan Bodewig wrote:
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
And it's not true, I just need to think about the returned ints in a
different way, all is fine :-)
Stefan
On 2014-11-12, Emmanuel Bourg wrote:
Le 12/11/2014 19:51, Stefan Bodewig a écrit :
A while ago I had already added a guard to ensure nobody tried to read
more than 32 bits since bits are accumulated inside an int - but
actually we can't do that as readBits returns -1 on EOF, so we can't
On 2014-11-13, Damjan Jovanovic wrote:
On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig bode...@apache.org wrote:
One thing BitStream and BitInputStream have in common is what happens
when I request more bits than are available from the underlying stream,
both will signal an EOF and discard
On 2014-11-14, sebb wrote:
On 12 November 2014 20:40, Emmanuel Bourg ebo...@apache.org wrote:
Le 12/11/2014 21:02, bode...@apache.org a écrit :
public int readBits(final int count) throws IOException {
-if (count 0 || count 32) {
if (count 0 || count 31) {
On 2014-11-29, Benedikt Ritter wrote:
currently I feel really overwhelmed by the stuff I'd like to do at commons
and the little time I can spend for it.
As many others have already said, most of us know exactly what you are
talking about and IMHO the only solution for you is to not pick too
On 2014-12-15, Kristian Rosenvold wrote:
I just thought I'd let you know I'm working on changes to allow
multiple threads to output to different ZipArchiveOutputStream
instances (backed by commons-io DeferredFileOutputStream or similar)
and then stitch the results back together as a single
On 2014-12-15, Kristian Rosenvold wrote:
There is also the issue of determining if the MANIFEST.MF file really
needs to be the first file in the jar, which puts an interesting
constraint on the parallelism. I have been unable to understand if the
jar spec actually requires this or if it's
On 2014-12-15, Kristian Rosenvold wrote:
There is also the issue of determining if the MANIFEST.MF file really
needs to be the first file in the jar, which puts an interesting
constraint on the parallelism.
I've found this for Ant which caused us to implement that logic (in 2001):
On 2014-12-16, Kristian Rosenvold wrote:
At least for maven's code, introducing the concept of a root stream
that will be the start of the physical zip stream can simplify things
quite a lot.
Yes, I can see the same for my compress antlib (Ant tasks based on
Commons Compress) as well. It
On 2014-12-18, krosenv...@apache.org wrote:
public void addRawArchiveEntry(ZipArchiveEntry entry, InputStream
rawStream)
Technically entry could be a java.util.zip.ZipEntry, I'm not sure this
would open up new opportunities, though.
/**
* Transfer selected entries from this
On 2014-12-22, krosenv...@apache.org wrote:
* It is possible to extend this class to support different kinds of backing
storage, the default
* implementation only supports file-based backing.
Wouldn't it be possible to create a proper interface for backing
stores and have
On 2014-12-22, Kristian Rosenvold wrote:
There are quite a few extension points in this class that make
changing it really hard.
ACK
I just committed r1647329 which basically duplicates some code from
this class into another class. As much as I hate duplication, I wasn't
able to achieve
On 2014-12-24, Bernd Eckenfels wrote:
I wonder, is it intentional, that this is no longer required/defined,
or just an oversight?
We're not very explicit about this, but at least a part of the releasing
guide for components says:
,
| Edit the SCM entries in the parent POM. Note: use the
Benedikt Ritter wrote:
Maybe it's finally time to start upgrading all components to Java 1.6.
All compontents that don't explicitly want to defer the upgrade. No
need to force this on all components IMHO.
On 2014-12-26, Jörg Schaible wrote:
Just add a profile that sets the two properties
On 2014-12-23, Stefan Bodewig wrote:
Your commit message calls out writeOut as a particilar problem.
Fortunately this is one is final, so we don't have to retain the effect
of subclasses overriding it. Wouldn't it be possible to have writeOut
call the StreamCompressor's writeOut method so
On 2014-12-24, krosenv...@apache.org wrote:
It seems like OpenJDK calendar operations are somewhat different from
sun jdk, so this is not a viable test to make
Actually the reason is that zips - at least those created by Commons
Compress - store time in UTC and you need to adjust for the
On 2014-12-28, Luc Maisonobe wrote:
I regularly check a few mirrors to see if they have mirrored the recent
[math] release, and many still seem to not know about it. I will
certainly not check all of them. Is there an accepted delay before
sending the official announce of the release, even if
On 2014-12-26, Kristian Rosenvold wrote:
Yup; I'm taking care of the duplication in trunk on my github fork.
The other interesting branch to look at is the somewhat stale
concurrentSupport branch and in particular the class
ConcurrentZipCreator. This is my primary goal, I just went off on a
On 2014-12-28, Kristian Rosenvold wrote:
2014-12-28 11:35 GMT+01:00 Stefan Bodewig bode...@apache.org:
On 2014-12-26, Kristian Rosenvold wrote:
D) Look at performance in the gather phase. It's too slow right now,
even with my last commit on trunk. Consider moving the creation of the
LFH
On 2014-12-28, Kristian Rosenvold wrote:
Stefan, I looked at your changes in the github repo
https://github.com/bodewig/commons-compress/commits/scatter-backing-store
I think they look great. Please commit them :)
Done
Stefan
On 2014-12-29, Kristian Rosenvold wrote:
The refactoring os ZipArchiveOutputStream to use StreamCompressor is now done
in
the branch https://github.com/krosenvold/commons-compress
Some code comments:
* the fields writtenToOutputStream, sourcePayloadLength and actualCrc in
StreamCompressor
On 2014-12-29, Gary Gregory wrote:
but I encourage Git 'pushers' (pun intended) to just bring up a VOTE for a
component and move the process along if you care about Git.
Just as a letter of intent - I'd prefer to cut Compress 1.10 while
we're still in svn (as I know how to do it, I'm in the
Welcome Sumit Gaur!
On 2014-12-29, Sumit Gaur wrote:
I am new to Open Source Development. I’ve been part of various Java,
J2EE, WebServices (SOAP,Rest), Spring based projects. I’ve some
questions regarding project life cycle at ASF. Kindly spare some time
to answer the following:
This is
On 2014-12-31, Jochen Wiedmann wrote:
On Mon, Dec 29, 2014 at 3:16 PM, Stefan Bodewig bode...@apache.org wrote:
Just as a letter of intent - I'd prefer to cut Compress 1.10 while
we're still in svn (as I know how to do it, I'm in the avoid the
release plugin camp) and call for a vote
On 2014-12-30, Kristian Rosenvold wrote:
I fixed all comments and reinstated the protected Deflater.
Thanks, looks good.
The whole ZipArchiveOutputStream class reminds me of a few of the
3000+ LOC java classes I refactored in maven core; sometimes the only
acceptable solution is to extract
Re backwards compatibility: ZipArchiveOutputStream's deflate method has
been protected and now has gone.
On 2014-12-31, Kristian Rosenvold wrote:
On a related note, I just added the *last* substantial change I intend
to do. I will do a tweak or two, and I'm sure that last class will
trigger a
On 2014-12-31, krosenv...@apache.org wrote:
static ScatterGatherBackingStoreSupplier defaultSupplier = new
DefaultSupplier();
This one could be instance variable (and made final when set in the
constructor). I think this would be a cleaner approach to overriding
the supplier that setting
On 2015-01-02, Kristian Rosenvold wrote:
2015-01-02 16:22 GMT+01:00 Stefan Bodewig bode...@apache.org:
On 2014-12-31, krosenv...@apache.org wrote:
... all else fixed in r1649128..
I thought you'd need a way to override the
ScatterGatherBackingStoreSupplier from Plexus, maybe I was wrong
On 2015-01-02, Kristian Rosenvold wrote:
All fixed :)
Thanks a lot!
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2015-01-22, Jochen Wiedmann wrote:
Same as user ID: jochen
sure?
If so, then you should be set up now.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2015-01-20, Emmanuel Bourg wrote:
Le 20/01/2015 15:24, bode...@apache.org a écrit :
throw a special exception when there is no password for an encrpyted
7z archive - COMPRESS-298
Is it possible to mention the name of the file in the message of the
exception?
Not without modifying the
On 2015-01-12, Kristian Rosenvold wrote:
We had somewhat of a discussion regarding this class on the maven dev
list over the weekend, some people wanted this code inside
commons-compress:
Code is here:
On 2015-01-20, Kristian Rosenvold wrote:
Btw it still seems like my JIRA karma is a bit weak ?
I'm not sure what you are missing, but I am sure I cannot provide it :-)
JIRA Admins for Commons are Phil, Luc and Mark Struberg.
Stefan
On 2015-01-20, Gary Gregory wrote:
Why not use an IllegalStateException?
Because it used to throw IOException and I don't want to break code that
was written to catch the IOException but not IllegalStateException.
Stefan
-
To
On 2015-01-22, Jochen Wiedmann wrote:
are there any special privileges, one needs to create a new page on
wiki.apache.org/commons?
Yes, you need to be added to the contributors group - unfortunately we
had to add this as an ant-spam measure.
If so, could I have those privileges?
Sure, what
Hi all
I've had good experience with creating a site build before cutting a
release candidate, so here we go:
http://people.apache.org/~bodewig/commons-compress/
Please have a look and identify stuff that looks as if I'd have to
reroll a new RC should it come to a vote with the current
On 2015-01-27, Gary Gregory wrote:
On Tue, Jan 27, 2015 at 4:54 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
I've run through all of our tests and the release looks good.
The testcase should fail 1 in 1000 times as is and has been fixed.
I'm +1 on the release as such (but
On 2015-01-30, Gary Gregory wrote:
On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig bode...@apache.org wrote:
The superclass of ZCompressorInputStream has changed from one we've
removed with the old __internal__ package to a new one in the now
supported lzw package.
Well, we cannot break BC
On 2015-01-31, sebb wrote:
Given that the protected fields were in a class marked as internal, it
seems arguable that users should not have referred to any of the items
in it.
Therefore we could potentially make all the mutable protected fields
private (and add protected getters).
Even if
On 2015-01-24, Stefan Bodewig wrote:
On 2015-01-23, Emmanuel Bourg wrote:
- BitInputStream: why not using a long cache instead of an int, like
BitStream before the refactoring? It might be interesting to do some
benchmarks and see if it make a difference.
We never needed more than 31 bits
On 2015-01-25, sebb wrote:
On 25 January 2015 at 05:11, Stefan Bodewig bode...@apache.org wrote:
On 2015-01-24, Kristian Rosenvold wrote:
After an intense few minutes discussing the color of the bike shed
with myself (package name) I moved the zip-unspecific parallel stuff
On 2015-01-24, Kristian Rosenvold wrote:
After an intense few minutes discussing the color of the bike shed
with myself (package name) I moved the zip-unspecific parallel stuff
to org.apache.commons.compress.parallel in r1654572.
Maybe add a package-info.java?
I'll need to add one to the
On 2015-01-24, Kristian Rosenvold wrote:
I suppose the what's new section on the site also needs to be
updated to 1.10 ?
Yes, that would be good.
Anything else I can assist with before the release ?
Thanks.
I intend to spend a bit of time with BitInputStream and cut the RC
tomorrow, at
On 2015-01-25, Emmanuel Bourg wrote:
Le 25/01/2015 11:38, Benedikt Ritter a écrit :
I'm not a compress developer, but IMHO exceptions should be packaged by
their API and not by their nature.
Thank you for moving the exception Stefan, however I tend to agree with
Benedikt on this,
As inidcated last week, here is the first RC for Compress 1.10.
Compress 1.10 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 7828)
Maven artifacts are here:
On 2015-01-23, luc wrote:
Le 2015-01-23 04:00, sebb a écrit :
On 22 January 2015 at 23:55, sebb seb...@gmail.com wrote:
On 20 January 2015 at 16:26, Stefan Bodewig bode...@apache.org
wrote:
JIRA Admins for Commons are Phil, Luc and Mark Struberg.
As far as I know, I don't have
On 2015-01-23, Emmanuel Bourg wrote:
Le 22/01/2015 17:30, Stefan Bodewig a écrit :
Please have a look and identify stuff that looks as if I'd have to
reroll a new RC should it come to a vote with the current code base.
I reviewed the API changes, here are my comments
Hi
I'm trying to bring together two separate discussions from two different
[VOTE]-threads. It seems as if I should cancel the RC2 vote and before
I rush another RC maybe we can get consensus on what to do.
* my experiments show that moving the LZWInputStream class hasn't got as
big an impact
Sorry for those who already reviewed the release candidate, I'm going to
cut a new RC once we've figured out what to do about LZWInputStream.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
601 - 700 of 1182 matches
Mail list logo
