If you have admin access to your HIPP, you can add a JDK in the Manage
Hudson section.
Have it point to /shared/common/jdk1.8.0-latest
Denis
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit_
__https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
On 30/09/15 01:32 PM, Greg Watson wrote:
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
On Sep 30, 2015, at 11:02 AM, David M Williams
<[email protected] <mailto:[email protected]>> wrote:
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_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=478009>and
*_Bug 478330_* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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 <[email protected]
<mailto:[email protected]>>,
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: [email protected]
<mailto:[email protected]>
------------------------------------------------------------------------
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_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=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_*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=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 <[email protected]
<mailto:[email protected]>>,
Date: 09/21/2015 08:09 PM
Subject: Re: [cross-project-issues-dev] DTP for Neon stream ... and LDT?
Sent by: [email protected]
<mailto:[email protected]>
------------------------------------------------------------------------
> 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
<http://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_
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=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").
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
