Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11224344)
Coverage increased (+0.03%) to 84.263% when pulling
**26eab98e3a0d40358
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11223865)
Coverage increased (+0.02%) to 84.26% when pulling
**0e8ff9c44058afbca9
In the case of Commons Logging, Log4j 2 works that way - Commons Logging uses
log4j-jcl as its implementation. But SLF4J replaces Commons Logging with
slf4j-over-jcl, so you must make sure the commons-logging jar is not present.
What Stephen is saying is that in that case commons-logging and slf
Fixed in SVN. Thank you for the good catch.
Gary
On Thu, Apr 20, 2017 at 5:59 AM, Gary Gregory
wrote:
>
>
> On Apr 20, 2017 2:40 AM, "Oliver Heger"
> wrote:
>
>
>
> Am 20.04.2017 um 05:17 schrieb ggreg...@apache.org:
>
>> Author: ggregory
>> Date: Thu Apr 20 03:17:59 2017
>> New Revision: 1792
Hm, I don't think a bridge implementation needs to fake a (API) module.
Your client code requires the API module and no specific implementation. The
implementations (including the bridge) export their specific packages to the
API module (optionally with service provider for discovery).
This is
(all addressees apart from dev@commons.a.o moved to bcc)
All,
My apologies.
I intended to send this to the Commons PMC's private list and put the
wrong addressee for the Commons project.
Fortunately the issue is already largely public at
https://issues.apache.org/jira/browse/JEXL-223 but even s
The Apache Commons project will not be treating this as a security
vulnerability. Executing untrusted / unsanitized / unvalidated code in a
scripting environment is always dangerous.
Progress may be followed via:
https://issues.apache.org/jira/browse/JEXL-223
Mark
On 21/04/17 08:52, Cloudsecint
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11213136)
Coverage increased (+0.04%) to 84.274% when pulling
**b10528a62e51b2c5f
On 24 April 2017 at 11:08, Jörg Schaible wrote:
> Stephen Colebourne wrote:
>
>> Sounds like you could use --add-modules to add the module separately
>> from the command line, or add the module to the application's
>> module-info rather than the libraries.
>>
>> In general, I suspect a library mod
Github user tballison commented on the issue:
https://github.com/apache/commons-compress/pull/20
+1 to both suggestions. Will do. Thank you.
---
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
Stephen Colebourne wrote:
> Sounds like you could use --add-modules to add the module separately
> from the command line, or add the module to the application's
> module-info rather than the libraries.
>
> In general, I suspect a library module-info.java should depend only on
> the other modules
Sounds like you could use --add-modules to add the module separately
from the command line, or add the module to the application's
module-info rather than the libraries.
In general, I suspect a library module-info.java should depend only on
the other modules it really needs (eg. the API of slf4j),
Hm why is that? What step in your compile would need the runtime module?
Gruss
Bernd
--
http://bernd.eckenfels.net
From: Ralph Goers
Sent: Sunday, April 23, 2017 7:14:02 PM
To: Commons Developers List
Subject: Re: [all] Java 9 module names
Yes, I know it doesn't
I changed the new item to "commons" and deleted the old one.
Cheers,Eyal
On Sunday, April 23, 2017 4:18 AM, Gilles
wrote:
Hello.
On Sat, 22 Apr 2017 18:30:46 + (UTC), Eyal Allweil wrote:
> Hi Gilles,
> It looks like there is no "edit" feature in Help Wanted.
>
> https://lists.apa
14 matches
Mail list logo
