Hi Gilles,
On 16.11.2024 16:11, Gilles Sadowski wrote:
Both sides have something in their favour; you are right in
the short term, Gary is right in the longer term. [IMO]
Wouldn't the project benefit from a common policy on how
to deal with such issues (rather than be divisive, once more)?
[I'd go even further that, by not delving into the crux (no policy)
of this kind of issues, we create "opportunities" for infighting,
based on who is more legitimate (so-called "meritocratic") to
make changes or revert them. In that respect, both sides
have again something in their favour.]
I've proposed (and have done so more than twice in the past)
to examine a way out (i.e. define an official hierarchy among
the "Commons" components), but you both have ignored it.
I have also proposed a compromise in PR #607[1]. A simple shading
operation does not seem to be viable, because classes such as
`SystemProperties` are not self-contained and depend on dozens of other
Commons Lang classes, so I introduced a new `o.a.c.c.internal.lang3`
package that:
* Clearly states that those functions are available in Commons Lang and
proposes a limit on the amount of code we can copy (1%). Currently we
need about 4 kB of uncompressed bytecode from Commons Lang out of 1.2 MB
of bytecode available.
* Proposes some workaround if the amount of copied code becomes higher
than 1%. I think that shading is a viable option up to 10% of the size
of Commons Lang: up to 10 dependencies can shade up to 10% and we still
save up some space on disk. Of course shading is terrible from a
security perspective (at least until
CycloneDX/cyclonedx-maven-plugin#472 is solved), but it is still better
than copying a large number of lines of code.
Piotr
[1] https://github.com/apache/commons-compress/pull/607
[2] https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/472
