[Statistics][All] Web site partly broken

[Gilles Sadowski]

Hi.

>From the "home" page:
  https://commons.apache.org/proper/commons-statistics/
clicking on the "latest release" link:
  https://commons.apache.org/statistics/download_statistics.cgi
leads to a page where the layout has not been applied.

Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Romain Manni-Bucau]

Before splitting maybe review why there are deps, don't think any is really
needed and it was mainly pre java 8 time.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 22 févr. 2024 à 17:29, Xeno Amess  a écrit :

> Another reason for suggesting common-compress split to several sub-modules:
> I see no application, nor lib, nor software that use common-compress and
> use all of the algorithms supported by common-compress...
> Usually we just use one or two algorithms we actually need...
> so splitting into several submodules (and letting users pick what they
> need) seems reasonable...
> If an all-in-one entry is really needed, we still have the SPI solution.
>
> Xeno Amess  于2024年2月23日周五 00:23写道：
>
> > > What I've been going in some projects is to never use Maven optional
> > dependencies and split Maven projects into multi-module ones and never
> use
> > optional dependencies when I care about what depends on what.
> >
> > I love this... just like what done in vfs right?.
> >
> > Gary Gregory  于2024年2月23日周五 00:14写道：
> >
> >> A basic issue is that there is a disconnect between Maven dependency
> >> declarations in a POM and running applications outside of Maven aware
> >> environment ('mvn' and IDEs). When you write your app, you deliver jars,
> >> you start the JVM, and so on, and if you don't follow Maven dependencies
> >> you can run into issues like missing classes. Maven, within a module,
> has
> >> no way to say "if you use this feature, then you need that jar".
> >>
> >> What I've been going in some projects is to never use Maven optional
> >> dependencies and split Maven projects into multi-module ones and never
> use
> >> optional dependencies when I care about what depends on what.
> >>
> >> The KISS solution here IMO is to remove the POM optional attribute from
> >> these dependencies. Apps can always prune dependency if they wish to do
> >> so.
> >>
> >> Gary
> >>
> >> On Thu, Feb 22, 2024, 4:08 AM Andrew Coates 
> >> wrote:
> >>
> >> > Hi all,
> >> >
> >> > I'm seeing a runtime failure using TarArchiveOutputStream when
> updating
> >> to
> >> > commons-compress 1.26.0.
> >> >
> >> > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> >> > at org.apache.commons.compress@1.26.0
> >> >
> >> >
> >>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> >> > at org.apache.commons.compress@1.26.0
> >> >
> >> >
> >>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> >> > at org.apache.commons.compress@1.26.0
> >> >
> >> >
> >>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> >> > at testcontainers@1.19.5
> >> >
> >> >
> >>
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> >> > ...
> >> >
> >> > Commons-compress 1.26.0 contains changes to make use of commons-codec,
> >> > rather than its own copy of files, but I see that the POM marks
> >> > commons-codec as *optional*. Excuse my potential ignorance, but I
> >> thought
> >> > optional dependencies shouldn't cause runtime failures if not present.
> >> Is
> >> > this not the case?
> >> >
> >> > Obviously, I can just add commons-codec as an explicit dependency. But
> >> this
> >> > seems wrong IMHO.
> >> >
> >> > Should I sign up for an account and raise this as a bug in Jira?
> >> >
> >> > Thanks,
> >> >
> >> > Andy
> >> >
> >>
> >
>

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Xeno Amess]

Another reason for suggesting common-compress split to several sub-modules:
I see no application, nor lib, nor software that use common-compress and
use all of the algorithms supported by common-compress...
Usually we just use one or two algorithms we actually need...
so splitting into several submodules (and letting users pick what they
need) seems reasonable...
If an all-in-one entry is really needed, we still have the SPI solution.

Xeno Amess  于2024年2月23日周五 00:23写道：

> > What I've been going in some projects is to never use Maven optional
> dependencies and split Maven projects into multi-module ones and never use
> optional dependencies when I care about what depends on what.
>
> I love this... just like what done in vfs right?.
>
> Gary Gregory  于2024年2月23日周五 00:14写道：
>
>> A basic issue is that there is a disconnect between Maven dependency
>> declarations in a POM and running applications outside of Maven aware
>> environment ('mvn' and IDEs). When you write your app, you deliver jars,
>> you start the JVM, and so on, and if you don't follow Maven dependencies
>> you can run into issues like missing classes. Maven, within a module, has
>> no way to say "if you use this feature, then you need that jar".
>>
>> What I've been going in some projects is to never use Maven optional
>> dependencies and split Maven projects into multi-module ones and never use
>> optional dependencies when I care about what depends on what.
>>
>> The KISS solution here IMO is to remove the POM optional attribute from
>> these dependencies. Apps can always prune dependency if they wish to do
>> so.
>>
>> Gary
>>
>> On Thu, Feb 22, 2024, 4:08 AM Andrew Coates 
>> wrote:
>>
>> > Hi all,
>> >
>> > I'm seeing a runtime failure using TarArchiveOutputStream when updating
>> to
>> > commons-compress 1.26.0.
>> >
>> > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
>> > at org.apache.commons.compress@1.26.0
>> >
>> >
>> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
>> > at org.apache.commons.compress@1.26.0
>> >
>> >
>> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
>> > at org.apache.commons.compress@1.26.0
>> >
>> >
>> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
>> > at testcontainers@1.19.5
>> >
>> >
>> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
>> > ...
>> >
>> > Commons-compress 1.26.0 contains changes to make use of commons-codec,
>> > rather than its own copy of files, but I see that the POM marks
>> > commons-codec as *optional*. Excuse my potential ignorance, but I
>> thought
>> > optional dependencies shouldn't cause runtime failures if not present.
>> Is
>> > this not the case?
>> >
>> > Obviously, I can just add commons-codec as an explicit dependency. But
>> this
>> > seems wrong IMHO.
>> >
>> > Should I sign up for an account and raise this as a bug in Jira?
>> >
>> > Thanks,
>> >
>> > Andy
>> >
>>
>

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Xeno Amess]

> What I've been going in some projects is to never use Maven optional
dependencies and split Maven projects into multi-module ones and never use
optional dependencies when I care about what depends on what.

I love this... just like what done in vfs right?.

Gary Gregory  于2024年2月23日周五 00:14写道：

> A basic issue is that there is a disconnect between Maven dependency
> declarations in a POM and running applications outside of Maven aware
> environment ('mvn' and IDEs). When you write your app, you deliver jars,
> you start the JVM, and so on, and if you don't follow Maven dependencies
> you can run into issues like missing classes. Maven, within a module, has
> no way to say "if you use this feature, then you need that jar".
>
> What I've been going in some projects is to never use Maven optional
> dependencies and split Maven projects into multi-module ones and never use
> optional dependencies when I care about what depends on what.
>
> The KISS solution here IMO is to remove the POM optional attribute from
> these dependencies. Apps can always prune dependency if they wish to do so.
>
> Gary
>
> On Thu, Feb 22, 2024, 4:08 AM Andrew Coates 
> wrote:
>
> > Hi all,
> >
> > I'm seeing a runtime failure using TarArchiveOutputStream when updating
> to
> > commons-compress 1.26.0.
> >
> > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> > at org.apache.commons.compress@1.26.0
> >
> >
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> > at org.apache.commons.compress@1.26.0
> >
> >
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> > at org.apache.commons.compress@1.26.0
> >
> >
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> > at testcontainers@1.19.5
> >
> >
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> > ...
> >
> > Commons-compress 1.26.0 contains changes to make use of commons-codec,
> > rather than its own copy of files, but I see that the POM marks
> > commons-codec as *optional*. Excuse my potential ignorance, but I thought
> > optional dependencies shouldn't cause runtime failures if not present.
> Is
> > this not the case?
> >
> > Obviously, I can just add commons-codec as an explicit dependency. But
> this
> > seems wrong IMHO.
> >
> > Should I sign up for an account and raise this as a bug in Jira?
> >
> > Thanks,
> >
> > Andy
> >
>

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Gary Gregory]

A basic issue is that there is a disconnect between Maven dependency
declarations in a POM and running applications outside of Maven aware
environment ('mvn' and IDEs). When you write your app, you deliver jars,
you start the JVM, and so on, and if you don't follow Maven dependencies
you can run into issues like missing classes. Maven, within a module, has
no way to say "if you use this feature, then you need that jar".

What I've been going in some projects is to never use Maven optional
dependencies and split Maven projects into multi-module ones and never use
optional dependencies when I care about what depends on what.

The KISS solution here IMO is to remove the POM optional attribute from
these dependencies. Apps can always prune dependency if they wish to do so.

Gary

On Thu, Feb 22, 2024, 4:08 AM Andrew Coates 
wrote:

> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> at testcontainers@1.19.5
>
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> ...
>
> Commons-compress 1.26.0 contains changes to make use of commons-codec,
> rather than its own copy of files, but I see that the POM marks
> commons-codec as *optional*. Excuse my potential ignorance, but I thought
> optional dependencies shouldn't cause runtime failures if not present.  Is
> this not the case?
>
> Obviously, I can just add commons-codec as an explicit dependency. But this
> seems wrong IMHO.
>
> Should I sign up for an account and raise this as a bug in Jira?
>
> Thanks,
>
> Andy
>

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Romain Manni-Bucau]

+1 Elliotte
...plus the fact [io] is optional in the pom too which is not correct.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 22 févr. 2024 à 14:44, Elliotte Rusty Harold  a
écrit :

> Looks like this was fixed at head a few days ago by using Charsets
> from commons-io instead of commons-codec, and will be in 1.26.1. That
> said, I don't really like the fix that was committed. The use of the
> Charsets class here is trivial and should simply be inlined. It's not
> sufficient reason to pull in an external Charsets class from either
> commons-codec or commons-io.
>
> On Thu, Feb 22, 2024 at 7:08 AM Andrew Coates 
> wrote:
> >
> > Hi all,
> >
> > I'm seeing a runtime failure using TarArchiveOutputStream when updating
> to
> > commons-compress 1.26.0.
> >
> > java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> > at org.apache.commons.compress@1.26.0
> >
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> > at org.apache.commons.compress@1.26.0
> >
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> > at org.apache.commons.compress@1.26.0
> >
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> > at testcontainers@1.19.5
> >
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> > ...
> >
> > Commons-compress 1.26.0 contains changes to make use of commons-codec,
> > rather than its own copy of files, but I see that the POM marks
> > commons-codec as *optional*. Excuse my potential ignorance, but I thought
> > optional dependencies shouldn't cause runtime failures if not present.
> Is
> > this not the case?
> >
> > Obviously, I can just add commons-codec as an explicit dependency. But
> this
> > seems wrong IMHO.
> >
> > Should I sign up for an account and raise this as a bug in Jira?
> >
> > Thanks,
> >
> > Andy
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Elliotte Rusty Harold]

Looks like this was fixed at head a few days ago by using Charsets
from commons-io instead of commons-codec, and will be in 1.26.1. That
said, I don't really like the fix that was committed. The use of the
Charsets class here is trivial and should simply be inlined. It's not
sufficient reason to pull in an external Charsets class from either
commons-codec or commons-io.

On Thu, Feb 22, 2024 at 7:08 AM Andrew Coates  wrote:
>
> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> at org.apache.commons.compress@1.26.0
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> at org.apache.commons.compress@1.26.0
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> at testcontainers@1.19.5
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> ...
>
> Commons-compress 1.26.0 contains changes to make use of commons-codec,
> rather than its own copy of files, but I see that the POM marks
> commons-codec as *optional*. Excuse my potential ignorance, but I thought
> optional dependencies shouldn't cause runtime failures if not present.  Is
> this not the case?
>
> Obviously, I can just add commons-codec as an explicit dependency. But this
> seems wrong IMHO.
>
> Should I sign up for an account and raise this as a bug in Jira?
>
> Thanks,
>
> Andy



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Niall Pemberton]

On Thu, 22 Feb 2024 at 12:08, Andrew Coates 
wrote:

> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> at testcontainers@1.19.5
>
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> ...
>
> Commons-compress 1.26.0 contains changes to make use of commons-codec,
> rather than its own copy of files, but I see that the POM marks
> commons-codec as *optional*. Excuse my potential ignorance, but I thought
> optional dependencies shouldn't cause runtime failures if not present.  Is
> this not the case?


No that’s not the case here or in the maven/java eco system in general.

It is possible to have that behaviour within a Java app/lib but the app/lib
would have to explicitly have code which detected the presence/absence of a
dependency to not fail and have an alternative mechanism for the
functionality.

For the vast majority of Java apps/libs that have an optional dependency it
means that the dependency is only required for a subset of the
functionality and if you don’t use that subset then it’s not required, but
if you do use that subset then you have to explicitly add that dependency.

Obviously, I can just add commons-codec as an explicit dependency. But this
> seems wrong IMHO.


That is the correct thing to do.

Should I sign up for an account and raise this as a bug in Jira?
>

It would be good to have documented which features require commons codec
and I don't see anything on the Compress site/user guide which indicates
this, so I think it would be worth raising a ticket to improve the docs for
this.

I'm not that familiar with compress, but it looks like LZ4
(FramedLZ4CompressorInputStream & FramedLZ4CompressorOutputStream),
snappy-framed (FramedSnappyCompressorInputStream &
FramedSnappyCompressorOutputStream) and the CompressorStreamFactory require
the Codec dependency

Niall

Thanks,
>
> Andy
>

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Romain Manni-Bucau]

Hi Andy,

I have the exact same feeling and commons-io is yet another one.
I understand the intent to not bring a not used dep when you use only a
subset of archives but default experience is not nice.
Maybe all these transitive commons deps should be dropped, they dont make
much sense anymore IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 22 févr. 2024 à 13:08, Andrew Coates  a
écrit :

> Hi all,
>
> I'm seeing a runtime failure using TarArchiveOutputStream when updating to
> commons-compress 1.26.0.
>
> java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
> at org.apache.commons.compress@1.26.0
>
> /org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
> at testcontainers@1.19.5
>
> /org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
> ...
>
> Commons-compress 1.26.0 contains changes to make use of commons-codec,
> rather than its own copy of files, but I see that the POM marks
> commons-codec as *optional*. Excuse my potential ignorance, but I thought
> optional dependencies shouldn't cause runtime failures if not present.  Is
> this not the case?
>
> Obviously, I can just add commons-codec as an explicit dependency. But this
> seems wrong IMHO.
>
> Should I sign up for an account and raise this as a bug in Jira?
>
> Thanks,
>
> Andy
>

commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Andrew Coates]

Hi all,

I'm seeing a runtime failure using TarArchiveOutputStream when updating to
commons-compress 1.26.0.

java.lang.NoClassDefFoundError: org/apache/commons/codec/Charsets
at org.apache.commons.compress@1.26.0
/org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:212)
at org.apache.commons.compress@1.26.0
/org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:157)
at org.apache.commons.compress@1.26.0
/org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.(TarArchiveOutputStream.java:147)
at testcontainers@1.19.5
/org.testcontainers.containers.ContainerState.copyFileToContainer(ContainerState.java:350)
...

Commons-compress 1.26.0 contains changes to make use of commons-codec,
rather than its own copy of files, but I see that the POM marks
commons-codec as *optional*. Excuse my potential ignorance, but I thought
optional dependencies shouldn't cause runtime failures if not present.  Is
this not the case?

Obviously, I can just add commons-codec as an explicit dependency. But this
seems wrong IMHO.

Should I sign up for an account and raise this as a bug in Jira?

Thanks,

Andy