On 2 May 2018 at 08:41, Stefan Bodewig wrote:
> It's a bit more complex than that. A hypothetical commons-sevenz would
> stil have an optional dependency on commons-lzma which then has a real
> depedendency on XZ for Java. The 7z code doesn't need XZ for Java if the
> archive you want to read onl
On 2018-05-01, Matt Sicker wrote:
> 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 m
>
> > 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
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
>
> > 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
>
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
>
> > 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.
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
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
>
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 had considered proposing an update to Java 8, but
that w
On 2018-04-29, Stefan Bodewig wrote:
> If this is something that looks acceptable I'll add expansion and remove
> the other two classes.
Just went ahead and added expansion as well, which doesn't mean it has
to stay.
Stefan
-
T
Hi Matt,
Am 29.04.2018 um 20:30 schrieb Matt Sicker:
> On 26 April 2018 at 14:38, Oliver Heger
> wrote:
>
>> Recently I had a closer look at streaming libraries like Akka Streams.
>> So I had the idea to model the problem in a similar way:
>>
>
> I've used Akka Streams a bit in the past, and wh
Am 29.04.2018 um 19:08 schrieb Stefan Bodewig:
> Hi all
>
> I've introduced a whole lot of infrastructure code with
>
> https://github.com/apache/commons-compress/commit/f62c523154dfedcf49a87a865db545bb8c55e795
>
> but the interface now looks nicer to me, in particual see
>
> try (Sin
On 26 April 2018 at 14:38, Oliver Heger
wrote:
> Recently I had a closer look at streaming libraries like Akka Streams.
> So I had the idea to model the problem in a similar way:
>
I've used Akka Streams a bit in the past, and while it's pretty awesome, I
feel as though taking this approach woul
On 29 April 2018 at 06:24, Stefan Bodewig wrote:
> The current compress-2.0 branch - which is something that I haven't fully
> given up on but is dormant right now - at least uses the file views for
> permissions and stuff.
>
Neat! I've experimented a bit locally in the past to see how big an ef
Hi all
I've introduced a whole lot of infrastructure code with
https://github.com/apache/commons-compress/commit/f62c523154dfedcf49a87a865db545bb8c55e795
but the interface now looks nicer to me, in particual see
try (Sink sink = FileToArchiveSink.forFile(args[1], new
File(args[2]))) {
On 2018-04-26, Oliver Heger wrote:
> Recently I had a closer look at streaming libraries like Akka Streams.
> So I had the idea to model the problem in a similar way:
> An archive or deflate operation could be modeled by a flow from a source
> via some filtering or modifying stages to a sink. The
On 2018-04-26, Matt Sicker wrote:
> If it helps in design, the most promising approach I found was to integrate
> with the java.nio.file API. However, that turns into a sort of hybrid
> library between VFS and Compress.
The current compress-2.0 branch - which is something that I haven't fully
giv
Am 26.04.2018 um 17:37 schrieb Matt Sicker:
> If it helps in design, the most promising approach I found was to integrate
> with the java.nio.file API. However, that turns into a sort of hybrid
> library between VFS and Compress. However, they are rather strongly related
> (if the two libraries w
If it helps in design, the most promising approach I found was to integrate
with the java.nio.file API. However, that turns into a sort of hybrid
library between VFS and Compress. However, they are rather strongly related
(if the two libraries were modular, then it wouldn't be such a problem to
com
On 2018-04-24, sebb wrote:
> On 23 April 2018 at 20:48, Torsten Curdt wrote:
>> TBH I am not such super big fan of adding and maintaining a high level
>> API at this stage.
>> You will never find the right abstraction that everyone is happy with.
>> If you would - well, then that should be the re
On 23 April 2018 at 20:48, Torsten Curdt wrote:
> TBH I am not such super big fan of adding and maintaining a high level
> API at this stage.
> You will never find the right abstraction that everyone is happy with.
> If you would - well, then that should be the real API afterall.
>
> Honestly - I
On 2018-04-23, Torsten Curdt wrote:
> TBH I am not such super big fan of adding and maintaining a high level
> API at this stage. You will never find the right abstraction that
> everyone is happy with.
TIt's not my intention to make everybody happy, there will still be use
cases that won't be c
I went through a few iterations of my own over the weekend and wasn't
satisfied with the direction in any of them. This approach looks
interesting, though I need to take a closer look.
On 23 April 2018 at 14:48, Torsten Curdt wrote:
> TBH I am not such super big fan of adding and maintaining a h
TBH I am not such super big fan of adding and maintaining a high level
API at this stage.
You will never find the right abstraction that everyone is happy with.
If you would - well, then that should be the real API afterall.
Honestly - I would just add example code for now. Maybe that can turn
int
Hi all
I've started to work on COMPRESS-118 and added Archiver and Expander
classes - without any tests for now. As I'm trying to cover a bunch of
possible use cases there are lots of inputs or outputs that can
represent archives. When expanding archives you may want to use
auto-detect the format
26 matches
Mail list logo
