Re: [cross-project-issues-dev] simrel builds timing out

2017-05-25 Thread Marc-André Laperle
Thanks Frederic!


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Frederic Gurr 

Sent: Thursday, May 25, 2017 7:30:23 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] simrel builds timing out

Hi,

I have increased the timeout to 10 minutes. I also added the
ManualTrigger permission for SimRel committers (not sure if that helps
though).

Regards,

Fred

On 25.05.2017 04:20, Marc-André Laperle wrote:
> Hi Patrick,
>
>
> The build managed to pass and I submitted the change. It would still be
> good if re-triggering could be enabled and the timeout a bit longer.
>
>
> Marc-André
>
> 
> *From:* cross-project-issues-dev-boun...@eclipse.org
>  on behalf of Patrick
> Tasse 
> *Sent:* Wednesday, May 24, 2017 5:40:30 PM
> *To:* cross-project-issues-dev@eclipse.org
> *Subject:* Re: [cross-project-issues-dev] simrel builds timing out
>
> Hi,
>
> I forgot to mention, once this build issue is fixed, please retrigger
> the build for the SWTBot contribution for Oxygen RC1, and merge it when
> successful:
>
> https://git.eclipse.org/r/97923
>
> Also, please consider giving simrel committers permission to retrigger
> builds.
>
> Thank you,
> Patrick
>
>
> On Wed, May 24, 2017 at 4:00 PM, Patrick Tasse  <mailto:patrick.ta...@gmail.com>> wrote:
>
> Hi,
>
> The following jobs seem to be running a little slower than usual,
> but the jobs are configured to time out after only 3 minutes. This
> causes the builds to be aborted.
>
> 
> https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE.gerrit/buildTimeTrend
> 
> <https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE.gerrit/buildTimeTrend>
>
> 
> https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE/buildTimeTrend
> 
> <https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE/buildTimeTrend>
>
>
>
>
> ___
> 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] simrel builds timing out

2017-05-24 Thread Marc-André Laperle
Hi Patrick,


The build managed to pass and I submitted the change. It would still be good if 
re-triggering could be enabled and the timeout a bit longer.


Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Patrick Tasse 

Sent: Wednesday, May 24, 2017 5:40:30 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] simrel builds timing out

Hi,

I forgot to mention, once this build issue is fixed, please retrigger the build 
for the SWTBot contribution for Oxygen RC1, and merge it when successful:

https://git.eclipse.org/r/97923

Also, please consider giving simrel committers permission to retrigger builds.

Thank you,
Patrick


On Wed, May 24, 2017 at 4:00 PM, Patrick Tasse 
mailto:patrick.ta...@gmail.com>> wrote:
Hi,

The following jobs seem to be running a little slower than usual, but the jobs 
are configured to time out after only 3 minutes. This causes the builds to be 
aborted.

https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE.gerrit/buildTimeTrend

https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE/buildTimeTrend


___
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

2017-03-31 Thread Marc-André Laperle
Sorry, I lost track of the thread a bit. What's the conclusion? Should projects 
continue using 15.0.0 or upgrade to a more recent one?


Thank you,

Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Andreas Sewe 

Sent: Tuesday, March 14, 2017 11:55:26 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Guava 15/21 warning

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

___
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

2017-03-14 Thread 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

Re: [cross-project-issues-dev] https://hudson.eclipse.org/cdt is down for ~40 minutes

2017-02-10 Thread Marc-André Laperle
The HIPP is being moved, I believe.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=511989#c1


Not sure how long it usually takes.


Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Marc Dumais 

Sent: Friday, February 10, 2017 10:40:44 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] https://hudson.eclipse.org/cdt is down for 
~40 minutes


Hi!


"This HIPP instance is currently unavailable. It may be turned off, or it may 
be unresponsive. Members of the project can restart this service using the HIPP 
Control tools in their Eclipse Foundation 
account (login required)."


Can we expect it to be back up soon?


Thanks,


Marc
___
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] Attention hipp3 users!!!

2017-01-24 Thread Marc-André Laperle
Just to be clear, by RCPTT, I mean, the RCPTT dependencies that are being 
downloaded as part of the Trace Compass builds, not the RCPTT builds themselves.


Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Marc-André Laperle
Sent: Tuesday, January 24, 2017 3:26:19 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Attention hipp3 users!!!


I wiped out a few workspaces for genie.tracecompass. I also noticed that RCPTT 
is using *a lot* of disk space in the maven repo, 13GB/workspace because it 
downloads a new snapshot every day (or more!). I added in the shell script to 
delete this folder every build so that the workspace will only contain one copy 
of the snapshot.


Hopefully this helps!


Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Denis Roy 

Sent: Tuesday, January 24, 2017 1:52:09 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Attention hipp3 users!!!

Greetings folks,


We're running into disk usage issues on hipp3. We don't have a formal
quota system, so we're relying on you (our beloved reasonable
committers) to please keep disk space in check.


Can the projects below clear out unnecessary builds and workspaces so
that there are no service interruptions to hipp3?


204Ggenie.capella
15G genie.eclipselink
15G genie.egf
50G genie.geomesa
21G genie.kura
47G genie.ldt
19G genie.rcptt
29G genie.stardust
159Ggenie.tracecompass
37G genie.udig
34G genie.xtext


We are working on new storage systems and technologies to prevent such
project interference. But in the meanwhile, we need all projects to play
nice with our scarce resources.


Thanks!


Denis


___
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] Attention hipp3 users!!!

2017-01-24 Thread Marc-André Laperle
I wiped out a few workspaces for genie.tracecompass. I also noticed that RCPTT 
is using *a lot* of disk space in the maven repo, 13GB/workspace because it 
downloads a new snapshot every day (or more!). I added in the shell script to 
delete this folder every build so that the workspace will only contain one copy 
of the snapshot.


Hopefully this helps!


Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Denis Roy 

Sent: Tuesday, January 24, 2017 1:52:09 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Attention hipp3 users!!!

Greetings folks,


We're running into disk usage issues on hipp3. We don't have a formal
quota system, so we're relying on you (our beloved reasonable
committers) to please keep disk space in check.


Can the projects below clear out unnecessary builds and workspaces so
that there are no service interruptions to hipp3?


204Ggenie.capella
15G genie.eclipselink
15G genie.egf
50G genie.geomesa
21G genie.kura
47G genie.ldt
19G genie.rcptt
29G genie.stardust
159Ggenie.tracecompass
37G genie.udig
34G genie.xtext


We are working on new storage systems and technologies to prevent such
project interference. But in the meanwhile, we need all projects to play
nice with our scarce resources.


Thanks!


Denis


___
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] Converting hudson-slave4 to a CentOS

2017-01-19 Thread Marc-André Laperle

Hi,

Is there anything I can do to help with this? Did the conversion happen on 
Wednesday? Just to make sure I understand, this conversion doesn't aim to 
convert HIIPs, just converting some machines so that they can be added as nodes 
to existing HIPPs.


Thanks a lot!

Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Frederic Gurr 

Sent: Thursday, January 5, 2017 5:39:09 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Converting hudson-slave4 to a CentOS

Hi,

CentOS has a track record of running UI tests more reliably then SLES12
and is therefore in high demand. To distribute the load, we'd like to
convert hudson-slave4 from SLES11 to CentOS.

If a project specifically requires SLES (which I doubt), there will
still be hudson-slave1 (SLES12) and hudson-slave2 (SLES11).

See also related issues:
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=509173
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=508909

Please let me know if you have any concerns before Wednesday, January 11th.


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 Info 
Page
dev.eclipse.org
Cross project issues. Using cross-project-issues-dev To post a message to all 
the list members, send email to 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 Project Neon (4.7) Plan Updated

2016-12-12 Thread Marc-André Laperle
Hi,


Should it also target macOS Sierra (10.12) ?


Marc-André


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Daniel Megert 

Sent: Friday, December 9, 2016 1:32:52 PM
To: General development mailing list of the Eclipse project.; 
cross-project-issues-dev
Subject: [cross-project-issues-dev] Eclipse Project Neon (4.7) Plan Updated

An updated version of the Eclipse top-level project plan for the Neon (4.7) 
release is now available:

http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_7.xml

Notable changes:
- Updated JRE versions
- Removed Ubuntu 14.04
- Updated the Execution Environment by Bundle appendix
- Sub-project plans have the new Java 9 date

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

Re: [cross-project-issues-dev] wiki.eclipse.org down?

2016-11-20 Thread Marc-André Laperle
Oh, it works again now. Thanks for trying it out!


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Jonah Graham 

Sent: Sunday, November 20, 2016 11:27:43 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] wiki.eclipse.org down?


Not sure if it helps, but works from UK.

Jonah

On 20 Nov 2016 3:32 p.m., "Marc-André Laperle" 
mailto:marc-andre.lape...@ericsson.com>> wrote:

>

> I'm trying to access http://wiki.eclipse.org/ and I get "The connection was 
> reset" errors. Any idea why?
>
>
> Marc-Andre
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org<mailto: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<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] wiki.eclipse.org down?

2016-11-20 Thread Marc-André Laperle
I'm trying to access http://wiki.eclipse.org/ and I get "The connection was 
reset" errors. Any idea why?


Marc-Andre
___
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] Statement of intent to move platform.ua to Lucene 6.1 for M4

2016-11-18 Thread Marc-André Laperle
Yes it's perfectly clear, thank you! So we will build the index with 4.7 for 
Oxygen simrel and users of Eclipse 4.6 installing our plugins will have an 
additional 1-2 secs delay.


Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Sopot Cela 

Sent: Friday, November 18, 2016 8:36:10 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Statement of intent to move platform.ua 
to Lucene 6.1 for M4

Pre-built indexes with Lucene 3.5 (what Eclipse 4.6 has) will not be consumable 
with Eclipse 4.7 M4 and later. However the content will be promptly re-indexed 
by Lucene 6.1 on the first search so there will be no loss of search results. 
The only thing is the 1-2 seconds (reasonable time for reasonable indexes on my 
machine) you have to wait for the re-indexing to be performed only on first 
search. The procedure to provide a brand new pre-built index is exactly the 
same as before with the ant task, you just have to use a recent enough build to 
do the indexing. This is what is being used now to provide the PDE, JDT and 
Platform pre-built indexes as part of the normal build.

Eclipse 4.6 of course has Lucene 3.5 so that will not be able to read the new 
Lucene 6.1 indexes.

Is that clear enough? Feel free to get back to me if it's not.

Sopot

- Oorspronkelijk bericht -
> Van: "Marc-André Laperle" 
> Aan: cross-project-issues-dev@eclipse.org
> Verzonden: Vrijdag 18 november 2016 14:13:17
> Onderwerp: Re: [cross-project-issues-dev] Statement of intent to  move
> platform.ua to Lucene 6.1 for M4
>
>
>
> Hi Sopot ,
>
>
>
>
> If I understand correctly, the pre-built index is not forward (or backward)
> compatible? For example, if I build the index for a documentation plugin
> with Eclipse 4.6, the index won't work with Eclipse 4.7 and vice versa? In
> this case, for Oxygen, it's probably preferable to build indexes always with
> 4.7 even if a documentation plugin is intended to be also installed in
> Eclipse 4.6 (some projects many compatibility with some older Eclipse
> versions). Eclipse 4.6 users will get a performance hit but that should be
> the only consequence. Let me know if I misunderstood.
>
>
>
>
>
> Regards,
>
>
> Marc-Andre
>
> From: cross-project-issues-dev-boun...@eclipse.org
>  on behalf of Sopot Cela
> 
> Sent: Friday, November 18, 2016 6:36:17 AM
> To: cross-project-issues-dev@eclipse.org
> Subject: Re: [cross-project-issues-dev] Statement of intent to move
> platform.ua to Lucene 6.1 for M4
> Hello,
>
> As stated below, the code in platform.ua was moved to consume Lucene 6.1 API.
> See the closing comment
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=466829#c34 for a short
> summary.
>
> I urge the other projects to move to this newer Lucene also and I'm open to
> assist if there is any question or issue in doing so. Feel free to add me on
> CC on the respective bugs if assistance is needed.
>
> Best regards,
> Sopot
>
> - Oorspronkelijk bericht -
> > Van: "Sopot Cela" 
> > Aan: cross-project-issues-dev@eclipse.org
> > Verzonden: Woensdag 2 november 2016 16:39:39
> > Onderwerp: Statement of intent to move platform.ua to Lucene 6.1 for M4
> >
> > Hello,
> >
> > In bug 466829 I am targeting to move the code (all of it is in internal
> > packages) in platform.ua which presently uses Lucene 3.x to Lucene 6.1. The
> > CQs were filed and approved. The Orbit work is being handled in sync with
> > the code work. I'll update again here as progress is made.
> >
> > If your project makes use of Lucene please plan accordingly to update to
> > the
> > latest version for Oxygen.
> >
> > Please raise any concern/issue you might have with the move.
> >
> > Best regards,
> > Sopot
> ___
> 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] Statement of intent to move platform.ua to Lucene 6.1 for M4

2016-11-18 Thread Marc-André Laperle
Hi Sopot,


If I understand correctly, the pre-built index is not forward (or backward) 
compatible? For example, if I build the index for a documentation plugin with 
Eclipse 4.6, the index won't work with Eclipse 4.7 and vice versa? In this 
case, for Oxygen, it's probably preferable to build indexes always with 4.7 
even if a documentation plugin is intended to be also installed in Eclipse 4.6 
(some projects many compatibility with some older Eclipse versions). Eclipse 
4.6 users will get a performance hit but that should be the only consequence. 
Let me know if I misunderstood.


Regards,

Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Sopot Cela 

Sent: Friday, November 18, 2016 6:36:17 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Statement of intent to move platform.ua 
to Lucene 6.1 for M4

Hello,

As stated below, the code in platform.ua was moved to consume Lucene 6.1 API. 
See the closing comment 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466829#c34 for a short summary.

I urge the other projects to move to this newer Lucene also and I'm open to 
assist if there is any question or issue in doing so. Feel free to add me on CC 
on the respective bugs if assistance is needed.

Best regards,
Sopot

- Oorspronkelijk bericht -
> Van: "Sopot Cela" 
> Aan: cross-project-issues-dev@eclipse.org
> Verzonden: Woensdag 2 november 2016 16:39:39
> Onderwerp: Statement of intent to move platform.ua to Lucene 6.1 for M4
>
> Hello,
>
> In bug 466829 I am targeting to move the code (all of it is in internal
> packages) in platform.ua which presently uses Lucene 3.x to Lucene 6.1. The
> CQs were filed and approved. The Orbit work is being handled in sync with
> the code work. I'll update again here as progress is made.
>
> If your project makes use of Lucene please plan accordingly to update to the
> latest version for Oxygen.
>
> Please raise any concern/issue you might have with the move.
>
> Best regards,
> Sopot
___
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] HIPP failing to download some content from maven central

2016-11-15 Thread Marc-André Laperle
Sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=507419


Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Roland Grunberg 

Sent: Tuesday, November 15, 2016 4:26:51 PM
To: Cross project issues
Subject: [cross-project-issues-dev] HIPP failing to download some content from 
maven central

I pushed a recent change and noticed that the HIPP failed to download the
pom file corresponding to an artifact. I cleared the cache and tried
re-triggering a build that succeeded a few hours ago only to see the
failure happen even earlier in the build.

( https://hudson.eclipse.org/orbit/job/gerrit-orbit-recipes/200/console )

Downloading: 
https://repo.maven.apache.org/maven2/org/antlr/antlr4-runtime/4.5.1-1/antlr4-runtime-4.5.1-1.pom
..
..
[ERROR] Failed to execute goal 
org.eclipse.ebr:ebr-maven-plugin:1.0.0-SNAPSHOT:eclipse-ip-info (default) on 
project org.antlr.runtime: Unable to resolve POM for artifact 
org.antlr:antlr4-runtime:4.5.1-1. No POM found for artifact 
org.antlr:antlr4-runtime:4.5.1-1. -> [Help 1]

I've tried restarting the HIPP but that seems to be failing as well
because the host keys have changed (output text displayed in HIPP control)


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
___
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] Gerrit seems broken (permission issues?)

2016-11-10 Thread Marc-André Laperle
Hi,


We noticed Gerrit seems to be unable to create objects (permissions issues?). I 
have opened this bug:

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


Marc-Andre
___
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] PTP will participate in Oxygen

2016-11-02 Thread Marc-André Laperle
Is PTP contributing to Oxygen M3? I haven't seen the build here yet: 
http://download.eclipse.org/tools/ptp/builds/oxygen/milestones/


Thanks,

Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Greg Watson 

Sent: Wednesday, August 10, 2016 8:10:14 AM
To: Cross project issues
Subject: [cross-project-issues-dev] PTP will participate in Oxygen

PTP will be participating at Oxygen at offset +3 (remote at +1). I will update 
the release record as soon as http://projects.eclipse.org is working again [1].

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=499478
___
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] Git servers not working well?

2016-10-28 Thread Marc-André Laperle
Hi,

A lot of our Hudson builds have been failing with for example:
Command "git fetch -t 
git://git.eclipse.org/gitroot/tracecompass/org.eclipse.tracecompass.git 
refs/changes/24/84124/2" returned status code 128: fatal: read error: 
Connection reset by peer


This seems to have happened all morning.


Even when I try to fetch locally, if often fails. Is is possible that the Git 
servers are overloaded?


Thank you,

Marc-Andre
___
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] repo.eclipse.org down?

2016-10-23 Thread Marc-André Laperle
Hello,


My local Maven builds and browser can't access https://repo.eclipse.org

Is anyone else seeing this?


Thank you,

Marc-André
___
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] Who can I ask for releng assistance?

2016-09-26 Thread Marc-André Laperle
If you job is set to allow parallel builds, you might be affected by

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


Basically, when recording test results, it has to wait for any previous build 
to be done in order to have proper test history.


Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Stefan Xenos 

Sent: Monday, September 26, 2016 12:36:17 PM
To: Eclipse JDT Core developers list.; platform-releng-...@eclipse.org; Cross 
project issues
Subject: [cross-project-issues-dev] Who can I ask for releng assistance?

The latest hudson builds for this patch have been freezing up:

https://git.eclipse.org/r/#/c/76660/

They seem to freeze up after the message "Recording test results". Is there 
anyone on the greater Eclipse team who knows how to debug hudson builds?

The tail end of the console logs for the problematic builds always looks like 
this:


[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 01:13 h
[INFO] Finished at: 2016-09-25T22:19:41-04:00
[INFO] Final Memory: 174M/5216M
[INFO] 
[DEBUG] Closing connection to remote
[DEBUG] Waiting for process to finish
[DEBUG] Result: 0
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
java.lang.InterruptedException
   
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at 
hudson.model.Run$Runner$CheckpointSet.waitForCheckPoint(Run.java:1388)
at hudson.model.Run.waitForCheckpoint(Run.java:1354)
at hudson.model.CheckPoint.block(CheckPoint.java:129)
at 
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:162)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:34)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:736)
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:714)
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:690)
at hudson.model.Build$RunnerImpl.post2(Build.java:163)
at 
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:652)
at hudson.model.Run.run(Run.java:1519)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
at hudson.model.ResourceController.execute(ResourceController.java:82)
at hudson.model.Executor.run(Executor.java:137)
___
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] Oomph b3 agregator

2016-09-14 Thread Marc-André Laperle
We were able to get a successful build for our contribution so it looks good! 
Thank you!

On Sep 14, 2016, at 14:25, LE MENEZ Quentin 
mailto:quentin.leme...@cea.fr>> wrote:

Hi again,

I just saw 
https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD_CACHED/659/consoleFull
 which completed successfully.
Does this means we (Papyrus) are out of the woods?

Thanks,
Quentin

De : 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] De la part de LE MENEZ 
Quentin
Envoyé : mercredi 14 septembre 2016 19:50
À : Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Objet : [PROVENANCE INTERNET] Re: [cross-project-issues-dev] Oomph b3 agregator

Yes my bad I had to remove the old build to put in the new,
It should be back in order now (hopefully)

Sorry again,
Quentin

De : 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] De la part de Marc-André 
Laperle
Envoyé : mercredi 14 septembre 2016 19:40
À : 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Objet : Re: [cross-project-issues-dev] Oomph b3 agregator


It looks like it's failing now because of a missing update site from Papyrus:



13:27:44   [exec] Unable to load repository 
p2:file:///home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/2.0/RC4/main

Is someone from the Papyrys project working on this right now?

Thanks!
Marc-Andre


From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of David Williams 
mailto:david_willi...@acm.org>>
Sent: Wednesday, September 14, 2016 1:13:56 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Oomph b3 agregator

On 09/14/2016 01:02 PM, Carsten Reckord wrote:

This build, which promoted the 1.5.0 release build, also removed the old 
milestone drop:



https://hudson.eclipse.org/oomph/job/integration/2601/console



This currently blocks validation of all simrel contributions through Gerrit.



Ed, would it be okay if we updated the oomph.b3aggrcon in simrel to point to 
http://download.eclipse.org/oomph/drops/release/1.5.0? I assume that's the 
build you'd want to contribute to Neon.1 RC4 anyway - otherwise Eike can still 
change it later.



Best,

Carsten


In parallel, I have opened bug Bug 
501441<https://bugs.eclipse.org/bugs/show_bug.cgi?id=501441> and will merged 
the change into HEAD of Neon_maintenance assuming "validate" passes (which it 
does for me locally).

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org<mailto: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] Oomph b3 agregator

2016-09-14 Thread Marc-André Laperle
It looks like it's failing now because of a missing update site from Papyrus:


13:27:44   [exec] Unable to load repository 
p2:file:///home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/2.0/RC4/main

Is someone from the Papyrys project working on this right now?

Thanks!
Marc-Andre



From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of David Williams 

Sent: Wednesday, September 14, 2016 1:13:56 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Oomph b3 agregator

On 09/14/2016 01:02 PM, Carsten Reckord wrote:

This build, which promoted the 1.5.0 release build, also removed the old 
milestone drop:

https://hudson.eclipse.org/oomph/job/integration/2601/console

This currently blocks validation of all simrel contributions through Gerrit.

Ed, would it be okay if we updated the oomph.b3aggrcon in simrel to point to 
http://download.eclipse.org/oomph/drops/release/1.5.0? I assume that's the 
build you'd want to contribute to Neon.1 RC4 anyway - otherwise Eike can still 
change it later.

Best,
Carsten



In parallel, I have opened bug Bug 
501441 and will merged 
the change into HEAD of Neon_maintenance assuming "validate" passes (which it 
does for me locally).



___
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] Gerrit is failing to connect to https://hudson.eclipse.org

2016-08-30 Thread Marc-André Laperle
I'm seeing something that sounds similar on the CDT HIPP

17:33:18  Aug 30, 2016 5:33:18 PM 
org.apache.http.impl.client.DefaultRequestDirector tryConnect
17:33:18  INFO: I/O exception (java.net.NoRouteToHostException) caught when 
connecting to {s}->https://hudson.eclipse.org: No route to host
17:33:18  Aug 30, 2016 5:33:18 PM 
org.apache.http.impl.client.DefaultRequestDirector tryConnect
17:33:18  INFO: Retrying connect to {s}->https://hudson.eclipse.org
...

https://hudson.eclipse.org/cdt/job/cdt-verify/5961/console

Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Jeff Johnston 
[jjohn...@redhat.com]
Sent: Tuesday, 30 August 2016 5:32 PM
To: Cross project issues
Cc: Wayne Beaton
Subject: Re: [cross-project-issues-dev] Gerrit is failing to connectto  
https://hudson.eclipse.org

I tried restarting our hipp instance and now linuxtools hudson pages are 
unavailable (503).  This is bad
timing since we are trying to get RC2 out for tomorrow.

- Original Message -
> I am having trouble with the Linux Tools gerrit jobs.  We get the launchbar
> stuff from
> the hudson launchbar-master job last successful build.
>
> I keep getting no route to host when our target file tries to connect to the
> repo.
>
> Any ideas?
>
> -- Jeff J.
> ___
> 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] Service downtime

2016-07-27 Thread Marc-André Laperle
I know it's an odd request but can you make sure *not* to upgrade the 
Checkstyle plugin? See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485812

Thanks!
Marc-Andre

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Frederic Gurr 
[frederic.g...@eclipse.org]
Sent: Wednesday, 27 July 2016 11:41 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Service downtime

Hi,

To make the best use of the planned downtime, I will upgrade Sonar after
it has been moved. This will be just a small upgrade from version 4.5.4
to 4.5.7 and should have no big impact.
It's a prerequisite to be able to upgrade to the latest LTS version
(5.6) in the near future after some more testing.

If there are any questions about the Sonar upgrade, please let me know.

Regards,

Fred

On 26.07.2016 17:37, Webmaster(Matt Ward) wrote:
> Hi Folks,
>
>   As part of our continuing work to upgrade our virtual machine
> infrastructure I need to move the virtual machines that support
> sonar.eclipse.org and the hudson hippcentos slave.  I plan to do the
> move this friday(July 29th) starting at 2pm EDT, and I expect the
> servers to be down for about an hour while they are moved.
>
> If you have any questions or concerns please let me know.
>
> -Matt.
>
>
> ___
> 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] Eclipse Installer makes first hand experience on Linux worse

2016-07-04 Thread Marc-André Laperle
Hi Alexander,

GTK2 was forced because of bug 471721/471035. Perhaps now it works correctly 
with GTK3 and there is no need to force GTK2 anymore. It was still a problem 
last time I tested (April 27th).

Marc-Andre



From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Aleksandar Kurtakov 
[akurt...@redhat.com]
Sent: Monday, 04 July 2016 10:43 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Eclipse Installer makes first hand  
experience on Linux worse

Hi everyone,

Oomph runs with GTK2 by default and when you install and run your ide with it 
(the very first time) the env variables are inherited thus in the very first 
run users of Neon will see something broken [1] on recent Linux distro (Fedora 
24) and that's pretty bad initial experience. It is really disturbing that 
installer/Oomph overrides defaults and decides that it knows better what is on 
the user machine better than SWT managed to find on the user machine. Upon 
restart of the IDE (when installer/oomph no longer defines env variables) user 
will see the proper page [2] but the initial experience would be already ruined 
and we might have lost the chance this user would ever start it again.
Not to mention that webkitgtk (gtk2 version) is no longer installed by default 
on latest Ubuntu/Fedora (AFAIK) unless one explicitly installs it or had 
installed some other application that explicitly requires it. This essentially 
breaking the Internal web browser [3], making Help center opening in browser 
tab instead of its own applications and probably others.
I understand this is just the first start but this is the most important run if 
we want to grow the user base. Doing such changes without deeply understanding 
the possible variations and how/when decisions are taken generates too much bad 
mouth and ruins so much effort spent that I would describe it as unacceptable.
I sincerely ask the Oomph project/installer to reconsider these practices.


[1] https://akurtakov.fedorapeople.org/broken.png
[2] https://akurtakov.fedorapeople.org/proper.png
[3] https://akurtakov.fedorapeople.org/broken_browser.png

--
Alexander Kurtakov
Red Hat Eclipse team
___
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] Trace Compass RC1 late

2016-05-18 Thread Marc-André Laperle
I just updated the Trace Compass RC1 contribution. Apologies for being a bit 
late!

Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc-André Laperle 
[marc-andre.lape...@ericsson.com]
Sent: Wednesday, 18 May 2016 4:48 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Trace Compass RC1 late

Hi,

We are trying to get our RC1 build ready but due to some build servers 
instability this is taking longer than expected. I expect it should be ready 
around 8PM (EST) or some time before that.

Thank you,
Marc-Andre
___
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] Trace Compass RC1 late

2016-05-18 Thread Marc-André Laperle
Hi,

We are trying to get our RC1 build ready but due to some build servers 
instability this is taking longer than expected. I expect it should be ready 
around 8PM (EST) or some time before that.

Thank you,
Marc-Andre
___
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] Sonar comments in Gerrit (Gerrit plugin for Sonar)

2016-01-15 Thread Marc-André Laperle
Hi,

I'd like to bring up to your attention a discussion about Sonarqube posting 
comments on Gerrit patches. This would mean that when you push a patch to 
Gerrit, a build gets triggered on Hudson and if you include Sonar analysis in 
the build, Sonarqube will post comments for the issues found *in the modified* 
files in the patch.

Here is how it looks: http://imgur.com/Bm3MTyF

This would help us improve code quality much earlier and would help reduce 
review time for things that Sonarqube can point out automatically.

The Gerrit plugin for Sonar would be disabled by default and each project could 
decide to enable it and choose whether it votes or not. I can see projects 
deciding to enable it to get the comments but not have it vote. That way, 
reviewers are free to ignore them if they are deemed not important.

Feel free to comment on this bug if you are interested in this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=464657

Regards,
Marc-Andre
___
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] Known outage?

2015-11-26 Thread Marc-André Laperle
It seems good on the CDT side now, thanks!

BTW, I don't know if it's related, but we've been seeing some issue contacting 
build.eclipse.org, I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=483118

Regards,
Marc-Andre



From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Matthew Ward(Bt. 
Kt. SSA.) [matt.w...@eclipse.org]
Sent: Wednesday, 25 November 2015 3:52 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Known outage?

I think some of these were caused by a new machine added to the proxy pool 
today.  I think it's nailed down now.

-Matt

On 11/25/2015 02:36 PM, Marc-André Laperle wrote:
There seems to be some intermittent issues connecting to several servers, like 
repo.maven.apache.org and download.eclipse.org.

For example:

Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could not 
transfer artifact org.eclipse.tycho.extras:tycho-p2-extras-plugin:jar:0.24.0 
from/to central (http://repo.maven.apache.org/maven2): Access denied to: 
http://repo.maven.apache.org/maven2/org/eclipse/tycho/extras/tycho-p2-extras-plugin/0.24.0/tycho-p2-extras-plugin-0.24.0.jar
 , ReasonPhrase:Forbidden.

and

Caused by: org.eclipse.equinox.p2.core.ProvisionException: Artifact not found: 
http://download.eclipse.org/tools/orbit/downloads/drops/R20150519210750/repository/artifacts.xml.xz.
at 
org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:428)

https://hudson.eclipse.org/cdt/job/cdt-verify/3707/console


Could there still be a problem with DNS or perhaps the proxy? We also tried 
restarting the CDT HIPP.

Thanks!
Marc-Andre


___
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] Known outage?

2015-11-25 Thread Marc-André Laperle
There seems to be some intermittent issues connecting to several servers, like 
repo.maven.apache.org and download.eclipse.org.

For example:

Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could not 
transfer artifact org.eclipse.tycho.extras:tycho-p2-extras-plugin:jar:0.24.0 
from/to central (http://repo.maven.apache.org/maven2): Access denied to: 
http://repo.maven.apache.org/maven2/org/eclipse/tycho/extras/tycho-p2-extras-plugin/0.24.0/tycho-p2-extras-plugin-0.24.0.jar
 , ReasonPhrase:Forbidden.

and

Caused by: org.eclipse.equinox.p2.core.ProvisionException: Artifact not found: 
http://download.eclipse.org/tools/orbit/downloads/drops/R20150519210750/repository/artifacts.xml.xz.
at 
org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:428)

https://hudson.eclipse.org/cdt/job/cdt-verify/3707/console


Could there still be a problem with DNS or perhaps the proxy? We also tried 
restarting the CDT HIPP.

Thanks!
Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Konstantin 
Komissarchik [konstantin.komissarc...@oracle.com]
Sent: Saturday, 21 November 2015 1:41 AM
To: Matthew Ward(Bt. Kt. SSA.); Cross project issues
Subject: Re: [cross-project-issues-dev] Known outage?

Thanks for the fix. Whatever you did also resolved inability to access the 
download server. The build is working now.

- Konstantin



From: Matthew Ward(Bt. Kt. SSA.)
Sent: Friday, November 20, 2015 12:31 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Known outage?


I've taken a look and the underlying host has no issues resolving names,
but it's postfix instance seems 'stuck' and unable to resolve the mail
relay.  I've restarted postfix and it's now sending mail.

-Matt.

On 11/20/2015 02:50 PM, Konstantin Komissarchik wrote:
> See Sapphire HIPP. The failure is seen consistently.
>
> Konstantin Komissarchik
> Senior Development Manager
> Eclipse Tools Group
> Oracle
>
>

___
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] Stats on OS being used

2015-11-18 Thread Marc-André Laperle
Ubuntu has Eclipse 3.8.1 [1] ... I hope the majority are not using this.

[1] http://packages.ubuntu.com/wily/eclipse



From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Doug Schaefer 
[dschae...@qnx.com]
Sent: Wednesday, 18 November 2015 2:20 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Stats on OS being used

From: 
mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Mat Booth mailto:mat.bo...@redhat.com>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, November 18, 2015 at 1:20 PM
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Stats on OS being used

On 18 November 2015 at 16:24, Eike Stepper 
mailto:step...@esc-net.de>> wrote:
This is what I figured for Mars (incl. milestones):

win32: 9,000,000
macos: 740,000
linux: 800,000

Cheers
/Eike


 I'm surprised by this, I always expect Linux to be under-represented by 
download stats due to distro packaging.

While that’s true, I don’t think Debian/Ubuntu/Mint have very up-to-date 
packages so those users have to download the latest from eclipse.org. And with 
apologies to our friends from Red Hat, Debian based distros still lead by a 
long shot.

In the past, the Mac numbers were very low compared to Linux. Interesting to 
see it catch up. It is a platform for our future growth and I think we need to 
make sure it’s getting enough love. It’s funny, but you go to EclipseCon and I 
see way more Mac’s than other platforms so you’d think that would already be 
the case.

Doug.
___
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] Trace Compass participation in Neon

2015-10-21 Thread Marc-André Laperle
Hi,

The Trace Compass project will participate in the
Neon simultaneous release train with a offset of +3 and version 2.0.0.

https://projects.eclipse.org/projects/tools.tracecompass/releases/2.0.0

Regards,
Marc-Andre Laperle
___
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] TableTreeViewer removed (please comment in bug 434575)

2015-09-13 Thread Marc-André Laperle
Hi David,

I added a comment for the CDT case in bug 
436505 and in bug 
434575
Regards,
Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of David M Williams 
[david_willi...@us.ibm.com]
Sent: Sunday, 13 September 2015 12:56 PM
To: Cross project issues
Subject: [cross-project-issues-dev] TableTreeViewer removed (please comment in 
bug 434575)

Thanks for letting us know of the unexpected impact, Ed. I'll talk to the team, 
and coordinate our response.

For a number of reasons, this may take several days, so in the mean time ... 
are there any other projects effected by this?
You should be able to tell, other than brute force searching for the family of 
classes, by building against our latest I-build, I20150908-0800,
or using it as a PDE target. If you are effected, please comment in bug 
434575.

Also, in the mean time, for those of you that "migrated" (e.g. Doug/CDT, for 
one) can you briefly write-up what changes were needed? Or, point to some Git 
commits that show the changes?
I'll confess my ignorance here, but I'm trying to determine if there is an 
"easy pattern" to migrating, or if something that would be highly variable?
Again, a brief comment in bug 
434575 would be the best 
place to put these, so easier to find in future.

Thanks again, and my personal apologies for the churn,





From:Ed Merks 
To:Cross project issues ,
Date:09/12/2015 04:06 AM
Subject:[cross-project-issues-dev] Unannounced Changes Have Unforeseen  
  Consequences
Sent by:cross-project-issues-dev-boun...@eclipse.org




Hi,

It was brought to my attention that
org.eclipse.jface.viewers.TableTreeViewer has been deleted.  Yes, I know
it's deprecated, but nevertheless it was once API before being
deprecated so deleting it is a breaking change.  I don't recall there
being an announcement to begin deleting arbitrary deprecated API.

In any case, I can't necessarily commit to making the necessary
changes.  As such I can't commit to contributing EMF Core to Neon.

I would suggest reconsidering the strategy of breaking APIs and most
certainly suggest any such actions ought to be announced and discussed
before such actions are taken.

Regards,
Ed
___
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] Maintenance Repository Empty - its back

2015-09-02 Thread Marc-André Laperle
Hi David,

For Trace Compass, we use the maintenance repository for our Mars builds in 
order to build against and tests properly with up-to-date dependencies (more up 
to date than releases/mars anyway). This way we can find dependencies issues or 
regressions much quicker. Also, updating all repository URLs in our target 
every milestone would be pretty impractical. I think it would be very useful to 
keep the maintenance repository, at least in a non-empty state. I understand 
that this is not meant to be a stable repository but it would be useful if it 
was not ephemeral.

Regards,
Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of David M Williams 
[david_willi...@us.ibm.com]
Sent: Wednesday, 02 September 2015 8:42 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Maintenance Repository Empty - its back

Apologies for not noticing. Thanks for pointing it out.

I will say, however, I would not recommend building against "maintenance". By 
definition, it is ephemeral -- not a usual persistent p2 repository. Hard to 
say what state it may be in at the time of your build.

But, thanks again.




From:
To:,
Date:09/02/2015 08:27 AM
Subject:Re: [cross-project-issues-dev] Maintenance Repository Empty
Sent by:cross-project-issues-dev-boun...@eclipse.org




Uh this is not good. Stardust is using this repo for the upcoming RC2 
contribution for Eclipse Mars SR1. So this means that we cannot run the build. 
Does we have an alternative URL which contains the latest simrel contributions 
for Mars SR1 RC2?

--
Sven

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Matthias 
Sohn
Gesendet: Mittwoch, 2. September 2015 12:46
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Maintenance Repository Empty

On Wed, Sep 2, 2015 at 11:12 AM, Stephan Leicht Vogt 
mailto:stephan.lei...@bsiag.com>> wrote:

Hi

The repository http://download.eclipse.org/releases/maintenance/is currently 
empty. Is this correct? Else when will it be back to normal?

it's not empty but seems to be missing completely:

msohn@build:/home/data/httpd/download.eclipse.org/releases>
 ls -l maintenance/
total 0

-Matthias___
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] Trace Compass Participation in Neon release

2015-08-10 Thread Marc-André Laperle
Hi,

The Trace Compass project will participate in the
Neon simultaneous release train with a offset of +3 and version 2.0.0.

https://projects.eclipse.org/projects/tools.tracecompass/releases/2.0.0

Regards,
Marc-Andre Laperle
___
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] Impossible to pack and sign on a tycho build

2015-06-10 Thread Marc-André Laperle
"[INFO] --- eclipse-jarsigner-plugin:1.0.5:sign (sign) @ 
org.eclipse.papyrus.infra.services.controlmode ---"

The jarsigner used in your build looks old, try with 1.1.2.

Hope this helps,
Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of SCHNEKENBURGER Remi 
211865 [remi.schnekenbur...@cea.fr]
Sent: Wednesday, 10 June 2015 1:54 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Impossible to pack and sign on a tycho build

Hi,

We are experiencing on this last milestone big issues with the tycho build. The 
pack+sign task is randomly failing during the maven build: see for example 
https://hudson.eclipse.org/papyrus/job/Papyrus-Master/1658/console
All our nightly builds are packed, so there should not be any issue on that. 
However, since today, we are unable to publish a new milestone being packed and 
signed.

Our last solution is to only sign for today.

Did anyone experience the same issue ? It worked fine until RC3, and we tried 
0.22 and 0.23 version.


Regards,
Rémi
---

Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST

[Description : 
PapyrusLogo_SmallFormat]www.eclipse.org/papyrus

___
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] Almost all projects are ready for the June 10 release review

2015-06-05 Thread Marc-André Laperle
Hi Wayne,

It looks like the 3 last links are saved searches (and won't work for anyone 
but you?). I get "The search named Mars does not exist. " for example.

Marc-Andre

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Wayne Beaton 
[wa...@eclipse.org]
Sent: Friday, 05 June 2015 2:46 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Almost all projects are ready for the June 
10 release review

Greetings folks. Before I say anything else, let me start with this: don't 
panic.

I have received the required PMC Approval of the review materials and IP Team 
approval of the IP Logs for most of the projects participating in the Mars 
release.

If I have everything that I need from you, your project will appear in the 
project activity list [1] under June 10 reviews. Thank you for your attention 
in this matter of process and please seek me out if you want a beer or 
something at EclipseCon.

As most of you have likely discovered, I use bugs to track each release review 
[2]. I've created a couple of different queries to help me keep track of what 
we're waiting for.

I'm still waiting on PMC Approval of the review materials from several projects 
[3]. I am either waiting for IP Logs or am waiting for responses regarding 
questions about IP  Logs from several projects [4]. If your project is on one 
of these lists, you need to take action now. You've missed the deadline 
participate in the June 10 review and are very late for IP Log reviews for a 
June 17 review. Immediate action is required if you intend to release with 
Mars. Maybe you can panic a little,..

If I've missed something, please first accept my humble apology, then be kind 
in consideration of how mindnumbing processing a bajillion IP Logs can be, and 
let me know what I've missed so that I can take the necessary steps to 
remediate.

While I have your attention...

Those of you who created your own review records may have noticed that the 
available dates for reviews has been made a little more restrictive. Moving 
forward, we are only scheduling reviews on first and third Wednesdays of the 
month. I'll admit that the timing of the change could have been better (I 
probably should have waited until post Mars) Exceptions may be permitted at my 
discretion, but only with input from the PMC. My preference is to give projects 
as much flexibility as possible, but, frankly, we've been running far too many 
review periods over the last year or so and I just don't have the bandwidth to 
continue to do weekly reviews.

Finally, I'd like to take this opportunity to remind you that IP tracking needs 
to be current and complete at all times. You must obtain approval from the IP 
Team before you check in any third party code libraries or code contributions 
for which the IP due diligence process mandates an IP Team review. Git commits 
must correctly indicate the author of the contribution and all contributions by 
non-project-committers must be signed off. If you have any questions about 
this, please ask your project mentors, project lead, PMC members, or me.

Thanks!

Wayne

[1] https://www.eclipse.org/projects/project_activity.php
[2] http://eclip.se/4t
[3] http://eclip.se/4s
[4] http://eclip.se/4v

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon   France 2015] 
___
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] Creating a new category in the simrel update site: Tracing

2014-11-12 Thread Marc-André Laperle
I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=451241

Regards,
Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of David M Williams 
[david_willi...@us.ibm.com]
Sent: Wednesday, 12 November 2014 5:58 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Creating a new category in the simrel 
update site: Tracing

Seems reasonable ... I wonder if it can be broadened a little to include 
"Testing"?
But, in any case, please open a cross-project bug, and after a few weeks of 
discussion we can probably come to a conclusion.
(That is, not in time for M3, but in time for M4).

Thanks for suggestions to improve the categorization.




From:    Marc-André Laperle 
To:"cross-project-issues-dev@eclipse.org" 
,
Date:11/12/2014 04:16 PM
Subject:[cross-project-issues-dev] Creating a new category in the 
simrelupdate site: Tracing
Sent by:cross-project-issues-dev-boun...@eclipse.org




Hi,

We would like to add a new category to the simultaneous release update site 
called "Tracing". It is my understanding that adding such a category needs to 
be discussed and approved first. We would like to add this category because 
some features do not fit well into existing categories such as LTTng trace 
analysis, GDB trace and Pcap analysis. Those features are being moved from the 
Linux Tools project to the Trace Compass project. We also don't think a "Trace 
Compass" category would be good because the categories should be seen as themes 
to the user and not project structure. Also, we think other features could be 
placed under the Tracing category, like SystemTap support. Let us know what you 
think!

Regards,
Marc-Andre Laperle___
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] Creating a new category in the simrel update site: Tracing

2014-11-12 Thread Marc-André Laperle
Hi,

We would like to add a new category to the simultaneous release update site 
called "Tracing". It is my understanding that adding such a category needs to 
be discussed and approved first. We would like to add this category because 
some features do not fit well into existing categories such as LTTng trace 
analysis, GDB trace and Pcap analysis. Those features are being moved from the 
Linux Tools project to the Trace Compass project. We also don't think a "Trace 
Compass" category would be good because the categories should be seen as themes 
to the user and not project structure. Also, we think other features could be 
placed under the Tracing category, like SystemTap support. Let us know what you 
think!

Regards,
Marc-Andre Laperle
___
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] Trace Compass Participation in Mars release

2014-11-12 Thread Marc-André Laperle
Hi,

The Trace Compass project will participate in the
Mars simultaneous release train with a offset of +3 and version 1.0.0.

https://projects.eclipse.org/projects/tools.tracecompass/releases/1.0.0

Regards,
Marc-Andre Laperle
___
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] Limiting GTK versions supported by SWT or SWT call for help

2014-10-09 Thread Marc-André Laperle
I see in the target environments that Eclipse 4.5 supports SUSE Linux 
Enterprise Server 11 which only has 2.14 according to the package 
list.
 Aside from that, I think only supporting 2.18 and up sounds pretty safe. Will 
it be sufficient to help the GTK3 situation though? It sounds like it won't 
help the two examples you gave (using GdkRGBA and using cairo only to draw). I 
also wonder how much time is really saved in testing, bug reporting and fixing 
for 2.10/2.14 if they are so old that it's unlikely that people use them. I can 
see that in the code it will remove quite a bit of branches so that's good for 
readability but will it make a difference for the GTK3 support stability and 
make it easier to adopt new recommendations? I was under the impression that as 
long as 2.24 is supported, it will be hard to adopt most of the new ways of 
GTK3. But you probably know a lot more that I do about the subject :)

By the way, is it completely ruled out to have two ports? The GTK2 port could 
remain almost untouched (critical bugs only) and the GTK3 port would be free to 
use all the new GTK3 stuff. I remember that for a while, there was both the 
Carbon and Cocoa port for Mac so people would be free to use the more stable 
one and "modern" development could happen on the Cocoa port without compromise. 
Eventually, Carbon was marked as unsupported and was removed recently without 
fuss.

Regards,
Marc-Andre


From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Aleksandar Kurtakov 
[akurt...@redhat.com]
Sent: Thursday, 09 October 2014 12:00 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT 
or SWT call for help

- Original Message -
> From: "Tom Schindl" 
> To: cross-project-issues-dev@eclipse.org
> Sent: Thursday, October 9, 2014 1:16:29 AM
> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by 
> SWT or SWT call for help
>
> hi,
>
> dropping Gtk2 means:
> * swing embed is broken when the Gtk-Theme is used because it links
> against Gtk2
> * javafx embed is broken because it links against Gtk2
>
> So clearly openjdk/oraclejdk (even the latest builds) links against
> Gtk2, or am I wrong in this regard?

Hi Tom,
My mail seems to be misunderstood. This is not a proposal to drop GTK 2.x 
support (2.10 - 2.24) in general but to limit this support to only newer 2.x 
versions (aka 2.18+). With 2.18 being released 5 years ago[1] and being in 
strict maintenance mode for smth like last 4 years this is safe requirement. It 
also DOES not require any change in Mars target environments [2] and will 
satisfy even Luna [3].
So to make it clear GTK 2.18 up to 2.24 will still be supported.
By bumping this minimum requirement we open the door for streamlining swt 
codebase as there are many changes that have happened (macros-> functions, 
struct access -> functions, etc.) which are the same for newer GTK 2.x 
(2.18-2.24) and GTK 3.x versions but we have different codepaths for older GTK 
2.x versions (2.10-2.17).
So this proposal will not affect the Swing problems in anyway.

[1] https://mail.gnome.org/archives/gtk-devel-list/2009-September/msg00054.html
[2] 
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_5.xml#target_environments
[3] 
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_4.xml#target_environments

Alexander Kurtakov
Red Hat Eclipse team

>
> I can also prove what Andrey said: We have turned of Gtk3 on *all* our
> linux desktops because there are too many problems with it.
>
> Tom
>
> On 08.10.14 16:18, Aleksandar Kurtakov wrote:
> > - Original Message -
> >> From: "Andrey Loskutov" 
> >> To: "Cross project issues" ,
> >> "Aleksandar Kurtakov" 
> >> Sent: Wednesday, October 8, 2014 5:11:53 PM
> >> Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by
> >> SWT or SWT call for help
> >>
> >> BTW we at Advantest are still using RHEL 5.8, even because RHEL has crazy
> >> long support times :o)
> >>
> >> Limiting to GTK3 only and drop GTK2 ports for *new* Eclipse releases would
> >> be
> >> good idea but AFAK GTK3 SWT port is still problematic (I'm on *latest*
> >> Ubuntu and must turn it off).
> >>
> >> In general I would also prefer to have always *one* (smallest possible
> >> from
> >> latest GTK on major distros) SWT port for latest Eclipse release but that
> >> port must be 99% usable.
> >>
> >> I won't hijack the thread, but the best long term solution for SWT Linux
> >> ports and Eclipse UI toolkit in general would be to move away from SWT to
> >> Java FX or better Qt (I know Qt LGPL license is a showstopper, but this

Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT or SWT call for help

2014-10-07 Thread Marc-André Laperle
Hi Alexander,

"If this is not done, properties using GdkColor seem to no longer have 
effect/have problems, so it's only a matter of time how long such changes can 
be delayed"

I am not familiar with this but it sounds like this shouldn't break if it was 
merely deprecated. From the bugs I've experienced among the different GTK3 
versions, I've been thinking that maybe the main problem is that GTK is 
changing too quickly for its own good - or at least, too quickly for the 
community to keep up, compared to GTK2 which is in maintenance mode. Is there a 
plan somewhere that indicates when GTK3 will enter maintenance mode and when 
development of GTK4 will start? I haven't found anything like that. I don't 
mean to sound negative though, I appreciate the enthusiasm and advances that 
are being made in GTK.

About supporting only specific versions, I'm not sure which ones would get 
picked. I think one approach could be to support only versions that are 
included in popular distributions with longterm/extended support. For Ubuntu 
and Debian that would mean supporting 3.4 and 3.10. Looking at RHEL7 that would 
mean 3.8. That's already 3 different versions. I'm not sure what to do about 
Fedora since it moves more rapidly and doesn't have a longterm/extended 
support. The thought of bundling a well tested GTK with Eclipse also crossed my 
mind but since it's LGPL that's not possible, unless I'm mistaken.

About getting more people involved, I can only hope that people hear the call 
for help. From my experience, the SWT committers/contributors have been very 
supportive and appreciative of bug reports, testing and patches. On my end, I 
will be looking at improving compatibility with 3.10 (on Ubuntu) in my spare 
time so I can start using GTK3 on a day to day basis.

Regards,
Marc-Andre

From: cross-project-issues-dev-boun...@eclipse.org 
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Aleksandar Kurtakov 
[akurt...@redhat.com]
Sent: Tuesday, 07 October 2014 11:15 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Limiting GTK versions supported by SWT  
or SWT call for help

On behalf of SWT team (committers working on GTK port):

The addition of the GTK+ 3.x based implementation of SWT which is now
officially supported along with the GTK+ 2.x implementation means that the
range of supported GTK+ versions has now grown pretty large and is in fact,
continuing to grow with every release (for each x.y+1 SWT release, there
are x.y+2 releases of GTK+). However, it is not practically possible for
the current set of committers alone to actually test all these versions
before we make a release. Therefore, we end up  "declaring" support for a
huge range of GTK+ versions while the reality is that they are not tested
and verified the way they must be to call them supported.

Another consequence of this is that constantly having to convert between
old-to-new or vice versa ways of doing things takes all our time, not
allowing for any meaningful new developments or even to keep pace with the
advancements in the platforms. There are two possible ways to improve this
situation from our point of view:

*) Others start to actively contribute to SWT - help improve the test
suite, get a representative range of test machine variations running the
tests so problems are caught earlier, get rid of dead bits from the
code-base to ease migrations, etc. etc. Many of the tasks don't require any
special OS specific knowledge as many seem to think before trying to help
with SWT. Also, the current committers are more than willing to help new
contributors with guidance and patch reviews as and when needed.

*) Actively limiting the number of supported GTK+ versions - continually
adapting to newer versions is really stretching the current resources. So,
we end up with neither the old nor the new versions being in a really good
shape. To overcome this limitation, it's needed that both groups of people
(committers and end-users) participate actively as some of the soon to come
changes in GTK+ require major overhaul of certain areas. For example,
GdkColor is being deprecated and GdkRGBA is the new way of doing stuff but
there are changes in too many places and there are huge chances to break
some older versions. If this is not done, properties using GdkColor seem to
no longer have effect/have problems, so it's only a matter of time how long
such changes can be delayed. And this is just one of the examples, there are
quite a few similar. As a bare minimum, we think that the range of
supported GTK+ versions should not grow until people step up to help
support a broader range.

An ideal solution would be a combination of both the above approaches -
having more people contributing to SWT + actively dropping support for
older versions of GTK+.

Please reply to this thread and let us know what your thoughts are. It
would be very useful for us to also know which versions of GTK+ ar

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

2014-06-05 Thread Marc-André Laperle
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 
> To: "'Cross project issues'" 
> 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.khouzam@ericsson.com_
> >
> To: "'cross-project-issues-dev@eclipse.org'"
> <_cross-project-issues-dev@eclipse.org_
> >
> Cc: Alvaro Sanchez-Leon <_alvaro.sanchez-leon@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-bounces@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


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

2014-06-05 Thread Marc-André Laperle
I just tested installing CDT RC3 on Eclipse Platform RC3 with Java 6.
Restarted, then plugins didn't load (expected). Then restarted again
with Java 7 and it worked correctly, I was able to create a Hello world
project and build it. But I did not use -clean in any steps.

Interestingly, I tried again and *did* use -clean for all the steps,
then I could reproduce the problem! I opened this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436758

Marc-Andre

On 14-06-05 03:56 PM, Doug Schaefer wrote:
> 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  >
> To: "'cross-project-issues-dev@eclipse.org'"
>  >
> Cc: Alvaro Sanchez-Leon  >
> 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] JFace Generics

2013-08-29 Thread Marc-André Laperle
+1 on working on a separate branch. I can't target 4.4 right now
because of the new warnings that I can't fix and we have this kind of
warning set to error.

Regards,
Marc-Andre

On Thu, 29 Aug 2013 12:36:38 +0200
Hendrik Still  wrote:

> 
> Hello,
> 
> as part of my Google Summer of Code Project I'm currently responsible 
> for the changes in the JFace Viewers, which leads to your warnings.
> 
> I fully understand your concerns about the incomplete generification
> of the viewer classes. We intended to have small reviews, but I agree
> that merging this changes to the master was not the best idea.
> I'll talk to Lars and John and suggest to roll the changes back and
> work in a own branch.
> I also will discuss with my mentors how to proceed with this project.
> 
> I'm also deeply sorry for the missing communication and the trouble.
> 
> Regards,
> Hendrik
> ___
> 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