Yes, a new lang release would be great. :-)
Thanks,
Pascal
Am 14.08.2018 um 03:31 schrieb Gary Gregory:
Go for it! :-)
Gary
On Mon, Aug 13, 2018, 18:36 Rob Tompkins wrote:
Hello all,
I’m planning on working on 3.8 for lang later this week. Does anyone want
to get any specific jira's in? I
On 2018-08-14, Rob Tompkins wrote:
> Must fix during artifact promotion:
> (1) Signature files contain more than the correct signatures (note the
> contents below):
This is the well known default format of GNU textutil's sha256sum.
Is this really a problem? I'm not aware of any policy that req
On Mon, Aug 13, 2018 at 10:21 PM Stefan Bodewig wrote:
> On 2018-08-13, Gary Gregory wrote:
>
> >> From src zip: ASC, SHA256 OK.
> > In the future we should only publish SHA512 hashes.
>
> can do.
>
> > Site typo: "It is no possible to specifiy various parameters for Zstd
> > output."
> > -> "It
On Mon, Aug 13, 2018 at 10:21 PM Stefan Bodewig wrote:
> On 2018-08-13, Gary Gregory wrote:
>
> >> From src zip: ASC, SHA256 OK.
> > In the future we should only publish SHA512 hashes.
>
> can do.
>
> > Site typo: "It is no possible to specifiy various parameters for Zstd
> > output."
> > -> "It
On 2018-08-13, Gary Gregory wrote:
>> From src zip: ASC, SHA256 OK.
> In the future we should only publish SHA512 hashes.
can do.
> Site typo: "It is no possible to specifiy various parameters for Zstd
> output."
> -> "It is *now *possible to *specify *various parameters for Zstd output."
Thank
Go for it! :-)
Gary
On Mon, Aug 13, 2018, 18:36 Rob Tompkins wrote:
> Hello all,
>
> I’m planning on working on 3.8 for lang later this week. Does anyone want
> to get any specific jira's in? I think that I can quickly button up
> LANG-1408 (selfishly want to get that in).
>
> Cheers,
> -Rob
>
+1
'mvn clean test package site' works with
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jd
Hello all,
I’m planning on working on 3.8 for lang later this week. Does anyone want to
get any specific jira's in? I think that I can quickly button up LANG-1408
(selfishly want to get that in).
Cheers,
-Rob
-
To unsubscribe,
TLDR;
The release distribution checksum policy requires new releases to use
SHA-512 or SHA-256 and not SHA-1 for verification. Existing releases do not
need to be changed. Releases still need to be signed via detached PGP
signatures.
-- Forwarded message -
From: Craig Russell
Dat
I'll get to this in the morning. I'm currently dealing with a PICNIC at work.
Rob Tompkins
804.241.3104
christopher.tompk...@capitalone.com
chtom...@apache.org
On 8/13/18, 2:24 PM, "Gary Gregory" wrote:
+1
From src zip: ASC, SHA256 OK.
In the future we should only publish SHA5
As an end user of JUL in other projects, let me warn you that you'll miss a
lot of abstractions that log4j2 and slf4j provide. :)
On Mon, 13 Aug 2018 at 09:50, Gary Gregory wrote:
> I like Remko's suggestion, a nice application of the KISS principle ;-)
>
> Gary
>
> On Mon, Aug 13, 2018, 07:58 R
+1
>From src zip: ASC, SHA256 OK.
In the future we should only publish SHA512 hashes.
Site typo: "It is no possible to specifiy various parameters for Zstd
output."
-> "It is *now *possible to *specify *various parameters for Zstd output."
changes.xml needs a release date (I usually try to remem
I like Remko's suggestion, a nice application of the KISS principle ;-)
Gary
On Mon, Aug 13, 2018, 07:58 Remko Popma wrote:
> If it was up to me I would use JUL in this particular case to keep the
> library free of dependencies. JUL is reasonable since performance is not an
> issue.
>
> Users t
On 13 August 2018 at 14:57, Remko Popma wrote:
> If it was up to me I would use JUL in this particular case to keep the
> library free of dependencies. JUL is reasonable since performance is not an
> issue.
>
> Users that use a logging framework can redirect the JUL logging into their
> log fil
If it was up to me I would use JUL in this particular case to keep the library
free of dependencies. JUL is reasonable since performance is not an issue.
Users that use a logging framework can redirect the JUL logging into their log
file with the JUL adapter of their logging library.
But that
I was thinking more about using that as an argument for using a logging
framework, but I think you are right. Probably slf4j/commons-logging + some
default binding, then allowing users to change the implementation.
Perhaps slf4j + log4j?
Bruno
From: Remko Popm
For new projects I would really avoid using Commons Logging. Ceki had a point
when he created SLF4J.
The projects you mentioned that have a dependency on Commons Logging were
started before SLF4J (and perhaps JUL) were created, I believe.
(Shameless plug) Every java main() method deserves ht
Hi Bruno.
On Mon, 13 Aug 2018 09:22:27 + (UTC), Bruno P. Kinoshita wrote:
Right now that's where I am standing too. If adding a dependency to
log4j is a no-no, then I'd probably check if jul would be OK, or
otherwise maybe import just Log4J's LowLevelLogUtil into the project
would work?
Co
Right now that's where I am standing too. If adding a dependency to log4j is a
no-no, then I'd probably check if jul would be OK, or otherwise maybe import
just Log4J's LowLevelLogUtil into the project would work?
Commons DBCP, Commons Configuration, Commons Beanutils, Commons JEXL, and
Common
Hi Matt!
>What I've seen done when trying to avoid a logging API dependency is to
>create a minimal logging API purely for framework use.
I've seen that happening in some projects, and not only in Java. I'd prefer to
use a logging library to simply the code maintenance for now, if possible.
Hi Gary,
that was my intention. But the API of Commons Imaging contains certain methods
like #dump, which call utility private methods (e.g. printbytes) that may print
to System.out, if a flag "verbose" is enabled.
I started changing the signatures of these methods, to allow for a
`PrintStream
Hi Remko!
Thanks a lot for your reply, and for the great points.
As for dependencies, being an image library, I think eventually we may have
dependencies in Commons Imaging. I am not keen to add dependencies myself, but
there could be a case for a dependency in order to support some image type
On Sat, 2018-08-11 at 22:14 +0100, Mark Thomas wrote:
>
https://docs.digicert.com/api-developer-portal/secure-app-service-api/downloads-and-resources/sas-csp-for-java-hash-signing/
For the record, the documentation also references a solution using the
maven-jarsigner-plugin.
Robert
---
Hello Gilles!
I was interested in hearing your opinion as you commented in the previous
thread too.
>[Hmm... Does "internal" mean that minor release can break BC
>on such a class?]
I think so, yes. [1] is a commit to a temporary branch, where I renamed the
.util package to internal, and u
Hi all,
I would like to release Compress 1.18.
Compress 1.18 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision
28684)
The tag is here:
tag 1.18-RC1 on commit b95d5cde
https://git-wip-us.apache.org/repos/asf?p=commons-compress.g
25 matches
Mail list logo
