User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Good to know that SimRel has chances to survive. Personally I can
hardly imagine the future of Eclipse "classic" ecosystem without
common baseline like we have now with SimRel - things could degrade
really quickly.
What I want to understand is the status of recommendation from
Jonah: "passage's p2 repo should be publishing its third party deps
and it should be possible for consumers to install passage from
passage's p2 repo without requiring an orbit repo be added too".
* Is it the best practice to follow for every SimRel project?
* If so, could it be a part of Project Handbook?
I was preferring to use Orbit version of bundles (from the
corresponding Orbit contribution) since otherwise we will have a lot
of duplicated 3rd party bundles with different versions in one
Eclipse Package.
Perhaps this is not a value anymore.
It's not entirely clear that a generous layer of
critique and pessimism as icing on the
neglect-and-apathy cake will help the broader team be
more motivated to work toward a more viable solution.
Certainly I personally find it hugely challenging to
deal with what feels like an endless stream of
disruptive changes that percolate their way through my
software stack. My projects are like book ends on this
train. Add to that playing police and being the
emergency response team, complemented by disruptive
infrastructure changes to add to the confusion, and it
feels like the goodness just never ends. I could spend
some time pointlessly pointing fingers at whom to blame
for all these messy things. But I always remind myself
that when I point fingers at others, several of my own
fingers are always pointing back at me. So I try to
focus on what can be done to make things better and what
I can do to enable those.
I couldn't agree more. I started to blame myself for many
failures and they start to happen faster and faster as I
clearly fail to keep the pace and the only solution I've
found is to just drop things that are non-essential to me/my
usecases/. Best way to do things better is to just let
non-viable things fall off. My experience (unfortunately!)
is that it almost never happens to get help on things until
someone getting it for free for now gets the breakage due to
no longer being kept up and warning messages seem to be just
ignored.
Let's also look at some of the positives. We are
building a highly complex system, comprising a great
many moving parts, with a lot of very busy people
involved, to deliver some really amazing results, on
time, four times a year. Surely we're doing a few
things right...
And we should strive for even better results. Quite often
"less is more" .
In that case I don't
understand why do we need
Orbit at all. With the
latest announcements
regarding tycho
capabilities from
Christoph + lack of
resources to support Orbit
in safe form it seems to
be useless.
You have hit the
nail on the head! Although
useless is going a little far.
Orbit does not likely have a
long term future. However as
there are many projects that
build from it still we need it.
Also there is a problem if
multiple projects start
contributing the same version of
third party lib that will
hopefully be solved in the
future with PGP signing.
Orbit should not
be directly contributing to
simrel, but for a variety of
reasons it does (see comments in
the file)
As mentioned in
the Gerrit, passage's p2 repo
should be publishing its third
party deps and it should be
possible for consumers to
install passage from passage's
p2 repo without requiring an
orbit repo be added too.
I know for sure
that numerous projects are not
quite doing that (again see
comments in orbit.aggrcon) but
hopefully at some point the
temporary contribution of orbit
to simrel directly can be
removed.
I would dare to say that as long
as the workarounds are in simrel
nothing will get fixed - it's time
to face reality.
Probably correct, but I don't
have the nerve to disable (or knowledge/time
to fix) Mylyn.
^^ Exactly - the amount of complains from
people not paying attention and putting burden on
others to workaround for them is what made me lost
trust that simrel is viable approach.
IMHO,
people should
actively
remove content
from Orbit
that has CVEs.
Much like with
any other
project. Even
without
replacing it
with a fixed
version. We
will be better
with less but
trusted
content than
questioning
ourselves for
each artifact.
Agreed. There is
usually a
clean-up/removal of
unneeded stuff. But
the downloads are
still available for
projects consuming the
repositories.
>[...]
That is
definitely
something
> new,
since Orbit
was a trusted
source of 3rd
party
libraries for
many
> years.
That's a
misconception. Orbit
essentially is like
Maven Central. Instead
of Maven Artifacts it
distributes Eclipse
plug-in artifacts.
Maven Central still
distributes the
vulnerable Log4j
version and ton of
other libraries with
CVEs. Does that make
it a less trustworthy
source now? I don't
think so. Consumers
still need to stay on
top of those.