Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/3#issuecomment-151607463
Oops, this looks bigger than intended :-)
It seems as if out migration to git has made the wrong branch the default
branch. I'll ask the ASF infra
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/3#issuecomment-151728703
Don't feel forced to create a pull request just because we are using git
now. The established workflow of attaching a patch to JIRA is still in
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/4#issuecomment-155670599
Thanks a lot!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/5#issuecomment-164276454
Thanks
I've merged you patch have a few questions - and would like to see tests
:-) Not sure whether you'd prefer to discuss this here, insid
GitHub user bodewig opened a pull request:
https://github.com/apache/commons-io/pull/52
IO-559 verify hostname part of suspected UNC paths in FileNameUtils
https://issues.apache.org/jira/browse/IO-559
I'm not 100% sure how/if Windows deals with percent encoded hostnam
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/12
Don't worry about Coveralls, I see the same behaviour for other projects as
well.
I think this is related to our Travis CI setup using different JDKs and
Coveralls picks whic
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/commit/56e82da90f1064c23dd630cf0066231567da3ed6#commitcomment-20498632
In
src/main/java/org/apache/commons/compress/compressors/lz4/BlockLZ4CompressorInputStream.java:
In
src/main/java
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/commit/56e82da90f1064c23dd630cf0066231567da3ed6#commitcomment-20502548
In
src/main/java/org/apache/commons/compress/compressors/lz4/BlockLZ4CompressorInputStream.java:
In
src/main/java
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
Some rough comparisons for larger files would be a good indicator.
The existing code is pretty ugly because this seemed to be necessary for
acceptable performance back then. "
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/15
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/14
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
Sorry, I didn't realize you had updated the PR, will have a look later.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as wel
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
I'm planning to set up a JMH based benchmark soonish and would like to get
some statistical information before merging this.
---
If your project is set up for it, you can reply to
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/16
Hmm, the no-arg `read` returns the byte read. So when reading an `'A'` your
code would count 65 bytes rather than 1, wouldn't it?
---
If your project is set up for it, y
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
For starters, https://github.com/bodewig/commons-compress-benchmarks -
right now I'm not sure where it'll end up.
---
If your project is set up for it, you can reply to this emai
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/16
True, a unit-test wouldn't hurt.
I'm afraid I can't close the PR myself.
---
If your project is set up for it, you can reply to this email and have your
reply appe
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
@thomasmey I've made some minor changes and pushed it to the branch PR13
My benchmarks at
https://github.com/bodewig/commons-compress-benchmarks/wiki/PR13 sees the
changed
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/17
Great, many thanks,
I've just found
https://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt states
> The CRC format is identical to the new ASCII format desc
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
I just realized I had benchmarked compression rather than decompression,
I've now updated
https://github.com/bodewig/commons-compress-benchmarks/wiki/PR13
Fortunately the resu
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r112810573
--- Diff:
src/test/java/org/apache/commons/compress/compressors/DetectCompressorTestCase.java
---
@@ -167,6 +171,26 @@ private String detect
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838584
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/23#discussion_r114257473
--- Diff: pom.xml ---
@@ -85,6 +91,13 @@ jar, tar, zip, dump, 7z, arj.
${powermock.version}
test
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/23
Many thanks Philippe
see my comments on the test.
Also I haven't checked whether the brotli lib is an OSGi bundle, we may
need to update the bundle-plugin configur
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/23#discussion_r114257946
--- Diff: pom.xml ---
@@ -68,6 +68,12 @@ jar, tar, zip, dump, 7z, arj.
test
+ org.brotli
+ dec
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
Many thanks @kvr000
Have you thought about adding a class implementing `ZipExtraField` for
padding? You could add that to the entry if you detect padding is necessary and
could
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
I don't see a chance of making it independent of `ZipArchiveOutputStream`,
you are certainly correct.
I was thinking along the lines of `ZipArchiveOutputStream` calculate
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
@kvr000 what do you think about
https://github.com/apache/commons-compress/commit/620196621e15a87cdd5e3382504bd8a9829f4698
?
---
If your project is set up for it, you can reply to this
GitHub user bodewig opened a pull request:
https://github.com/apache/commons-compress/pull/25
actually use commons.module.name
Tiny change to trigger
https://builds.apache.org/job/Commons-Compress%20PullRequest%20Builder/
You can merge this pull request into a Git repository by
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/26
Sorry, I'm currently swamped and won't find time to look into this for the
coming days. @sesuncedu there is a discussion going on on the dev mailing list
that you may want to join
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/27
Thanks, do you think you could re-create the PR without the commits that
belong to #26 ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/33
Fortunately I'm not the only one who could merge this :-)
More seriously, it may take a bit of time until I get there, but I will.
---
If your project is set up for it, yo
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/33
Thanks @TheRealHaui
I agree with your comment on
`ChecksumCalculatingInputStreamTest#testGetValueThrowsNullPointerException`
this looks like a bug. So I'd rather remove the
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/32
Thanks, Simon. I didn't know this feature.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/28#discussion_r122244704
--- Diff:
src/main/java/org/apache/commons/compress/utils/FixedLengthBlockOutputStream.java
---
@@ -0,0 +1,227 @@
+/*
+ * Licensed to the
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/33
Thanks a lot.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/33#discussion_r122573708
--- Diff:
src/test/java/org/apache/commons/compress/compressors/xz/XZCompressorOutputStreamTest.java
---
@@ -0,0 +1,51 @@
+/*
+ * Licensed
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/35
Thanks, I had to cherry pick 6f37913 but I think I've got everything merged.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/8#issuecomment-188288771
merged, many thanks.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/10#issuecomment-192735255
Thanks a lot Matt, this makes things quite a bit more consistent.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user bodewig commented on the pull request:
https://github.com/apache/commons-compress/pull/11#issuecomment-197788653
I had naively assumed `InflaterInputStream#close` would free up the
resources. Come to think of it, if we pass in the `Inflater` ourselves it makes
sense that
On 2019-04-16, Gary Gregory wrote:
> Based on a recent JIRA, it seems like using Java 8 in [compress] would be
> helpful.
I'd +1 that it bumping the dependency turned out to be really
useful. I'm not convinced, yet.
> Plus, it's 2019 and Java 12 is out.
As long as using Java 7 doesn't hurt us,
On 2019-04-16, Gary Gregory wrote:
> On Tue, Apr 16, 2019 at 9:39 AM Stefan Bodewig wrote:
>> As long as using Java 7 doesn't hurt us, I don't see any reason to
>> update.
> Using old dead versions of Java turns off potential contributors IMO.
> You have
After Compress has been upgraded to Parent 48 the JDK 7 build started to
fail as the new version of the bnd plugin has been compiled with
-target 8, or so it seems.
I'll downgrade the bnd plugin for compress for now.
Stefan
-
To
Hi all
https://issues.apache.org/jira/browse/COMPRESS-486 highlights a problem
of the code inside the example package. The methods with stream or
channel arguments create wrapper objects around said streams or channels
and never close them. They don't close them because this in turn would
close th
On 2019-08-07, Gary Gregory wrote:
> I think you are missing openjdk13, openjdk-ea now maps to 14 IIRC.
If so then it hasn't been in there before my change either :-)
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apa
Hi
https://issues.apache.org/jira/browse/COMPRESS-479 highlights a problem
where our zip reading code may reject an archive because it uses extra
fields that we only partially understand. In this case the archive is
not a real one, but it is easy to envision extra fields in the wild that
use more
On 2019-08-13, Matt Sicker wrote:
> The enum makes sense. Are there any feasible ways to, say, configure
> some sort of handler class that can implement logic around unknown
> fields?
Not really. The only extension point here currently is plugging in your
own implementations of ZipExtraField via
On 2019-08-14, Matt Sicker wrote:
> Yes, I think you understand us. A strategy pattern with default sensible
> strategies to choose.
Done now.
I'm going to tweak the implementation a little more but the API of
ExtraFieldParsingBehavior seems to work quite well.
Thanks
Stefan
-
Hi all
while I have a bit of time at hand I'd like to use that and cut a new
release of Compress. On my list of things I intend to do for the
release:
https://issues.apache.org/jira/browse/COMPRESS-485 - make the change to
ParallelScatterZipCreator#submit backwards compatible. japicmp doesn't
eve
It's been more than a year since the last release of Commons Compress
and it is about time to get the fixes and enhancements out of the
door.
Compress 1.19 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision
35357)
The tag is here:
ht
Hi all
with binding +1s by
Gary Gregory
Bruno P. Kinoshita
Rob Tompkins
and my own implicit +1 the vote has passed. I'll proceed with publishing
the release artifacts and will announce the release after mirrors had a
bit of time to catch up.
Many thanks to those who had a look at the release c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.19.
Apache Commons Compress software defines an API for working with
compression and archive formats. These include: bzip2, gzip, pack200,
lzma, xz, Snappy, tradi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Re-Sending with fixed subject, sorry]
The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.19.
Apache Commons Compress software defines an API for working with
compression and archive formats. These include: bzip2
://commons.apache.org/proper/commons-compress/security-reports.html
Stefan Bodewig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAl1lgKIACgkQohFa4V9ri3IsSwCg0tYlFA5WXy6EuHFtRjsbVofR
WjAAn2uNwEELGpIR2JiRO+jEAyxQJZvV
=Ds0n
-END PGP SIGNATURE
On 2019-08-31, Gary Gregory wrote:
> On Sat, Aug 31, 2019 at 10:58 AM Gilles Sadowski
> wrote:
>> Links returns "404".
> Works for me, anyone else?
Only works if you are logged in - an probably a member of the apache
organization. github returns 404 for links you are not allowed to see.
Stefa
Hi all
https://issues.apache.org/jira/browse/COMPRESS-491 correctly points out
that some of our InputStream implementantions violate the contract of
the read(byte[]...) pair of methods. They may return 0 instead of trying
to block and read data.
Digging deeper this really only seems to happen on
On 2019-09-29, sebb wrote:
> On Sun, 29 Sep 2019 at 17:21, Matt Sicker wrote:
>> Projects that have a configure script usually include that in the source
>> distribution but not in the source repository (at least for autotools
>> users).
> But is that correct?
This is what people expect.
As o
On 2019-09-30, sebb wrote:
> On Mon, 30 Sep 2019 at 10:25, Stefan Bodewig wrote:
>> On 2019-09-29, sebb wrote:
>>> On Sun, 29 Sep 2019 at 17:21, Matt Sicker wrote:
>>>> Projects that have a configure script usually include that in the source
>>>> dis
On 2019-10-18, Gary Gregory wrote:
> BZip2FileObject does not implement doGetContentSize() and always returns
> -1, which causes VFS to blow up if you try to read. Can this kind of
> content only be streamed?
First a "I'm not an expert in the bzip2 file format" disclaimer.
>From what I can tell
On 2019-10-18, Gilles Sadowski wrote:
> In another thread, the question was asked whether "Commons"
> follows "SemVer".[1]
> It seems to me that we (informally) abide by the intended goal.
> Why not state it explicitly (and make it a formal requirement for
> a release)?
To me it seems we have oft
On 2019-10-18, Gilles Sadowski wrote:
> My point/question was whether we do not already follow it.
We don't, at least not in all components.
Quite a few of our components don't have a patch number at all and they
sometimes create minor releases that would be patch releases if we
followed SemVer.
Hi all
I've started to look into
https://issues.apache.org/jira/browse/COMPRESS-498 which (correctly)
points out that Compress 1.18 has changed the OSGi coordinates over the
previous versions.
The symbolic name is defined inside the parent POM. In Parent 46 this
has been
org.apache.commons.
On 2019-12-19, Peter Lee wrote:
> Hi all.
> A recent issue COMPRESS-499(
> https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-499)
> discussed about a potential problem in SeekableInMemoryByteChannel.
> Based on the java docs(
> https://docs.oracle.com/en/java/javase/11/docs/api/jav
Hi all
due to a change in the parent POM the Bundle-SymbolicName of the
commons-compress JAR changed from org.apache.commons.compress to
org.apache.commons.commons-compress with version 1.18. So we've had a
lot of releases up to 1.17 with one name and two newer releases with a
different name in 1.
Hi
our travis build also uses the combination
- dist: trusty
jdk: openjdk-ea
which has started to use OpenJDK 14 a while ago and our build has been
failing there ever since. The reason is
https://openjdk.java.net/jeps/367 - the whole Pack200 stuff has been
removed without any replaceme
On 2020-01-02, Bruno P. Kinoshita wrote:
> I think if we are going to release it soon, the only option to support java
> 14+ the would be to remove it. Tell users it may be added back later either
> as-was or as a separate artefact.
If we want to cut a new release soon, we can just tell people
On 2020-01-02, Oliver Heger wrote:
> The change of the bundle name does not necessarily break all OSGi users.
> AFAIK, the recommended way to use an OSGi bundle is to import the
> packages, not to require a specific bundle - this use case would not be
> affected by the change of the bundle name.
On 2020-01-04, Emmanuel Bourg wrote:
> Le 02/01/2020 à 11:06, Stefan Bodewig a écrit :
>> Any other ideas?
> The removal of pack200 isn't an issue for the upcoming release yet since
> we still target Java 7. For now this is just an issue with the CI using
> Java 14+. Mayb
On 2020-01-04, Gary Gregory wrote:
> Java has a service leader mechanism for that. No sense in duplicating it.
Compress already supports that, and IIRC you've added that yourself :-)
Stefan
-
To unsubscribe, e-mail: dev-unsubsc
On 2020-01-05, Gary Gregory wrote:
> Is Pack200 100% Java? Even if not, I think it would be neat to bring it in
> from Apache Harmony as a new module.
What Emmanuel says.
> I think we should consider converting compress into a multi-module
> project and avoid hard dependencies. For folks who wan
Hi all
I'm trying to make the builds work on Jenkins and intend to cut a new
COmpress release soon. Right now I don't see any chance of understanding
COMPRESS-494 or COMPRESS-500 and would address 501 and 502 after the
release.
Also I'd like to postpone the pack200 issue and mention that Compress
On 2020-01-26, Gary Gregory wrote:
> On Sun, Jan 26, 2020, 07:39 wrote:
>>+ * @return the parsed PAX header
> Plural?
Not sure. I believe it is a single PAX header block holding multiple
header variables - while the code calls those header variable headers to
make things more confusing.
S
This time there are not so many bugs but significant improvements that
people are waiting to get their hands on.
Compress 1.20 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 37832)
The tag is here:
https://gitbox.apache.org/re
this is what you get when you copy-paste from the release
instructions :-)
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 04:00 UTC 31-March 2010
i.e. sometime after 16:00 UTC 05-Feb-2020
Stefan
On 2020-02-03, Rob Tompkins wrote:
> I’m not sure what changed between yesterday and today, but it seems that the
> org.apache.commons.compress.OsgiTest is failing due to a 501 being returned
> from
> http://repo1.maven.org/maven2/org/ops4j/pax/exam/pax-exam-inject/4.13.1/pax-exam-inject-4.13.1
On 2020-02-03, Rob Tompkins wrote:
> If you declare your .m2 directory to be somewhere else, do you see the same
> failure?
I do.
It looks as if there was an option to explicitly set remote
repositories, I'll try that.
Stefan
---
On 2020-02-03, Stefan Bodewig wrote:
> On 2020-02-03, Rob Tompkins wrote:
>> If you declare your .m2 directory to be somewhere else, do you see the same
>> failure?
> I do.
> It looks as if there was an option to explicitly set remote
> repositories, I'll try tha
On 2020-02-03, Rob Tompkins wrote:
> I'm fairly indifferent. I would minimally state it in the release
> notes that test fails with that.
After having slept over it, I think it is awkward that a build on a
fresh machine won't work. I'll cancel the vote.
> If you want, I'm happy to RC for 1.20-RC
Hi all
as Rob pointed out one of Compress' tests based on Pax Exam fails unless
you happen to have built it once before Maven Central started enforcing
TLS. This is fixed in master and I'll tag a RC2 and call for a new vote.
Probably tomorrow.
Thanks
Stefan
-
The only change compared to RC1 is one to a unit test which wouldn't
pass unless you already had PAX Exam in your local mvn repo.
Compress 1.20 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 37873)
The tag is here:
https://git
Making my own vote explicit.
We still lack another +1, though.
On 2020-02-05, Stefan Bodewig wrote:
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 05:30 UTC 08-Feb 2020
+
With binding +1s by Gary, Rob and myself the vote has passed.
I'll start with publishing the artifacts and will announce the release
once the mirrors have had time to catch up.
Many thanks
Stefan
-
To unsubscribe, e-mail:
On 2020-02-08, Gary Gregory wrote:
> But next time:
> - On the site: it would be nice to keep all "What's new in 1.zzz?" sections
> so users can see what's new based on the version _they_ currently have.
Really, this is going to become a pretty long list. I've resurrected all
sections since we st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.20.
Apache Commons Compress software defines an API for working with
compression and archive formats. These include: bzip2, gzip, pack200,
lzma, xz, Snappy, tradi
On 2020-02-08, Gary Gregory wrote:
> On Sat, Feb 8, 2020 at 11:50 AM Stefan Bodewig wrote:
>> On 2020-02-08, Gary Gregory wrote:
>>> - mvn javadoc:javadoc outputs LOTS of errors.
>> Not a single one for me (building with Java 8).
> Did you run 'mvn javadoc:ja
On 2020-03-07, Peter Lee wrote:
> I'm planning to build a pure Java deflater/inflater on my own. Believe this
> may help a lot.
Compress contains a pure Java Deflate64 deflater, which also is a
"normal" deflater by defintion. You may want to take a look at it.
When I implemented the LZ4 encoder
On 2020-03-08, Matt Juntunen wrote:
> I'm creating a dist-archive module for commons-geometry using
> commons-rng as a template [1]. However, when I build the project it
> fails with an errors saying that the url
> https://dist.apache.org/repos/dist/dev/commons/geometry does not
> exist, which is
On 2020-03-08, Matt Juntunen wrote:
> I don't currently have permissions for that. Is someone able to create
> "geometry" and "numbers" directories in there?
Done.
But I suspect you won't have permission to upload a distribution there
either.
Stefan
On 2020-03-09, Rob Tompkins wrote:
> We have fixed quite a few bugs and added some significant enhancements since
> Apache Commons Configuration 2.6 was released, so I would like to release
> Apache Commons Configuration 2.7.
+1
Stefan
-
On 2020-03-09, Peter Lee wrote:
> I'm thinking about adding some easy-to-use APIs for Zip. Currently I got
> some ideas :
> 1. Add extractAll(String targetPath) in ZipFile : extract all the files to
> the specific directory.
> 2. Add getInputStream(String fileName) in ZipFile : get the input strea
welcome :-)
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2020-04-01, Gilles Sadowski wrote:
> Alternatives (using the yet-to-be-created tag for the release
> candidate of the first beta version of [Numbers] as an example):
> [ ] Option 1: NUMBERS_1_0_BETA1_RC1
> [ ] Option 2: commons-numbers-1.0-beta1-rc1
> [ ] Option 3: commons-numbers_v1.0-beta
On 2020-04-01, Gary Gregory wrote:
> The docs should also make sure that release tags are in the form rel/...
> which makes them read-only.
So far I've created a new tag under rel/ for the RC tag when the vote
has been accepted. So only "real" releases end up there.
If we want to create all our
On 2020-04-24, Peter Kovacs wrote:
> Now I figured that beanshell was included into apache copmmons, which we also
> use.
The move has been proposed but actually never actually happened IIRC.
https://www.mail-archive.com/dev@taverna.incubator.apache.org/msg00224.html
is the best reference (more
On 2020-05-13, Peter Lee wrote:
> Hi,all
> The travis build of Compress is failing now cause the openjdk14 was added
> to travis.yml recently. The reason is the Pack200 was removed from JDK14
> and there was a discussion about it in January. Emmanuel is working on his
> replacement project(https
On 2020-05-14, Peter Lee wrote:
> Unfortunately it seems commons-compress can not build on Java14. Maybe we
> should provide a statement about this in README or somewhere else?
Done.
Also I added something to the "known limitations" page and will
re-generate the website.
Stefan
---
there doesn't seem to be a JDK 7 for Windows in our Jenkins farm anymore
https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix
I've made the Windows build use JDK 8 and we now rely on the Linux build
to catch JDK 7 incompatibilites.
Stefan
On 2020-05-26, wrote:
> -public void addPaxHeader(String name,String value) {
> - processPaxHeader(name,value);
> +public void addPaxHeader(String name, String value) throws IOException {
> +processPaxHeader(name, value);
no, we can't do that. Adding a checked exception t
On 2020-05-26, wrote:
>+// COMPRESS-530 : skip non-number chars
>+if (ch < '0' || ch > '9') {
>+continue;
>+}
if this ever happens, doesn't that mean the PAX header is malformed? In
that case may it be better to throw an IOExcep
On 2020-05-27, Peter Lee wrote:
> Oops, sorry about that.
No big deal. Better we detect that now than at the point when we want to
cut the release.
> Will undo all the commits.
It may be possible to keep most of your code changes without breaking
the public API. I must admit I haven't lloked a
1 - 100 of 1321 matches
Mail list logo
