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...
On 23.02.2022 17:32, Jonah Graham
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).
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
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
knows how to only sign and publish
to Orbit without re-bundling?
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...
On 08.02.2022 15:48, Dirk
I got in
contact with the reload4j
team. They changed the
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
Require-Bundle was used. My
local tests worked so far.
re-bundling for Orbit should
not be necessary as reload4j
could directly be consumed
via Maven Central.