Re: [cross-project-issues-dev] Java 9 Readiness

[Ed Willink]

Hi

@Ed M: Thanks, your explanation about the licensing problems explians 
why the builds are unhelpful. I've added this to the Wiki.


@Michael: The Marketplace installation works wonderfully, but only once 
the Marketplace client is installed. I've added this to the Wiki.


@Dani: I've clarified my confusions in the wiki and added a new table 
for Orbit utility; ASM bombs on Java 9 classes.


Exercising OCL fairly successfully provides encouraging indications for 
EMF, UML2, Xtext. Do you want provisional entries for these projects?


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 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] Guava 15/21 warning

[Andreas Sewe]

Hi Ed,

> Great, you sound like an expert who has demonstrated a solution.
> 
> Can you contribute a wiki page on how you do it?

I'll try, although the PDE tooling isn't that great [1, 2]. IMHO, bnd is
far better at automatically identifying uses constraints (although you
can still cheat it by using reflection), but most Eclipse projects use
Tycho and manifest-first builds, so I guess that's what the Wiki page
should focus on.

FYI, if you don't mind (and the OCL Oomph setup is up-to-date) I may use
OCL as a running example.

> Can you identify what checks a SimRel report should do to detect
> projects that are doing it wrong?

I agree, reports would be great. I am not aware of any tooling for this,
though. The maven-bundle-plugin focuses on *generating* MANIFEST.MFs
with uses constraints rather than checking the uses constraints of
existing MANIFEST.MFs. Also, I don't think PDE has a tool that could
easily be turned in a manifest checker. :-(

Best wishes,

Andreas

[1] 
[2] 
[3] 

-- 
Codetrails GmbH
The knowledge transfer company

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

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Ed Willink]

Hi Andreas

Great, you sound like an expert who has demonstrated a solution.

Can you contribute a wiki page on how you do it?

Can you identify what checks a SimRel report should do to detect 
projects that are doing it wrong?


Regards

Ed Willink


On 14/03/2017 14:21, Andreas Sewe wrote:

Hi,


If you have a technical solution that allows multiple Guava versions to
co-exist, please add it to Bug 437107. My current understanding is that
"uses" directives may be a solution but that no demonstration has been
performed and so the requirements for tooling are at best guesses and of
course not yet implemented. It is unlikleyt that any project currently
complies with any potential "uses" solution.

not true. Code Recommenders has exported interfaces [1] which have Guava
classes in their public signature. However, Code Recommenders [2]
properly declares these uses constraints and has not seen a major
problem since we introduced this in 2013(!).

Yes, if consumers of the org.eclipse.recommenders.models API also want
to use Guava for other purpose, then they are restricted in their choice
of Guava versions by what org.eclipse.recommenders.models uses but
that's how OSGi works.

This is IMHO a small price to pay for generally being able to have two
versions of the same bundle in your runtime. No more "one classpath to
rule them all", which *might* work in the closely coordinated
simultaneous release (although based on [3] I doubt it), but certainly
not once third-party plug-ins come into play.

Best wishes,

Andreas

[1]

[2]

[3]




___
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




---
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 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] Guava 15/21 warning

[Ed Willink]

Hi Gunnar

I seem to be a piggy-in-the-middle on this. My projects (OCL and QVTd) 
consume Guava solely via Xtext and so I can delegate my Guava selection 
to Xtext. Not my problem. However I tend to be an early integrator and 
so when I see my consumers such as Papyrus suffering, sometimes in my 
code, I try to help. Unfortunately since this is an area where I have 
intuition but no significant expertise, I can only relay the problem and 
promote hypotheses as to what the root issue is. StackOverflow may well 
be where some good experts can be found and once a solution has been 
identified, Bug 437107 should be the vehicle for ensuring that the 
solution is adopted across the full SimRel. IMHO a SimRel 'aggregation' 
report should somehow fail if a conflicting Guava could cause a 
SimRel-only Eclipse user to have a Guava problem. From Luna, Mars, Neon 
we know a really simple workaround; just one agreed Guava.


(Today while trying Java 9 and M6, my code failed to build; 
Iterators.emptyIterator() was fine in Guava 15, deprecated in Guava 19, 
removed in Guava 21. A bit of investigation identified Mylyn as the 
'innovators' who had not announced their change. I started this thread 
to highlight the risk that the nightmare we had between Luna RC1 to RC3 
could recur. For Luna RC4, everyone tolerated Guava 15.)


Regards

Ed Willink


On 14/03/2017 14:37, Gunnar Wagenknecht wrote:

Ed,

I think a single global bug as well as cross-project is a bad place 
for discussing OSGi questions. We encourage our users not to open bugs 
for questions and be diligent and go the extra mile to do some 
research and reach out via forums. I believe as committers we should 
behave similar and also use such channels for questions and 
discussions to allow others participate and to lower the disruption 
for people relying on cross-project for announcements/project 
coordination. My apology if I get your intention wrong and you are not 
using cross-project as a general help channel for issues you have.


FWIW, I think your best bet right now is StackOverflow. There is a 
huge OSGi community there that can help answering your questions 
around uses constraint. If you feel there is a gap around tooling you 
could ask there as well what other people are using and/or suggest 
improvements to PDE (if you think there is a lack). I agree that uses 
constraint are almost impossible to get right manually. However, the 
PDE "Organize Manifest" wizard has a checkbox which works for 
straightforward cases.


-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org , http://guw.io/






On 14 Mar 2017, at 14:59, Ed Willink > wrote:


Hi Gunnar

There is no problem with Orbit, given the need to allow Guava to be a 
non-singleton.


If you have a technical solution that allows multiple Guava versions 
to co-exist, please add it to Bug 437107. My current understanding is 
that "uses" directives may be a solution but that no demonstration 
has been performed and so the requirements for tooling are at best 
guesses and of course not yet implemented. It is unlikleyt that any 
project currently complies with any potential "uses" solution.


IMHO Bug 437107 requires a solution, not a WONTFIX. Until we have a 
demonstrable solution with associated tooling, I feel we need to 
stick with the Luna 'solution'; all project's Guava dependency bounds 
include at least an agreed version and only that version is bundled, 
so only that version is used in practice.


Regards

Ed Willink





___
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




---
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 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] Neon.3 respin staging repo is complete

[Kaloyan Raev]

Hi Fred,

I did the following test:
1. Installed and started the existing Neon.3 PHP EPP (20170309).
2. Reproduced the problem.
3. Killed the IDE.
4. Started again the IDE.
5. Added the the Staging Neon p2 repo.
6. Updated from Check for Updates - only PDT features were suggested for 
update.

7. Restarted the IDE.
8. Cannot reproduce the problem anymore.

All looks good!

Kaloyan Raev| Zend Studio Team Lead
Rogue Wave Software, Inc.
Accelerating Great Code
*M* +359 887 648 663
www.roguewave.com  / kaloyan.r...@roguewave.com

On 03/14/2017 04:36 PM, Frederic Gurr wrote:

Hi,

The staging repo now includes the changes in PDT described here:
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14194.html

=> http://download.eclipse.org/staging/neon/

Please test thoroughly.

Regards,

Fred

___
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] Guava 15/21 warning

[Gunnar Wagenknecht]

Ed,

I think a single global bug as well as cross-project is a bad place for 
discussing OSGi questions. We encourage our users not to open bugs for 
questions and be diligent and go the extra mile to do some research and reach 
out via forums. I believe as committers we should behave similar and also use 
such channels for questions and discussions to allow others participate and to 
lower the disruption for people relying on cross-project for 
announcements/project coordination. My apology if I get your intention wrong 
and you are not using cross-project as a general help channel for issues you 
have.

FWIW, I think your best bet right now is StackOverflow. There is a huge OSGi 
community there that can help answering your questions around uses constraint. 
If you feel there is a gap around tooling you could ask there as well what 
other people are using and/or suggest improvements to PDE (if you think there 
is a lack). I agree that uses constraint are almost impossible to get right 
manually. However, the PDE "Organize Manifest" wizard has a checkbox which 
works for straightforward cases.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/






> On 14 Mar 2017, at 14:59, Ed Willink  wrote:
> 
> Hi Gunnar
> There is no problem with Orbit, given the need to allow Guava to be a 
> non-singleton.
> 
> If you have a technical solution that allows multiple Guava versions to 
> co-exist, please add it to Bug 437107. My current understanding is that 
> "uses" directives may be a solution but that no demonstration has been 
> performed and so the requirements for tooling are at best guesses and of 
> course not yet implemented. It is unlikleyt that any project currently 
> complies with any potential "uses" solution.
> IMHO Bug 437107 requires a solution, not a WONTFIX. Until we have a 
> demonstrable solution with associated tooling, I feel we need to stick with 
> the Luna 'solution'; all project's Guava dependency bounds include at least 
> an agreed version and only that version is bundled, so only that version is 
> used in practice.
> 
> Regards
> 
> Ed Willink

___
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] Neon.3 respin staging repo is complete

[Frederic Gurr]

Hi,

The staging repo now includes the changes in PDT described here:
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14194.html

=> http://download.eclipse.org/staging/neon/

Please test thoroughly.

Regards,

Fred

___
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] Guava 15/21 warning

[Andreas Sewe]

Hi,

> If you have a technical solution that allows multiple Guava versions to
> co-exist, please add it to Bug 437107. My current understanding is that
> "uses" directives may be a solution but that no demonstration has been
> performed and so the requirements for tooling are at best guesses and of
> course not yet implemented. It is unlikleyt that any project currently
> complies with any potential "uses" solution.

not true. Code Recommenders has exported interfaces [1] which have Guava
classes in their public signature. However, Code Recommenders [2]
properly declares these uses constraints and has not seen a major
problem since we introduced this in 2013(!).

Yes, if consumers of the org.eclipse.recommenders.models API also want
to use Guava for other purpose, then they are restricted in their choice
of Guava versions by what org.eclipse.recommenders.models uses but
that's how OSGi works.

This is IMHO a small price to pay for generally being able to have two
versions of the same bundle in your runtime. No more "one classpath to
rule them all", which *might* work in the closely coordinated
simultaneous release (although based on [3] I doubt it), but certainly
not once third-party plug-ins come into play.

Best wishes,

Andreas

[1]

[2]

[3]


-- 
Codetrails GmbH
The knowledge transfer company

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

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Severe regression in PDT Neon.3 RC4 - chance for a respin?

[Sravan K Lakkimsetti]

Hi,

 

Thanks Arthur for clarification

 

Thanks

Sravan

 

From: Arthur van Dorp [mailto:arthur.vand...@bsi-software.com] 
Sent: Tuesday, March 14, 2017 7:13 PM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - 
chance for a respin?

 

Hi,

 

The change is in 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/?h=Neon.3_respin.

 

Regards,

Arthur

 

Von: cross-project-issues-dev-boun...@eclipse.org 
  
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Sravan K 
Lakkimsetti
Gesendet: Dienstag, 14. März 2017 14:39
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - 
chance for a respin?

 

Hi,

I don't see any contribution here  

 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/?h=Neon_maintenance.
 Is this merged to simrel repo?

Thanks and Regards,
Sravan 

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858

Frederic Gurr ---14-03-2017 06:08:14 PM---Hi, Respin is in progress.

From: Frederic Gurr mailto:frederic.g...@eclipse.org> >
To: cross-project-issues-dev@eclipse.org 
 
Date: 14-03-17 06:08 PM
Subject: Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - 
chance for a respin?
Sent by: cross-project-issues-dev-boun...@eclipse.org 
 

  _  




Hi,

Respin is in progress.

Regards,

Fred

On 14.03.2017 10:53, Markus Knauer wrote:
> Any status updates and progress on this issue?
> 
> Thanks,
> Markus
> 
> On 13 March 2017 at 19:57, Kaloyan Raev   
> > wrote:
> 
> Thank you, Fred!
> 
> PDT 4.3 RC5 is released [1]
> I prepared the Gerrit patch for the Neon SimRel repo [2]. You still
> need to merge it.
> 
> [1] http://download.eclipse.org/tools/pdt/updates/4.3-rc5
> 
> [2] https://git.eclipse.org/r/#/c/92967/
> 
> 
> Kaloyan Raev| Zend Studio Team Lead
> Rogue Wave Software, Inc.
> Accelerating Great Code
> *M* +359 887 648 663
> www.roguewave.com    /
> kaloyan.r...@roguewave.com   
> 
> 
> On 03/13/2017 08:21 PM, Frederic Gurr wrote:
>> Hi Kaloyan,
>>
>> If this has not be done already, please revert the patch in PDT, release
>> a RC5 milestone and provide the new URL(s).
>>
>> I will respin the Neon staging P2 repo tomorrow morning.
>>
>> Regards,
>>
>> Fred
>>
>> On 10.03.2017 10:24, Kaloyan Raev wrote:
>>> Hi,
>>>
>>> While testing the PHP EPP Neon.3 RC4 we found a severe regression [1].
>>> While it does not affect the Simultaneous Release as a whole, it is
>>> something that would affect most of the PHP users.
>>>
>>> I know the simplest and risk free solution is PDT to have a maintenance
>>> release on the date of the Neon.3 release train. But, as the affected
>>> workflow is one that would be executed early after starting the IDE,
>>> most probably, the affected users would not notice that there is a
>>> maintenance update they need to apply. The effect of freezing the IDE
>>> would result in a very negative experience with the Eclipse IDE.
>>>
>>> For the above reasons, I'd like to ask what are our chances for
>>> respinning the Neon staging p2 repo?
>>>
>>> Technically speaking, we need to revert one patch in PDT and release a
>>> RC5 milestone. Then the Neon staging p2 repo needs to be respun and then
>>> the EPP packages.
>>>
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513432
>>> 
>>>
>>> -- 
>>> Kaloyan Raev| Zend Studio Team Lead
>>> Rogue Wave Software, Inc.
>>> Accelerating Great Code
>>> *M* +359 887 648 663
>>> www.roguewave.com   
>>>   
>>>  / kaloyan.r...@roguewave.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
>>> https://dev.eclips

Re: [cross-project-issues-dev] Guava 15/21 warning

[Ed Willink]

Hi Gunnar

There is no problem with Orbit, given the need to allow Guava to be a 
non-singleton.


If you have a technical solution that allows multiple Guava versions to 
co-exist, please add it to Bug 437107. My current understanding is that 
"uses" directives may be a solution but that no demonstration has been 
performed and so the requirements for tooling are at best guesses and of 
course not yet implemented. It is unlikleyt that any project currently 
complies with any potential "uses" solution.


IMHO Bug 437107 requires a solution, not a WONTFIX. Until we have a 
demonstrable solution with associated tooling, I feel we need to stick 
with the Luna 'solution'; all project's Guava dependency bounds include 
at least an agreed version and only that version is bundled, so only 
that version is used in practice.


Regards

Ed Willink


On 14/03/2017 13:45, Gunnar Wagenknecht wrote:
On 14 Mar 2017, at 14:34, Ed Willink > wrote:


Please read the Bugzillas. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107


Both bugs are assigned to nobody and in the Cross-Project component. 
I'm not sure who is responsible. However, it seems impossible to 
address them as there is no clear path to decide on. It looks like 
their main purpose is a sink for discussions. I'd suggest closing them 
as WONTFIX. It doesn't look like they'll ever be solved.


The problem never occurs for individual projects. It only occurs when 
an integrating project 'inherits' conflicting Guava loads from two 
distinct component projects with Guava in the APIs.


So Mylyn only is no problem, but something that integrates Mylyn and 
Xtext can encounter obscure failures when the wrong class is re-used 
on a code path in which both are used.




FWIW, there are technical solutions to allow projects to co-exist 
consuming different versions of Guava. Yes it is complicated and gets 
even more complicated when projects are re-exporting Guava as part of 
their APIs. But there are solutions that work.


If you believer there are specific problems with regards to the Guava 
libraries in Orbit please open a bug for Orbit with more details (eg., 
exceptions). We'll look at addressing them.


-Gunnar




___
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




---
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 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] Guava 15/21 warning

[Andreas Sewe]

Hi Ed,

> Please read the
> Bugzillas. https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107

Reading through Bug 427862 comment 8 ff. [1], it seems like OSGi's uses
constraints would solve your problem.

> The problem never occurs for individual projects. It only occurs when an
> integrating project 'inherits' conflicting Guava loads from two distinct
> component projects with Guava in the APIs.
> 
> So Mylyn only is no problem, but something that integrates Mylyn and
> Xtext can encounter obscure failures when the wrong class is re-used on
> a code path in which both are used.
I had a *brief* look at the Papyrus (RT) code and I think I know why you
continue to have problems with Guava:

1.) A bundle like org.eclipse.papyrusrt.umlrt.core requires
com.google.guava, but only provides a lower version bound [2]:

> Require-Bundle: com.google.guava;bundle-version="11.0.0"

This is dangerous, as Guava may change API in incompatible ways between
major versions (and has done so in the past).

2.) Your bundles export packages [3] whose classes have Guava classes in
their public API [4]:

> Export-Package: org.eclipse.papyrus.infra.core.resource

> Optional isReadOnly(...)

The above package should clearly have a uses constraints:

> Export-Package:
org.eclipse.papyrus.infra.core.resource;uses:="com.google.common.base"

Have a look at this article [5] that nicely explains "What is a Uses
Constraint Anyway".

Hope this helps,

Andreas

[1] 
[2]

[3]

[4]

[5] 

-- 
Codetrails GmbH
The knowledge transfer company

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

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Gunnar Wagenknecht]

> On 14 Mar 2017, at 14:34, Ed Willink  wrote:
> Please read the Bugzillas. 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862 
>  
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107 
> Both bugs are assigned 
> to nobody and in the Cross-Project component. I'm not sure who is 
> responsible. However, it seems impossible to address them as there is no 
> clear path to decide on. It looks like their main purpose is a sink for 
> discussions. I'd suggest closing them as WONTFIX. It doesn't look like 
> they'll ever be solved.

> The problem never occurs for individual projects. It only occurs when an 
> integrating project 'inherits' conflicting Guava loads from two distinct 
> component projects with Guava in the APIs.
> 
> So Mylyn only is no problem, but something that integrates Mylyn and Xtext 
> can encounter obscure failures when the wrong class is re-used on a code path 
> in which both are used.
> 

FWIW, there are technical solutions to allow projects to co-exist consuming 
different versions of Guava. Yes it is complicated and gets even more 
complicated when projects are re-exporting Guava as part of their APIs. But 
there are solutions that work.

If you believer there are specific problems with regards to the Guava libraries 
in Orbit please open a bug for Orbit with more details (eg., exceptions). We'll 
look at addressing them.

-Gunnar


___
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] Severe regression in PDT Neon.3 RC4 - chance for a respin?

[Arthur van Dorp]

Hi,

The change is in 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/?h=Neon.3_respin.

Regards,
Arthur

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Sravan K 
Lakkimsetti
Gesendet: Dienstag, 14. März 2017 14:39
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - 
chance for a respin?


Hi,

I don't see any contribution here 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/?h=Neon_maintenance.
 Is this merged to simrel repo?

Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858

[Inactive hide details for Frederic Gurr ---14-03-2017 06:08:14 PM---Hi, Respin 
is in progress.]Frederic Gurr ---14-03-2017 06:08:14 PM---Hi, Respin is in 
progress.

From: Frederic Gurr 
mailto:frederic.g...@eclipse.org>>
To: 
cross-project-issues-dev@eclipse.org
Date: 14-03-17 06:08 PM
Subject: Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - 
chance for a respin?
Sent by: 
cross-project-issues-dev-boun...@eclipse.org





Hi,

Respin is in progress.

Regards,

Fred

On 14.03.2017 10:53, Markus Knauer wrote:
> Any status updates and progress on this issue?
>
> Thanks,
> Markus
>
> On 13 March 2017 at 19:57, Kaloyan Raev mailto:kaloya...@zend.com%0b>> > wrote:
>
> Thank you, Fred!
>
> PDT 4.3 RC5 is released [1]
> I prepared the Gerrit patch for the Neon SimRel repo [2]. You still
> need to merge it.
>
> [1] http://download.eclipse.org/tools/pdt/updates/4.3-rc5
> 
> [2] https://git.eclipse.org/r/#/c/92967/
> 
>
> Kaloyan Raev| Zend Studio Team Lead
> Rogue Wave Software, Inc.
> Accelerating Great Code
> *M* +359 887 648 663
> www.roguewave.com  /
> kaloyan.r...@roguewave.com 
> 
>
> On 03/13/2017 08:21 PM, Frederic Gurr wrote:
>> Hi Kaloyan,
>>
>> If this has not be done already, please revert the patch in PDT, release
>> a RC5 milestone and provide the new URL(s).
>>
>> I will respin the Neon staging P2 repo tomorrow morning.
>>
>> Regards,
>>
>> Fred
>>
>> On 10.03.2017 10:24, Kaloyan Raev wrote:
>>> Hi,
>>>
>>> While testing the PHP EPP Neon.3 RC4 we found a severe regression [1].
>>> While it does not affect the Simultaneous Release as a whole, it is
>>> something that would affect most of the PHP users.
>>>
>>> I know the simplest and risk free solution is PDT to have a maintenance
>>> release on the date of the Neon.3 release train. But, as the affected
>>> workflow is one that would be executed early after starting the IDE,
>>> most probably, the affected users would not notice that there is a
>>> maintenance update they need to apply. The effect of freezing the IDE
>>> would result in a very negative experience with the Eclipse IDE.
>>>
>>> For the above reasons, I'd like to ask what are our chances for
>>> respinning the Neon staging p2 repo?
>>>
>>> Technically speaking, we need to revert one patch in PDT and release a
>>> RC5 milestone. Then the Neon staging p2 repo needs to be respun and then
>>> the EPP packages.
>>>
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513432
>>> 
>>>
>>> --
>>> Kaloyan Raev| Zend Studio Team Lead
>>> Rogue Wave Software, Inc.
>>> Accelerating Great Code
>>> *M* +359 887 648 663
>>> www.roguewave.com  
>>>   / 
>>> kaloyan.r...@roguewave.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
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> 
>>>
>> ___
>> cross-project-issues-dev mailing list
>> 
>> cross-project-issues-dev@eclipse.org
>> 

Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - chance for a respin?

[Sravan K Lakkimsetti]

Hi,

I don't see any contribution here
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/?h=Neon_maintenance
. Is this merged to simrel repo?

Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858



From:   Frederic Gurr 
To: cross-project-issues-dev@eclipse.org
Date:   14-03-17 06:08 PM
Subject:Re: [cross-project-issues-dev] Severe regression in PDT Neon.3
RC4 - chance for a respin?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

Respin is in progress.

Regards,

Fred

On 14.03.2017 10:53, Markus Knauer wrote:
> Any status updates and progress on this issue?
>
> Thanks,
> Markus
>
> On 13 March 2017 at 19:57, Kaloyan Raev  > wrote:
>
> Thank you, Fred!
>
> PDT 4.3 RC5 is released [1]
> I prepared the Gerrit patch for the Neon SimRel repo [2]. You still
> need to merge it.
>
> [1] http://download.eclipse.org/tools/pdt/updates/4.3-rc5
> 
> [2] https://git.eclipse.org/r/#/c/92967/
> 
>
> Kaloyan Raev| Zend Studio Team Lead
> Rogue Wave Software, Inc.
> Accelerating Great Code
> *M* +359 887 648 663
> www.roguewave.com  /
> kaloyan.r...@roguewave.com 
>
> On 03/13/2017 08:21 PM, Frederic Gurr wrote:
>> Hi Kaloyan,
>>
>> If this has not be done already, please revert the patch in PDT,
release
>> a RC5 milestone and provide the new URL(s).
>>
>> I will respin the Neon staging P2 repo tomorrow morning.
>>
>> Regards,
>>
>> Fred
>>
>> On 10.03.2017 10:24, Kaloyan Raev wrote:
>>> Hi,
>>>
>>> While testing the PHP EPP Neon.3 RC4 we found a severe regression
[1].
>>> While it does not affect the Simultaneous Release as a whole, it is
>>> something that would affect most of the PHP users.
>>>
>>> I know the simplest and risk free solution is PDT to have a
maintenance
>>> release on the date of the Neon.3 release train. But, as the
affected
>>> workflow is one that would be executed early after starting the
IDE,
>>> most probably, the affected users would not notice that there is a
>>> maintenance update they need to apply. The effect of freezing the
IDE
>>> would result in a very negative experience with the Eclipse IDE.
>>>
>>> For the above reasons, I'd like to ask what are our chances for
>>> respinning the Neon staging p2 repo?
>>>
>>> Technically speaking, we need to revert one patch in PDT and
release a
>>> RC5 milestone. Then the Neon staging p2 repo needs to be respun and
then
>>> the EPP packages.
>>>
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513432
>>> 
>>>
>>> --
>>> Kaloyan Raev| Zend Studio Team Lead
>>> Rogue Wave Software, Inc.
>>> Accelerating Great Code
>>> *M* +359 887 648 663
>>> www.roguewave.com  <
http://www.roguewave.com>  /
kaloyan.r...@roguewave.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
>>> 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
> 
>
>
>
>
>
> ___
> 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-issu

Re: [cross-project-issues-dev] Guava 15/21 warning

[Ed Willink]

Hi

Please read the Bugzillas. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107


The problem never occurs for individual projects. It only occurs when an 
integrating project 'inherits' conflicting Guava loads from two distinct 
component projects with Guava in the APIs.


So Mylyn only is no problem, but something that integrates Mylyn and 
Xtext can encounter obscure failures when the wrong class is re-used on 
a code path in which both are used.


Regards

Ed Willink

On 14/03/2017 13:08, Andreas Sewe wrote:

Hi Ed,


We have been using Guava 15 for some time.

The latest Mylyn snapshot (mylyn-3.22.0.v20170308-0427.zip) has moved to
Guava 21.

When we changed to Guava 15 for Luna, it was all rather painful:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862

can you please point me to a bug (or better yet, an individual comment
in a bug) that clearly lays out a problem that is *not* due to too lax
version constraints or missing uses directives on the bundle importing
Guava.

I've used the latest Mylyn build (using Guava 21) and Code Recommenders
(using Guava 15) without problems in the same Eclipse instance, so
whatever the problem you perceive is, it doesn't cause things to blow up
straight-away. Hence, I would appreciate a pointer to the evils that
Guava does (presumably using reflection). Thank you.

Best wishes.

Andreas



___
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




---
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 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] Guava 15/21 warning

[Andreas Sewe]

Hi Ed,

> We have been using Guava 15 for some time.
> 
> The latest Mylyn snapshot (mylyn-3.22.0.v20170308-0427.zip) has moved to
> Guava 21.
> 
> When we changed to Guava 15 for Luna, it was all rather painful:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862

can you please point me to a bug (or better yet, an individual comment
in a bug) that clearly lays out a problem that is *not* due to too lax
version constraints or missing uses directives on the bundle importing
Guava.

I've used the latest Mylyn build (using Guava 21) and Code Recommenders
(using Guava 15) without problems in the same Eclipse instance, so
whatever the problem you perceive is, it doesn't cause things to blow up
straight-away. Hence, I would appreciate a pointer to the evils that
Guava does (presumably using reflection). Thank you.

Best wishes.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Marc-André Laperle]

Hi,

I think it would be best if the move takes place for M7 as +0 and +1 projects 
already made their build for M6.


Regards,

Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Ed Willink 

Sent: Tuesday, March 14, 2017 8:57:26 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Guava 15/21 warning

Hi

We have been using Guava 15 for some time.

The latest Mylyn snapshot (mylyn-3.22.0.v20170308-0427.zip) has moved to
Guava 21.

When we changed to Guava 15 for Luna, it was all rather painful:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862

https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107 is open to identify
a policy for non-singleton plugins, but no resolution has been found.

We can probably avoid problems if we all move to Guava 21 for M7 and if
Mylyn refrains from contributing its change at M6.

 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 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] Guava 15/21 warning

[Ed Willink]

Hi

We have been using Guava 15 for some time.

The latest Mylyn snapshot (mylyn-3.22.0.v20170308-0427.zip) has moved to 
Guava 21.


When we changed to Guava 15 for Luna, it was all rather painful: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862


https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107 is open to identify 
a policy for non-singleton plugins, but no resolution has been found.


We can probably avoid problems if we all move to Guava 21 for M7 and if 
Mylyn refrains from contributing its change at M6.


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 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] Bugzilla and Gerrit are down again

[Denis Roy]

They were intermittently down.

wiki.eclipse.org is generating an abnormal amount of database write
traffic, which is affecting performance of surrounding databases.  We
are looking into it.

Denis


On 03/14/2017 04:30 AM, Gunnar Wagenknecht wrote:
> I can confirm the errors. Might be a bogus web node we are hitting.
>
> -Gunnar
>
> -- 
> Gunnar Wagenknecht
> gun...@wagenknecht.org , http://guw.io/
>
>
>
>
>
>
>> On 14 Mar 2017, at 09:29, Pierre-Charles David
>> mailto:pierre-charles.da...@obeo.fr>>
>> wrote:
>>
>> Le 14/03/2017 à 09:25, Pierre-Charles David a écrit :
>>> Both give the same kind of error messages than two days ago:
>>>
>>> * https://bugs.eclipse.org/bugs/:  Internal Server Error
>>> * https://git.eclipse.org/r/#/: 500 Internal server error
>>
>> They seem up again, sorry for the false alarm.
>>
>> ___
>> 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] Severe regression in PDT Neon.3 RC4 - chance for a respin?

[Frederic Gurr]

Hi,

Respin is in progress.

Regards,

Fred

On 14.03.2017 10:53, Markus Knauer wrote:
> Any status updates and progress on this issue?
> 
> Thanks,
> Markus
> 
> On 13 March 2017 at 19:57, Kaloyan Raev  > wrote:
> 
> Thank you, Fred!
> 
> PDT 4.3 RC5 is released [1]
> I prepared the Gerrit patch for the Neon SimRel repo [2]. You still
> need to merge it.
> 
> [1] http://download.eclipse.org/tools/pdt/updates/4.3-rc5
> 
> [2] https://git.eclipse.org/r/#/c/92967/
> 
> 
> Kaloyan Raev| Zend Studio Team Lead
> Rogue Wave Software, Inc.
> Accelerating Great Code
> *M* +359 887 648 663
> www.roguewave.com  /
> kaloyan.r...@roguewave.com 
> 
> On 03/13/2017 08:21 PM, Frederic Gurr wrote:
>> Hi Kaloyan,
>>
>> If this has not be done already, please revert the patch in PDT, release
>> a RC5 milestone and provide the new URL(s).
>>
>> I will respin the Neon staging P2 repo tomorrow morning.
>>
>> Regards,
>>
>> Fred
>>
>> On 10.03.2017 10:24, Kaloyan Raev wrote:
>>> Hi,
>>>
>>> While testing the PHP EPP Neon.3 RC4 we found a severe regression [1].
>>> While it does not affect the Simultaneous Release as a whole, it is
>>> something that would affect most of the PHP users.
>>>
>>> I know the simplest and risk free solution is PDT to have a maintenance
>>> release on the date of the Neon.3 release train. But, as the affected
>>> workflow is one that would be executed early after starting the IDE,
>>> most probably, the affected users would not notice that there is a
>>> maintenance update they need to apply. The effect of freezing the IDE
>>> would result in a very negative experience with the Eclipse IDE.
>>>
>>> For the above reasons, I'd like to ask what are our chances for
>>> respinning the Neon staging p2 repo?
>>>
>>> Technically speaking, we need to revert one patch in PDT and release a
>>> RC5 milestone. Then the Neon staging p2 repo needs to be respun and then
>>> the EPP packages.
>>>
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513432
>>> 
>>>
>>> -- 
>>> Kaloyan Raev| Zend Studio Team Lead
>>> Rogue Wave Software, Inc.
>>> Accelerating Great Code
>>> *M* +359 887 648 663
>>> www.roguewave.com   
>>>  / kaloyan.r...@roguewave.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
>>> 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
> 
> 
> 
> 
> 
> 
> ___
> 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] Java 9 Readiness

[Ed Merks]

Ed,

Comments below.


On 14.03.2017 10:20, Ed Willink wrote:


Hi

I'm sorry if my confusion appears as rudeness, but I really am confused.

Definitely it appears as if you're suggesting that Dani, and perhaps 
other platform developers, don't understand the tools they're developing.


The only testing I have ever done in Eclipse uses JUnit and JUnit 
cannot use Java 9 without "Java 9" name support.


So yes, you need to install Java 9 support to have a Java 9 JRE enabled 
in your workspace.


I have semi-successfuly followed the instructions to start up Eclipse 
using Java 9. (However adding a -vm to eclipse.ini seemed to give me 
both Java 8 and Java 9, so I had to use my usual short cut after 
setting JAVA_HOME globally.) Eclipse seems to work. My Xtext-based 
editor starts, very encouraging, but beyond that I need real tests.


This is why I provided a setup to try to make it dead simple compared to 
manual approached.


Trying to follow the marketplace instruction I just get "Unable to 
read repository at 
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593.
Unable to read repository at 
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593.
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593 
is not a valid repository location." Not surprising since the 
Marketplace never seems to work for me. I use ZIPs. Is there no ZIP 
for the Y-build?


I can't comment on Marketplace support.  It seems the long and hard way 
to accomplish the goal.  Given you have an OCL Oomph project setup, I'm 
not sure why you don't try what I suggested.


The earlier thread refers to a PDT Y-build. Googling I find 
http://download.eclipse.org/eclipse/downloads/drops4/Y20160922-1000/ 
advertised in September 2016. So, yes, I am really confused that 
passive support for Java 9 was not in at least M3. By passive support, 
I mean use the Java 9 VM only in ways that a Java 8 VM worked. In 
terms of Eclipse, from my limited knowledge, this surely just requires 
Java 9 to be specified as a Window->Preferences->Java->Installed JREs, 
and thereafter have Java 9 as a menu option wherever installed VMs are 
selectable (e.g JUnit launches, manifest BREEs.)


Java 9 uses *.jmod to package up the libraries into modules.  An older 
version of JDT can't handle those and so can't recognize this structure 
as a JRE/JDK.  That's what the new branch is developing.


The above Y-build no longer exists. Trying just the ...drops4 in a 
browser takes me to the platform downloads where I see no Y-builds.


The setup I sent around includes that location: 
http://download.eclipse.org/eclipse/updates/4.7-Y-builds


Since my expectation of Java 9 support seems to be so adrift of 
reality, I am clearly missing something. Why is there any question 
about what is in Oxygen?


I believe Mike suggested on the planning council mailing list that it's 
a legal licensing issue.


Surely Oxygen should have passive Java 9 support (potentially from M3).

It would be nice, but no, that's not the plan, and it's been suggested 
there are legal issues with releasing Java 9 support before Java 9 is 
released.


Perhaps even Neon.3 should have had passive Java 9 support.

What you're suggesting is infeasible.  The packaging structure of Java 9 
is so different that the old tooling can't support it without the 
changes that are currently being developed in the new tooling (and that 
apparently can't be released until Java 9 is released).


With Java GA being so close to Oxygen, it would seem sensible to 
include active Java 9 support in Oxygen too, but if the JDT developers 
need the extra month, or if a significant Java 9 change is too high a 
risk, then ok an Update 1 may be necessary.


Issues regarding when Java 9 support can be released and the Oxygen 
schedule and contents for that is a topic for the planning council that 
is currently under discussion.


I really am confused. The simple use of Java 9 as Java 8 today seems 
unreasonably hard. 

That's why I provided a configuration to simplify the whole process.


Regards

Ed Willink


On 14/03/2017 08:20, Ed Merks wrote:


Ed,

This just seems downright rude to me.  There's simply no need to be 
snarky.  I suspect you're not actually confused, you're just being 
deliberately obtuse to make a point.


Dani's team is providing the excellent environment that all the 
Eclipse project developers use.  I'm absolutely certain that Dani is 
not only very familiar with Eclipse's development environment, he is 
in fact using it for JDT development and moreover is providing it for 
all of us to use.  He has been involved in that effort since day 
one.  His team's latest effort is to provide world-class support for 
the latest features of Java 9 and he's been kind enough to provide 
guidance in the wiki.  It's a wiki.  If you see room for improvement, 
do so.  That's what I just did (though the wiki just went down, along 
with Bugzilla).


In an

Re: [cross-project-issues-dev] Severe regression in PDT Neon.3 RC4 - chance for a respin?

[Markus Knauer]

Any status updates and progress on this issue?

Thanks,
Markus

On 13 March 2017 at 19:57, Kaloyan Raev  wrote:

> Thank you, Fred!
>
> PDT 4.3 RC5 is released [1]
> I prepared the Gerrit patch for the Neon SimRel repo [2]. You still need
> to merge it.
>
> [1] http://download.eclipse.org/tools/pdt/updates/4.3-rc5
> [2] https://git.eclipse.org/r/#/c/92967/
>
> Kaloyan Raev | Zend Studio Team Lead
> Rogue Wave Software, Inc.
> Accelerating Great Code
> *M* +359 887 648 663
> www.roguewave.com / kaloyan.r...@roguewave.com
>
> On 03/13/2017 08:21 PM, Frederic Gurr wrote:
>
> Hi Kaloyan,
>
> If this has not be done already, please revert the patch in PDT, release
> a RC5 milestone and provide the new URL(s).
>
> I will respin the Neon staging P2 repo tomorrow morning.
>
> Regards,
>
> Fred
>
> On 10.03.2017 10:24, Kaloyan Raev wrote:
>
> Hi,
>
> While testing the PHP EPP Neon.3 RC4 we found a severe regression [1].
> While it does not affect the Simultaneous Release as a whole, it is
> something that would affect most of the PHP users.
>
> I know the simplest and risk free solution is PDT to have a maintenance
> release on the date of the Neon.3 release train. But, as the affected
> workflow is one that would be executed early after starting the IDE,
> most probably, the affected users would not notice that there is a
> maintenance update they need to apply. The effect of freezing the IDE
> would result in a very negative experience with the Eclipse IDE.
>
> For the above reasons, I'd like to ask what are our chances for
> respinning the Neon staging p2 repo?
>
> Technically speaking, we need to revert one patch in PDT and release a
> RC5 milestone. Then the Neon staging p2 repo needs to be respun and then
> the EPP packages.
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=513432
>
> --
> Kaloyan Raev| Zend Studio Team Lead
> Rogue Wave Software, Inc.
> Accelerating Great Code
> *M* +359 887 648 663www.roguewave.com  
>  / kaloyan.r...@roguewave.com
>
>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, 
> visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, 
> visithttps://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] Java 9 Readiness

[Mickael Istria]

On 03/14/2017 10:20 AM, Ed Willink wrote:


Trying to follow the marketplace instruction I just get "Unable to 
read repository at 
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593.
Unable to read repository at 
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593.
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593 
is not a valid repository location." Not surprising since the 
Marketplace never seems to work for me. I use ZIPs.



Click on those links and enjoy a nice surprise in your web browser.
--
Mickael Istria
Eclipse developer for Red Hat Developers 
My blog  - My Tweets 

___
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] Java 9 Readiness

[Daniel Megert]

> I'm not sure that installed Java 9 is usable by projects other than 
Platform - bug 469515 states this and 
https://hudson.eclipse.org/platform/job/Generate-jdeps-report-using-java-9/ 
uses location that doesn't look to be accessible by others,

Sorry for that. You are correct, see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=469515#c4. I've opened bug 
513618 requesting access for all release train projects. Until then, you 
can still build with Java 8 and run tests locally using Java 9.

Dani



From:   Evgeny Mandrikov 
To: Cross project issues 
Date:   13.03.2017 23:10
Subject:Re: [cross-project-issues-dev] Java 9 Readiness
Sent by:cross-project-issues-dev-boun...@eclipse.org



On Mon, Mar 13, 2017 at 9:32 PM Jonah Graham  
wrote:
Are there any examples of any project's HIPP config that does this? I 
assume I need to set up a tycho configuration that builds with Java 8 but 
runs tests with Java 9.

You can do this locally or on Hudson. A Java 9 VM is installed on Hudson (
bug 469515).
I'm not sure that installed Java 9 is usable by projects other than 
Platform - bug 469515 states this and 
https://hudson.eclipse.org/platform/job/Generate-jdeps-report-using-java-9/ 
uses location that doesn't look to be accessible by others, at least it 
didn't worked for me.

But principle is correct: create toolchains.xml pointing to Java 9 and 
instruct Tycho to use it ( 
https://eclipse.org/tycho/sitedocs/tycho-surefire/tycho-surefire-plugin/test-mojo.html#useJDK
 ) instead of the one that executes Maven. We are using this in Travis to 
run build with Java 8, but some tests with Java 7 -  see 
https://github.com/eclipse/eclemma/commit/37c744f2773f8914048149f776398a287e068ecb

HTH,
Evgeny
___
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] Java 9 Readiness

[Ed Willink]

Hi

I'm sorry if my confusion appears as rudeness, but I really am confused.

The only testing I have ever done in Eclipse uses JUnit and JUnit cannot 
use Java 9 without "Java 9" name support.


I have semi-successfuly followed the instructions to start up Eclipse 
using Java 9. (However adding a -vm to eclipse.ini seemed to give me 
both Java 8 and Java 9, so I had to use my usual short cut after setting 
JAVA_HOME globally.) Eclipse seems to work. My Xtext-based editor 
starts, very encouraging, but beyond that I need real tests.


Trying to follow the marketplace instruction I just get "Unable to read 
repository at 
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593.
Unable to read repository at 
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593.
http://marketplace.eclipse.org/marketplace-client-intro?mpc_install=2393593 
is not a valid repository location." Not surprising since the 
Marketplace never seems to work for me. I use ZIPs. Is there no ZIP for 
the Y-build?


The earlier thread refers to a PDT Y-build. Googling I find 
http://download.eclipse.org/eclipse/downloads/drops4/Y20160922-1000/ 
advertised in September 2016. So, yes, I am really confused that passive 
support for Java 9 was not in at least M3. By passive support, I mean 
use the Java 9 VM only in ways that a Java 8 VM worked. In terms of 
Eclipse, from my limited knowledge, this surely just requires Java 9 to 
be specified as a Window->Preferences->Java->Installed JREs, and 
thereafter have Java 9 as a menu option wherever installed VMs are 
selectable (e.g JUnit launches, manifest BREEs.)


The above Y-build no longer exists. Trying just the ...drops4 in a 
browser takes me to the platform downloads where I see no Y-builds.


Since my expectation of Java 9 support seems to be so adrift of reality, 
I am clearly missing something. Why is there any question about what is 
in Oxygen? Surely Oxygen should have passive Java 9 support (potentially 
from M3). Perhaps even Neon.3 should have had passive Java 9 support. 
With Java GA being so close to Oxygen, it would seem sensible to include 
active Java 9 support in Oxygen too, but if the JDT developers need the 
extra month, or if a significant Java 9 change is too high a risk, then 
ok an Update 1 may be necessary.


I really am confused. The simple use of Java 9 as Java 8 today seems 
unreasonably hard.


Regards

Ed Willink


On 14/03/2017 08:20, Ed Merks wrote:


Ed,

This just seems downright rude to me.  There's simply no need to be 
snarky.  I suspect you're not actually confused, you're just being 
deliberately obtuse to make a point.


Dani's team is providing the excellent environment that all the 
Eclipse project developers use.  I'm absolutely certain that Dani is 
not only very familiar with Eclipse's development environment, he is 
in fact using it for JDT development and moreover is providing it for 
all of us to use.  He has been involved in that effort since day one.  
His team's latest effort is to provide world-class support for the 
latest features of Java 9 and he's been kind enough to provide 
guidance in the wiki.  It's a wiki.  If you see room for improvement, 
do so. That's what I just did (though the wiki just went down, along 
with Bugzilla).


In any case, please don't insult Dani (or platform developers) with 
obtuse suspicions.


Regards,
Ed

On 14.03.2017 08:13, Ed Willink wrote:


Hi Dani

I suspect that as a platform developer, you are not familiar with the 
nice environment that Eclipse provides for project developers.


I recognize two ways of running my tests.

a) as standalone JUnit tests

b) as Plugin JUnit tests

Both require the launch config to specify/re-use the invoking Eclipse 
JVM. So no Java 9 in Eclipse => no testing.


Regards

Ed Willink

On 13/03/2017 20:06, Daniel Megert wrote:

Hi Ed

It depends whether you want to run the tests from the command line 
or out of the IDE. From the command line you only need a Java 9 VM 
(e.g. the one installed on Hudson). From the IDE you need to install 
the Java 9 support as indicated in 'Running Eclipse with Java 9 
Support (BETA)'.


Dani



From: Ed Willink 
To: cross-project-issues-dev@eclipse.org
Date: 13.03.2017 20:40
Subject: Re: [cross-project-issues-dev] Java 9 Readiness
Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi

I'm confused again.

You previously replied that it was necessary to install a special 
JDT so that a Java 9 JDK was available within Eclipse. I see no 
mention of this in the wiki. Without doing this how can tests be run 
using Java 9?


Regards

Ed Willink


On 13/03/2017 19:05, Daniel Megert wrote:
I assume many of you already heard that Java 9 is _scheduled for GA 
on July 27, 2017_ . The 
Planning Council did not yet decided how we will ship the Java 9 
support for

Re: [cross-project-issues-dev] Java 9 Readiness

[Daniel Megert]

In the platform we run jdeps with every build, using the script mentioned 
in the wiki. jdeps is included in Java 8 already.

Dani



From:   Tom Schindl 
To: cross-project-issues-dev@eclipse.org
Date:   13.03.2017 21:09
Subject:Re: [cross-project-issues-dev] Java 9 Readiness
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

Is there a chance that we get maven-tycho snapshots who use the java9
branch of jdt? This would help us to find problems when new code is
added who violates eg module-access rules.

Tom

On 13.03.17 21:06, Daniel Megert wrote:
> Hi Ed
> 
> It depends whether you want to run the tests from the command line or
> out of the IDE. From the command line you only need a Java 9 VM (e.g.
> the one installed on Hudson). From the IDE you need to install the Java
> 9 support as indicated in 'Running Eclipse with Java 9 Support (BETA)'.
> 
> Dani
> 
> 
> 
> From:Ed Willink 
> To:cross-project-issues-dev@eclipse.org
> Date:13.03.2017 20:40
> Subject:Re: [cross-project-issues-dev] Java 9 Readiness
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> 
> Hi
> 
> I'm confused again.
> 
> You previously replied that it was necessary to install a special JDT so
> that a Java 9 JDK was available within Eclipse. I see no mention of this
> in the wiki. Without doing this how can tests be run using Java 9?
> 
> Regards
> 
> Ed Willink
> 
> 
> On 13/03/2017 19:05, Daniel Megert wrote:
> I assume many of you already heard that Java 9 is _scheduled for GA on
> July 27, 2017_ . The Planning
> Council did not yet decided how we will ship the Java 9 support for
> Eclipse but requires all release train projects to assess their
> readiness regarding Java 9. We have created the following wiki page to
> capture this: _https://wiki.eclipse.org/Java_9_Readiness_. That wiki
> page also explains how you can check your project and how you can launch
> Eclipse with a Java 9 VM.
> 
> Dani
> 
> 
> 
> ___
> 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_
> 
> 
> 
> 
>   This email has been 
checked for
> viruses by Avast antivirus software. _
> __www.avast.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
> 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
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
___
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] Java 9 Readiness

[Sievers, Jan]

you should be able to override which version of org.eclipse.jdt.core is used by 
tycho-compiler-plugin as long as it's available from a public maven repo. (i.e. 
no need to switch to a SNAPSHOT version of Tycho)

See e.g.

https://github.com/eclipse/eclipse.platform.releng.aggregator/blob/7589b0b199c0d5cddb0232bbec49085aab9bff57/eclipse-platform-parent/pom.xml#L418

Maybe repo.eclipse.org already provides the java9 branch binaries of JDT?

Regards,
Jan

On 13/03/2017, 21:09, "cross-project-issues-dev-boun...@eclipse.org on behalf 
of Tom Schindl"  wrote:

Hi,

Is there a chance that we get maven-tycho snapshots who use the java9
branch of jdt? This would help us to find problems when new code is
added who violates eg module-access rules.

Tom

On 13.03.17 21:06, Daniel Megert wrote:
> Hi Ed
> 
> It depends whether you want to run the tests from the command line or
> out of the IDE. From the command line you only need a Java 9 VM (e.g.
> the one installed on Hudson). From the IDE you need to install the Java
> 9 support as indicated in 'Running Eclipse with Java 9 Support (BETA)'.
> 
> Dani
> 
> 
> 
> From:Ed Willink 
> To:cross-project-issues-dev@eclipse.org
> Date:13.03.2017 20:40
> Subject:Re: [cross-project-issues-dev] Java 9 Readiness
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> 
> Hi
> 
> I'm confused again.
> 
> You previously replied that it was necessary to install a special JDT so
> that a Java 9 JDK was available within Eclipse. I see no mention of this
> in the wiki. Without doing this how can tests be run using Java 9?
> 
> Regards
> 
> Ed Willink
> 
> 
> On 13/03/2017 19:05, Daniel Megert wrote:
> I assume many of you already heard that Java 9 is _scheduled for GA on
> July 27, 2017_ . The Planning
> Council did not yet decided how we will ship the Java 9 support for
> Eclipse but requires all release train projects to assess their
> readiness regarding Java 9. We have created the following wiki page to
> capture this: _https://wiki.eclipse.org/Java_9_Readiness_. That wiki
> page also explains how you can check your project and how you can launch
> Eclipse with a Java 9 VM.
> 
> Dani
> 
> 
> 
> ___
> 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_
> 
> 
> 
> 
>  This email has been checked for
> viruses by Avast antivirus software. _
> __www.avast.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
> 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
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
___
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] Java 9 Readiness

[Mickael Istria]

I suspect that as a platform developer, you are not familiar with the 
nice environment that Eclipse provides for project developers.


Please spend some efforts trying to read and understand properly the 
answers, and ask more explanations if necessary before suspecting anyone 
for not being familiar with the technology they've built.


I recognize two ways of running my tests.
a) as standalone JUnit tests
b) as Plugin JUnit tests
Both require the launch config to specify/re-use the invoking Eclipse 
JVM. So no Java 9 in Eclipse => no testing.


Those 2 ways are in the category properly named by Dani "testing from 
the IDE". As you understood, they do require the JDT's Java 9 support to 
work.


What you're missing to recognize are the other JDT-independent ways to 
run/test a plugin. For example starting directly an Eclipse Platform 
which hosts your plugins, or orchestrating tests from the command-line 
(once again properly described by Dani in his email). In case your 
project has no dependency on JDT, then simply running it as a separate 
process which uses Java 9 should be enough.


HTH
--
Mickael Istria
Eclipse developer for Red Hat Developers 
My blog  - My Tweets 

___
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] Bugzilla and Gerrit are down again

[Gunnar Wagenknecht]

I can confirm the errors. Might be a bogus web node we are hitting.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/






> On 14 Mar 2017, at 09:29, Pierre-Charles David  
> wrote:
> 
> Le 14/03/2017 à 09:25, Pierre-Charles David a écrit :
>> Both give the same kind of error messages than two days ago:
>> 
>> * https://bugs.eclipse.org/bugs/:  Internal Server Error
>> * https://git.eclipse.org/r/#/: 500 Internal server error
> 
> They seem up again, sorry for the false alarm.
> 
> ___
> 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] Bugzilla and Gerrit are down again

[Remi Schnekenburger]

Hi Pierre-Charles,

Both links are working for me.

Cheers,
Rémi

2017-03-14 9:25 GMT+01:00 Pierre-Charles David :

> Both give the same kind of error messages than two days ago:
>
> * https://bugs.eclipse.org/bugs/:  Internal Server Error
> * https://git.eclipse.org/r/#/: 500 Internal server error
>
>
> Regards,
> Pierre-Charles David (Obeo)
>
> ___
> 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
>



-- 
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenbur...@eclipsesource.com
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 08 65
German Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19
Hangouts: rschnekenbur...@eclipsesource.com

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY
___
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] Bugzilla and Gerrit are down again

[Pierre-Charles David]

Le 14/03/2017 à 09:25, Pierre-Charles David a écrit :

Both give the same kind of error messages than two days ago:

* https://bugs.eclipse.org/bugs/:  Internal Server Error
* https://git.eclipse.org/r/#/: 500 Internal server error


They seem up again, sorry for the false alarm.

___
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] Bugzilla and Gerrit are down again

[Pierre-Charles David]

Both give the same kind of error messages than two days ago:

* https://bugs.eclipse.org/bugs/:  Internal Server Error
* https://git.eclipse.org/r/#/: 500 Internal server error


Regards,
Pierre-Charles David (Obeo)

___
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] Java 9 Readiness

[Mickael Istria]

On 03/13/2017 09:09 PM, Tom Schindl wrote:

Hi,

Is there a chance that we get maven-tycho snapshots who use the java9
branch of jdt? This would help us to find problems when new code is
added who violates eg module-access rules.
There's a dedicated mailing-list you where you could ask this: 
tycho-u...@eclipse.org ;)

--
Mickael Istria
Eclipse developer for Red Hat Developers 
My blog  - My Tweets 

___
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] Java 9 Readiness

[Ed Merks]

Ed,

This just seems downright rude to me.  There's simply no need to be 
snarky.  I suspect you're not actually confused, you're just being 
deliberately obtuse to make a point.


Dani's team is providing the excellent environment that all the Eclipse 
project developers use.  I'm absolutely certain that Dani is not only 
very familiar with Eclipse's development environment, he is in fact 
using it for JDT development and moreover is providing it for all of us 
to use.  He has been involved in that effort since day one.  His team's 
latest effort is to provide world-class support for the latest features 
of Java 9 and he's been kind enough to provide guidance in the wiki.  
It's a wiki. If you see room for improvement, do so.  That's what I just 
did (though the wiki just went down, along with Bugzilla).


In any case, please don't insult Dani (or platform developers) with 
obtuse suspicions.


Regards,
Ed

On 14.03.2017 08:13, Ed Willink wrote:


Hi Dani

I suspect that as a platform developer, you are not familiar with the 
nice environment that Eclipse provides for project developers.


I recognize two ways of running my tests.

a) as standalone JUnit tests

b) as Plugin JUnit tests

Both require the launch config to specify/re-use the invoking Eclipse 
JVM. So no Java 9 in Eclipse => no testing.


Regards

Ed Willink

On 13/03/2017 20:06, Daniel Megert wrote:

Hi Ed

It depends whether you want to run the tests from the command line or 
out of the IDE. From the command line you only need a Java 9 VM (e.g. 
the one installed on Hudson). From the IDE you need to install the 
Java 9 support as indicated in 'Running Eclipse with Java 9 Support 
(BETA)'.


Dani



From: Ed Willink 
To: cross-project-issues-dev@eclipse.org
Date: 13.03.2017 20:40
Subject: Re: [cross-project-issues-dev] Java 9 Readiness
Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi

I'm confused again.

You previously replied that it was necessary to install a special JDT 
so that a Java 9 JDK was available within Eclipse. I see no mention 
of this in the wiki. Without doing this how can tests be run using 
Java 9?


Regards

Ed Willink


On 13/03/2017 19:05, Daniel Megert wrote:
I assume many of you already heard that Java 9 is _scheduled for GA 
on July 27, 2017_ . The 
Planning Council did not yet decided how we will ship the Java 9 
support for Eclipse but requires all release train projects to assess 
their readiness regarding Java 9. We have created the following wiki 
page to capture this: _https://wiki.eclipse.org/Java_9_Readiness_. 
That wiki page also explains how you can check your project and how 
you can launch Eclipse with a Java 9 VM.


Dani



___
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_





This email has been checked for viruses by Avast antivirus software. _
__www.avast.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

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





Avast logo   

This email has been checked for viruses by Avast antivirus software.
www.avast.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
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] Works-with CQs with the new PMI

[Jens Reimann]

Thanks Roland,

I know the process from before the PMI update ...

So with the new PMI I have to lie and state that I do want to distribute
sources/binaries ... although I don't?!

That seemed wrong to me. But if that is the current process, then alright.
I just thought I overlooked something.

Cheers

Jens



On Mon, Mar 13, 2017 at 6:37 PM, Roland Grunberg 
wrote:

> On Mon, 2017-03-13 at 17:43 +0100, Jens Reimann wrote:
> > Now this sounds like a noob question ...
> >
> > ... but how do I create works-with CQs with the new PMI workflow?
> >
> > It seems only possible to create a normal 3rd party dependency CQ. I
> > don't see any more the option for a works-with/per-requisite
> > dependency.
>
> I went through this process a while back with 'vagrant', and 'docker-
> machine'. As far as I understand, you file them as regular CQs but
> state explicitly that this is a works-with/pre-requisite CQ. Then start
> a discussion on tools-pmc where some basic questions about the request
> may be asked (eg. how does the plugin handle absence of library, is the
> library likely to be found on a user's system, etc.)
>
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10263
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10209
>
>
> Cheers,
> --
> Roland Grunberg
> ___
> 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
>



-- 
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
___
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] Java 9 Readiness

[Ed Willink]

Hi Dani

I suspect that as a platform developer, you are not familiar with the 
nice environment that Eclipse provides for project developers.


I recognize two ways of running my tests.

a) as standalone JUnit tests

b) as Plugin JUnit tests

Both require the launch config to specify/re-use the invoking Eclipse 
JVM. So no Java 9 in Eclipse => no testing.


Regards

Ed Willink

On 13/03/2017 20:06, Daniel Megert wrote:

Hi Ed

It depends whether you want to run the tests from the command line or 
out of the IDE. From the command line you only need a Java 9 VM (e.g. 
the one installed on Hudson). From the IDE you need to install the 
Java 9 support as indicated in 'Running Eclipse with Java 9 Support 
(BETA)'.


Dani



From: Ed Willink 
To: cross-project-issues-dev@eclipse.org
Date: 13.03.2017 20:40
Subject: Re: [cross-project-issues-dev] Java 9 Readiness
Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi

I'm confused again.

You previously replied that it was necessary to install a special JDT 
so that a Java 9 JDK was available within Eclipse. I see no mention of 
this in the wiki. Without doing this how can tests be run using Java 9?


Regards

Ed Willink


On 13/03/2017 19:05, Daniel Megert wrote:
I assume many of you already heard that Java 9 is _scheduled for GA on 
July 27, 2017_ . The Planning 
Council did not yet decided how we will ship the Java 9 support for 
Eclipse but requires all release train projects to assess their 
readiness regarding Java 9. We have created the following wiki page to 
capture this: _https://wiki.eclipse.org/Java_9_Readiness_. That wiki 
page also explains how you can check your project and how you can 
launch Eclipse with a Java 9 VM.


Dani



___
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_





This email has been checked for viruses by Avast antivirus software. _
__www.avast.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

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




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