I’m blocked because I don’t have a JDK 1.8 option on the PTP HIPP
instance (https://bugs.eclipse.org/bugs/show_bug.cgi?id=478669).
If anyone knows how to add this, please let me know.
Greg
OK,
I give up.
It appears some
projects are not going
to be able to react to the removal of
runtime.compatibility bundle, for
M2, so I have re-enabled the LDT contribution. (Bug
478009 and Bug 478330).
This will allow
the aggregation build,
at least, to complete, so that others can make progress.
This won't help
projects who have a
direct dependancy on, say, DTP (which in turn as a
dependency on runtime
compatibility bundle) since they depend on it, but do
not provide it.
For those
people, the only work around
I know of is to "include" only that bundle from our M1
repository,
or something similar.
Less that ideal,
but I'd like to push
forward and see if we can get out some form of M2 that
can be used to create
a cleaner M3!
Let me know if
suggestions or alternative
approaches. (And, FYI, it does not appear that extending
the deadline a
few days will help with the runtime compatibility issue,
but, if anyone
has been blocked due to this issue, and needs a few days
to work around
the problem, I think it reasonable to consider an
extension of a few days
... if you make such a request, please be specific ...
I'd hate to extend
it to Monday instead of Friday (let's say) and then that
still not be enough
time.)
Thanks,
From:
David
M Williams/Raleigh/IBM@IBMUS
To:
Cross
project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
09/28/2015
08:47 PM
Subject:
Re:
[cross-project-issues-dev]
DTP for Neon stream ... runtime.compatibility ... and
LDT? ... and Neon
M2
Sent
by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
I hope everyone
remembers that Neon
M2 is this Friday ... and that means your Neon M2
contributions must be
done by Wednesday.
AND .. it seems, some have not yet reacted to the
platform removing org.eclipse.
runtime.compatibility bundle (Bug
394739).
AND .. some have been "getting it automatically" from
the current
Sim. Release contributions, because Lua Development
Tools (LDT) duplicates
it (and many others) in their repository (Bug
478009).
Since LDT has not updated their repo yet for Neon, I
fear some may have
of a false sense that "everything is ok".
Put more bluntly, we all know, some projects do not
build against the latest
version of their pre-reqs! And, we all know that some
projects won't react
until "the build fails".
Therefore ... I am about to make the build fail for
others, by removing
LDT's massive contribution.
If someone has a better suggestion, that would be good
to hear, but I hope
I am doing everyone a favor, by making the problem more
apparent in the
aggregation build.
(And, greatest thanks to those of you who HAVE reacted
to this change already
... thanks to all your release engineers!)
Thank to you all,
From: David
M Williams/Raleigh/IBM@IBMUS
To: Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 09/21/2015
08:09 PM
Subject: Re:
[cross-project-issues-dev] DTP for Neon stream ... and
LDT?
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
> A question regarding the aggregation build. I
thought it was
> designed to catch issues like this, but I don’t
see any failures
on Hudson.
I was wondering that too. :) So ...
I looked in the log, at
https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/111/consoleFull
and could see
- mirroring artifact
osgi.bundle,org.eclipse.core.runtime.compatibility,3.2.300.v20150423-0821
and then searching backwards in log, for "Mirroring
artifacts from",
could see that the LDT project is (also) contributing
that bundle, via
their repository at
.../download.eclipse.org/ldt/releases/stable/1.3
I hope that is a temporary condition, since (in this
case) do not think
the Platform would like others
"extending the life" of something they are trying to
end. But
... I am not sure. I think the next step
is to hear from the LDT project. I have opened bug
478009 for this issue.
I did also use b3 aggregator editor to search for others
who might be contributing
that bundle, and it appears there are no others.
(And, appears that LDT contributes much more potentially
problematic bundles,
than just that one, since they duplicate a great deal
of other's projects, for their "Eclipse product").
|