It makes sense to reference multiple repos, as in my cut and
paste from my S-build that referenced both latest-S and latest-R
Orbit, since latest-S is usually the most recent except just after
a release when latest-R may be later (unless a gratuitous S-build
immediately followed the R-build).
However multiple explicit references seems crazy especially when
they are so stale.
Please see my email about removal of CVS built bundles from the p2. If you still refer to these old Orbit bundles you will need to keep a reference to an older Orbit repo in your target platform, or update your dependencies.
HTH,
Jonah
Regards
Ed Willink
On 24/02/2022 08:27, Martin Lippert
wrote:
Hey!
Quick question:
why do those update sites refer to the latest S or R
builds AS WELL AS a specific release repo from 2020 ?
so there is no need to update ever again.
Just rebuild.
Regards
Ed Willink
On 24/02/2022 02:13, Jonah
Graham wrote:
Hi folks,
I have now checked and the EPP
packages that have org.apache.log4j now have the
1.2.19 reload4j version.
Some progress has already been made on
the bugs, so with a bit more work we can have the
whole simrel free of the 1.2.15 version of log4j.
However, individual projects need to
update to the newest Orbit version and rebuild.
Numerous projects still have the 1.2.15 version in
their p2 repos.
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.