elharo commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1976603939
Yes, a good BOM is a workaround; but it's still only a workaround. and one
that operates post facto. That is, first the developer sees their project
break. Then they spend an hour
ppkarwasz commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1976543279
> The problem of deep dependencies can be solved if Compress provides a BOM
POM and my app depends on this BOM POM (commons-compress-bom).
I think the point that @elharo
garydgregory commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1976481820
The problem of deep dependencies can be solved if Compress provides a BOM
POM and my app depends on this BOM POM (commons-compress-bom). The refactored
Compress can contain
ppkarwasz commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1976210334
> The basic problem is that a project can have the old commons-compress deep
in the transitive dependency tree.
>
> One then updates some other library to a new version
vy commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1975996682
> The basic problem is that a project can have the old commons-compress deep
in the transitive dependency tree.
>
> One then updates some other library to a new version that now
elharo commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1973447694
I believe @ppkarwasz is simply wrong. This change is not backwards
compatible, and will break existing projects. It works in the very simple case
where a project only has a direct
vy commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1973262056
@elharo, I am confused with your remarks given @ppkarwasz stated that it
works and it is backward compatible.
I see [your objections in the mailing list due to JPMS
garydgregory commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1973251143
From my POV, if we do anything, and as a first cut, I would follow the route
we are taking in Commons VFS: Move to new modules, format-specific code that is
already in their
ppkarwasz commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1972698986
[To give some context to this PR, it was motivated by [this
discussion](https://lists.apache.org/thread/p26gslhdm6mztx2vxt5zqw4zotov4fg6)
on `dev@commons`.]
@ebourg,
vy commented on code in PR #490:
URL: https://github.com/apache/commons-compress/pull/490#discussion_r1508612754
##
pom.xml:
##
@@ -41,499 +45,115 @@ Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z,
arj.
1.8
compress
-org.apache.commons.compress
ppkarwasz commented on code in PR #490:
URL: https://github.com/apache/commons-compress/pull/490#discussion_r1508601256
##
pom.xml:
##
@@ -41,499 +45,115 @@ Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z,
arj.
1.8
compress
-org.apache.commons.compress
olamy commented on code in PR #490:
URL: https://github.com/apache/commons-compress/pull/490#discussion_r1508535646
##
pom.xml:
##
@@ -41,499 +45,115 @@ Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z,
arj.
1.8
compress
-org.apache.commons.compress
ebourg commented on PR #490:
URL: https://github.com/apache/commons-compress/pull/490#issuecomment-1970172265
I like this idea. If we follow this path I'd push further and fully
modularize commons-compress, with a separate module for each compression and
archive format. That may be easier
13 matches
Mail list logo
