from:"Thomas Watson"

Re: [cross-project-issues-dev] JustJ 21 Available

2023-10-13 Thread Thomas Watson via cross-project-issues-dev

It is unfortunate that we are forbidden from using the Eclipse OpenJ9 project 
Java releases.  I am sure they will have a ppc64le variant when they release 
Java 21.

Tom

From: cross-project-issues-dev  
on behalf of Ed Merks via cross-project-issues-dev 

Sent: Friday, October 13, 2023 8:20 AM
To: Cross project issues 
Cc: Ed Merks 
Subject: [EXTERNAL] [cross-project-issues-dev] JustJ 21 Available

JustJ 21 is available here:

https://download.eclipse.org/justj/jres/21/updates/release/21.0.0

Unfortunately there is no ppc64le version; I'm not sure if Adoptium will
eventually provide those.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Sorry, entering a bug into the product JDT has been disabled.,

2022-04-18 Thread Thomas Watson

I'm sure Ed is just being cute with the remark about JDT being perfect.  But in 
case anyone missed it: the Eclipse project moved to Github.  JDT issues should 
be opened there against the proper repository: https://github.com/eclipse-jdt

We still have much to work out to get our issue reporting process to be better 
at github.  I think at minimum we need the foundation to improve this message 
from bugzilla to at least point to the organization in github where to report 
issues now.

Tom
[https://avatars.githubusercontent.com/u/102054714?s=280=4]
Eclipse JDT · GitHub
Eclipse JDT™ The Eclipse JDT™ project provides the tool plug-ins that implement 
a Java IDE supporting the development of any Java application, including 
Eclipse plug-ins.
github.com


From: cross-project-issues-dev  
on behalf of Ed Willink 
Sent: Sunday, April 17, 2022 5:43 AM
To: Cross project issues 
Subject: [EXTERNAL] [cross-project-issues-dev] Sorry, entering a bug into the 
product JDT has been disabled.,

Hi

The PMI form for JDT at

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT

is no longer able to report a bug. It reports "Sorry, entering a bug
into the product JDT has been disabled.,,Please press Back and try again."

Does this mean that JDT is now perfect and will never have any bugs ever
again?

 Regards

 Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Move JDT to Java 11

2021-06-16 Thread Thomas Watson

I don't think ecj itself requires equinox.common.
Tom 
 
 
- Original message -From: Christian Dietrich Sent by: "cross-project-issues-dev" To: cross-project-issues-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [cross-project-issues-dev] Move JDT to Java 11Date: Wed, Jun 16, 2021 8:35 AM 
as org.eclipse.equinox.common already requires java 11 and this is a(transitive) dependency of jdt,i assume jdt already effectively needs java 11 with the current releaseAm 16.06.21 um 15:31 schrieb Andrey Loskutov:> Hi all,>> sorry for cross-posting, but I would like to take your attention to JDT specific topic that may affect some downstream JDT consumers.>> *** Request to move JDT to Java 11 ***>> 1) I request that JDT stops supporting compilation of JDT code on Java 8 and execution of JDT code on Java 8, for the 4.21 release, and switches to compile JDT project code against Java 11 libraries.> 2) If this request would be agreed / approved, I would like to add an item to the 4.21 release plan [1] that Eclipse Compiler for Java (ecj) can only be used on Java 11+ runtime environment.>> *** Reason for this request ***>> JDT team is a very small team, overloaded since a very long time with support of various Java releases in compiler.> This team can't afford to support running ecj on Java 8 AND on Java 11 AND on Java 16 AND on Java 17+ etc.> The code complexity and the issues we see in JDT are overwhelming and constantly growing.> With every Java release more and more features need to be added to the code base, and the maintenance burden is becoming bigger, not smaller!>> To simplify maintainers life and save time for proper Eclipse Java compiler support we should declare end of "run on Java 8" support in JDT code.> To be honest: since we are not testing ecj on Java 8 since long time, no one can guarantee that any recent ecj version can run on Java 8 anyway.>> *** Important note ***>> This request doesn't mean JDT would not support compilation of programs with Java 8 target!  > We still support compilation targets from Java 1.3 to the latest Java release.>> This request is only about JDT own project code that will be compiled with Java 11 target. Moving JDT to Java 11 would also open a door for possible contributions that could use API's only available since Java 9+, but that's not the main driver here.>> Please note, that Eclipse platform (IDE/RCP) as a whole does not support compilation/execution on Java 8 since 4.17 release (2020-09) and we do not run any tests on Java 8 that would guarantee Java 8 compliance.>> There is a discussion on bug 572389 [2], which is not a new one. Most of the Platform projects are already moved to compile against Java 11, only some parts of JDT related to the standalone compiler are still (theoretically) compatible to Java 8, the IDE part of JDT has dependencies to libraries / bundles that only support Java 11+.>> *** What downstream consumers could do after move ***>> If JDT code base is moved to Java 11, downstream consumers can do following:>> 1) Use previously released JDT / ecj versions.> 2) Run the build/application using JDT on Java 11+.> 3) Clone JDT code and build / maintain own fork, compatible to Java 8.> 4) Contribute to JDT.>> *** Action item for PMC / JDT team ***>> Please, can we make a decision & have an agreement to drop "run on Java 8" support for 4.21, and move JDT code to Java 11?> *If* not 4.21, can we please make a decision & have an agreement to drop "run on Java 8" support in JDT for some *concrete* platform version?>> PS>> Before someone would write an answer asking JDT project to continue "run on Java 8" support - please provide a *concrete* proposal, how *you* or your organisation could contribute to JDT, because nobody else is there that would have time to do that.>> [1] https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_21.xml> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389>> Kind regards,> Andrey Loskutov>> Спасение утопающих - дело рук самих утопающих>> https://www.eclipse.org/user/aloskutov>> ___> cross-project-issues-dev mailing list> cross-project-issues-dev@eclipse.org> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev--Christian Dietrich (Diplom-Informatiker (BA))Softwareentwickler / -ArchitektCommitter and Co-Lead for Eclipse XtextTel.: +49 (0) 711 / 34 21 91-0Fax.: +49 (0) 711 / 34 21 91-29Mobil: +49 (0) 151 / 173969 17Mail: christian.dietr...@itemis.deXING: https://www.xing.com/profile/Christian_Dietrich8 Web: http://www.itemis.de Skype: christiandietrich1982itemis AGNiederlassung SüdIndustriestraße 670565 Stuttgart--Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle,Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef SchuermannAufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), HaraldGoertz, Stephan GrollmannSitz der

Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3

2021-06-03 Thread Thomas Watson

I opened https://github.com/eclipse/jetty.project/issues/6354
Tom 
 
 
- Original message -From: Jesse McConnell Sent by: "cross-project-issues-dev" To: Cross project issues Cc:Subject: [EXTERNAL] Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3Date: Thu, Jun 3, 2021 7:53 AM 
Open an issue with the project and we can discuss there, not sure the right balance to strike for that value, thus far we have just told concerned parties to simply use the previous slf4j versions.
 
https://github.com/eclipse/jetty.project/issues
 
cheers,
Jesse
 
--jesse mcconnelljesse.mcconn...@gmail.com 

On Thu, Jun 3, 2021 at 7:30 AM Thomas Watson <tjwat...@us.ibm.com> wrote:
The issue is now the Import-Package for the jetty bundles have a non-optional import on the slf4j package with a range forcing it to be 2.0:
 
For example:https://search.maven.org/artifact/org.eclipse.jetty/jetty-io/10.0.2/jar
 
 
Has this import:
 
org.slf4j;version="[2.0.0,3)"
 
If this either had a range that included 1.x, or was made an optional import then it would allow us to keep using the current stable version of slf4j (the latest 1.x version).  As far as I can tell slf4j 2.0 is has not released a final version.  It seems to have been in a perpetual alpha state since 2019.
Tom 
 
 
- Original message -From: Jesse McConnell <jesse.mcconn...@gmail.com>Sent by: "cross-project-issues-dev" <cross-project-issues-dev-boun...@eclipse.org>To: Cross project issues <cross-project-issues-dev@eclipse.org>Cc:Subject: [EXTERNAL] Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3Date: Thu, Jun 3, 2021 5:30 AM 
From the jetty perspective, you don't need to use a slf4j version 2 unless you're making use of the JPMS features. I believe you should be fine just running with the older version of slf4j. 

On Wed, Jun 2, 2021, 05:58 Sravan K Lakkimsetti <sravankum...@in.ibm.com> wrote:
Slf4j version 2 dependency is coming from jetty 10. At platform we are consuming jetty. This is where the slf4j.api version 2 is coming from. Since Jetty stopped building p2 repositories we built jetty p2 repositories with bare minimum components that are required for platform. 
 
We tried to use update Jetty around 2021-03 M3. But we thought this upgrade will be disruptive so we postponed to 2021-06 M1.
 
We added the feature announcement in N https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#jetty-10-update
We also sent a note because of jetty upgrade there are conflicts in simrel to crossproject-dev list. There was a considerable discussion on this topic.
 
I am just listing what happened with update Jetty 10. Now we cannot go back to older version of slf4j that means downgrading Jetty. Now what should be the way forward?
 
-Sravan
 
From: Mickael Istria <mist...@redhat.com>Sent: 02 June 2021 14:49To: eclipse-...@eclipse.orgCc: Discussions on Eclipse IDE Working Group <eclipse-ide...@eclipse.org>Subject: [EXTERNAL] Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: [cross-project-issues-dev] IMHO serious issues in the Eclipse Java IDE 2021-06 M3
 
Thanks for raising this issue folks. About Orbit or not, I fail at seeing what would that change: if slf4j 2.0 -which is a requirement- were in Orbit, how would that have prevented this issue in m2e from happening? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
Thanks for raising this issue folks.
About Orbit or not, I fail at seeing what would that change: if slf4j 2.0 -which is a requirement- were in Orbit, how would that have prevented this issue in m2e from happening?___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
 ___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3

2021-06-03 Thread Thomas Watson

The issue is now the Import-Package for the jetty bundles have a non-optional import on the slf4j package with a range forcing it to be 2.0:
 
For example:https://search.maven.org/artifact/org.eclipse.jetty/jetty-io/10.0.2/jar
 
 
Has this import:
 
org.slf4j;version="[2.0.0,3)"
 
If this either had a range that included 1.x, or was made an optional import then it would allow us to keep using the current stable version of slf4j (the latest 1.x version).  As far as I can tell slf4j 2.0 is has not released a final version.  It seems to have been in a perpetual alpha state since 2019.
Tom 
 
 
- Original message -From: Jesse McConnell Sent by: "cross-project-issues-dev" To: Cross project issues Cc:Subject: [EXTERNAL] Re: [cross-project-issues-dev] FW: Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: IMHO serious issues in the Eclipse Java IDE 2021-06 M3Date: Thu, Jun 3, 2021 5:30 AM  
From the jetty perspective, you don't need to use a slf4j version 2 unless you're making use of the JPMS features. I believe you should be fine just running with the older version of slf4j. 

On Wed, Jun 2, 2021, 05:58 Sravan K Lakkimsetti  wrote:
Slf4j version 2 dependency is coming from jetty 10. At platform we are consuming jetty. This is where the slf4j.api version 2 is coming from. Since Jetty stopped building p2 repositories we built jetty p2 repositories with bare minimum components that are required for platform. 
 
We tried to use update Jetty around 2021-03 M3. But we thought this upgrade will be disruptive so we postponed to 2021-06 M1.
 
We added the feature announcement in N https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#jetty-10-update
We also sent a note because of jetty upgrade there are conflicts in simrel to crossproject-dev list. There was a considerable discussion on this topic.
 
I am just listing what happened with update Jetty 10. Now we cannot go back to older version of slf4j that means downgrading Jetty. Now what should be the way forward?
 
-Sravan
 
From: Mickael Istria Sent: 02 June 2021 14:49To: eclipse-...@eclipse.orgCc: Discussions on Eclipse IDE Working Group Subject: [EXTERNAL] Re: [eclipse-ide-wg] [eclipse-pmc] Fwd: [cross-project-issues-dev] IMHO serious issues in the Eclipse Java IDE 2021-06 M3
 
Thanks for raising this issue folks. About Orbit or not, I fail at seeing what would that change: if slf4j 2.0 -which is a requirement- were in Orbit, how would that have prevented this issue in m2e from happening? ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
Thanks for raising this issue folks.
About Orbit or not, I fail at seeing what would that change: if slf4j 2.0 -which is a requirement- were in Orbit, how would that have prevented this issue in m2e from happening?___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] (Mirror) security

2020-09-25 Thread Thomas Watson

I'll point out that even if runtime verification of signed JARs is enabled (which does NOT require a security manager to be used), there is nothing that would stop Wim from modifying a class in the JAR and also removing all the signature/signer data from the JAR such that the runtime thinks the JAR is not signed and therefore will not have anything to validate its entries against.  Once the JAR has been verified and installed by p2 or the user decided to let unsigned content get installed with a warning p2 gives them, then it is assumed the JAR will remain unchanged and valid for the remainder of the time it is used by the platform.  The runtime does not record the SHA of the initial JAR installed and even with runtime verification of JARs enabled it would not validate that the SHA has not changed since last launch.
Tom 
 
 
- Original message -From: Ed Merks Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: cross-project-issues-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [cross-project-issues-dev] (Mirror) securityDate: Fri, Sep 25, 2020 9:52 AM 
Denis,
Comments below.
On 25.09.2020 16:01, Denis Roy wrote:

Ed,
I get your point. However, Eclipse running under my user account won't be able to alter my executables in /usr/bin.No, it can't modify files for which the user account doesn't have write access, but it could delete every file in your user account, or could transmit some or all of them to a server.  It could also send all your passwords that you've stored in your Eclipse password file.
Installing some great looking plugin from Marketplace could overwrite Eclipse jars that capture credentials.That wound be a very round-about way of accomplishing something the plugin could just do itself.  All plugins have access to the credentials, for example.
 
If it's possible to verify the signature of mission-critical jars at startup, would it make sense to offer it as an option (at the cost of slower startup) ?
 
I think you're assuming some jars a special in some way.  That's not the case.  Any plugin could do anything any other plugin can do.  Without a security manager running, there's really nothing to stop destructive behavior, and there's no need to tamper other plugins to accomplish that goal.
For those truly paranoid, verifying jar signatures (only run with signed jars) might grant some sense of security, but no user has ever asked for this as far as I know and even Java doesn't have a simple flag for such a thing...
 
Denis
 
On 2020-09-25 4:10 a.m., Ed Merks wrote:

Denis,
If one has a rogue running process that can write arbitrarily to your file system (or parts thereof), it could tamper anything, so it would seem that at that point you would have arbitrary security risks even without an Eclipse IDE.  Even Windows doesn't prevent a tampered or unsigned executable from running.  I don't think that Linux even has signed executables, given there is no signing of such things in the Tycho builds.
Looking at this search:
  https://www.google.com/search?q=java+run+only+signed+jars
and at answers like these:
https://stackoverflow.com/questions/54011270/allow-a-jar-to-run-only-if-it-is-signedhttps://stackoverflow.com/questions/34641305/is-it-possible-to-force-jvm-to-check-that-every-jar-must-be-signed
suggests that it's not really so feasible to prevent Java from running unsigned jars, though I expect from Thomas' answer that OSGi can do verification with its specialized class loader (though presumably that has a performance impact).
Running Java with a security manager enabled for the purpose of running an IDE I think makes zero sense, so generally the IDE can do anything and can itself be a rogue process (if and when the user installs arbitrary things from the marketplace).
Even if the jars are verified, I can still personally think of a number of ways that I could tamper data files used by the IDE that would make the IDE "do bad things".  I'll not outline the possible ways that I can think of...  :-P
I think a fundamental aspect (assumption?) of security is that the machine itself is secure, sufficiently so that a process that does rogue things never runs in the first place.  Verifying signatures and checksums ensures that only known content is downloaded and installed in order to keep the machine secure.
Regards,Ed
On 24.09.2020 19:53, Denis Roy wrote:

So it's possible for another process to tamper with jars and have Eclipse run them blindly.
Do we know if that is industry practice?
 
 
On 2020-09-24 12:07 p.m., Thomas Watson wrote:

Yes, p2 verifies the signatures and content of the JARs to confirm it hasn't been tampered with before installing the JAR.  At runtime the verification of JARs is not enabled by default.  Otherwise what you did would have resulted in a runtime exception for the class you changed.
 
Tom 
 
 
- Original message -From: Wim Jongman Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: Cross project issues Cc:Subject: [EXTERNAL] [cross-project-

Re: [cross-project-issues-dev] (Mirror) security

2020-09-24 Thread Thomas Watson

Yes, p2 verifies the signatures and content of the JARs to confirm it hasn't been tampered with before installing the JAR.  At runtime the verification of JARs is not enabled by default.  Otherwise what you did would have resulted in a runtime exception for the class you changed.
 
Tom 
 
 
- Original message -From: Wim Jongman Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: Cross project issues Cc:Subject: [EXTERNAL] [cross-project-issues-dev] (Mirror) securityDate: Thu, Sep 24, 2020 10:18 AM   

 

Hi,
 
This is probably a silly question but I was wondering how we protect the content of jar files as they are being pulled from mirrors all over the world.
 
Due to a recent break in the Platform class, I compiled my own version of the Platform class where I re-added the removed method. Then I replaced it in the plugins/o.e.c.runtime jar using 7-zip.
 
This solved my issue but it also made me wonder how this was protected if some mirror-server user used the same hack to dope our jars.
 
I assume this is being done by p2 when downloading the jar files by comparing some MDA hash?
 
Please enlighten me.
 
Cheers,
 
Wim
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Odd bugzilla access issues for anonymous access

2020-09-02 Thread Thomas Watson

FYI - I'm seeing odd behavior for recently opened bugzilla issues that do not allow them to be read without being logged into bugzilla.  I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=566622
 
NOTE: You must be logged into bugzilla to read the details of the bug!!
Tom 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Simultaneous Release Page 2020-09

2020-09-02 Thread Thomas Watson

+1
Tom 
 
 
- Original message -From: Martin Lippert Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: Cross project issues Cc:Subject: [EXTERNAL] Re: [cross-project-issues-dev] Simultaneous Release Page 2020-09Date: Wed, Sep 2, 2020 4:13 AM +1
 
Cheers
Martin
 
 
 
Am 28.08.2020 um 18:43 schrieb Wayne Beaton : 

It's not really up to me. 
 
I suppose that we could think of Eclipse JustJ as something that the package project pulls in, but it should IMHO have a proper place in the simultaneous release. It serves us well to include it (and not including it will lead to weird "what does it mean to be in the simultaneous release then anyway" sorts of discussions). FWIW (and more for other random observers, because I know that you know this), there's no rule that says that participating projects must contribute bits for the shared p2 repository.
 
So... since we're well past M1, I'll need Planning Council approval to add it. Can I get a couple of +1s from Planning Council members on this thread please?
 
For completeness, +1 from me (and as assumed +1 from Ed).
 
Wayne
  

On Fri, Aug 28, 2020 at 12:11 AM Ed Merks  wrote:
Wayne,
You may wish to add JustJ:
  https://projects.eclipse.org/projects/technology.justj/releases/1.0
While it is not in the release train p2 repo, it is incorporated into the Eclipse Installer and into three of the EPP packages.
Regards,Ed 
On 27.08.2020 20:50, Wayne Beaton wrote:
I've created the tracking page for 2020-09. Please have a look to ensure that I've correctly recorded your project's participation correctly.

 
In particular, please make sure that I have the version right. If I've made a mistake... please first make sure that you've created a release record for the right version and then let me know to update the tracking page to point to that version.
 
If you are contributing a new major or minor release and have not engaged in a release review since September 16/2019, then you need to submit your IP Log and connect with EMO ASAP to initiate the release review process. Note that you only need to submit your IP Log for review if you are required to engage in a release review. There's more information in the handbook.
 
Based on messages on this list, both Eclipse Corrosion, Eclipse EMFStore, and Eclipse Tools for Cloud Foundry (CFT) have dropped out, so they've been removed from the list. 
 
AFAICT, the corrosion.aggrcon file still exists and is not disabled. Also, since CFT has dropped out, its aggrcon file should also be removed (not just disabled). Can somebody take care of that, please?
 
Thanks for all your efforts.
 
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Join us at our virtual event: EclipseCon 2020 - October 20-22  

 
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 

 --

Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Join us at our virtual event: EclipseCon 2020 - October 20-22___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Issues with git/gerrit and sometimes bugzilla

2020-02-07 Thread Thomas Watson

I've been getting 502 errors access the eclipse servers, bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=559928 opened.
 
Tom 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Equinox will contribute fixes for Oxygen.1a

2017-09-25 Thread Thomas Watson

 
Equinox will contribute to Oxygen.1a for the following bugs:
 
Bug 520636 - Make sure Eclipse starts with Java 9
Bug 522313 - Remove loop used to acquire the bundle id lock on bundle installation
 
Tom 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Equinox participation in Photon

2017-09-18 Thread Thomas Watson

Hi,
 
Equinox will participate in the Photon release with version 4.8.0 at offset 0.
 
The release record is here: https://projects.eclipse.org/projects/rt.equinox/releases/4.8.0-photon
 
Tom 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Will Your Project Work When Running on Java 9?

2017-03-08 Thread Thomas Watson

> From: Ed Merks 
> During testing I also see this stack trace in my Error log:
> 
> java.lang.reflect.InaccessibleObjectException: Unable to make field 
> private static volatile java.net.Authenticator 
> java.net.Authenticator.theAuthenticator accessible: module java.base
> does not "opens java.net" to unnamed module @26749efe
> at java.base/
> 
java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:
> 335)
> at java.base/
> 
java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:
> 278)
> at 
java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:175)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:169)
> at 
> 
org.eclipse.epp.internal.mpc.core.util.ProxyHelper.getDefaultAuthenticator(ProxyHelper.java:
> 116)

> I'm not sure what to make of that, but it suggests that MPC might 
> well not function when running on Java 9. 
> So in the end, I think there isn't so much to worry about, but 
> nevertheless, I strongly encourage each team to test their project's
> readiness so we can all avoid hassles and embarrassment when Java 9 
> is finally released.  I've tried to help make that as easy as 
possible...

> Regards,
> Ed

This is an indication that ProxyHelper is using reflection on some 
internal types of java.net.Authenticator.  Looks like it is to unset 
itself from the private static field 
java.net.Authenticator.theAuthenticator.  This likely is happening on 
shutdown and the ProxyHelper is just trying to clean up the VMs static 
field.  In the Eclipse Platform case this is not a big deal that it failed 
because the VM is going to terminate anyway so there is no concern that 
ProxyHelper could not clean up from the awful static instance in the VM.

I had to work around a similar issue in the Equinox Framework in order to 
clean up our URLStreamHandlerFactory implementation [1].  I did horrendous 
things by using the Unsafe class to get around this.  There is a temporary 
option in Java 9 (--force-open-all-module-packages) that should force all 
packages from modules in the boot layer to be open for deep reflection on 
private types.  You can try this option out to see if it works around the 
issue.  They say this option will be removed in a future release so I 
don't think it is a viable long term solution.  You could also try using 
the more specific option --add-opens:

--add-opens java.base/java.net=ALL-UNNAMED

The commandline help for --add-options does not state that ALL-UNNAMED is 
a valid target so it may not work, but the similar options --add-reads and 
--add-exports do state ALL-UNNAMED is a valid target so it may work.  Even 
this is not a great option because in the future we may try to get the 
bundles to be loaded as real named modules [2] (note this article is out 
of date and some of the details have changed significantly).  In that case 
you would have to be more specific and list the symbolic names of the 
bundles that need to do deep reflection.

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209
[2] 
https://www.eclipse.org/community/eclipse_newsletter/2016/october/article3.php


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Equinox participation in Oxygen

2016-10-05 Thread Thomas Watson

You passed!  yes Equinox IS participating in Oxygen.

Tom

From:   Christian Campo <christian.ca...@compeople.de>
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Date:   10/05/2016 10:09 AM
Subject:Re: [cross-project-issues-dev] Equinox participation in 
Oxygen
Sent by:cross-project-issues-dev-boun...@eclipse.org

So this MUST be a test to see if someone is paying attention..

Title is "participation in Oxygen".. Text is "participating in 
Neon".

So yes I DID pay attention :-)

christian

p.s. version 4.7 seems to be right though

Von: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> im Auftrag von Thomas 
Watson <tjwat...@us.ibm.com>
Gesendet: Dienstag, 4. Oktober 2016 23:19
An: Cross project issues
Betreff: [cross-project-issues-dev] Equinox participation in Oxygen 

Equinox will be participating in the Neon Simultaneous release with an 
offset 0.

The planned release is 4.7.0.

Tom

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Frank Laskowski, Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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] Equinox participation in Oxygen

2016-10-04 Thread Thomas Watson

Equinox will be participating in the Neon Simultaneous release with an 
offset 0.

The planned release is 4.7.0.

Tom



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] git.eclipse.org not reachable

2016-08-16 Thread Thomas Watson

Same for me.

Tom





From:   Pascal Rapicault 
To: Webmaster , Cross project issues 

Date:   08/16/2016 07:30 AM
Subject:[cross-project-issues-dev] git.eclipse.org not reachable
Sent by:cross-project-issues-dev-boun...@eclipse.org



I can't fetch from git.eclipse.org, nor can I connect to web interface.

http://www.downforeveryoneorjustme.com/git.eclipse.org


Pascal

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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] Notice: the removal of the org.eclipse.equinox.log bundle in Neon

2016-04-14 Thread Thomas Watson

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=491565

The org.eclipse.equinox.log implementation and API has been included in 
the Equinox framework since the Indigo release.  As such the old 
org.eclipse.equinox.log has been untouched and not maintained over the 
years.  For Neon we are removing this bundle from the Equinox release and 
do not plan to build it in future builds.  Please voice any concerns you 
may have about this removal in the bug 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=491565

David has informed me that the riena project appears to have a dependency 
on this bundle (using require-bundle?).  Christian, could you have a look 
from the Riena perspective?

Tom



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] core.jobs dependency on Java 8

2015-12-07 Thread Thomas Watson

One thing to note is that Java 8 is already supported for WebShere 
Application Server Liberty.  Also, the statement of general direction from 
IBM is that IBM intends to support Java 8 for WebSphere Application Server 
- Classic [1]

I would imagine by the time Neon is released in June and used to build RAP 
applications most all the major app servers should support Java 8.

Tom

[1] 
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN=CA=897/ENUS215-417=USN#sodx





From:   Ivan Furnadjiev 
To: cross-project-issues-dev@eclipse.org
Date:   12/07/2015 09:32 AM
Subject:Re: [cross-project-issues-dev] core.jobs dependency on 
Java 8
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi John,
today I found that another set of bundles that RAP uses from platform 
depends now on Java 8:
org.eclipse.core.databinding
org.eclipse.core.databinding.property
org.eclipse.core.databinding.observable
Regards,
Ivan

On 12/7/2015 16:40, John Arthorne wrote:
The fact that the Eclipse SDK as a whole will require Java 8 doesn't imply 
that any particular bundle should require Java 8. Since the change 
requiring Java 8 was cosmetic and there is a significant impact caused by 
the change, I think it is fair to ask the question and to consider the 
request. I have entered this bug for further discussion, so please chime 
in there if you have an opinion: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=483803

One question for you Ralf, is whether this is the only bundle RAP requires 
that is blocking you in this way? I thought there were a number of other 
platform bundles already requiring Java 8 as well.

John


-cross-project-issues-dev-boun...@eclipse.org wrote: - 
To: Cross project issues 
From: Lars Vogel 
Sent by: cross-project-issues-dev-boun...@eclipse.org
Date: 12/07/2015 04:50AM
Subject: Re: [cross-project-issues-dev] core.jobs dependency on Java 8

Hi Ralf,

Dani announced a while ago that Eclipse Neon will drop support for
Java 7. See: 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg12177.html


Best regards, Lars

On Mon, Dec 7, 2015 at 10:41 AM, Ralf Sternberg
 wrote:
> Hi,
>
> while we all want to use the new features in Java 8, some users of the
> RAP project still can't switch to Java 8 because they have to deploy
> on application servers that run on a (bundled) non-Java-8 VM. For
> example, looking at the IBM WebSphere JDK support list [1], it seems
> that for the server side, it's still a bit too early to require Java
> 8.
>
> Since one of the bundles RAP depends on (core.jobs) has recently been
> updated to Java 8, we find ourselves faced with the choice of either
> locking out those users or shipping RAP 3.1 with an older version of
> the platform. The latter would probably mean to abstain from the Neon
> simultaneous release.
>
> I wonder if there is a general consensus that the Eclipse platform
> (not the IDE) does not support Java 7 anymore. If this is the case, we
> have to live with it, however, I'd appreciate to keep at least the
> core Java-7-compatible for one more year. Looking at the respective
> change in core.jobs [2], it looks like a refactoring, not an API
> change that would require Java 8. Also on the Neon release plan [3],
> it's still marked as 1.7. Is there a chance to revert this change or
> are more of those going to come?
>
> Regards,
> Ralf
>
> [1] http://www-01.ibm.com/support/docview.wss?rs=180=swg27005002
> [2] 
http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/bundles/org.eclipse.core.jobs?id=e0c1dc5111c5200d39f4611082b34110d735ac29

> [3] 
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_6.xml#appendix

>
> --
> Ralf Sternberg
> Project Lead, Remote Application Platform (RAP)
> EclipseSource
>
> Tel: +49 721 66 47 33-0
>
> Innoopract Informationssysteme GmbH
> Lammstraße 21, 76133 Karlsruhe, Germany
> General Manager: Jochen Krause
> Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vo...@vogella.com, Web: 
http://www.vogella.com
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit

Re: [cross-project-issues-dev] participation in Neon

2015-10-21 Thread Thomas Watson

I did create on: 
https://projects.eclipse.org/projects/rt.equinox/releases/4.6.0-neon

Unless you are talking about something else.  I still have to fill in the 
details of the release plan but I figured the release record at that URL 
was good enough to declare intent.

Tom





From:   David M Williams/Raleigh/IBM@IBMUS
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Date:   10/21/2015 11:25 AM
Subject:Re: [cross-project-issues-dev] participation in Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org



Maybe it is obvious, but I have a feeling that Wayne would wish I would 
have reminded everyone to create a release record, to go along with your 
announcements. :) 

I am lucky and never have ... but appears the "how to" instructions have 
moved to 

https://www.eclipse.org/projects/handbook/#pmi-releases

Thanks, 





From:    Thomas Watson/Austin/IBM@IBMUS
To:"Cross project issues" <cross-project-issues-dev@eclipse.org>, 
Date:10/21/2015 11:29 AM
Subject:[cross-project-issues-dev] Equinox participation in Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org



Equinox will be participating in the Neon Simultaneous release with an 
offset 0.

The planned release is 4.6.0.

Tom

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

2015-10-21 Thread Thomas Watson

Not sure you noticed but Equinox only declared for Neon just now.  Would 
have been interesting to see what happens if you disabled Equinox.

Tom





From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org
Date:   10/21/2015 09:15 AM
Subject:[cross-project-issues-dev] Did I mess up our procedure for 
Neon? With respect to declaring, and enablement, and our "list of 
participants"?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Just today I realized I think I was supposed to "disable" everyone, until 
they responded affirmatively that they were participating in Neon. 

Since so many have declared their intent already, I hate to start over, by 
disabling everyone, but, need to come up with a list of "those who have 
declared intent", 
and then I will disable the rest. 

Wayne have you been keeping track? So far, the list at 
https://projects.eclipse.org/releases/neon
only shows "Eclipse" is participating. I assume that's set to always be 
true. :) 
But the rest need someone to enter the data? 

If we can get a better list in next week or so, then by M3 I will disable 
anyone who has not yet declared intent. 
For example, perhaps BIRT is no longer planning to participate? (For all I 
know?) 

Thanks, 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Mars 1 RC4 issue with Buildship / workspace prompt

2015-09-23 Thread Thomas Watson

> 
> I think this is also something, which should be fixed directly in 
> the code, which reads or parses the /configuration/org.eclipse.osgi/
> framework.info.{x} file.
> 
> Regards,
> 
> Simon
> 

The OSGi framework is behaving exactly the way you told it to.  There is 
no bug in the framework here.  You persistently started the bundle with 
Bundle.start().  The framework cannot simply ignore that on a restart.  It 
must eagerly start the persitently started bundle on restart.  To do 
otherwise will cause the framework implementation to be non-compliant with 
the specification.

Tom


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Mars 1 RC4 issue with Buildship / workspace prompt

2015-09-22 Thread Thomas Watson

I think the fix in https://bugs.eclipse.org/bugs/show_bug.cgi?id=478054 is 
incorrect.  I added a comment to the defect with the details.

Tom





From:   Etienne Studer 
To: Cross project issues 
Date:   09/22/2015 12:08 PM
Subject:[cross-project-issues-dev] Eclipse Mars 1 RC4 issue with 
Buildship   / workspace prompt
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi

In our Gradle forum, a user recently reported a problem with not seeing 
the workspace prompt when starting Eclipse and suspected that it is 
related to Buildship. We created a BugZilla issue for this. After deeper 
investigations, Simon Scholz from Vogella GmbH eventually found the 
problem and a fix:

When launching a Gradle build with Buildship 1.0.3, an extension point is 
used to start the Buildship UI bundle. The code in Buildship which is 
responsible for starting the Buildship UI bundle is called even when the 
UI bundle is already active. This causes the 
/configuration/org.eclipse.osgi/framework.info.{x} file to change into an 
unstable state, and as a consequence the workspace prompt is not shown 
anymore when starting Eclipse. The plugin activation code has been in 
Buildship for a very long time but until very recently, nobody had ever 
experienced this problem.

Buildship 1.0.4, built today, contains a patch for this issue by only 
starting the UI bundle programmatically if the bundle is not already in 
state “ACTIVE". This avoids the corruption of 
/configuration/org.eclipse.osgi/framework.info.{x} and thus the workspace 
prompt is always properly shown when starting Eclipse.

It seems like there is an underlying bug in the 
org.osgi.framework.Bundle.start() method that causes the 
/configuration/org.eclipse.osgi/framework.info.{x} to become corrupt when 
start() is called and the bundle is already "ACTIVE". Unfortunately, we 
were not able to read the 
/configuration/org.eclipse.osgi/framework.info.{x} file and thus we were 
not able to confirm this theory, nor could we figure out what was actually 
changed with tools like kdiff3.

How should we proceed from here?

Kind regards, Etienne
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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] Late discovery of a breaking change in Equinox that impacts Equinox hook implementations

2015-05-29 Thread Thomas Watson

In Mars M6 a fix [1] went into Equinox that allows an Equinox extension 
hook implementation to return resource URLs that use a different protocol 
than the built-in bundleresource protocol.  For example, Virgo has the 
need to return the VM built-in jar or file URLs in some scenarios.  While 
doing the final testing of the Mars release candidates I found this change 
causes a breaking change in the behavior for resource URL lookups when 
equinox hooks are present which want to augment the content of the bundle 
resources [2].  This must be fixed for Mars in my opinion.  But in order 
to fix this any equinox extension hooks that want to change the protocol 
used for resource URLs will need to override a different method.  For more 
information please see [2]. 

Unfortunately this change is not available in RC3, but this late change 
impacts a very small number of projects.  I really only know of it 
impacting Virgo.  Please comment in the bug [2] if you have concerns.

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=460637
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=468817
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] To be able to install newly signed plug-in on Helios and Indigo

2015-04-20 Thread Thomas Watson

If you really cannot move up to at least the Juno release then the 2 
following options area available:

1) remove the signatures from the jars and place them on your own update 
sight to install from ... or
2) patch equinox (org.eclipse.osgi) with 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=378155

Tom





From:   Grégoire Dupé gd...@mia-software.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org
Date:   04/20/2015 05:04 AM
Subject:[cross-project-issues-dev] To be able to install newly 
signed  plug-in on Helios and Indigo
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hello,
 
We are not able to install newly signed plug-ins on Helios, and Indigo. We 
get the following error (during the installation of a signed plug-in): 
Caused by: java.security.NoSuchAlgorithmException: No algorithm found for 
2.16.840.1.101.3.4.2.1
at 
org.eclipse.osgi.internal.signedcontent.PKCS7Processor.findDigest(PKCS7Processor.java:87)
at 
org.eclipse.osgi.internal.signedcontent.PKCS7Processor.processSignerInfos(PKCS7Processor.java:311)
at 
org.eclipse.osgi.internal.signedcontent.PKCS7Processor.init(PKCS7Processor.java:133)
at 
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:93)
at 
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:60)
at 
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.setBundleFile(SignedBundleFile.java:47)
at 
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:247)
 
This error happens because the class ‘PKCS7Processor’ embedded in Helios 
and Indigo isn’t able to deal with SHA-256. SHA-256 is used since Java-1.7 
to sign [1]. I assume that the signing service has been updated to 
Java-1.7.
 
From the release train point of view this seems to be a good thing. But my 
company integrates EMF Facet and MoDisco into its own product and some of 
our clients are still using Helios and Java-1.5! 
 
Does anybody have any advice to be able to install newly signed plug-in on 
Helios and Indigo?
 
Regards,
Grégoire Dupé___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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] org.eclipse.equinox.common has added generics to API in org.eclipse.core.runtime package

2015-02-20 Thread Thomas Watson

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=442021

Markus Keller wrote up an nice summary of what consumers should do to fix 
any warnings that may be caused by this change at 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=442021#c25

Here is a copy of the recommendations if you are going to compile against 
the latest version of org.eclipse.equinox.common:

1. In MANIFEST.MF, update your Require-Bundle: 
org.eclipse.core.runtime;bundle-version=[3.11.0,4.0.0), or 
org.eclipse.equinox.common;bundle-version=[3.7.0,4.0.0), or update your 
Import-Package: org.eclipse.core.runtime; version=[3.5,4.0)

2. If your bundle re-exports one of these bundles, then you also have to 
make sure the minor version is incremented.

3. Remove unnecessary casts (Clean Up, or Problems view  Quick Fix  
Select All)

4. Update implementations of IAdaptable#getAdapter(ClassT), unless you 
override another implementation of that method that still uses the old 
signature.

Typical change:
Old:
public Object getAdapter(Class adapter) {
if (ICompilationUnit.class.equals(adapter))
return getCompilationUnit();
return null;
}

New:
@SuppressWarnings(unchecked)
public T T getAdapter(ClassT adapter) {
if (ICompilationUnit.class.equals(adapter))
return (T) getCompilationUnit();
return null;
}

5. Update implementations of IAdapterFactory

Hint for 4.  5.:
- Open Type Hierarchy on IAdaptable, etc.
- In the view menu, select a working set that contains your projects
- In the methods list of the Type Hierarchy view, select the methods, and 
then click the first toolbar button (Lock View and Show Members in 
Hierarchy)


Tom

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Potential for errors with p2 update and http client version

2014-10-29 Thread Thomas Watson

I have not heard of any other reporters of this.   I got it hit with it 
again recently and wanted to make others aware while testing M3.  If your 
installation contains multiple versions of the apache http client then you 
could be hit by https://bugs.eclipse.org/bugs/show_bug.cgi?id=447993

My installation of jgit happens to pull in an older version of apache http 
client and I get hit with the following exception when trying to update 
with p2.

java.lang.NoSuchMethodError: 
org.apache.http.impl.client.DefaultHttpClient.execute(Lorg/apache/http/client/methods/HttpUriRequest;Lorg/apache/http/protocol/HttpContext;)Lorg/apache/http/client/methods/CloseableHttpResponse;
at 
org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.performConnect(HttpClientRetrieveFileTransfer.java:1077)
at 
org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.access$0(HttpClientRetrieveFileTransfer.java:1068)
at 
org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer$1.performFileTransfer(HttpClientRetrieveFileTransfer.java:1064)
at 
org.eclipse.ecf.filetransfer.FileTransferJob.run(FileTransferJob.java:73)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)


The only work around I have found is to bring up the osgi console and 
manually refresh the org.eclipse.ecf.provider.filetransfer.httpclient4 
bundle:

osgi refresh org.eclipse.ecf.provider.filetransfer.httpclient4

That allows ecf to be rewired to the latest version of apache.  I suspect 
I am hitting this because I do build to build upgrades which has been 
updating the latest version of apache http client recently.  This ends up 
causing ecf to be re-resolved and wires to the pre-resolved older version 
still left around.

Tom

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Equinox participation in Mars

2014-10-06 Thread Thomas Watson

I realized Equinox never announced.  Lets make it official.

Equinox will be participating in the Mars simultaneous release with an 
offset of +0
The 4.5 version will be contributed: 
https://projects.eclipse.org/projects/rt.equinox/releases/4.5.0-mars

Tom

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Apparent Luna SR1 regression in build failure reporting

2014-09-09 Thread Thomas Watson

This sounds similar to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436073

There have been some changes to Equinox for SR1 dealing with system 
properties.  I am wondering somehow the system property 
osgi.framework.useSystemProperties=true is being set before invoking the 
framework from the build.

Tom





From:   Konstantin Komissarchik konstantin.komissarc...@oracle.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org
Date:   09/08/2014 10:34 PM
Subject:Re: [cross-project-issues-dev] Apparent Luna SR1 
regression in   build   failure reporting
Sent by:cross-project-issues-dev-boun...@eclipse.org



Anyone? We are down to the wire here and it’s looking like Luna SR1 will 
be useless as a build driver unless there is a last-minute fix, since we 
can’t depend on it failing the build correctly.
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Konstantin Komissarchik
Sent: Monday, September 08, 2014 10:01 AM
To: 'Cross project issues'
Subject: [cross-project-issues-dev] Apparent Luna SR1 regression in build 
failure reporting
 
We are seeing a serious regression in Luna SR1 (tested with platform RC3) 
where PDE build does not report a process failure code when the build 
fails. This causes any invoking build process (such as Ant) to not detect 
a failure and continue.
 
Just confirmed that this works correctly if Luna is used to drive the 
build instead of Luna SR1.
 
I am not sure if the regression is in the launcher or in the PDE build. 
 
Is anyone else seeing this?
 
Thanks,
 
- Konstantin
 ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Apparent Luna SR1 regression in build failure reporting

2014-09-09 Thread Thomas Watson

Konstantin

I put a fix into master for the 4.5 Eclipse I-Build that should happen 
today (we need to respin for another issue).  Would you be able to test 
with this I-Build once it is done to see if it fixes the issue?  Then we 
can consider backporting to Luna.

Tom





From:   Thomas Watson/Austin/IBM@IBMUS
To: Cross project issues cross-project-issues-dev@eclipse.org
Date:   09/09/2014 07:35 AM
Subject:Re: [cross-project-issues-dev] Apparent Luna SR1 
regression  in  build   failure reporting
Sent by:cross-project-issues-dev-boun...@eclipse.org



This sounds similar to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436073 

There have been some changes to Equinox for SR1 dealing with system 
properties.  I am wondering somehow the system property 
osgi.framework.useSystemProperties=true is being set before invoking the 
framework from the build. 

Tom





From:Konstantin Komissarchik 
konstantin.komissarc...@oracle.com 
To:'Cross project issues' cross-project-issues-dev@eclipse.org 

Date:09/08/2014 10:34 PM 
Subject:Re: [cross-project-issues-dev] Apparent Luna SR1 
regression inbuildfailure reporting 
Sent by:cross-project-issues-dev-boun...@eclipse.org 



Anyone? We are down to the wire here and it’s looking like Luna SR1 will 
be useless as a build driver unless there is a last-minute fix, since we 
can’t depend on it failing the build correctly. 
  
- Konstantin 
  
  
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Konstantin Komissarchik
Sent: Monday, September 08, 2014 10:01 AM
To: 'Cross project issues'
Subject: [cross-project-issues-dev] Apparent Luna SR1 regression in build 
failure reporting 
  
We are seeing a serious regression in Luna SR1 (tested with platform RC3) 
where PDE build does not report a process failure code when the build 
fails. This causes any invoking build process (such as Ant) to not detect 
a failure and continue. 
  
Just confirmed that this works correctly if Luna is used to drive the 
build instead of Luna SR1. 
  
I am not sure if the regression is in the launcher or in the PDE build. 
  
Is anyone else seeing this? 
  
Thanks, 
  
- Konstantin 
 ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Apparent Luna SR1 regression in build failure reporting

2014-09-09 Thread Thomas Watson

OK, please track the issue and post the repro with bug 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=443595

Tom





From:   Konstantin Komissarchik konstantin.komissarc...@oracle.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org
Date:   09/09/2014 08:57 AM
Subject:Re: [cross-project-issues-dev] Apparent LunaSR1 
regression  in  build   failure reporting
Sent by:cross-project-issues-dev-boun...@eclipse.org



Here is how we are calling into PDE Build. I don’t see any references to 
osgi.framework.useSystemProperties.
 
  java classname=org.eclipse.core.launcher.Main
fork=true failonerror=true maxmemory=${java.maxmemory}
classpath
  fileset dir=${bootstrap.platform}/plugins
include name=**/org.eclipse.equinox.launcher_*.jar/
  /fileset
/classpath
arg line=-clean/
arg line=-application org.eclipse.ant.core.antRunner/
arg line=-data ${build.dir}/pde/workspace/
arg line=-configuration ${build.dir}/pde/configuration/
arg line=-buildfile ${.pdeBuildDir}/scripts/build.xml/
arg value=-DtopLevelElementId=@{feature.id}/
arg value=-DarchivePrefix=eclipse/
arg value=-DbaseLocation=@{eclipse.install.dir}/
arg value=-DbuildDirectory=@{root.dir}/
arg value=-Dbuilder=${build.dir}/pde/builder/
arg value=-DcollectingFolder=collecting/
arg value=-DbuildId=@{build.id}/
arg value=-DbuildType=I/
arg value=-DbuildLabel=build/
arg value=-DROOT_RELENG_DIR=@{root.releng.dir}/
arg value=-DforceContextQualifier=@{build.id}/
arg value=-DgenerateFeatureVersionSuffix=false/
arg value=-DindividualSourceBundles=true/
arg value=-DallowBinaryCycles=true /
arg value=-DcompilerArg=${pde.build.compiler.arg}/
arg value=-DJ2SE-1.4=${java.14.system.classpath}/
arg value=-DJavaSE-1.6=${java.16.system.classpath}/
arg value=-DJavaSE-1.7=${java.17.system.classpath}/
java-args/
  /java
 
I will work on a stand-alone repro today.
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas 
Watson
Sent: Tuesday, September 09, 2014 6:41 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Apparent Luna SR1 regression in 
build failure reporting
 
Konstantin 

I put a fix into master for the 4.5 Eclipse I-Build that should happen 
today (we need to respin for another issue).  Would you be able to test 
with this I-Build once it is done to see if it fixes the issue?  Then we 
can consider backporting to Luna. 

Tom





From:Thomas Watson/Austin/IBM@IBMUS 
To:Cross project issues cross-project-issues-dev@eclipse.org 
Date:09/09/2014 07:35 AM 
Subject:Re: [cross-project-issues-dev] Apparent Luna SR1 
regressioninbuildfailure reporting 
Sent by:cross-project-issues-dev-boun...@eclipse.org 




This sounds similar to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436073 

There have been some changes to Equinox for SR1 dealing with system 
properties.  I am wondering somehow the system property 
osgi.framework.useSystemProperties=true is being set before invoking the 
framework from the build. 

Tom





From:Konstantin Komissarchik konstantin.komissarc...@oracle.com
 
To:'Cross project issues' cross-project-issues-dev@eclipse.org 

Date:09/08/2014 10:34 PM 
Subject:Re: [cross-project-issues-dev] Apparent Luna SR1 
regression inbuildfailure reporting 
Sent by:cross-project-issues-dev-boun...@eclipse.org 




Anyone? We are down to the wire here and it’s looking like Luna SR1 will 
be useless as a build driver unless there is a last-minute fix, since we 
can’t depend on it failing the build correctly. 
 
- Konstantin 
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Konstantin Komissarchik
Sent: Monday, September 08, 2014 10:01 AM
To: 'Cross project issues'
Subject: [cross-project-issues-dev] Apparent Luna SR1 regression in build 
failure reporting 
 
We are seeing a serious regression in Luna SR1 (tested with platform RC3) 
where PDE build does not report a process failure code when the build 
fails. This causes any invoking build process (such as Ant) to not detect 
a failure and continue. 
 
Just confirmed that this works correctly if Luna is used to drive the 
build instead of Luna SR1. 
 
I am not sure if the regression is in the launcher or in the PDE build. 
 
Is anyone else seeing this? 
 
Thanks, 
 
- Konstantin 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman

Re: [cross-project-issues-dev] Intalling with java 6 cannot recover

2014-06-06 Thread Thomas Watson

FYI, We are planning to fix for RC4.  Thanks for reporting the issue.

Tom

From:   Marc-André Laperle marc-andre.lape...@ericsson.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Date:   06/05/2014 05:14 PM
Subject:Re: [cross-project-issues-dev] Intalling with java 6 cannot
recover
Sent by:cross-project-issues-dev-boun...@eclipse.org

Thomas,

I think I managed to find reproducable steps, see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436758

Marc-Andre

On 14-06-05 04:54 PM, Thomas Watson wrote:

  I just tried and could not reproduce.  Installing CDT on Java 6,
  re-launching and having a look at the osgi console showed the CDT
  bundles as INSTALLED (not resolved).  Relaunching with Java 7 allowed
  the CDT bundles to resolve.  I would double check that Java 7 is
  really being used.  Start with -console and issue the command:

  props | grep environment

  That should give you the following:

  org.osgi.framework.executionenvironment =

OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4,J2SE-1.5,JavaSE-1.6,JavaSE-1.7

  Notice JavaSE-1.7 at the end.

  Tom

  Inactive hide details for Marc Khouzam ---06/05/2014
  02:54:27 PM---Sadly I did launch with -clean and it didn't
  help. Since it Marc Khouzam ---06/05/2014 02:54:27 PM---Sadly I did
  launch with -clean and it didn't help. Since it should be fixed in
  M7, we'll try to repr

  From: Marc Khouzam marc.khou...@ericsson.com
  To: 'Cross project issues' cross-project-issues-dev@eclipse.org
  Date: 06/05/2014 02:54 PM
  Subject: Re: [cross-project-issues-dev] Intalling with java 6 cannot
  recover
  Sent by: cross-project-issues-dev-boun...@eclipse.org

  Sadly I did launch with –clean and it didn’t help.

  Since it should be fixed in M7, we’ll try to reproduce on another
  machine to make sure it is not my environment.

  From: cross-project-issues-dev-boun...@eclipse.org [
  mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of
  Thomas Watson
  Sent: Thursday, June 05, 2014 3:07 PM
  To: Cross project issues
  Subject: Re: [cross-project-issues-dev] Intalling with java 6 cannot
  recover

  This sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=432485

  But that should have been fixed in M7.  I am curious if launching
  with -clean fixes the issue.  I would start with a bug against
  Equinox Framework if it is what I suspect (somehow the framework is
  not forcing a refresh of the system bundle to update its capabilities
  to include the Java 7 execution environment).

  Tom

  Inactive hide details for Marc Khouzam ---06/05/2014
  12:05:12 PM---Hi, I'm testing installing CDT on RC3. CDT
  requires Java 7.Marc Khouzam ---06/05/2014 12:05:12 PM---Hi, I'm
  testing installing CDT on RC3.  CDT requires Java 7.

  From: Marc Khouzam marc.khou...@ericsson.com
  To: 'cross-project-issues-dev@eclipse.org' 
  cross-project-issues-dev@eclipse.org
  Cc: Alvaro Sanchez-Leon alvaro.sanchez-l...@ericsson.com
  Date: 06/05/2014 12:05 PM
  Subject: [cross-project-issues-dev] Intalling with java 6 cannot
  recover
  Sent by: cross-project-issues-dev-boun...@eclipse.org

  Hi,

  I'm testing installing CDT on RC3.  CDT requires Java 7.
  My system switched to java 6 under my feet, so I ended up installing
  CDT using java 6.
  The install worked but when running, most CDT plugins didn't start
  and I got some errors due to java 6.
  I then switched back to java 7 and ran the already installed version.
  Surprisingly, things still failed but no errors reported.

  So, it looks like installing plugins that require a newer java than
  what is running is non-recoverable.

  Is this a bug I should report? If so, to what component?

  Thanks

  Marc
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev

Re: [cross-project-issues-dev] Switch from Luna RC2 to RC3 fails all our Tycho run UI tests: Known issue?

2014-06-06 Thread Thomas Watson


That looks to be https://bugs.eclipse.org/bugs/show_bug.cgi?id=435888

Tom





From:   Andreas Sewe andreas.s...@codetrails.com
To: cross-project-issues-dev@eclipse.org
Date:   06/06/2014 11:13 AM
Subject:[cross-project-issues-dev] Switch from Luna RC2 to RC3 fails
all our Tycho run UI tests: Known issue?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

hope cross-project-issues is the right list for this, but for us it's a
huge issue (none of our builds pass) and I am wondering whether any
other project has encountered this as well:

We use http://download.eclipse.org/releases/luna/ as update site in
our builds. Now, as of today, i.e., the promotion of RC3 from staging to
said update site, Tycho fails to execute all of our UI tests. I have
opened Bug 436858 [1] to document my findings so far, but the short
version is that the UI tests all fail with the tycho-surefire-plugin
saying some along the lines of

 An error has occurred. See the log
file .../target/work/data/.metadata/.log.

with the log then containing

 !ENTRY org.eclipse.osgi 4 0 2014-06-06 09:17:04.074
 !MESSAGE Application error
 !STACK 1
 java.lang.NullPointerException
at
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine
$StylingPreferencesHandler.getPreferences(PartRenderingEngine.java:1500)
at
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine
$StylingPreferencesHandler.resetOverriddenPreferences
(PartRenderingEngine.java:1470)
at
org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine
$StylingPreferencesHandler$1.handleEvent(PartRenderingEngine.java:1458)
at org.eclipse.swt.widgets.EventTable.sendEvent
(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent
(Display.java:4487)
at org.eclipse.swt.widgets.Display.sendEvent
(Display.java:4480)
at org.eclipse.swt.widgets.Display.release(Display.java:3488)
at org.eclipse.swt.graphics.Device.dispose(Device.java:249)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start
(IDEApplication.java:151)
at
org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication
(UITestApplication.java:31)
at
org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run
(AbstractUITestApplication.java:114)
at
org.eclipse.tycho.surefire.osgibooter.UITestApplication.start
(UITestApplication.java:37)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run
(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication
(EclipseAppLauncher.java:134)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start
(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:236)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework
(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)

and possibly a complaint about an invalid thread access (SWTException).

Has anyone else seen this?

Best wishes,

Andreas

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=436858

--
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Intalling with java 6 cannot recover

2014-06-05 Thread Thomas Watson


This sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=432485

But that should have been fixed in M7.  I am curious if launching with
-clean fixes the issue.  I would start with a bug against Equinox Framework
if it is what I suspect (somehow the framework is not forcing a refresh of
the system bundle to update its capabilities to include the Java 7
execution environment).

Tom





From:   Marc Khouzam marc.khou...@ericsson.com
To: 'cross-project-issues-dev@eclipse.org'
cross-project-issues-dev@eclipse.org
Cc: Alvaro Sanchez-Leon alvaro.sanchez-l...@ericsson.com
Date:   06/05/2014 12:05 PM
Subject:[cross-project-issues-dev] Intalling with java 6 cannot recover
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

I'm testing installing CDT on RC3.  CDT requires Java 7.
My system switched to java 6 under my feet, so I ended up installing CDT
using java 6.
The install worked but when running, most CDT plugins didn't start and I
got some errors due to java 6.
I then switched back to java 7 and ran the already installed version.
Surprisingly, things still failed but no errors reported.

So, it looks like installing plugins that require a newer java than what is
running is non-recoverable.

Is this a bug I should report? If so, to what component?

Thanks

Marc
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Intalling with java 6 cannot recover

2014-06-05 Thread Thomas Watson

I just tried and could not reproduce.  Installing CDT on Java 6,
re-launching and having a look at the osgi console showed the CDT bundles
as INSTALLED (not resolved).  Relaunching with Java 7 allowed the CDT
bundles to resolve.  I would double check that Java 7 is really being used.
Start with -console and issue the command:

props | grep environment

That should give you the following:

org.osgi.framework.executionenvironment =
OSGi/Minimum-1.0,OSGi/Minimum-1.1,OSGi/Minimum-1.2,JRE-1.1,J2SE-1.2,J2SE-1.3,J2SE-1.4,J2SE-1.5,JavaSE-1.6,JavaSE-1.7

Notice JavaSE-1.7 at the end.

Tom





From:   Marc Khouzam marc.khou...@ericsson.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org
Date:   06/05/2014 02:54 PM
Subject:Re: [cross-project-issues-dev] Intalling with java 6 cannot
recover
Sent by:cross-project-issues-dev-boun...@eclipse.org



Sadly I did launch with –clean and it didn’t help.

Since it should be fixed in M7, we’ll try to reproduce on another machine
to make sure it is not my environment.

From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas
Watson
Sent: Thursday, June 05, 2014 3:07 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Intalling with java 6 cannot
recover



This sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=432485

But that should have been fixed in M7.  I am curious if launching with
-clean fixes the issue.  I would start with a bug against Equinox Framework
if it is what I suspect (somehow the framework is not forcing a refresh of
the system bundle to update its capabilities to include the Java 7
execution environment).

Tom



Inactive hide details for Marc Khouzam ---06/05/2014 12:05:12 PM---Hi, I'm
testing installing CDT on RC3.  CDT requires Java 7.Marc Khouzam
---06/05/2014 12:05:12 PM---Hi, I'm testing installing CDT on RC3.  CDT
requires Java 7.

From: Marc Khouzam marc.khou...@ericsson.com
To: 'cross-project-issues-dev@eclipse.org' 
cross-project-issues-dev@eclipse.org
Cc: Alvaro Sanchez-Leon alvaro.sanchez-l...@ericsson.com
Date: 06/05/2014 12:05 PM
Subject: [cross-project-issues-dev] Intalling with java 6 cannot recover
Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi,

I'm testing installing CDT on RC3.  CDT requires Java 7.
My system switched to java 6 under my feet, so I ended up installing CDT
using java 6.
The install worked but when running, most CDT plugins didn't start and I
got some errors due to java 6.
I then switched back to java 7 and ran the already installed version.
Surprisingly, things still failed but no errors reported.

So, it looks like installing plugins that require a newer java than what is
running is non-recoverable.

Is this a bug I should report? If so, to what component?

Thanks

Marc
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Intalling with java 6 cannot recover

2014-06-05 Thread Thomas Watson

Yes, -clean does still do something.  If it actually fixes anything is
another topic.

It clears the osgi cache of installed bundles which then forces p2 to
re-install everything.  You can clearly see it doing something in this
scenario.  After you install CDT on top of RC3 and have a look at the osgi
console with the 'ss' or 'lb' command you will see a listing of the bundles
where the cdt bundles are the last bundles in the list (with the highest
bundle IDs) because they wre the last ones installed.  Then if you restart
with -clean and look at the bundle listing again you will see that the
bundles got re-installed in alphabetical order (since that is how p2 sorts
them in the bundles.info file).

Tom





From:   Doug Schaefer dschae...@qnx.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Date:   06/05/2014 02:57 PM
Subject:Re: [cross-project-issues-dev] Intalling with java 6 cannot
recover
Sent by:cross-project-issues-dev-boun...@eclipse.org



I think -clean is a placebo. It's our go to answer, but does it actually do
anything any more? It certainly never fixes anything any more.

Doug.


From: cross-project-issues-dev-boun...@eclipse.org
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc Khouzam
[marc.khou...@ericsson.com]
Sent: Thursday, June 05, 2014 3:53 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Intalling with java 6 cannot
recover

Sadly I did launch with –clean and it didn’t help.

Since it should be fixed in M7, we’ll try to reproduce on another machine
to make sure it is not my environment.

From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas
Watson
Sent: Thursday, June 05, 2014 3:07 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Intalling with java 6 cannot
recover

This sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=432485

But that should have been fixed in M7.  I am curious if launching with
-clean fixes the issue.  I would start with a bug against Equinox Framework
if it is what I suspect (somehow the framework is not forcing a refresh of
the system bundle to update its capabilities to include the Java 7
execution environment).

Tom



Inactive hide details for Marc Khouzam ---06/05/2014 12:05:12 PM---Hi, I'm
testing installing CDT on RC3.  CDT requires Java 7.Marc Khouzam
---06/05/2014 12:05:12 PM---Hi, I'm testing installing CDT on RC3.  CDT
requires Java 7.

From: Marc Khouzam marc.khou...@ericsson.com
To: 'cross-project-issues-dev@eclipse.org' 
cross-project-issues-dev@eclipse.org
Cc: Alvaro Sanchez-Leon alvaro.sanchez-l...@ericsson.com
Date: 06/05/2014 12:05 PM
Subject: [cross-project-issues-dev] Intalling with java 6 cannot recover
Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi,

I'm testing installing CDT on RC3.  CDT requires Java 7.
My system switched to java 6 under my feet, so I ended up installing CDT
using java 6.
The install worked but when running, most CDT plugins didn't start and I
got some errors due to java 6.
I then switched back to java 7 and ran the already installed version.
Surprisingly, things still failed but no errors reported.

So, it looks like installing plugins that require a newer java than what is
running is non-recoverable.

Is this a bug I should report? If so, to what component?

Thanks

Marc
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Equinox no longer supports interim headers/attributes in Luna

2013-12-16 Thread Thomas Watson



It has come to my attention that some bundles in eclipse appear to be using
interim headers and attributes that never made it into a final OSGi
specification.  For Luna the Equinox framework no longer supports these
interim headers [1].  This seemed like a relatively safe change since we
assumed all bundles at Eclipse have long since moved to real OSGi specified
headers if they were available.  I could simply add back support for the
interim headers into the Framework, but I fear this will just brush the
issue under the rug and result in Eclipse having many bundles that have
invalid bundle manifests from an OSGi specification perspective.  Besides I
would like to remove these eclipse-isms from the framework if possible.

Please test on Luna and verify your stuff is working.  If you use any of
the following in your bundle manifests it is likely stuff is not working as
expected:

 - Provide-Package header
 - singleton=true attribute on Bundle-SymbolicName header
 - reprovide=true attribute on Require-Bundle
 - optional=true attribute on Require-Bundle

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=424151___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Has Java 5 Platform support been discontinued?

2013-09-03 Thread Thomas Watson


Sorry for not communicating this aspect of the Equinox Framework changes in
Luna.  Obviously we need to spell out the VM requirements clearly for the
Equinox framework being included in Luna.  the NLS class is part of the
Equinox framework which has moved up to requiring Java 6.

Sorry for the inconvenience this may have caused.  I opened a bug in
Equinox to make sure this is clearly documented and allow others to voice
concerns over the move to Java 6 [1]

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=416432




From:   Ed Willink e...@willink.me.uk
To: Cross project issues cross-project-issues-dev@eclipse.org,
Date:   09/03/2013 07:34 AM
Subject:Re: [cross-project-issues-dev] Has Java 5 Platform  support
beendiscontinued?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi Szymon

Your list omits the 'culprit'.

It is org.eclipse.osgi.util.NLS that is now Java 6 putting paid to all
attempts at internationalization with Java 5.

 Regards

 Ed Willink

On 02/09/2013 16:41, Szymon Ptaszkiewicz wrote:
 See

http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#appendix
 for the table of  minimum EE per bundle.

 Szymon




 From:  David M Williams david_willi...@us.ibm.com
 To:Cross project issues cross-project-issues-dev@eclipse.org
 Date:  2013-09-02 17:34
 Subject:   Re: [cross-project-issues-dev] Has Java 5 Platform
support
  been  discontinued?
 Sent by:   cross-project-issues-dev-boun...@eclipse.org



 So it seems that the Platform no longer supports Java 5.
 Yes and no. As a whole, such for whole Eclipse SDK, even Kepler (If not
 Juno) said Java 6 required, although there were always some bundles
(and
 combination of bundles) that supported lower VMs.

 Is this intentional and an unannounced policy change?
 Probably not announced well. It has been discussed at status meetings,
and
 various bugzillas, that some previous 1.4 or 1.5 bundles were moving
to
 1.5 or 1.6, but I am not sure there is yet a comprehensive list of
 those that have. (Other than looking in the manifests themselves).

 I think it's been assumed no one cares about Java 1.5 any longer ...
so,
 if anyone does (i.e. you have requirements or customers with requirements
 for 1.5), then I suggest you open a bug on the specific use-case you need
 to support on 1.5 and what bundle changes prevent that. I'm sure the
 committers for those components would be willing to re-consider if it
 impacts adopters.

 But, the default assumption for testing should be 1.6 ... would be my
 personal advice.

 HTH





 From:Ed Willink e...@willink.me.uk
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:09/02/2013 11:02 AM
 Subject:[cross-project-issues-dev] Has Java 5 Platform support
been
 discontinued?
 Sent by:cross-project-issues-dev-boun...@eclipse.org



 Hi

 Using a recent (post M1) platform I-build some of my unit tests now fail
 with a NoClassDef found for Platform.

 Changing the launch configuration to force JVM 6 and the tests run fine.

 So it seems that the Platform no longer supports Java 5.

 Is this intentional and an unannounced policy change?

  Regards

  Ed Willink
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


 -
 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 2013.0.3392 / Virus Database: 3222/6630 - Release Date: 09/02/13



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

inline: graycol.gif___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] HEADS UP: many equinox internals have changed

2013-08-09 Thread Thomas Watson


I posted a note a couple of weeks back [1] about the changes coming to the
Equinox OSGi framework implementation for Luna.  If you have dependencies
on Equinox Framework internals and you have not tried to build against any
of the Eclipse/Equinox project M1 builds then you likely will have issues
building against the latest M1 Luna builds.

If any of the unnamed projects Konstantin mentions below have issues and
would like assistance please ask on the equinox-dev mailing list.

Tom

[1] -
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09424.html


- Forwarded by Thomas Watson/Austin/IBM on 08/09/2013 12:29 PM -

From:   Konstantin Komissarchik konstantin.komissarc...@oracle.com
To: 'Equinox development mailing list' equinox-...@eclipse.org,
Date:   08/09/2013 11:04 AM
Subject:Re: [equinox-dev]
org.eclipse.osgi.framework.debug.FrameworkDebugOptions
Sent by:equinox-dev-boun...@eclipse.org



Thanks for the follow-up, Thomas.

I think another reminder of Equinox changes might be in order on
cross-project. I notice that some Luna projects (not going to name the
guilty parties) with dependencies on Equinox internals have yet to try
building with Luna platform. I expect lots of surprised and angry reactions
in about a week.

Thanks,

- Konstantin


From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
Sent: Friday, August 09, 2013 8:53 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev]
org.eclipse.osgi.framework.debug.FrameworkDebugOptions



David's answer is correct.  Thanks David!

FrameworkDebugOptions is not API, the Equinox API (not OSGi API!) is
org.eclipse.osgi.service.debug.DebugOptions.  As David mentions, this is
intended to be consumed as an OSGi service and Equinox does not provide
static API to access it.  the Platform.getDebugOption method does provide
static access to the debug options service if that is what you would prefer
to use.  But I still recommend using the OSGi service directly instead of
using the old org.eclipse.core.runtime.Platform class, but that is because
I really dislike static APIs and I am used to using the OSGi service
registry for such things.

Tom



Inactive hide details for Konstantin Komissarchik ---08/06/2013 04:45:34
PM---Thanks, David.Konstantin Komissarchik ---08/06/2013 04:45:34
PM---Thanks, David.

From: Konstantin Komissarchik konstantin.komissarc...@oracle.com
To: 'Equinox development mailing list' equinox-...@eclipse.org,
Date: 08/06/2013 04:45 PM
Subject: Re: [equinox-dev]
org.eclipse.osgi.framework.debug.FrameworkDebugOptions
Sent by: equinox-dev-boun...@eclipse.org




Thanks, David.

I found that I can replace FrameworkDebugOptions.getDefault
().getBooleanOption(key) with Platform.getDebugOption(key).

- Konstantin

From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of David M Williams
Sent: Monday, August 05, 2013 11:03 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev]
org.eclipse.osgi.framework.debug.FrameworkDebugOptions

Tom (and the one or two others who might know) are not available this week
so ... just so that you do not feel ignored :)  I'll respond with the
tiny bit I know, and Tom can later address deeper if needed.

Short answer: I believe it is intended to be gone ... but I don't what to
recommend on how to transition.

The previous version, in package org.eclipse.osgi.framework.debug, was
marked as x-internal in MANIFEST.MF (meaning, was not API, even though
did not have internal in the package name).

There is a new version of FrameworkDebugOptions, now in a package with
'internal' in the name, org.eclipse.osgi.internal.debug, which, off
hand, ... from the most casual of skim reading ... appears to be intended
to be used more as a service, not by direct (non-API) reference.

Tom has been working hard re-implementing a large amount of Equinox
internals for some time (in anticipation of new specs) and while I didn't
see 'debug' mentioned explicitly, there is a lot written about the changes
at

http://wiki.eclipse.org/Equinox/Luna_Framework

and that wiki page in turn points to various specs and other specific bugs
which might help you migrate off the non-API class.

Hope this helps ... but if if not, ask again in a week or two and I'm sure
Tom can say more.

Thanks,






From:Konstantin Komissarchik konstantin.komissarc...@oracle.com

To:'Equinox development mailing list' equinox-...@eclipse.org,
Date:08/06/2013 12:47 AM
Subject:Re: [equinox-dev]
org.eclipse.osgi.framework.debug.FrameworkDebugOptions
Sent by:equinox-dev-boun...@eclipse.org




Does anyone have any thoughts on this issue? I am assuming that this is
result of recent refactoring. The package in question doesn’t have internal
in the name, but if the class is going away for good, could someone let me
know what the equivalent invocation should be?

Thanks

[cross-project-issues-dev] New Equinox Framework now included in the Equinox and Eclipse Integration builds

2013-07-18 Thread Thomas Watson



We are well into M1 now for Luna.  I thought I would take some time to
announce the efforts we have been making to improve the Equinox Core
Framework implementation for the Luna release.  As you may know from
previous posts I have made to the equinox-dev mailing list, we have been
working in a branch on significant re-factoring and in many cases rewriting
portions of the Equinox Framework.  Please see
http://wiki.eclipse.org/Equinox/Luna_Framework for more details.  The new
framework implementation has been in master since the I20130702-1230
integration build.

For most developers this change should not be noticed.  But, as documented
in the wiki above, there are 4 main areas of concern that the community
should be aware of:

1) The Framework no longer uses the old Equinox resolver API
org.eclipse.osgi.service.resolver internally to resolve bundles.
2) All Equinox Framework specific hook implementations are broken and will
need to migrate.  This impacts Virgo and ObjectTeams projects in
particular.
3) Removal of Old Style Plugin Support.  Compatibility fragment available
to add support back.
4) Removal of PlatformAdmin Service Implementation.  Compatibility fragment
available to add support back.

I actually expect 2) to cause the most heartache, but hopefully for a very
small set of developers that need to plug directly into the implementation
details of the Equinox framework.  For this group of develpers please do
not hesitate to direct questions to the equinox-dev mailing list for
assistance in migrating to the Luna release.

Please direct any questions or concerns you may have to the equinox-dev
mailing list.  Also, please give the new framework a try and open any bug
reports for issues you come across.

Thanks

Tom
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Libraty piggy-back CQs

2013-05-17 Thread Thomas Watson


Also using Import-Package allows for provider substitution.  You don't
really know who the provider of the package dependency is by looking at a
bundle manifest in isolation.

Tom





From:   Wayne Beaton wa...@eclipse.org
To: cross-project-issues-dev@eclipse.org,
Date:   05/17/2013 02:06 PM
Subject:Re: [cross-project-issues-dev] Libraty piggy-back CQs
Sent by:cross-project-issues-dev-boun...@eclipse.org



The issue is one of tracking who is using what third-party library.

Right now, the tools that I use to scan the downloads directory almost do a
good enough job to eliminate piggyback CQs altogether. Almost. The problem
is that the tool only detects libraries that are actually distributed by
the project. It works by file name alone. It fails to detect libraries that
are pulled in from Orbit, for example.

I think that the solution is to scan bundles for references to third-party
libraries, but I'll need some p2 magic to sort that out, I think. Bash just
isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for a
definitive list of dependencies (including bundle and package imports?)

Of course, this doesn't help us if a project isn't distributing OSGi
bundles...

Wayne

On 05/17/2013 02:35 PM, Ed Willink wrote:
  Hi

  Thanks; that's clear but is hardly sensible. I have a handful of PB
  CQs to raise and I suspect many other projects must do too.

  Since we are strongly encouarged to track the latest Orbit version,
  shouldn't there be an auto-PB CQ for any project that has a PB CQ for
  an Orbit library?

  Currently I see
  20 Guava 10.x PB CQs
  2 Guava 11.x PB CQs
  0 Guava 12.x PB CQs
  4 Guava 13.x PB CQs
  0 Guava 14.x PB CQs

  With M7 changing the preferred Guava release to 12 that makes for 20
  out of 20 projects in breach of IP policy.

  Regards

  Ed Willink




  On 17/05/2013 19:20, Wayne Beaton wrote:
I believe that the Contribution Questionnaire page in the wiki
[1] answers this. If it is unclear, either take a crack at
clarifying it yourself or let me know I can take another run at
it.

The short version is that you need CQ for any library that
project code uses directly. You do not require a CQ for any
library that is used indirectly via another Eclipse project. I
spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of a
library that project code uses.

It doesn't matter where project code comes from. If a tool like
Xtext generates project code (i.e. code that goes into your
source code repository, or dynamically-generated code that gets
distributed in compiled form) that uses a library, this is
considered a direct reference.

HTH,

Wayne

[1]

http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire


On 05/17/2013 02:31 AM, Ed Willink wrote:
  Hi Wayne

  Can you clarify the policy on library piggy-back CQs?

  For MDT/OCL we initially used Guava indirectly through
  Xtext and so might not need a PB CQ although we did raise
  one since Xtext auto-generates source code for us with
  direct calls to the Injector class. Subsequently we have
  some manually written code that exploits Guava too.

  Our PB CQ has not updated from version 10, although Guava
  in Orbit is charging along through 11, 12 with 14 on the
  horizon.

  Are we at fault through not raising more PB CQs? Do I
  misunderstand the policy? Is the policy inappropriate for
  major evolving libraries?

  Regards

  Ed Willink
  ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
  
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev






No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6332 - Release
Date: 05/17/13

Re: [cross-project-issues-dev] Some Juno participants have not signed up for Kepler

2013-01-09 Thread Thomas Watson


I know that jetty is NOT an oversight in case that is one your were
wondering about.

Tom





From:   Wayne Beaton wa...@eclipse.org
To: Cross project issues cross-project-issues-dev@eclipse.org,
Date:   01/08/2013 03:17 PM
Subject:[cross-project-issues-dev] Some Juno participants have not
signed  up for Kepler
Sent by:cross-project-issues-dev-boun...@eclipse.org



AFAICT, the following Juno participants  have not yet signed up to
participate in Kepler:

Virgo, Jetty, Xtend, Xtext, Modeling Workflow Engine, Orion, and Data Tools
Platform

I assume that at least some of these are oversights/errors. Can everybody
please take a look at the projects you care about?

Thanks,

Wayne
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
  2013___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
inline: graycol.gifinline: 1D484668.gif___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Layout and licenses

2012-06-06 Thread Thomas Watson


I don't know anything about why gemini.jpa or gef3d are getting added to
the repo, but this made me think about your question:

If these bundles are in the repository, shouldn't the owning projects be
Juno particpants?

I don't know the correct answer, but it strikes me as odd that we allow
non-eclipse third party dependencies to be added to the repo, but when it
comes to a dependency on another project's bundles we force the other
owning project to participate fully in the release.  What if the project
does not want to participate?  What if there is an IP acceptable
alternative (non-eclipse) project that could be used?  Would we prefer the
use of that non-eclipse third party technology over the eclipse one simple
because the owning eclipse project does not want to participate in the Juno
release?  It seems to me that such cases should be treated as any other
third party dependency and we should not force the owning project to
participate in the release.

Tom




   
  From:   Wayne Beaton wa...@eclipse.org 
   
  To: cross-project-issues-dev@eclipse.org,
   
  Date:   06/06/2012 08:17 AM  
   
  Subject:[cross-project-issues-dev] Layout and licenses   
   





Hey folks. I'm going through the layout and licenses reports today.

I've already opened a couple of bugs regarding missing about files and am
just starting into the licenses. These issues need to be addressed before
any reviews can be declared successful. Note that these are very basic
requirements that are independent of participation in the simultaneous
release. If you need help, please ask.

There a Gemini JPA bundle in the repository. I'm also seeing a GEF3D
bundle. Why? If these bundles are in the repository, shouldn't the owning
projects be Juno particpants? Or did I miss a memo?

org.eclipse.gemini.jpa_1.0.99.v20120225-1927.jar
org.eclipse.gef3d_0.8.1.v20120528-0244.jar

Who owns these bundles:

org.eclipse.rephraserengine.core_8.0.0.201205300709.jar
org.eclipse.rephraserengine.ui_8.0.0.201205300709.jar

(I'll guess tools.ptp.photran based on the version number).

Wayne
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

inline: graycol.gifinline: ecblank.gif___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Bugzilla down

2012-05-24 Thread Thomas Watson


Same for me.  Although DJ in Ottawa says he can access bugzilla, but e-mail
appears to be busted.  He has sent a mail to the webmaster.

Tom




   
  From:   Glyn Normington gnorming...@vmware.com 
   
  To: Cross Project cross-project-issues-dev@eclipse.org,
   
  Date:   05/24/2012 04:56 AM  
   
  Subject:[cross-project-issues-dev] Bugzilla down 
   





Eclipse bugzilla appears to be down.

Regards,
Glyn
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

inline: graycol.gifinline: ecblank.gif___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] API changes coming in OSGi - org.osgi.framework.resource renamed to org.osgi.resource

2012-02-22 Thread Thomas Watson


This should have little or no impact on projects outside of Equinox, but
thought I should mention this just in case.  If your project uses any of
the types introduced in the new package org.osgi.framework.resource then
please pay attention.

The org.osgi.framework.resource package was introduced in an early Juno
milestone.  The OSGi Alliance has decided that the package name needs to be
changed to org.osgi.resource.  For the most part all interfaces from the
org.osgi.framework.wiring package have moved.  It should be a simple
migration to the new package if you actually started using the
org.osgi.framework.resource package.  One exception is the class
org.osgi.framework.resource.ResourceConstants.  This class has been deleted
and the constants have now moved into either the
org.osgi.resource.Namespace class or into the package
org.osgi.framework.namespace.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=371997 for details and in
particular see commit
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=61b4c49d88895f2c7cc9760a8d74816f7206f7f4
 for the specific changes.

Thanks for your time.

Tom


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] projects with framework extension bundles beware of M5

2012-01-27 Thread Thomas Watson


Sorry for the late warning on this.  Any one that owns a framework
extension (a fragment of the org.eclipse.osgi bundle) pay close attention.
I hope this very small set of folks.

We had a bug opened late last night
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=369880) that prevents
framework extension bundles from resolving if they specify a
Bundle-RequiredExecutionEnvironment header.  Everyone should be specifying
the Bundle-RequiredExecutionEnvironment header and it is
recommended/required to participate in the release (e.g. Juno).  We were
not able to get this issue fixed for M5 because of some clarifications
needed in the R5 OSGi specification and it is really getting too late for
M5.

Unfortunately this means that anyone with framework extensions in Juno M5
will need to temporarily remove their Bundle-RequiredExecutionEnvironment
headers from their framework extension bundles until we can get this fixed
in M6.  Sorry for the inconvenience.

Tom


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Use of jsr14 and Java 7 javac

2012-01-23 Thread Thomas Watson


The Equinox Framework and a some of the other core services provided by the
Equinox project have long supported the J2ME Foundation profile.  As the
rest of the Java community moved on we spent a fair amount of time figuring
out how to continue our support of the J2ME profiles.  Even when OSGi added
generics to their APIs (and p2 as well) we still supported the J2SE 1.4
based J2ME Foundation 1.2 profile with the use of the jsr14 compile target.

Our use of jsr14 for some Equinox projects in order to use generics AND
continue support of J2SE 1.4 and J2ME Foundation 1.2 will cause problems
for folks compiling against our jars (which include APIs with generics)
using the Java 7 javac compiler.  I have opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=369145 to discuss not using
the jsr14 option anymore.  Please comment in that bug with your concerns or
comments.  The consequence is that the any Equinox component with generics
in the API will have a J2SE-1.5 minimum execution environment for the Juno
release.  This includes the core OSGi Equinox Framework implementation.

Tom
Tom


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Use of jsr14 and Java 7 javac

2012-01-23 Thread Thomas Watson

That is only for the components that use the jetty 8 based OSGi http
service implementation in equinox.  This includes the Eclipse Help (UA)
components.  Here we are talking about the Framework itself, something even
lower in the stack than the Servlet container Jesse ;-)

Tom




|
| From:  |
|
  
--|
  |Jesse McConnell jesse.mcconn...@gmail.com  
 |
  
--|
|
| To:|
|
  
--|
  |Cross project issues cross-project-issues-dev@eclipse.org, 
 |
  
--|
|
| Date:  |
|
  
--|
  |01/23/2012 08:59 AM  
 |
  
--|
|
| Subject:   |
|
  
--|
  |Re: [cross-project-issues-dev] Use of jsr14 and Java 7 javac 
 |
  
--|





If your using jetty 8 like planned with servlet 3.0, I thought you
were going to minimum version 1.6 since that is what is mandated by
the servlet 3.0 api...

or is that just for components using the http bits

jesse

--
jesse mcconnell
jesse.mcconn...@gmail.com



On Mon, Jan 23, 2012 at 08:35, Thomas Watson tjwat...@us.ibm.com wrote:

 The Equinox Framework and a some of the other core services provided by
the
 Equinox project have long supported the J2ME Foundation profile.  As the
 rest of the Java community moved on we spent a fair amount of time
figuring
 out how to continue our support of the J2ME profiles.  Even when OSGi
added
 generics to their APIs (and p2 as well) we still supported the J2SE 1.4
 based J2ME Foundation 1.2 profile with the use of the jsr14 compile
target.

 Our use of jsr14 for some Equinox projects in order to use generics AND
 continue support of J2SE 1.4 and J2ME Foundation 1.2 will cause problems
 for folks compiling against our jars (which include APIs with generics)
 using the Java 7 javac compiler.  I have opened
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=369145 to discuss not using
 the jsr14 option anymore.  Please comment in that bug with your concerns
or
 comments.  The consequence is that the any Equinox component with
generics
 in the API will have a J2SE-1.5 minimum execution environment for the
Juno
 release.  This includes the core OSGi Equinox Framework implementation.

 Tom
 Tom


 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

47 matches

Mail list logo