On 2018-08-12, Gary Gregory wrote:
> Whatever you do, please document in the parent what does what and how a
> component should enable and disable the report.
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1837064=1837920
Actually, you don't have to do anything. It
Has anyone communicated these issues (whatever they are) back to the japicmp
author(s)? Or are they unaware?
Forking the project in Commons means you’ve given up on the maintainers. It
also likely means a significant time investment. Why not spend a fraction of
that time to submit a bug fix to
If you want to avoid a dependency I would not create a custom logging
abstraction but just use JUL. Most logging libraries have JUL adapters so
clients can do the bridging on their side.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Aug 13, 2018, at 0:17, Matt
On Sun, 12 Aug 2018 08:59:56 -0600, Gary Gregory wrote:
+1
From src zip: ASC, SHA1, SHA256 OK.
In the future, we should only publish SHA512 files per recent Apache
guideline (some email I saw on the security ML IIRC.)
mvn apache-rat:check OK
mvn clirr:check OK
mvn clean install site OK
Using
> On Aug 12, 2018, at 11:16 AM, Stefan Bodewig wrote:
>
>> On 2018-08-12, Rob Tompkins wrote:
>>
>> I agree with this statement generally. That said, this doesn’t
>> surprise me that I made this error because japicmp is minimally
>> cumbersome to work with.
>
> I didn't mean to blame you,
Whatever you do, please document in the parent what does what and how a
component should enable and disable the report.
Thanks!
Gary
On Sun, Aug 12, 2018 at 9:16 AM Stefan Bodewig wrote:
> On 2018-08-12, Rob Tompkins wrote:
>
> > I agree with this statement generally. That said, this doesn’t
>
What I've seen done when trying to avoid a logging API dependency is to
create a minimal logging API purely for framework use. This can have a
default System.err style implementation, but the idea is to make it easy
(and performant hopefully) to bridge into the end user's choice of
framework and
On 2018-08-12, Rob Tompkins wrote:
> I agree with this statement generally. That said, this doesn’t
> surprise me that I made this error because japicmp is minimally
> cumbersome to work with.
I didn't mean to blame you, sorry if you received it that way. Fully
agreed that japicmp is a pain, but
+1
>From src zip: ASC, SHA1, SHA256 OK.
In the future, we should only publish SHA512 files per recent Apache
guideline (some email I saw on the security ML IIRC.)
mvn apache-rat:check OK
mvn clirr:check OK
mvn clean install site OK
Using
Apache Maven 3.5.4
On Fri, Aug 10, 2018 at 9:35 PM Gilles wrote:
> Hello Rob.
>
> On Fri, 10 Aug 2018 21:52:38 -0400, Rob Tompkins wrote:
> > We have added some significant enhancements since Apache Commons RNG
> > 1.0 was released, so I would like to release Apache Commons RNG 1.1.
> >
> > Apache Commons RNG 1.1
You could also log to a pluggable print stream which could be sys err by
default. Kind of like what JDBC allows. My bias is to Log4j 2 as well :-)
Gary
On Sun, Aug 12, 2018, 08:00 Remko Popma wrote:
> There’s a couple of considerations about doing logging in a library, but
> I’ll just mention
+1 using japicmp is maddening due to bugs. It feels unsupported... fork it
and fix it within Commons?
Gary
On Sun, Aug 12, 2018, 07:08 Rob Tompkins wrote:
> I agree with this statement generally. That said, this doesn’t surprise me
> that I made this error because japicmp is minimally
Keep in mind the option of releasing an alpha or beta version first to
allow for API changes...
Gary
On Sun, Aug 12, 2018, 03:12 Bruno P. Kinoshita
wrote:
> Oh, sounds reasonable.
> So going to try 1.0 with Java 7, then possibly another bug fix release
> after that (there are some issues I'd
There’s a couple of considerations about doing logging in a library, but I’ll
just mention a few:
* dependencies
* performance
* ease of use
* Dependencies*
Will the library be less attractive to users if it requires an external
dependency? Then don’t introduce one (so: use system err or
I agree with this statement generally. That said, this doesn’t surprise me that
I made this error because japicmp is minimally cumbersome to work with. It
feels very unfinished/unpolished. Next time I get into [parent], I’ll try to go
up and submit more polishing work to the japicmp codebase.
Hi
while building the site for Compress the japicmp report was empty,
taking a closer look there is a little warning that says "skipping
report because skip is set to true" which in fact it is.
http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1832506=185
added this
Hello Bruno.
On Sun, 12 Aug 2018 08:56:37 + (UTC), Bruno P. Kinoshita wrote:
Hi all,
I commented on IMAGING-154, but copying the last comment here as it
contains the approach I would like to follow to fix the last change
in
the project blocking
a 1.0 release:
---
So went ahead to
On 2018-08-11, Gary Gregory wrote:
> The reports should include RAT.
https://stefan.samaflost.de/staging/commons-compress-1.18/rat-report.html
has been there all the time :-)
Stefan
-
To unsubscribe, e-mail:
On 2018-08-11, Gary Gregory wrote:
> The reports should include RAT.
> The japicmp report is blank, either fix or replace with Clirr.
strange, I haven't changed anything, so the disappearing RAT report and
the empty japicmp must be due to Compress upgrading commons-parent. I'll
have to
Oh, sounds reasonable.
So going to try 1.0 with Java 7, then possibly another bug fix release after
that (there are some issues I'd like to fix, but after 1.0 is out). And finally
in 1.2 or after we can go to Java 8.
Thanks Pascal!
Bruno
From: Pascal Schumacher
To:
Hi Bruno,
imho it would be preferable to release 1.0 using Java 7. That would
allow everybody using snapshots to replace them with a release. E.g.
https://github.com/LibrePDF/OpenPDF is using a snapshot but is still on
Java 7.
After the release we can update to Java 8 for 1.1.
Cheers,
Hi all,
I commented on IMAGING-154, but copying the last comment here as it contains
the approach I would like to follow to fix the last change in the project
blocking
a 1.0 release:
---
So went ahead to re-design the Debug class, in a way users could still
enable/disable debugging, and
22 matches
Mail list logo
