script.
>> On Tue, 13 Jul 2021 at 11:04, sebb wrote:
>>> On Tue, 13 Jul 2021 at 10:28, Stefan Bodewig wrote:
>>>> On 2021-07-13, Bruno P. Kinoshita wrote:
>>>>> I think I used this page when publishing the site?
>>>>> http://comm
>> Are there any tests that actually use the uid/gid of the current user?
>> Compress will no read them by itself, so the only place things could
>> fail was if we used native tar to create an archive. Is there such a
>> test? If so we could try to adapt the test in question.
On 2021-07-10, Henr
On 2021-07-13, sebb wrote:
> On Tue, 13 Jul 2021 at 10:28, Stefan Bodewig wrote:
>> On 2021-07-13, Bruno P. Kinoshita wrote:
>>> I think I used this page when publishing the site?
>>> http://commons.apache.org/site-publish.html
>> Yes, that's what I
On 2021-07-13, Bruno P. Kinoshita wrote:
> I think I used this page when publishing the site?
> http://commons.apache.org/site-publish.html
Yes, that's what I've done for the past releases as well ;-)
https://cms.apache.org/commons/publish is what it tells you to use - and
this one returns an
On 2021-07-13, Henri Biestro wrote:
> You actually don't change the main site, just the component site if
> I'm not mistaken. I guess you found this;
> http://commons.apache.org/site-publish.html#Main_site . When
> everything is set correctly, the site-deploy target does everything
> for you, nam
Hi
I recall the CMS is no more but I haven't followed how to publish the
site now. The docs still talk about the CMS.
I have updated component_releases.properties and the DOAP file for
compress but don't know how to apply the change to the deployed website.
Stefan
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.21.
Apache Commons Compress software defines an API for working with
compression and archive formats. These include: bzip2, gzip, pack200,
lzma, xz, Snappy, tradi
Hi
with +1s by Gary Gregory, Bruno P. Kinoshita, Peter Lee and myself, the
vote has passed.
I'll publish the artifacts and will announce the release once the
mirrors have caught up - which probably means after a night of sleep for
myself :-)
Many thanks to all who have verified the release candi
Making my own vote explicit
[X] +1 Release these artifacts
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2021-07-10, Henri Biestro wrote:
> Side note whilst trying to validate RC1:
> On a Mac that used LDAP, user ids and groups are 'long':
> henri.biestro@L-HBIESTRO-1 commons-compress % id
> uid=1447288081(henri.biestro) gid=1024222515
Didn't know that.
> A lot of tar tests will fail in this (p
On 2021-07-10, Bruno P. Kinoshita wrote:
> The RELEASE-NOTES.txt for 1.21 starts with "Compress 1.20 now at least
> requires Java 8 to build and run." which is a bit confusing, but not a
> major issue. (Maybe it would be better to say "Compress 1.20 and later
> require Java 8..."?)
It is going to
On 2021-07-09, Gary Gregory wrote:
> "Details of changes since 1.19 are in the release notes:"
> 1.19 -> 1.20 ;-)
fortunately only the vote mail is wrong.
It even is true, in a way, the release notes even include all changes
since 1.0. :-)
Stefan
--
It's been way too long since the last relase and the number of resolved
issues is huge.
Compress 1.21 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 48755)
The tag is here:
https://gitbox.apache.org/repos/asf?p=commons-compres
On 2021-07-03, Stefan Bodewig wrote:
> I assume the code originates from
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack200/src/main/
> and I'd look into porting the tests from
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk
Hi all
is there anything you want to work on or can we go ahead with cutting a
new Compress release in about a week?
There are some test coverage and javadoc issues that need to get
resolved but other than that at least I do not intend to work on any
changes or new features.
A current build of t
Hi
our current pack200 tests don't seem to cover much of the pack200 code
imported from harmony and the overall test coverage of Compress as a
whole has dropped significantly (from 86% to 61%) as the new package
contains quite a bit of code.
I assume the code originates from
https://svn.apache.or
On 2021-07-03, Gary Gregory wrote:
> This is the approach I've taken: I merged the pack200 branch into
> master as is.
Thank you
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
On 2021-06-12, Gary Gregory wrote:
> Please have a look at the pack200 branch if you want, there are still
> Javadoc TODOs but it's all there.
Just so we get this into this list's archive properly: I've propsed a
few changes in https://github.com/apache/commons-compress/pull/210 but
completely le
On 2021-07-01, Torsten Curdt wrote:
>> That certainly doesn't prevent anybody else from trying to find a
>> compromise :-)
> It feels like Optionals could be a compromise.
I must admit I've lost track of the later discussion threads. If you
mean that we'd return Optional<> results, this would be
Hi all
there isn't a single option that hasn't at least received two -1s with
eight people indicating their preference. So neither option seems to be
an option that could lead to a compromise.
With this I run out of ideas and will rest my case and not try to find a
generic solution - but rather t
On 2021-06-29, Stefan Bodewig wrote:
> Options raised during the thread:
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> subclass) and throw the IOException
+1
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOExcept
Hi
I'm sorry, but I'm unable to see what would or would not work for the
people who chimed in. Short of calling for a vote, lets try with a poll
that could show whether there is some sort of solution that is
acceptable to everybody.
Please use +1 to mean "I like this option", +0 to mean "the opti
On 2021-06-29, Miguel Munoz wrote:
> Catching all RuntimeExceptions and wrapping them in an IOException
> looks like the cleanest solution. RuntimeExceptions usually mean bugs,
> so if the archive code is throwing them due to a corrupted archive, it
> makes sense to wrap it in a checked exception.
On 2021-06-27, Gilles Sadowski wrote:
> Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>> As I said, we can as well document that each method could throw
>> arbitrary RuntimeExceptions, but I don't believe we can list the kinds
>> of RuntimeExceptions exhausti
On 2021-06-27, Gilles Sadowski wrote:
> Hi.
>> [...]
>> it seemed Gilles was opposed to this idea
> Rather (IIRC) my last comment was that it was your choice as to
> what the API should look like.
Sorry, I didn't mean to misrepresent your POV.
> My opinion on the matter was along Gary's lines
On 2021-06-27, Gary Gregory wrote:
> Catching all unchecked exceptions (UE) and rethrowing as checked exceptions
> (CE) feels like both a horror show and an exercise in futility, especially
> in order to appease some tool that complains today of one thing which may
> complain differently tomorrow,
Hi
I'd like to get closure on which approach we want to take.
When we read a broken archive it may trigger arbitrary RuntimeExceptions
because we are not explicitly checking for each and every sizuation
where a bounds check could fail, a negative size is sent to a classlib
method that then throws
On 2021-06-12, Stefan Bodewig wrote:
> On 2021-06-12, Gary Gregory wrote:
>> Please note that the Java 16 and 17 builds are now green on GitHub after my
>> changes this morning to update some dependencies.
> They haven't been green before - or for any JDK > 14 - be
On 2021-06-12, Gary Gregory wrote:
> Please note that the Java 16 and 17 builds are now green on GitHub after my
> changes this morning to update some dependencies.
They haven't been green before - or for any JDK > 14 - because of
missing pack200 classes inside of the classlib.
Stefan
-
On 2021-06-06, Gilles Sadowski wrote:
> Le dim. 6 juin 2021 à 07:51, Stefan Bodewig a écrit :
>> Hi
>> I'm thinking about a specific IOException subclass that is thrown when a
>> RuntimeException "happens" somewhere in the code that parses data in
>&g
Hi
I'm thinking about a specific IOException subclass that is thrown when a
RuntimeException "happens" somewhere in the code that parses data in
Zip/SevenZ/TarFile, see
https://github.com/apache/commons-compress/compare/catch-RuntimeExceptions
is this a good idea? Should anything be worded/named
Hi all
7z archives provide CRCs for the metadata section so you can quickly
identify a wide range of broken archives - which is far better than what
you get for ZIP for example.
It is possible to recover from a certain type of broken archive. A case
where the archive has been written almost compl
On 2021-05-24, Bernd wrote:
> Am Mo., 24. Mai 2021 um 20:46 Uhr schrieb Matt Sicker :
>> There's also a bit of an issue of fixing these types of
>> vulnerabilities at the library level. The library itself typically
>> won't have much in the way of a security model until you integrate it
>> into a
On 2021-05-24, Tero Saarni wrote:
> We are getting reports from JFrog Xray vulnerability scanner that seem
> to be related to recently fixed OSS-Fuzz issues:
I wasn't aware of this effect. This is very unfortunate.
> * Summary: Apache Commons Compress archivers/zip/ZipFile.java
> ZipFile::read
Many thanks Fabian
and sorry for the delay - unfortunately I'm not really able to free up
as much time as necessary for any OSS stuff right now
On 2021-05-03, Fabian Meumertzheim wrote:
> The behavior you are observing has only become the standard somewhat
> recently [1], which is also why I had
Hi (Fabian)
by now we've resolved the first issues detected by ClusterFuzz (and I
forgot to credit it OSS Fuzz in Compress, my bad). What we observed is
that the issues became public automatically once the patch fixing the
issue was merged into master and ClusterFuzz reran the test. In the case
of
On 2021-04-19, Stefan Bodewig wrote:
> On 2021-04-18, Fabian Meumertzheim wrote:
>> Stefan, if you agree, I would submit the two PRs tomorrow and ask you
>> to sign them off on GitHub via a comment on the PR and a link to this
>> email thread.
> Fine with me.
I hope my
On 2021-04-18, Fabian Meumertzheim wrote:
> Stefan, if you agree, I would submit the two PRs tomorrow and ask you
> to sign them off on GitHub via a comment on the PR and a link to this
> email thread.
Fine with me.
Thank you
Stefan
---
On 2021-04-18, Fabian Meumertzheim wrote:
> On Sun, Apr 18, 2021 at 6:22 PM Stefan Bodewig wrote:
>> Can probably do, what is the duty of a primary contact? My github
>> username is bodewig.
> The primary contact may be asked to sign off on PRs to that project in
>
On 2021-04-18, Stefan Bodewig wrote:
> I've created https://issues.apache.org/jira/browse/INFRA-21741 if you
> want to lend a hand moderating, you may want to add yourself to the
> ticket before the list is created.
The list has been created, so if you want to receive the fuzz
you want to act as the "primary_contact"? That does not
> require a Google account, but a GitHub account would be helpful for
> interactions with the OSS-Fuzz repo.
Can probably do, what is the duty of a primary contact? My github
username is bodewig.
> I have prepared fuzzers for compress a
Hi all
I've created https://issues.apache.org/jira/browse/INFRA-21741 if you
want to lend a hand moderating, you may want to add yourself to the
ticket before the list is created.
Thanks
Stefan
-
To unsubscribe, e-mail:
On 2021-04-17, Matt Sicker wrote:
> I have a Google account I can be CC’d on. I do security engineering
> professionally, so I have some experience in the area as well.
Thanks Matt, I'll add you as one of the initial moderators as well.
Stefan
---
On 2021-04-17, Fabian Meumertzheim wrote:
> Let me describe the restrictions in more detail, including example reports.
> Everyone listed under "primary" or "auto_cc" will receive the bugs created
> in the issue tracker at [1] in email form and can also add comments by
> replying to the email thre
On 2021-04-15, Fabian Meumertzheim wrote:
> Just to keep the following in mind: Full access to bug reports and
> reproducers requires a Google account (which can be associated with
> any existing non-list email address). At least the moderators of the
> list would therefore have to be listed expli
On 2021-04-13, Gary Gregory wrote:
> Please don't use @security for automated emails, that ML IMO should be for
> humans.
> If you want to setup a new ML for bots that's fine, we can direct GitHub's
> Dependanot emails there if GitHub allows for that.
I don't believe dependabot and the results o
On 2021-04-13, Mark Thomas wrote:
> On 13/04/2021 17:49, Stefan Bodewig wrote:
>
>> Fabian has offered to set up OSS Fuzz for Compress. Given that the
>> issues OSS Fuzz detects may or may not be security sensitive, I don't
>> feel it would be a good idea to ha
Hi all
I want to pick up (and finish) the discussion that started in
Compress[1].
Short Recap:
OSS Fuzz[2] runs fuzz testing for open source projects by invoking
methods of our code with random data looking for unexpected outcomes
(undeclared exceptions or worse code that never retu
On 2021-03-09, Gary Gregory wrote:
> A reminder that we can break our own builds by configuring maven plugins
> like spotbugs, pmd, and so on. If we need to configure another plugin to
> run in our builds to check for different errors, then let's consider that.
Fuzz testing need compute power bey
On 2021-03-08, Gary Gregory wrote:
> Note that we already have FIVE mailing lists:
> commits
> dev
> issues
> notifications
> user
which are all public
> PLUS, private and security.
subscribers of which will probably not like to receive automated emails.
> Do we really want a SIXTH? Can't thi
On 2021-03-08, Gary Gregory wrote:
> Are we talking about a human sending emails to the security list or letting
> the actual tool loose on the list to possibly spam it with false positives?
We are talking about a tool sending mails that (currently) is unable to
identify whether an issue it detec
Gary
> On Sun, Mar 7, 2021, 12:45 Matt Sicker wrote:
>> We could create another private list for static analysis alerts perhaps?
>> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig wrote:
>>> On 2021-03-07, Fabian Meumertzheim wrote:
>>>> On Sat, Mar 6, 2021 at
On 2021-03-07, Fabian Meumertzheim wrote:
> On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig wrote:
>> OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't
>> read the docs only looked at the image of the process. Seeing a
>> Sheriffbot track
On 2021-03-05, Fabian Meumertzheim wrote:
> I am one of the maintainers of Jazzer
> (https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
> fuzzer for JVM projects based on libFuzzer.
> I have set up a few Commons projects for local fuzzing with Jazzer,
> which lead to quite a fe
On 2020-07-26, Melloware wrote:
> I know there seems to to be a holy war about the use of GitHub going
> on here
This has never been my intention. Far from it. And if you believ I've
tried to start any kind of war you must have misread my original mail
completely. I'm really sorry about thaty.
I
On 2020-07-24, Xeno Amess wrote:
>> We respectfully discuss and in the end come to a compromise or a common
>> ground where we can agree to disagree. I still see this happen here and
>> don't think all of us need to have the same opinion.
> So maybe at the end some of commons repos using as new
On 2020-07-23, Olivier Lamy wrote:
> In the Maven project we have plenty of maven-* git repo so we have created
> a dedicated Jenkins plugin (which is used by other TLP such netbeans) which
> scan the gitbox server to get repo based on regular expression or name
> content and create the build reus
On 2020-07-24, Xeno Amess wrote:
> As for community building, I agree with you that commons seems not a
> close community, but I doubt it be github's fault. even there be no
> github, sub-repos in commons are not that close to each other.
Commons is an old project and it started with a striving
On 2020-07-24, Xeno Amess wrote:
> I will explain why github come to be center, but not apache gitbox.
> 1.1
> I have right to register an account on github.
> 1.2
> I registered an account at github.
> 1.3
> I commit then create pr.
> 1.4
> pr get reviewed then merged.
I am fully aware of how gi
This is an attempt at answering something raised be Gilles in a
different thread. I'm afraid it is getting longer than I
intended. Something seems to need to get out. Sorry.
On 2020-07-23, Gilles Sadowski wrote:
> I missed the turn where this project's PMC decided that we must
> be present on GH
On 2020-07-24, Bernd Eckenfels wrote:
> When it comes to dependencies wie have both problems: if we upgrade
> dependencies to aggressively (or if we don't test with older dependencies)
> then users have the problem that they might not easily be able to upgrade to
> a new commons version since t
On 2020-07-24, Xeno Amess wrote:
> how about:
> 1. we force versions of dependencies in commons-parent
> 2. we make every commons repo use commons-parent as parent.
> 3. we make sure no other repos forces versions of dependencies; all of the
> versions number shall be inherited from commons-parent
On 2020-07-24, Gary Gregory wrote:
> Now back to our code depending on other dependencies. My view is that there
> are bugs, you just have not hit them. If I find one in a dependency and it
> gets fixed, it's going to mean a new version of that dependency.
This either is "we hit a bug that affect
On 2020-07-24, Torsten Curdt wrote:
> It still needs a person to decide to merge a PR for a new version.
> So this indeed is just about the dependency upgrade policies.
Right.
> But isn't that what the version definition is for?
> I'd argue that 1.12.4 <-> 1.12.6 should be a compatible upgrade A
Hi all
here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.
First of all let me get a few things out of the
On 2020-07-24, Rob Tompkins wrote:
>> On Jul 23, 2020, at 10:16 PM, Matt Sicker wrote:
>> Also, how different is a bot proposing a dependency update from a human
>> doing the same? The bot includes far more context about the update in the
>> PR comment, too, which is super useful for determinin
On 2020-07-23, Oliver Heger wrote:
> Am 22.07.20 um 18:28 schrieb Stefan Bodewig:
>> On 2020-07-22, Rob Tompkins wrote:
>>> I’m happy to merge them….will get to them by tomorrow morning ok?
>> Personally I don't see any value for our downstream users if we updat
On 2020-07-23, Stefan Bodewig wrote:
> My preference would be for using less of github rather than more. But
> I'm probably alone with that.
Of course I'm not. Sorry Gilles. :-)
Stefan
-
To unsubscribe, e-ma
On 2020-07-23, Gilles Sadowski wrote:
> If I'm not mistaken, the issues@ ML was intended to keep one
> posted of and reactive on a human discussion happening on
> JIRA. With the advent of JIRA-GitHub integration, the ratio of
> auto-generated messages relayed through that channel has
> exploded,
On 2020-07-22, Gary Gregory wrote:
> My main driver is that we already use GitHub for source mirroring and PRs,
> so it feels better to me to have builds in the same place.
My preference would be for using less of github rather than more. But
I'm probably alone with that.
-0 on defaulting to git
I hope anybody sees this message.
Can we please discuss this per component? I personally do like the idea
of dependabot for applications but feel it is completly wrong for
libraries and would prefer to not use it.
Stefan
-
To un
To answer the question of your subject: my opinion is a very strong NO.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2020-07-22, Rob Tompkins wrote:
> I’m happy to merge them….will get to them by tomorrow morning ok?
TBH I'd prefer to turn them off and reject the PRs.
Personally I don't see any value for our downstream users if we update
our dependencies without actually needing an update - with the excepti
On 2020-07-18, Merbin J Anselm wrote:
> Well. Commons Fileupload's last release was in December 2018 and it has
> been released at least once a year before that. My thoughts were on this
> line
Well, the question is whether there have been changes that would warrant
a new release at all. It hasn'
On 2020-07-12, Rob Tompkins wrote:
> given the consistency of the signatures from the plugins…do we need to
> check them for releases anymore?
Yes, please. Not everybody uses the plugins and even if everybody did a
misconfiguration could be pulling in the wrong key or a key not
available from the
On 2020-06-28, Peter Lee wrote:
> Currently we will add a Zip64 extra field for the entries with uncompressed
> size unspecified. And we will update the zip64 extra field in
> ZipArchiveOutputStream.rewriteSizesAndCrc a little bit : if we actually
> doesn't need a Zip64 extra, we will not remove i
On 2020-06-12, Gilles Sadowski wrote:
> 2020-06-12 15:52 UTC+02:00, Xeno Amess :
>> But if Apache Commons is thought to be a whole project, I do think
>> the relationship between each of its components should be enforced.
The Commons project is the legal entity that binds people with similar
int
On 2020-06-12, Xeno Amess wrote:
> Hi.
>>> 2. How are commons projects related?
>> They are not necessarily related. Usually it is considered
>> a feature if a component has zero dependency (as it is was
>> easier to avoid "JAR hell").
>> However, there are also drawbacks, e.g. duplicating func
On 2020-06-02, Peter Lee wrote:
> Oops, I was looking the commit and found two @throws
> IllegalArgumentException, and I was thinking this is a duplicated throws
> caused by copy-paste. And I was so much foolish that I deleted it without
> any invesgating into the code. Really sorry about this.
N
On 2020-06-01, wrote:
> The following commit(s) were added to refs/heads/master by this push:
> new 42b6aa4 minor typos cleanup
> - * @throws IllegalArgumentException if the {@link
> TarArchiveOutputStream#longFileMode} equals
> - * {@link
> TarArc
On 2020-05-27, Peter Lee wrote:
> Did some googles, can't find too much but this :
> https://www.systutorials.com/docs/linux/man/5-star/
> And it says :
>> Each record starts with a a decimal length field. The length includes the
>> total size of a record including the length field itself and the
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
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-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
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-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
---
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-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-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-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
welcome :-)
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
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
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-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-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-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-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
-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:
> 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
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:
1 - 100 of 1321 matches
Mail list logo
