If I understand the details correctly, Xtext still has a
dependency on Xpand. Perhaps if we disable the feature included
from the Xpand repo while leaving the repo itself available, only
the bundles actually needed (by Xtext) would be aggregated and the
old log4j would not be aggregated.
I really need to find time to continue the work on the analysis
tool, because it can produce the content metadata for an
aggregation without doing the actual artifact
aggregation/mirroring so that one can quickly (in a minute) try
out such things to see what will end up in the repo...
Regards,
Ed
On 23.02.2022 17:32, Jonah Graham
wrote:
Hi Planning Council folks,
There are two hard dependencies on the "bad" version of
log4j - one from ECF which I hope can easily be resolved, and
one from m2t.xpand, which cannot be resolved as m2t.xpand has
had no commits in 6 years and has no CI (see Bug 578941).
Well, from
my point of view the usage of
reload4j is the only backwards
compatible solution. Unfortunately
not for every case, e.g. too strict
version ranges. The solution forward
is of course the usage of a log
wrapper to decouple development from
deployment.
Anyhow I
don't know how to add a bundle jar
signed and unchanged to Orbit. I am
only aware of the re-bundling via
EBR. Doing that will cause a change
in the jar structure that causes for
example logpresso to identify a CVE,
although it is fixed. Which is
actually only an issue in the
detection. But that was one of the
reasons why I contacted the reload4j
project to change the base to avoid
the re-bundling.
Anyone who
knows how to only sign and publish
to Orbit without re-bundling?
Thanks. That's really great!
It would be great for this
release cycle if it were jar
signed and available from Orbit
so that we could ship it with
2022-03...
Though I'm not sure if they
would consider the problem being
fixed in 1.2.19 a fact and even
if its a fact if it would be a
fact that matters...
Regards,
Ed
On 08.02.2022 15:48, Dirk
Fauth via
cross-project-issues-dev wrote:
Hi,
I got in
contact with the reload4j
team. They changed the
Bundle-SymbolicName to
org.apache.log4j and fixed
several OSGi meta data
related issues in the
meanwhile. Today they
published 1.2.19 which
should work as a drop-in
replacement in Eclipse based
applications where
Require-Bundle was used. My
local tests worked so far.
That said,
re-bundling for Orbit should
not be necessary as reload4j
could directly be consumed
via Maven Central.
On 26/01/2022 07:48,
Christoph Läubrich wrote:
> Why not using SLF4J in
all places and let the user
choose the
> implementation with
their favorite CVEs?
Use of SLF4J has been
suggested before and so I
tried to be a good
Eclipse citizen. My failed
attempts are described in:
If SLF4J is to be used, can
someone please ensure that
the platform is
fit for purpose and that
there is a good tutorial on
how to do really
boring logging.