[all] getting japicmp to work in pom modules

I’ve opened an issue on the project, and am planning on working on the code to see if I can get it working. Let me know if you guys have any thoughts. https://github.com/siom79/japicmp/issues/207 Cheers, -Rob

[rng] japicmp failure

I was starting to fiddle with [parent] version 46 with [rng] and stumbled across the seemingly legitimate japicmp failure. @Gilles - any thoughts here? If it is indeed correct I would think those would be BC incompatible changes between 1.0 and 1.1. -Rob Comparing source compatibility of commo

Re: [compress] High Level API for Archives

> > > That said - optional dependencies are also not really my favorite thing. > > I am myself a big fan of shading dependencies in libraries (if the > license > > allows), > > which also forces one to re-evaluate the modularity vs inclusiveness of > > (even transitive) dependencies. > > > > I'm ge

Re: [compress] High Level API for Archives

On 1 May 2018 at 12:23, Torsten Curdt wrote: > That smell must be something else ;) > Just have a look at the dependencies > > https://github.com/apache/commons-compress/blob/master/pom.xml#L69 Right, I see several dependencies marked "optional" which means as an end user, I still have to spe

Re: [compress] High Level API for Archives

> > > Just one question: Why? > > > > The implementation jars for compress would be tiny and would have close > to > > none dependencies. > > > > As an end user, I'd prefer to only have to manage a single maven coordinate > (e.g., commons-vfs-ssh) instead of multiple ones depending on my use case >

Re: [compress] High Level API for Archives

On 1 May 2018 at 05:12, Torsten Curdt wrote: > Just one question: Why? > > The implementation jars for compress would be tiny and would have close to > none dependencies. > As an end user, I'd prefer to only have to manage a single maven coordinate (e.g., commons-vfs-ssh) instead of multiple one

Re: [compress][io] Avoid InputStream#skip?

Speaking of rarely used APIs in java.io, would that also include mark/available/reset? Or are those all implemented in terms of skip()? On 1 May 2018 at 06:05, Torsten Curdt wrote: > +1 > > On Tue, May 1, 2018 at 12:59 PM, sebb wrote: > > > On 1 May 2018 at 11:24, Stefan Bodewig wrote: > > > H

ApacheCon North America 2018 schedule is now live.

Dear Apache Enthusiast, We are pleased to announce our schedule for ApacheCon North America 2018. ApacheCon will be held September 23-27 at the Montreal Marriott Chateau Champlain in Montreal, Canada. Registration is open! The early bird rate of $575 lasts until July 21, at which time it goe

Re: [compress][io] Avoid InputStream#skip?

+1 On Tue, May 1, 2018 at 12:59 PM, sebb wrote: > On 1 May 2018 at 11:24, Stefan Bodewig wrote: > > Hi all > > > > as skip throwing exception is uncommon enough that it hasn't been > > reported before in Compress and only seems to happen if you use streams > > like System.in maybe we can solve

Re: [compress][POLL] High Level API

https://github.com/apache/commons-compress/blob/master/ src/main/java/org/apache/commons/compress/archivers/Archiver.java Is tiny compared the whole lots of https://github.com/apache/commons-compress/tree/master/ src/main/java/org/apache/commons/compress/archivers/examples and while the later i

Re: [compress][io] Avoid InputStream#skip?

On 1 May 2018 at 11:24, Stefan Bodewig wrote: > Hi all > > as skip throwing exception is uncommon enough that it hasn't been > reported before in Compress and only seems to happen if you use streams > like System.in maybe we can solve the issue by providing a wrapper > stream that overrides skip s

Re: [compress][io] Avoid InputStream#skip?

Hi all as skip throwing exception is uncommon enough that it hasn't been reported before in Compress and only seems to happen if you use streams like System.in maybe we can solve the issue by providing a wrapper stream that overrides skip so that it uses read and advice people to use that if they

Re: [compress] High Level API for Archives

> > > As in one module/jar per implementation. One module for a zipfs, one for > an > > sshfs, etc., instead of just "commons-vfs" as a monolith with optional > > dependencies. > Just one question: Why? The implementation jars for compress would be tiny and would have close to none dependencies.

[compress][POLL] High Level API

Hi all right now the master branch contains two different ideas of hign level APIs: * https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/Archiver.java and Expander in the same package * https://github.com/apache/commons-compress/tree/ma

Re: [compress] High Level API for Archives

On 2018-04-30, Matt Sicker wrote: > Not sure if it helps much, but based on my experience in writing a totally > unrelated library from scratch in Java 8, I feel as though the use of > default interface methods would help tremendously in providing a nice API > while maintaining BC. I may have bee

Re: [compress] High Level API for Archives

On 2018-04-29, Matt Sicker wrote: > On 29 April 2018 at 06:24, Stefan Bodewig wrote: >> I'm not sure what you mean by modular in this context. > As in one module/jar per implementation. One module for a zipfs, one for an > sshfs, etc., instead of just "commons-vfs" as a monolith with optional >