Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

[Oberhuber, Martin]

Hi all,

Another use-case for working offline with the Committers Package just came up – 
big pop-up:
“
Code Recommenders cannot download its model repository index.
Please make sure that you are connected to the Internet. If so, check our FAQ 
for help on resolving this issue.
“

So I checked the FAQ, but didn’t get much wiser. Sure I can “Silently ignore 
future download failures”. But I’d rather want to either turn off the feature 
pro-actively, or download the model repository for offline use. Any help here?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From:  on behalf of Martin 
Oberhuber 
Reply-To: Cross issues 
Date: Monday 22 May 2017 at 13:38
To: Cross issues 
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

Thanks Johannes,

So it looks like I’ll need to craft a –pluginCustomization for the eclipse.ini 
to turn it off programmatically / via switch.
I can live with that – thanks !

Cheers,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From:  on behalf of Johannes Dorn 

Reply-To: Cross issues 
Date: Monday 22 May 2017 at 10:45
To: Cross issues 
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

Hi,

This is the RSS News reader.

It can be disabled via a preference: 
/instance/org.eclipse.recommenders.news.rcp/newsEnabled
Set its value to false to disable automatic news polling.

In the UI, the setting can be found at Preferences > General > News > Enable 
automatic news polling

Hope that helps.
Johannes


Oberhuber, Martin wrote:


Hi all,

Just noticed another “calling home” kind of feature:
eclipse-committers-oxygen-M7 shows “polling news feeds” in the progress 
occasionally.
Does anyone know how to turn that off?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From: 
<mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Martin Oberhuber 
<mailto:martin.oberhu...@windriver.com>
Reply-To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Date: Sunday 21 May 2017 at 13:14
To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

Thanks so much for the quick answer, Ed!

I’ve added that System Property and will run with it for a while.

Still wondering if USS could also be turned off for the MPC (or globally for 
all clients?), but MPC is by far not so important since users of MPC are 
already prepared to access the Internet anyways.

Cheers,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From: 
<mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of "Ed com>" <mailto:ed.me...@gmail.com>
Reply-To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Date: Sunday 21 May 2017 at 10:25
To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?


Martin,

I think -Doomph.setup.sync.skip=true will avoid the use of USS by Oomph.

You can host your own index somewhere else as follows:

  
https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Hosting_your_own_index_.2F_catalogs

On 21/05/2017 7:36 AM, Oberhuber, Martin wrote:
Hi cross-project,

While testing the brand-new Oxygen M7 packages, I came across an issue that I 
wanted to share.
Plus, I have no solution yet so I’m looking for help!

At a customer site, I want to use Oxygen Packages, but I’m sitting behind an 
authenticating proxy there.
So I have no Internet access. And if I had, I’d still want to make sure no data 
gets sent to the
Internet from that customer.

I easily found out how to disable AERI, to avoid error reporting reaching out:
https://wiki.eclipse.org/EPP/Logging#Disabling_AERI_in_builds_and_runtime_Eclipse

But how can I disable the new USS used by Oomph and MPC?

I found a related forum thread 
[1]<https://www.eclipse.org/forums/index.php/t/1081127/>, but it was no help. 
What I need is a System Property to turn off all internet access. I still want 
to use Oomph with locally stored setup tasks, but the attempt using USS or 
downloading setup.zip must be turned off.

Right now, I’m getting several exceptions logged due to Oomph/USS, and I want 
to get rid of them.
But what concerns me more, I think it is a valid use-case disabling all sort of 
“calling home” by Eclipse.
So I think that documentation on how to turn this off must be available very 
easily!

Any help / comments?

[1] https://www.eclipse.org/forums/index.php/t/1081127/

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River







___

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 fro

Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

[Oberhuber, Martin]

Thanks Johannes,

So it looks like I’ll need to craft a –pluginCustomization for the eclipse.ini 
to turn it off programmatically / via switch.
I can live with that – thanks !

Cheers,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From:  on behalf of Johannes Dorn 

Reply-To: Cross issues 
Date: Monday 22 May 2017 at 10:45
To: Cross issues 
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

Hi,

This is the RSS News reader.

It can be disabled via a preference: 
/instance/org.eclipse.recommenders.news.rcp/newsEnabled
Set its value to false to disable automatic news polling.

In the UI, the setting can be found at Preferences > General > News > Enable 
automatic news polling

Hope that helps.
Johannes


Oberhuber, Martin wrote:

Hi all,

Just noticed another “calling home” kind of feature:
eclipse-committers-oxygen-M7 shows “polling news feeds” in the progress 
occasionally.
Does anyone know how to turn that off?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From: 
<mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of Martin Oberhuber 
<mailto:martin.oberhu...@windriver.com>
Reply-To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Date: Sunday 21 May 2017 at 13:14
To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

Thanks so much for the quick answer, Ed!

I’ve added that System Property and will run with it for a while.

Still wondering if USS could also be turned off for the MPC (or globally for 
all clients?), but MPC is by far not so important since users of MPC are 
already prepared to access the Internet anyways.

Cheers,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From: 
<mailto:cross-project-issues-dev-boun...@eclipse.org>
 on behalf of "Ed com>" <mailto:ed.me...@gmail.com>
Reply-To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Date: Sunday 21 May 2017 at 10:25
To: Cross issues 
<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?


Martin,

I think -Doomph.setup.sync.skip=true will avoid the use of USS by Oomph.

You can host your own index somewhere else as follows:

  
https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Hosting_your_own_index_.2F_catalogs

On 21/05/2017 7:36 AM, Oberhuber, Martin wrote:
Hi cross-project,

While testing the brand-new Oxygen M7 packages, I came across an issue that I 
wanted to share.
Plus, I have no solution yet so I’m looking for help!

At a customer site, I want to use Oxygen Packages, but I’m sitting behind an 
authenticating proxy there.
So I have no Internet access. And if I had, I’d still want to make sure no data 
gets sent to the
Internet from that customer.

I easily found out how to disable AERI, to avoid error reporting reaching out:
https://wiki.eclipse.org/EPP/Logging#Disabling_AERI_in_builds_and_runtime_Eclipse

But how can I disable the new USS used by Oomph and MPC?

I found a related forum thread 
[1]<https://www.eclipse.org/forums/index.php/t/1081127/>, but it was no help. 
What I need is a System Property to turn off all internet access. I still want 
to use Oomph with locally stored setup tasks, but the attempt using USS or 
downloading setup.zip must be turned off.

Right now, I’m getting several exceptions logged due to Oomph/USS, and I want 
to get rid of them.
But what concerns me more, I think it is a valid use-case disabling all sort of 
“calling home” by Eclipse.
So I think that documentation on how to turn this off must be available very 
easily!

Any help / comments?

[1] https://www.eclipse.org/forums/index.php/t/1081127/

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River






___

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

--

Johannes Dorn

Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Tel: +49 6151 2767092
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 yo

Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

[Oberhuber, Martin]

Hi all,

Just noticed another “calling home” kind of feature:
eclipse-committers-oxygen-M7 shows “polling news feeds” in the progress 
occasionally.
Does anyone know how to turn that off?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From:  on behalf of Martin 
Oberhuber 
Reply-To: Cross issues 
Date: Sunday 21 May 2017 at 13:14
To: Cross issues 
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?

Thanks so much for the quick answer, Ed!

I’ve added that System Property and will run with it for a while.

Still wondering if USS could also be turned off for the MPC (or globally for 
all clients?), but MPC is by far not so important since users of MPC are 
already prepared to access the Internet anyways.

Cheers,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From:  on behalf of "Ed com>" 

Reply-To: Cross issues 
Date: Sunday 21 May 2017 at 10:25
To: Cross issues 
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?


Martin,

I think -Doomph.setup.sync.skip=true will avoid the use of USS by Oomph.

You can host your own index somewhere else as follows:

  
https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Hosting_your_own_index_.2F_catalogs

On 21/05/2017 7:36 AM, Oberhuber, Martin wrote:
Hi cross-project,

While testing the brand-new Oxygen M7 packages, I came across an issue that I 
wanted to share.
Plus, I have no solution yet so I’m looking for help!

At a customer site, I want to use Oxygen Packages, but I’m sitting behind an 
authenticating proxy there.
So I have no Internet access. And if I had, I’d still want to make sure no data 
gets sent to the
Internet from that customer.

I easily found out how to disable AERI, to avoid error reporting reaching out:
https://wiki.eclipse.org/EPP/Logging#Disabling_AERI_in_builds_and_runtime_Eclipse

But how can I disable the new USS used by Oomph and MPC?

I found a related forum thread 
[1]<https://www.eclipse.org/forums/index.php/t/1081127/>, but it was no help. 
What I need is a System Property to turn off all internet access. I still want 
to use Oomph with locally stored setup tasks, but the attempt using USS or 
downloading setup.zip must be turned off.

Right now, I’m getting several exceptions logged due to Oomph/USS, and I want 
to get rid of them.
But what concerns me more, I think it is a valid use-case disabling all sort of 
“calling home” by Eclipse.
So I think that documentation on how to turn this off must be available very 
easily!

Any help / comments?

[1] https://www.eclipse.org/forums/index.php/t/1081127/

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River





___

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] Oxygen: How to turn off USS?

[Oberhuber, Martin]

Thanks so much for the quick answer, Ed!

I’ve added that System Property and will run with it for a while.

Still wondering if USS could also be turned off for the MPC (or globally for 
all clients?), but MPC is by far not so important since users of MPC are 
already prepared to access the Internet anyways.

Cheers,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

From:  on behalf of "Ed com>" 

Reply-To: Cross issues 
Date: Sunday 21 May 2017 at 10:25
To: Cross issues 
Subject: Re: [cross-project-issues-dev] Oxygen: How to turn off USS?


Martin,

I think -Doomph.setup.sync.skip=true will avoid the use of USS by Oomph.

You can host your own index somewhere else as follows:

  
https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Hosting_your_own_index_.2F_catalogs

On 21/05/2017 7:36 AM, Oberhuber, Martin wrote:
Hi cross-project,

While testing the brand-new Oxygen M7 packages, I came across an issue that I 
wanted to share.
Plus, I have no solution yet so I’m looking for help!

At a customer site, I want to use Oxygen Packages, but I’m sitting behind an 
authenticating proxy there.
So I have no Internet access. And if I had, I’d still want to make sure no data 
gets sent to the
Internet from that customer.

I easily found out how to disable AERI, to avoid error reporting reaching out:
https://wiki.eclipse.org/EPP/Logging#Disabling_AERI_in_builds_and_runtime_Eclipse

But how can I disable the new USS used by Oomph and MPC?

I found a related forum thread 
[1]<https://www.eclipse.org/forums/index.php/t/1081127/>, but it was no help. 
What I need is a System Property to turn off all internet access. I still want 
to use Oomph with locally stored setup tasks, but the attempt using USS or 
downloading setup.zip must be turned off.

Right now, I’m getting several exceptions logged due to Oomph/USS, and I want 
to get rid of them.
But what concerns me more, I think it is a valid use-case disabling all sort of 
“calling home” by Eclipse.
So I think that documentation on how to turn this off must be available very 
easily!

Any help / comments?

[1] https://www.eclipse.org/forums/index.php/t/1081127/

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River




___

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

[cross-project-issues-dev] Oxygen: How to turn off USS?

[Oberhuber, Martin]

Hi cross-project,

While testing the brand-new Oxygen M7 packages, I came across an issue that I 
wanted to share.
Plus, I have no solution yet so I’m looking for help!

At a customer site, I want to use Oxygen Packages, but I’m sitting behind an 
authenticating proxy there.
So I have no Internet access. And if I had, I’d still want to make sure no data 
gets sent to the
Internet from that customer.

I easily found out how to disable AERI, to avoid error reporting reaching out:
https://wiki.eclipse.org/EPP/Logging#Disabling_AERI_in_builds_and_runtime_Eclipse

But how can I disable the new USS used by Oomph and MPC?

I found a related forum thread 
[1], but it was no help. 
What I need is a System Property to turn off all internet access. I still want 
to use Oomph with locally stored setup tasks, but the attempt using USS or 
downloading setup.zip must be turned off.

Right now, I’m getting several exceptions logged due to Oomph/USS, and I want 
to get rid of them.
But what concerns me more, I think it is a valid use-case disabling all sort of 
“calling home” by Eclipse.
So I think that documentation on how to turn this off must be available very 
easily!

Any help / comments?

[1] https://www.eclipse.org/forums/index.php/t/1081127/

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
___
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.org-planning-council] Neon.3 update problem status

[Oberhuber, Martin]

Hi Carsten,

Regarding “non-deterministic”: One thing I’ve observed earlier is, that once a 
bundle is
Wired that wiring tends to “stick” if there are multiple alternatives (ie 
there’s ambiguity).
So it might make a difference in what order you install / update your stuff.

In my use-case, I could reproduce a wiring problem when I installed bundles 
with 
Command-line p2 and launched Eclipse on the full install (which was ambiguous).
I could resolve the issue by installing only part of my bundles, launching 
Eclipse
(which caused bundles to be wired OK), and installed the rest afterwards.

I cannot explain this behavior, but perhaps this observation helps …

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

On 09/05/17 11:45, "cross-project-issues-dev-boun...@eclipse.org on behalf of 
Carsten Reckord"  wrote:

Hi Marcel,

> did any of the three scenarios previously result in an error? In other
> words: Was the problem reproducible for you and is that reproducible
> situation now fixed?

Good question. I was able to reproduce the issue when it first came up by 
installing the Docker Client into a vanilla Neon.3, and also by updating a 
Neon.2 that had it installed. So I actually didn't try this time around.

As it turned out now that I did, I couldn't get the broken wiring to appear 
even with the current public Neon.3 version. Equinox now always wires both MPC 
and USS to the non-broken 4.3.6 version, whereas it did wire MPC to 4.5 before, 
causing the breakage. I guess there's some non-deterministic element in what's 
going on in bug 514149[1]? Otherwise I'm not sure what might be different...

At any rate, installations based on the new Neon.3a candidate are looking 
good from MPC's perspective.

Best,
Carsten

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=514149
___
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] Neon.3 Update Problems: To Fix and How to Fix?

[Oberhuber, Martin]

Ed Merks wrote:

➢ If nothing requires a given bundle, I would expect that bundle to be 
➢ removed from the profile, but I don't see the problematic bundles being 
➢ removed...

If I’m not mistaken, the current solution with Neon.3a is reverting the 
problematic http bundle to the Neon.2 version; so it’s supposed to be older 
(lower version) than Neon.3 .

Therefore, I’d expect that “updating” from neon.3 which has the newer bundle to 
Neon.3a which requires the older one would probably ignore the older bundle and 
wire the newer one … unless something explicitly removes / uninstalls the 
broken Neon.3 variant.

Jeff, are you reasonably confident that a p2.inf command to uninstall the 
Neon.3 bundle would only perform that operation at the time the Neon.3a update 
is installed … and not potentially at a later time?

I see some risk that 3rd party plugins which want to bring in their own http 
bundle would not be able to do so because we’d uninstall their payload … can we 
be reasonably sure that this scenario can’t occur, for example by specifying an 
exact 4-digit version in the p2.inf to remove the broken bundle ?

IMO, the “Update Neon.3 to Neon.3a” workflow is less important than fixing the 
“Neon.[012] -> Neon.3a” workflow.
So if in doubt, I’d rather not take too much risk enabling the 3 -> 3a update …

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River

On 25/04/17 17:19, "cross-project-issues-dev-boun...@eclipse.org on behalf of 
Ed Merks"  wrote:

Fred,

No I didn't try that.  It's much harder to try that.  Oomph itself is 
broken, so I can't run setup tasks.  Check for Updates finds no updates 
because I installed all the categories and their IUs don't have updated 
versions.   I tried explicitly installing Docker so that it would do an 
update, but that didn't not solve the wiring problem.  I also running 
the p2 task in an IDE with Oomph 1.8 where I can run setup tasks 
(because Oomph's dependency on userstorage is optional in 1.8) and where 
the wiring problems also occurred so that more things got updated, but 
this also did not resolve the wiring problem.  So it's not clear if 
updates to an already -broken IDE will fix that IDE; it doesn't look so 
promising, though I don't understand why that wouldn't work.   If 
nothing requires a given bundle, I would expect that bundle to be 
removed from the profile, but I don't see the problematic bundles being 
removed...

Regards,
Ed


On 25.04.2017 16:41, Frederic Gurr wrote:
> Thanks Ed.
>
> That sounds promising. Did you also test updating a broken ELWMS with
> the new repo?
>
> I'm currently trying to reproduce the error with EPP packages, but so
> far updating a Neon.2 package to Neon.3 (with "Check for Updates") did
> not result in a broken MPC. Not sure what I'm missing.
>
> Regards,
>
> Fred
>
> On 25.04.2017 16:30, Ed Merks wrote:
>> Fred,
>>
>> Installing the Eierlegende Wollmilchsau with this additional repository
>> in the p2 task's repository list results in an installation without
>> wiring problems.
>>
>> The profile of the installation contains version 2.3.0.20170421191 of
>> org.eclipse.linuxtools.docker.core with is indeed the version available
>> in
>> 
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final
>> so I think this is a good demonstration that installations creation from
>> this repository's contents will not have the wiring problems we've been
>> seeing in Neon.3.
>>
>> Regards,
>> Ed
>>
>>
>>> Ed,
>>>
>>> The temporary update site URL is:
>>>
>>> 
https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/3/artifact/aggregation/final
>>>
>>>
>>> Regards,
>>>
>>> Fred
>>>
>>> On 25.04.2017 15:13, Ed Merks wrote:
 Fred,

 What update site URL contains these results?

 Regards,
 Ed


 On 25.04.2017 14:28, Frederic Gurr wrote:
> Thanks Jeff,
>
> This is the comparison of the non-unique versions list:
>
> neon3_respin aggregation build 20.04.
> 
(https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/2/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt):
>
>
>
> org.apache.httpcomponents.httpclient
>   4.3.6.v201411290715
>   4.5.2.v20161115-1643
>   4.3.6.v201511171540
>   4.2.6.v201311072007
> org.apache.httpcomponents.httpcore
>   4.3.3.v201411290715
>   4.4.6.v20170210-0925
>   4.2.5.v201311072007
>   neon3_respin aggregation bui

Re: [cross-project-issues-dev] Neon.3 Update Problems

[Oberhuber, Martin]

Ed Merks wrote:

I don't know if the EGit update problems are at all related:
  https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_1758538
It definitely looks like a different problem, but 
org.slf4j.api_1.7.10.v20160921-1923 also comes from the update-neon-docker 
update site.  And that's not a version that's in 
http://download.eclipse.org/tools/orbit/downloads/latest-R, i.e., it appears 
not to be a released version.

IIRC there’s a policy that 3rd party libs for simrel must come from Orbit. 
Isn’t there a “simrel consistency check” that could validate 3rd party lib 
versions against Orbit-R automatically before we go ahead releasing something? 
Maybe related to Wayne’s IP Check Tooling?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6
___
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] UI tests on HIPP - segfaults and browser support

[Oberhuber, Martin]

Hi Carsten,

I suppose that libwebkitgtk.so is not installed or otherwise not working on 
your HIPP. 

Eclipse would usually prefer webkitgtk over xulrunner automatically if it’s 
available.
By enforcing webkitgtk, you enforced a non-working configuration. 

Perhaps at least temporarily you should consider running on GTK2, by setting 
the SWT_GTK3 environment variable to 0:
https://www.eclipse.org/swt/faq.php#gtkstartup

Since you probably don’t have shell access to you HIPP, you may have to file a 
Bugzilla asking Webmaster’s help to add a working version of libwebkitgtk.so to 
your HIPP.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6
 

On 03/02/17 11:36, "cross-project-issues-dev-boun...@eclipse.org on behalf of 
Carsten Reckord"  wrote:

Hi everybody,

Do any of you have UI tests running on HIPP? I'm running SWTBot tests on 
the MPC HIPP using Xvnc, and I'm currently having a couple of problems:

1. MPC is using the embedded SWT Browser widget, and since the default 
XULRunner support doesn't work on GTK3, I moved my tests to WebKit (using 
-Dorg.eclipse.swt.browser.UseWebKitGTK=true 
-Dorg.eclipse.swt.browser.DefaultType=WebKit). Now I just get a very 
nondescript "Internal browser is not available: No more handles" SWT error the 
first time the browser is initialized, and all my browser-related tests (still) 
fail.

2. I recently switched my target platform to Oxygen, and now my UI tests 
always segfault somewhere down the line:

> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f19ea78b510, pid=10922, 
tid=0x7f1b077af700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 
1.8.0_102-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode 
linux-amd64 compressed oops)
> # Problematic frame:
> # C  [libgdk-3.so.0+0x38510]  gdk_test_simulate_button+0x0

It looks like this happens the first time SWTBot "clicks" on a Link widget. 
But I don't have the faintest idea what to do about it.

What makes this even more complicated is that I can't reproduce any of this 
in my own Linux VM. So any ideas how to get this solved would be greatly 
appreciated.

/cheers
Carsten

-- 
Yatta Solutions GmbH
- Carsten Reckord -

  t  +49 (0)69 2475666-33
  f  +49 (0)69 2475668-0
  e  reck...@yatta.de
  
Anschrift Office Frankfurt a.M.
  Mainzer Landstraße 50
  60325 Frankfurt a.M.

Anschrift Office Kassel
  Universitätsplatz 12
  34127 Kassel 
  
Sitz, Handelsregister:
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

Geschäftsführung:
  Johannes Jacop

Kontakt Geschäftsstelle:
  t  +49 (0)69 2475666-0
  f  +49 (0)69 2475668-0
  e  i...@yatta.de

___
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] TCF participation in Oxygen

[Oberhuber, Martin]

Hi Wayne, all –

I’ve announced TCF participation in Oxygen on 10-Oct as per below.
But I still cannot find it on the list of participating projects:
https://projects.eclipse.org/releases/oxygen

Am I missing a step to take ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


From:  on behalf of Martin 
Oberhuber 
Reply-To: Cross issues 
Date: Monday 10 October 2016 at 13:19
To: Cross issues 
Subject: [cross-project-issues-dev] TCF participation in Oxygen

Hi all,

The TCF project will participate in Oxygen with offset +2. We currently plan to 
contribute version 1.5:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.5.0

Sorry if I missed this, but do I still have to toggle a flag for Oxygen 
Participation in the PMI ? I couldn’t find it when quickly looking …

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] TCF participation in Oxygen

[Oberhuber, Martin]

Hi all,

The TCF project will participate in Oxygen with offset +2. We currently plan to 
contribute version 1.5:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.5.0

Sorry if I missed this, but do I still have to toggle a flag for Oxygen 
Participation in the PMI ? I couldn’t find it when quickly looking …

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Mylyn participation in Oxygen

[Oberhuber, Martin]

Hi all,

The TCF project will participate in Oxygen with offset +2. We currently plan to 
contribute version 1.5:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.5.0

Sorry if I missed this, but do I still have to toggle a flag for Oxygen 
Participation in the PMI ?
I couldn’t find it when quickly looking …

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


___
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-dev] Notice that Eclipse Platform plans to no longer provide MD5 and SHA1 checksums for Neon (but still SHA512)

[Oberhuber, Martin]

Hi David,

One problem I’ve seen with sha256 is that I couldn’t find a Windows 
command-line executable to automatically check the checksums.

There’s a couple of UI tools, but for automation a plain command-line 
sha256.exe (build from GNU coreutils for example) would be good. And no, I 
wouldn’t want that to be based on Cygwin.

Does anyone have a pointer where to get such a command-line tool, or working 
instructions how to build myself ?
All I’ve found so far is cross-build instructions here:
https://bugzilla.redhat.com/show_bug.cgi?id=527060#c13
These did work for me but perhaps Eclipse should reference an easier way 
getting a tool when we switch to sha256 ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


From:  on behalf of 'David Williams' 

Reply-To: "eclipse-...@eclipse.org" 
Date: Tuesday 10 May 2016 at 02:37
To: "eclipse-...@eclipse.org" , 
"equinox-...@eclipse.org" , Cross issues 

Subject: [eclipse-dev] Notice that Eclipse Platform plans to no longer provide 
MD5 and SHA1 checksums for Neon (but still SHA512)

The topic of this note is about the downloads and checksums obtained directly 
from the the Eclipse Project. It does not involve the checksums from the 
"select a mirror" page -- that is controlled by the Eclipse Foundation -- nor 
any of the packages downloaded from http://www.eclipse.org/downloads-- also 
controlled by the Eclipse Foundation.  My intuition is that few "casual users" 
use our checksums but some adopters or committers might use them in automated 
scripts or builds.

If any of you do get checksums directly from 
.../eclipse/downloads/drops4//checksum/... then this note is for you.

We announced in Luna we would "stop producing MD5 and SHA1 checksums" after 
Luna's release (Bug 
423714)... and I am just 
now getting around to it. Since it has been a long time since that 
announcement, and since we are late in this cycle, I am cross-posting to 3 
lists to be sure those that might be impacted will be notified.

We will continue to provide SHA512 checksums and I recently decided to also 
provide SHA256 checksums since SHA256 seems to be popular "in the industry".

This RC1 effort is documented in Bug 
454784. If the removal of 
the MD5 and SHA1 checksums would unduly burden anyone, please say so in that 
Bug 454784 and we would 
be happy to accommodate.

I will soon be updating our wiki on How to verify a 
download
 to contain accurate information for Neon, but wanted to get this notice out 
now so if you are negatively impacted you would have time to say so.

Thank you,




___
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] [tm-dev] Any RSE dependencies in Neon?

[Oberhuber, Martin]

Hello Kaloyan,

Why do you think moving RSE to an “orphan project” would simplify things ?
Why couldn’t interested parties maintain RSE in its current project ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Kaloyan Raev
Sent: Saturday, December 12, 2015 9:15 AM
To: Cross project issues
Cc: TM project developer discussions
Subject: Re: [cross-project-issues-dev] [tm-dev] Any RSE dependencies in Neon?

The DLTK project contributes a DLTK RSE feature to the release train. My guess 
is that no one else on the release train depends on this DLTK RSE feature, so 
it would be easy to remove it if necessary.

From adopter's point of view, like JBoss Tools, Zend Studio also heavily relies 
on RSE.
The new o.e.remote really has some advantages like the Synchronized Project, 
but still misses some basic features of RSE:
  - Connecting to Windows systems (no cygwin please)
  - FTP connections
  - Remote Systems Explorer view, which allows browsing and editing files 
without creating a project on a remote system, but also on the local file 
system using the Local connection.

However, I suppose that Zend Studio, JBoss Tools and any other adopter can 
continue using RSE outside of the release train, while the project remains 
under the Eclipse Foundation.

BTW, something interesting I noticed is that IBM has already a fork of the RSE 
project. In the IBM Rational products the RSE plugins exist with the same 
org.eclipse.rse.* IDs, but with version 4.4.x. RSE under the Eclipse Foundation 
is still with version 3.7.2. This already causes a nasty fragmentation of RSE 
in the community. Any plugin that depends on the EF RSE most likely cannot be 
installed on IBM Rational due to dependency conflicts.

So, I have a suggestion. If the TM project has no interest in maintaining RSE 
in future, how about moving RSE to a new "orphan" project outside of the TM 
project, so those adopter who still rely on RSE can continue maintaining and 
improving it until they are ready to switch to the new alternative?

Kaloyan


On Sat, Dec 12, 2015 at 9:17 AM, Max Rydahl Andersen 
mailto:mande...@redhat.com>> wrote:
I know we are not on the release train but JBoss tools continues to use RSE.

Afaik there are still no replacement for the functionality it provides with 
respect to UI for connecting to ssh and ftp based systems.

If there are I would love to hear about them.

Thus my interest is still to keep it in.

If help is needed for including it let me know.

/max
http://about.me/maxandersen


> On 11 Dec 2015, at 19:13, Greg Watson 
> mailto:g.wat...@computer.org>> wrote:
>
> Are there any projects that have a dependency on Remote System Explorer (RSE) 
> in Neon? The TM project must decide if RSE will be included in the Neon 
> release. Currently there is only interest in including TM Terminal.
>
> Thanks,
> Greg
> ___
> tm-dev mailing list
> tm-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tm-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] TCF participation in Neon

[Oberhuber, Martin]

Hi all,

Target Communication Framework (TCF) intends to participate in Neon with an 1.4 
release:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.4.0

Our offset will remain at +1.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Make sure that you sign with Java 8 if you are building and packing with Java 8

[Oberhuber, Martin]

Thanks Kosta for the heads up,

Just to be clear, I assume Tycho / CBI are doing the right thing so no changes 
needed in that case?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin 
Komissarchik
Sent: Friday, October 16, 2015 3:03 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Make sure that you sign with Java 8 if you 
are building and packing with Java 8


A public service notice since many projects are moving to Java 8 for Neon… If 
you build and condition/pack with Java 8, it’s important that you sign using 
Java 8, otherwise you could run into some really bizarre issues with your 
.pack.gz files failing verification after unpacking. By default, the sign 
command uses Java 6. Please refer to the following wiki for instructions on how 
to sign with Java 8.



https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29



Thanks,



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

Re: [cross-project-issues-dev] Mars M7 Simultaneous Release repository is now visible

[Oberhuber, Martin]

Hi David, all -

Thanks for the notice, I've tested the new installer, it's great stuff !
Big thanks & Kudos to the Oomph team and everyone else who contributed to this !

Just to make sure others don't run into the same pitfalls that I did -
the installer is actually launched by starting "oomph", it needs Java 7 and is 
a bit unfriendly when it gets only 6  :)

I've filed 2 bugs to track improving this for the wider community to use more 
intuitively:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466864
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466865


Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Friday, May 08, 2015 4:10 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Mars M7 Simultaneous Release repository is 
now visible

The M7 repository is now ready, at the built-in URL of
http://download.eclipse.org/releases/mars

(And includes M6 and M5 too, in that composite).

Most of the EPP packages are available, or will be soon, at
https://www.eclipse.org/downloads/index-developer-installer.php

That is a new URL, to encourage people to try "the Installer" -- and please do 
give it a try -- but if you want the previous, traditional page, for now you 
can still use
https://www.eclipse.org/downloads/index-developer-default.php

Note: a few packages are still waiting for a +1 from the package maintainers.

NOTE: The 'Eclipse IDE for Java and DSL Developers' package, will not be 
available until Monday (due to a missing piece of it) and in fact,
if M6 users of that package updated now (before Monday) they would risk losing 
some function ... but if that does happen, they can revert, if they would like,
and either way, they will get the update on Monday, once the package work is 
re-done (and the EPP repo updated).

Good luck and test well ... not much time left to fix any issues found!
___
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] Mars M7: TCF Terminals -> TM Restructuring is DONE

[Oberhuber, Martin]

Hi all,

I'd like to inform you that as per today and with our Mars M7 contribution, the 
restructuring of "TCF Terminals" to the TM project is complete.

The new repo is here and activated in simrel:
http://git.eclipse.org/c/tm/org.eclipse.tm.terminal.git

The new TM Terminal 4.0 can be installed from Marketplace:
https://marketplace.eclipse.org/content/tm-terminal

Remaining ACTION is for the EPP packages to please replace any 
"org.eclipse.tcf.te" feature references with "org.eclipse.tm.terminal.feature".

Please let me know if there's any questions !

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] How to merge (subsets of) 2 git repos into 1, preserving history ?

[Oberhuber, Martin]

Thanks Mickael,

Your solution looks simple and compelling, but I'm afraid it would merge the 
_entire_ two repositories.

We only want the terminal/ and terminals/ subtrees respectively, with any 
history for stuff outside those trees pruned away ...

Thanks for the hints so far, I'd appreciate more tips on the restructuring bug 
to avoid spamming cross-project :)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=462230

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Thursday, April 09, 2015 11:36 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] How to merge (subsets of) 2 git repos 
into 1, preserving history ?

On 04/09/2015 11:14 AM, Oberhuber, Martin wrote:
Hi all,
Hi,

1.  Create a new git repo under /gitroot/tm/org.eclipse.tm.terminal.git

2.  Fill it with the following subtrees from 2 other git repos, including 
all history in those subtrees respectively:

a.   http://git.eclipse.org/c/tm/org.eclipse.tm.git/tree/terminal

b.  http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/terminals
Unfortunately, those repositories seem to have colliding content (pom.xml, 
.project... filed under the same relative location). This will require actual 
conflict resolution.
Do you also need to keep all branches/tags, or just merging master branches 
with history is enough?
If the later:
  $ cd org.eclipse.tm.terminal/
  $ git remote add tcf git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.git
  $ git remote add tm 
git://git.eclipse.org/gitroot/tm/org.eclipse.tm.git
  $ git fetch tcf master
  $ git merge FETCH_HEAD
  $ git fetch tm master
  $ git merge FETCH_HEAD
// Have fun with actual merging of files, that's where most of the work is. 
Apparently, there are "only" 8 files to merge, some of them being trivial, so 
it may be only 1 hour of work.
  $ git add admin/target-defs/*.target admin/* .gitignore
  $ git commit -m "Merge TM and TCF"
  $ git push origin HEAD:master

HTH
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat<http://www.jboss.org/tools>
My blog<http://mickaelistria.wordpress.com> - My 
Tweets<http://twitter.com/mickaelistria>
___
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] How to merge (subsets of) 2 git repos into 1, preserving history ?

[Oberhuber, Martin]

Hi all,

Sorry for the wide distribution, but I'm sure somebody has done this before and 
any pointer would be very helpful.
The TCF/Terminals restructuring which I mentioned earlier has passed its review 
so we want to proceed now:


1.   Create a new git repo under /gitroot/tm/org.eclipse.tm.terminal.git

2.   Fill it with the following subtrees from 2 other git repos, including 
all history in those subtrees respectively:

a.   http://git.eclipse.org/c/tm/org.eclipse.tm.git/tree/terminal

b.  http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/terminals

I have already reached out to webmaster who could provide the new git repo, but 
now we're wondering how to merge/import the 2 git histories.

Please put any hints/advice on the restructuring bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=462230

Many thanks in advance !
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] FW: Heads Up: TCF Terminals Moving to TM

[Oberhuber, Martin]

Hi all,

We have been convinced that contributing under a foreign project's namespace is 
not a good idea; on the other hand, the deprecated legacy 
org.eclipse.tm.terminal.view feature has already been removed from the simrel, 
so if there's any existing adopter of that one he will be broken in M6 since we 
cannot proceed with the move before the move review is complete.

Find attached what I have proposed to the EPP packages (pull in the existing 
org.eclipse.tcf.te.terminals.feature for M6 such that we get wide exposure and 
feedback).
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03448.html

Please discuss any comments, concerns or questions on the Move Review bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=462230

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Oberhuber, 
Martin
Sent: Monday, March 16, 2015 6:42 PM
To: Cross project issues (cross-project-issues-dev@eclipse.org)
Subject: [cross-project-issues-dev] Heads Up: TCF Terminals Moving to TM

Hi all,

You might be aware that based on the original TM Terminal view, the TCF Project 
has come up with a much enhanced terminal:
https://marketplace.eclipse.org/content/tcf-terminals

In order to simplify code adoption and contributions, we want to restructure 
the codebase and re-unite it with the original TM codebase.
The result will be called "TM Terminal 4.0" but will contain the related TM 
_and_ TCF code in a single, small git repository.
Here is the respective restructuring review:
https://projects.eclipse.org/projects/tools.cdt.tcf/reviews/move-tcf-terminals-code-tm-project

Now unfortunately the review is scheduled to complete by April 1 which is after 
M6, but we would like to give adopters
a preview of the new Terminal with M6 in order to get more feedback. Thus 
here's what we are planning:

-  The TM project will no longer contribute its 
org.eclipse.tm.terminal.* to the simrel

-  Instead, the TCF project will contribute 
org.eclpse.tm.terminal.*_4.0 to the simrel (already using the *new* namespace).

If you do not take any action, you will simply see the new "4.0" version of 
those features from TCF, giving you the new tabbed terminal view.
Downstream consumers would only be affected if they consume 
org.eclipse.tm.terminal.(ssh|telnet|view) directly from the TM repo rather than 
simrel repo.
As far as I can tell, this shouldn't affect anyone, but wanted to make sure 
everyone is aware.
The original Terminal widget (org.eclipse.tm.terminal) is not affected by the 
restructuring, only the view and the connectors.

For now this is just a heads up; more details are on the epp-dev mailinglist,
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03447.html

We are planning to add the new "TM Namespace" features to the TCF simrel 
contribution over the course of the week.
I will send another notification once the new features are available.

Please let us know here on the list of any concerns or questions !
Or comment directly on the Move Review if you want.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

--- Begin Message ---
Hi Package Maintainers,



We have been convinced that contributing from TCF under a foreign namespace is 
not a good idea.

On the other hand, the deprecated legacy terminal view has already been removed 
from the simrel:
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=d677d5a6ae094bb2d1a7136be9d5b1d84c62740d



This means there is now some action strongly suggested, or packages might fail 
to build or build against outdated (M5) terminal contributions:

-  jee : Remove legacy terminal.view , optionally add the new 
tcf.terminals.view - Bug 
462087<https://bugs.eclipse.org/bugs/show_bug.cgi?id=462087>

-  reporting : Remove legacy terminal.view , optionally add the new 
tcf.terminals.view - Bug 
462089<https://bugs.eclipse.org/bugs/show_bug.cgi?id=462089>

-  parallel : Optionally add org.eclipse.tcf.te.terminals.feature AND 
org.eclipse.tcf.te.terminals.rse.feature

-  cpp : Optionally add org.eclipse.tcf.te.terminals.feature AND 
org.eclipse.tcf.te.terminals.rse.feature



For the must-have changes in jee and reporting, we have created bugs and Gerrit 
changesets.

Since I am an epp committer, I think I could apply these for you, but I would 
like the package maintainer’s OK before I do that.



I would strongly recommend also applying the optional changes (adding the TCF 
Terminals View) such that users can see the new view and provide feedback.

Without doing this, the Terminal view would be GONE in the respective packages 
in M6 and only reappear in M7 once the move has been compl

[cross-project-issues-dev] Heads Up: TCF Terminals Moving to TM

[Oberhuber, Martin]

Hi all,

You might be aware that based on the original TM Terminal view, the TCF Project 
has come up with a much enhanced terminal:
https://marketplace.eclipse.org/content/tcf-terminals

In order to simplify code adoption and contributions, we want to restructure 
the codebase and re-unite it with the original TM codebase.
The result will be called "TM Terminal 4.0" but will contain the related TM 
_and_ TCF code in a single, small git repository.
Here is the respective restructuring review:
https://projects.eclipse.org/projects/tools.cdt.tcf/reviews/move-tcf-terminals-code-tm-project

Now unfortunately the review is scheduled to complete by April 1 which is after 
M6, but we would like to give adopters
a preview of the new Terminal with M6 in order to get more feedback. Thus 
here's what we are planning:

-  The TM project will no longer contribute its 
org.eclipse.tm.terminal.* to the simrel

-  Instead, the TCF project will contribute 
org.eclpse.tm.terminal.*_4.0 to the simrel (already using the *new* namespace).

If you do not take any action, you will simply see the new "4.0" version of 
those features from TCF, giving you the new tabbed terminal view.
Downstream consumers would only be affected if they consume 
org.eclipse.tm.terminal.(ssh|telnet|view) directly from the TM repo rather than 
simrel repo.
As far as I can tell, this shouldn't affect anyone, but wanted to make sure 
everyone is aware.
The original Terminal widget (org.eclipse.tm.terminal) is not affected by the 
restructuring, only the view and the connectors.

For now this is just a heads up; more details are on the epp-dev mailinglist,
https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03447.html

We are planning to add the new "TM Namespace" features to the TCF simrel 
contribution over the course of the week.
I will send another notification once the new features are available.

Please let us know here on the list of any concerns or questions !
Or comment directly on the Move Review if you want.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] TCF Participation in Mars

[Oberhuber, Martin]

(Resend with a proper subject)

Target Communication Framework (TCF) intends to participate in Mars with an 1.3 
release
(or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be 
backward compatible).

Key things we’re working on include

-  Improve the TCF Terminals View and have it picked up as the default 
terminal by EPP packages (instead of TM Terminal which drops from Mars)

-  Symbol resolver improvements for C++11 and ADA Debugging

-  Improve documentation for new adopters and extenders of TCF

Our release record is here:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0

Our offset will be +2 (since we depend on CDT)

And I couldn’t figure out where to “flip the flag” on the PMI to show Mars 
participation, so please let me know if anything is still missing.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Projects missing from Mars

[Oberhuber, Martin]

Doug,

As a committer on TM and a project lead on TCF I am violently opposed against 
keeping the TM terminal alive.

If you still believe that TCF terminal does not support multiple views, you are 
1.5 years or more late with your assessment.

As of today, the TCF Terminals view is at 100% feature parity compared to TM 
Terminal, and offers MUCH more (like drag-and-drop rearrangement of its 
multiple views for example, local terminal support, proper detection of target 
encoding and more). I've documented the feature parity on a bugzilla bug long 
ago if you want details (just don't have time digging that out now).

Please, don't make announcements like this without talking to the committers on 
the projects that you are talking about.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer
Sent: Thursday, December 11, 2014 9:03 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Projects missing from Mars

BTW, I am going to take another look at the TM Terminal. Dropping should be 
considered on hold at the moment. It might have a place with our o.e.remote 
strategy and has some UX features that are actually better than the TCF 
Terminal, like multiple views. Again no commitments but I should have a good 
understanding of where we need this to go by end of Jan.

BTW2, my biggest problem is that I'm releasing the LaunchBar in Luna SR-2 with 
CDT 8.6 and it has dependencies on all this stuff. So I'm walking a bit of a 
tight rope on this at the moment.

Doug.

From: , Martin 
mailto:martin.oberhu...@windriver.com>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Thursday, December 11, 2014 at 2:55 PM
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Projects missing from Mars

Hi Wayne, all -

Target Communication Framework (TCF) intends to participate in Mars with an 1.3 
release
(or probably 1.4 in case we end up releasing 1.3 sooner - at any rate it'll be 
backward compatible).

Key things we're working on include

-  Improve the TCF Terminals View and have it picked up as the default 
terminal by EPP packages (instead of TM Terminal which drops from Mars)

-  Symbol resolver improvements for C++11 and ADA Debugging

-  Improve documentation for new adopters and extenders of TCF

Our release record is here:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0

Our offset will be +2 (since we depend on CDT)

And I couldn't figure out where to "flip the flag" on the PMI to show Mars 
participation, so please let me know if anything is still missing.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Thursday, December 11, 2014 8:29 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Projects missing from Mars

Greetings folks.

I believe that I'm caught up with the opt-in.

The following projects are on the "dropped" list:
? Intent
? Target Management
? Data Tools Platform
? Java Workflow Tooling
? Marketplace Client
? Koneki
? Target Communication Framework

Both Intent and Target Management have informed the community that they've 
dropped out (though there is still some ongoing discussion regarding TM).

The rest have not yet created a release record. I'm expecting that least two of 
them (Data Tools and Marketplace Client) really do want to participate. I'll 
give them all a kick.

Wayne
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]
___
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] Observation: Frequent UI freezes when working with files

[Oberhuber, Martin]

Hi,

The most significant UI bloopers of the sort that Marcel mentioned I have seen 
in dialogs which validate input fields to actually be a file on every keystroke.

This really hurts if the path you’re trying to enter is a Windows UNC path 
(\\myserver\myshare\path\to\file.c) 
and you make the beginner’s mistake of just starting to type … trying to 
validate \\m and then \\my and then 
\\mys will cost an average time of 2-5 seconds per keystroke 
which is really painful. The workaround is typing your path in an external 
editor and then “pasting” in one shot, or typing a relative path first (which 
is obviously no file) and then inserting the \\ at the beginning as your last 
action.

I would love to see some sort of common infrastructure, which can be applied on 
arbitrary folders (not just IResource) and would return answers like isFile() 
asynchronously via callback in order to validate or invalidate dialogs … of 
course any new keystroke would need to cancel any pending asynchronous 
request(s) in order to just validate the new request.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, December 11, 2014 7:54 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when 
working with files

The IResource/IWorkspace API is backed by a completely in-memory skeleton of 
your file system structure. So any time you can query the resource model 
instead of the file system, you will see orders of magnitude performance 
improvement over direct java.io.File access. The IResource API (and EFS) 
encourage a batch-style interaction for the rare thing that is not in memory. 
For example IResource#getResourceAttributes or IFileStore#fetchInfo  returns a 
struct of all the attributes in a single native call, which is vastly more 
efficient than doing many calls such as if (file.exists() && file.isFile() && 
file.canRead()) {... }.

For the IResource API and much of the rest of the platform API, the best 
indicator is whether there is an IProgressMonitor in the API method. If the 
method takes a progress monitor, you probably don't want to call it from the UI 
thread. If there is no progress monitor, then for the most part you are ok. 
There are a few embarrassing exceptions to this (e.g.,, Job#join), but it's a 
useful rule of thumb.

John




From:Lars Vogel mailto:lars.vo...@gmail.com>>
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date:12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI freezes 
when working with files
Sent by:
cross-project-issues-dev-boun...@eclipse.org




I would guess that java.nio.file.Files.exists() [1] improves this access 
performance. Do you see these freezes cause by 
org.eclipse.core.resources.IResources or by directly using the Java File API?

[1] 
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#exists(java.nio.file.Path,%20java.nio.file.LinkOption...))

2014-12-10 14:53 GMT+01:00 Marcel Bruch 
mailto:marcel.br...@codetrails.com>>:
Hi,

I just want to share an insight I got from reviewing several ui freezes. One 
common cause for UI freezes are operations that touch the filesystem. For 
instance, File.isFile, File.lastModified, or 
WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I 
read on the internet it seems that some of these methods (e.g. getAttributes) 
may even take up to several seconds to return on windows systems.


This has been discussed elsewhere in the internet [1] and seems to be a 
long-standing issue in Java.



With this mail I’d like to make you aware of this (in case you did not know 
this before) and would like to encourage you to actually not execute file 
operations in the ui thread. We may also consider doing some kind of caching 
but such a discussion would by far be over my knowledge, and thus, should be 
left to discuss with the platform team.

For now, I think we would benefit very much if every project that accesses 
files/resources would review their code and think about refactoring some part 
of the FileSystem work (even if it’s only checking a file’s attributes) into 
background processes.

Best,
Marcel


[1] 
http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance


--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

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

___
cross-project-issues-dev mailing list
cross-project-issues-de

Re: [cross-project-issues-dev] Projects missing from Mars

[Oberhuber, Martin]

Hi Wayne, all –

Target Communication Framework (TCF) intends to participate in Mars with an 1.3 
release
(or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be 
backward compatible).

Key things we’re working on include

-  Improve the TCF Terminals View and have it picked up as the default 
terminal by EPP packages (instead of TM Terminal which drops from Mars)

-  Symbol resolver improvements for C++11 and ADA Debugging

-  Improve documentation for new adopters and extenders of TCF

Our release record is here:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0

Our offset will be +2 (since we depend on CDT)

And I couldn’t figure out where to “flip the flag” on the PMI to show Mars 
participation, so please let me know if anything is still missing.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Thursday, December 11, 2014 8:29 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Projects missing from Mars

Greetings folks.

I believe that I'm caught up with the opt-in.

The following projects are on the "dropped" list:
· Intent
· Target Management
· Data Tools Platform
· Java Workflow Tooling
· Marketplace Client
· Koneki
· Target Communication Framework

Both Intent and Target Management have informed the community that they've 
dropped out (though there is still some ongoing discussion regarding TM).

The rest have not yet created a release record. I'm expecting that least two of 
them (Data Tools and Marketplace Client) really do want to participate. I'll 
give them all a kick.

Wayne
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
[EclipseCon2015]
___
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] Remove CVS from Eclipse packages?

[Oberhuber, Martin]

I would suggest keeping it in "Standard" as long as the Eclipse Orbit project 
still uses CVS.
"Standard" should continue being the one-stop-shop for self-hosted development 
of Eclipse Plugins.
The CVS adapter is really small enough to not cause any harm IMHO.

Moving it out of the other packages, and offering CVS on the Marketplace 
instead, is a good idea.
Marketplace Statistics will also give some idea how many people still want it.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Moritz 
Eysholdt
Sent: Thursday, June 26, 2014 11:16 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Remove CVS from Eclipse packages?

+1

yes! let's get rid of this dinosaur!

regards,
  Moritz

On 26 Jun 2014, at 10:24, Mickael Istria 
mailto:mist...@redhat.com>> wrote:


Hi all,

Now that CVS is only used by 3.7% of people according to latest Eclipse survey, 
wouldn't it make sense to kick it out of default Eclipse packages to avoid 
showing the useless CVS entries (in show view or import for example) to the 
remaining 96.3% of Eclipse users? Instead, we could think of providing CVS on 
marketplace.

What do you think about it?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My 
Tweets
___
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] TCF (+2) participation in Luna

[Oberhuber, Martin]

Hi all,

TCF 1.2 will be participating in the Luna release train:
https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.2.0

The offset of TCF is +2 (after the CDT).

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] proposal: active eclipse installation count service

[Oberhuber, Martin]

Hi Igor,

This sounds very interesting !

Several companies / plugins do this already with their own methods (I remember 
Max Andersen's EclipseCon talk about JBoss tools [1], Pydev and Subclipse also 
do it from what I remember). I really like the idea of providing common 
infrastructure under Eclipse.org custody for these kind of things rather than 
everyone doing their own.

Just two thoughts,

1. As a commercial vendor of Eclipse-based tools, we'd probably disable the 
feature in our offering such that we don't offend those of our customers who 
are particularly paranoid and/or use our tools in secured labs without Web 
access; so in order for yourself to get reasonable statistics you should 
collect the product/branding ID along with the active plugin count. If you know 
that your plugin is in vendor X's tool but you don't get data from vendor X's 
product ID you'll get some idea how you have to correct your data.

2. At one customer of ours, the Pydev "call home" functionality caused nasty 
side-effects with the customer's authenticating web proxy and Equinox Secure 
Storage (forcing a login dialog on every Eclipse launch ... wasn't easy to 
discover what caused this). So keep an eye on the proxy policy when you call 
home.

I'm sure Max would have much other good advice on interesting data to collect. 
My feeling is that those users who consent to collecting _any_ data would 
likely consent to collecting more data than just active install counts. So you 
might better want to collect things like host OS, Platform Version, screen 
resolution alongside. I'm not a lawyer and the rules are different in many 
countries around the world (with Germany being particularly strict it seems), 
but since there's precedent for what you're trying to do I'd hope that the 
must-have legal requirements aren't too hard to figure out.

[1] http://www.eclipsecon.org/2013/sessions/google-analytics-eclipse-plugins

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Igor 
Fedorenko
Sent: Thursday, September 05, 2013 2:15 AM
To: Cross project issues
Subject: [cross-project-issues-dev] proposal: active eclipse installation count 
service

As you may or may not know, p2 can be configured to report feature or plugin 
"download stats" to a remote server [1]. As a side note, this reporting is done 
silently, i.e., without telling the user, and both installations from remote 
servers and local filesystem are reported.

I would like to propose extending this functionality and in addition to initial 
plugin/feature installation count, provide a way to count active plugin 
installations on ongoing basis.

Here is what I have in mind

* All installation counting functionality will be moved to a separate plugin, 
possibly outside of p2.
* There will be workspace preference to enable the counting, it will be on by 
default.
* When the plugin first starts, it will inform the user about the counting via 
a popup dialog or some other UI means and the user will have a choice to either 
acknowledge the counting or navigate to corresponding preferences page and 
disable counting there.
* The plugin will introduce new extension point that will allow bundles express 
their desired to report active installation count. I don't have exact details 
of the extension point yet, but I thin it should be similar to existing 
p2.statsURI/download.stats p2 configuration properties.
* Active installation count will be reported weekly and will only include 
information about bundles that have the extension point and were active since 
last report (hence "active installation count").
* On server-side, active installation count will use existing 
http://download.eclipse.org/stats/ infrastructure, but we'll probably recommend 
using different URLs for downloads and active installation stats.

I also volunteer to implement this, provided there are no objections to the 
proposed approach from Eclipse Foundation and somebody from platform committers 
agrees to help me review and merge the changes.

For the reference, I've opened bugzilla enhancement [2] request yesterday.

What do you think?

[1] http://wiki.eclipse.org/Project_Download_Stats
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=416456

--
Regards,
Igor
___
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] Status and outlook for Luna M1

[Oberhuber, Martin]

I have "declared intent" for tcf-1.2 by enabling the contribution ... but will 
keep the repo disabled until the build is green.

The build has been failing since 11.01am server time today so I'm not sure if 
it's a good idea adding more contributions before it is green ... in the end, 
someone (David?) would need to disable culprits.

FWIW, when running the "validate aggregation" in the b3 model editor I get this 
error right now:

Cannot complete the install because one or more required items could not be 
found.
Missing requirement: Sapphire XML Editor Support (Incubation) 
0.7.0.201308211148 (org.eclipse.sapphire.ui.swt.xml.editor 0.7.0.201308211148) 
requires 'bundle org.eclipse.wst.sse.core [1.1.600,2.0.0)' but it could not be 
found

Bundle(org.eclipse.wst.sse.core [1.1.600,2.0.0)) is required by:
  ValidationSet(main)
Contribution(Sapphire)
  
MappedRepository(http://download.eclipse.org/sapphire/0.7.0.201308211148/repository)
Feature(org.eclipse.sapphire.ui.swt.xml.editor.feature.group 0.7.0)
  InstallableUnit(org.eclipse.sapphire.ui.swt.xml.editor 
0.7.0.201308211148)

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Wednesday, August 21, 2013 6:01 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Status and outlook for Luna M1

Doesn't look good. I'll admit there is one day left, but so far 50 projects 
have not even enabled their "contribution" to Luna (pasted below).

Thank you to the 20 of you who have.

Remember, enable your contribution if you plan to participate (remove the 
"enabled="false"), but disable your repository if you are simply waiting for 
pre-reqs to get enabled or fixed (disable by adding enabled="false" to your 
repository element(s)).

Please ask if questions. (Or, please say if you have explicitly decided not to 
participate in Luna).

Thanks,

= = = = =

This list are those that have not yet enabled contribution:

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
egit.b3aggrcon - org.eclipse.simrel.build
emf-cdo.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
emf-query.b3aggrcon - org.eclipse.simrel.build
emf-transaction.b3aggrcon - org.eclipse.simrel.build
emf-validation.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
emft-emffacet.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jubula.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
linuxtools.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mmt-qvto.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
mylyn.b3aggrcon - org.eclipse.simrel.build
objectteams.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
ptp.b3aggrcon - org.eclipse.simrel.build
sapphire.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build
tm.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build
___
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] Are too many packages actually hurting Eclipse?

[Oberhuber, Martin]

What about an “ultimate” edition of Eclipse that has all plugins _available_ 
but not necessarily _activated_ ?

Technically, a base Eclipse with the most relevant / least intrusive plugins 
preinstalled , + a downloaded p2 repo in the same download bundle with add-ons 
that are installable . Pascal said in his EclipseCon talk this year, that on an 
existing downloaded p2 repo, a “zerocopy install” is possible so activating 
your add-ons should be fast and easy.

If then the categorization and granularity of the add-ons provided is 
meaningful, and the UI for selecting them looks nice, you get a single download 
plus add-on selection wizard where you quickly can activate add-ons that you 
need. And if you need more later you don’t have to hunt for downloads or update 
sites but you simply activate them.

Eclipse.org could provide the technical foundation of this “Eclipse Ultimate” 
plus there could be another edition hosted outside Eclipse.org where also 
non-Eclipse.org content (such as Subclipse, Emacs+, ColorThemes, …) are bundled.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
Christian
Sent: Tuesday, July 30, 2013 2:56 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

I am not sure about the disaster thing really. As we are also having the 
discussion about other IDE's look at IntelliJ just for a second 
(http://www.jetbrains.com/idea/download/index.html)

They have 2 downloads. One that is free and one that is everything.

That makes it at least very simple for users of the IDE. Even if you dont agree 
on that, 90 % of the downloads are from 4 pre-packed IDEs for Eclipse.

How about an "Ultimate" edition for Eclipse. Why do I have to make a choice 
whether I want to develop J2EE, Modelling or RCP or be a Tester ? We all know 
that you can do multiple things with one IDE at the same time. The download 
page makes us think we have to make a choice.

Von: Pascal Rapicault mailto:pas...@rapicault.net>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 30. Juli 2013 14:05
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

An all in one IDE is a recipe for disaster and will contribute to even more FUD 
around Eclipse.
Also I fail to see which improvements to the user experience can be done since 
we would not have a specific persona to focus on.
Instead I think we should focus on improving the integrations between the tools 
that are known to be installed together (yes ideally we would need user input 
on this). IMO this will have a better chance of success since it is much more 
focused and would also involve less ppl.


On 07/30/2013 12:13 PM, Konstantin Komissarchik wrote:
> so they are actually useful to end-users.

Actually, we have no evidence that users find packages useful. They download 
them because what else is there for them to do. Then if they are experienced, 
they know what’s included and how to install the missing pieces. If not, they 
thrash on forums wondering why Eclipse for Java Developers doesn’t come with an 
XML editor.

We can certainly measure the value of maintaining a menagerie of packages. All 
it would take is to put out an everything package alongside the existing ones 
and compare download numbers.

While it wouldn’t happen overnight, a single Eclipse IDE would have a unifying 
effect on the community, ultimately leading, I believe, to higher overall 
quality.

- Konstantin



From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Tuesday, July 30, 2013 2:46 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

On 07/30/2013 12:35 AM, Konstantin Komissarchik wrote:

Would user experience be better if there was only one Eclipse package on the 
main download site that had pretty much everything that’s in the aggregated 
repository?
I really don't think so.
Packages are a good way to start which includes most available relevant stuff 
for release-train.


---
___
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] [nebula-dev] Nebula Grid is available from Kepler update site

[Oberhuber, Martin]

Hi Tom,



I can confirm it's riena:



$> ssh build.eclipse.org

$> cd /home/data/httpd/download.eclipse.org/releases/kepler/201306260900

$> unzip -p content.jar | grep -B 50 'require.*nebula.widgets.grid' | egrep 
'unit|nebula.widgets.grid'

























I don't know from what repository riena (or the aggregator) pulls in the odd 
version.



Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6





-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Tom Schindl
Sent: Friday, June 28, 2013 3:08 PM
To: Nebula Dev
Cc: Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site



Wild guess is that one of the release train projects uses it - IIRC riena used 
to use it.



Tom



On 28.06.13 13:51, Wim Jongman wrote:

> Hi,

>

> Apparently the Nebula Grid widget is available from the Kepler Update

> site. This should not be the case.

>

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

>

> Regards,

>

> Wim

>

>

> ___

> nebula-dev mailing list

> nebula-...@eclipse.org

> https://dev.eclipse.org/mailman/listinfo/nebula-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] What is a maintenance release

[Oberhuber, Martin]

Hi John,

I agree with you in principle, but in this case Kosta does have a point.

The Version Numbering document that you cite in [1] says
"The minor segment number must be incremented when a plug-in changes in an 
"externally visible" way. Examples [...] include [...]significant performance 
changes"

When XText decided to require EMF 2.9 in order to benefit from its significant 
performance improvements, it would have made sense to release it as XText 2.5 
with a minor version increment; those Version Numbering Guidelines should be 
followed to avoid adopter confusion.

Now this hasn't been done for Kepler, I'm not sure why it hasn't been detected 
earlier, and I'm not sure what the immediate implications are (other than EdW 
having to stick to XText 2.4.1 and not being able to upgrade yet). To me it 
sounds that Ed Merks' proposal of making sure that EMF 2.9 is a fully working 
drop-in replacement for EMF 2.8 in all cases is the right approach moving 
forward.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, June 27, 2013 9:22 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] What is a maintenance release

I realize this was a rhetorical question, but the requirement is that projects 
are capable of working with the version of their dependencies that is shipped 
in the same simultaneous release. In this case the Kepler version of XText 
requires the Kepler version of EMF. This is quite reasonable, and although some 
projects support multiple older versions of their dependencies, there is no 
requirement to do so that I'm aware of.

In both Eclipse versioning [1] and the more widely cited semantic versioning 
[2], version increases don't have transitive effect (unless dependencies are 
re-exported). I.e., just because the major or minor version of something I 
require changes, doesn't mean my version has to increase by the same magnitude. 
More concretely, the fact that EMF's minor version increased does not imply 
that XText's minor version must increase. If you follow such a transitive 
policy to its logical conclusion you will see the version numbers of individual 
components become meaningless, impossible to manage, and everyone would end up 
needing to increase their major version number just about every release.

[1] http://wiki.eclipse.org/Version_Numbering
[2] http://semver.org/

John




From:Ed Willink mailto:e...@willink.me.uk>>
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:06/27/2013 02:51 PM
Subject:Re: [cross-project-issues-dev] What is a maintenance release
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Hi Ed

I am trying to understand what if any release rigour exists in the
Eclipse release policies; indeed if there are any policies at all.

There is clearly a large discrepancy between my expectation and what I
observe in practice.

Regards

Ed Willink

On 27/06/2013 18:50, Ed Merks wrote:
> You've also had ample opportunity to notice the bounds on Xtext's
> contributions to the release train, so it's not clear what you're
> hoping to achieve after the fact by involving a broader audience.

___
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] Hudson seems to need a kick ...

[Oberhuber, Martin]

Ø  same here, can't access hudson. IMHO this happens too often.

+1

I’m really wondering what is special about the Eclipse.org infrastructure that 
causes these failures … the current “single point of failure” is a problem. And 
even if it doesn’t fail, with so many jobs on the initial page it’s often very 
slow (categorization would help probably).

I’m really looking forward to the HIPP initiative 
[1] 
announced by webmaster, or whatever else can be done to improve robustness.

[1] http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00925.html

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] SSH down on Build.eclipse.org?

[Oberhuber, Martin]

Note that you'll have to send your _externally visible_ IP address, which is 
sometimes nontrivial to find out.
This may help:
http://www.whatismyip.com/

I've had that problem in the past when some colleague of mine accidentally had 
3 invalid logins in a row - your whole subnet gets locked out.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Webmaster(Matt Ward)
Sent: Thursday, May 23, 2013 3:44 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] SSH down on Build.eclipse.org?

I've just checked and the service is responding.

Most likely it's one of 2 things:

1) You've been blocked due to multiple 'bad' logins (from you, or someone else 
on your subnet)
2) If this is the first time you've connected from your current IP, a block was 
created and an 'unblock' email was sent to the address we have on file for 
you(unless another committer on your subnet did it first)

If you send your IP to Webmaster I'll go digging.

-Matt.

On 05/23/2013 09:32 AM, Mark Russell wrote:
I can't get to build.eclipse.org via ssh.  But I can 
get there via http (http://build.eclipse.org).  anyone else having issues or is 
it just something local?

--
Mark R Russell
(724) 473-3140
Software Engineer in Test
Google Shopping Express
Google Pittsburgh


___
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] Apache Commons Net 3.2

[Oberhuber, Martin]

Hi all,

FYI, the TM/RSE project is considering updating from Apache Commons Net 2.2 to 
Commons Net 3.2 for FTP and Telnet support.
The older Commons Net is now 2.5 years old, and many bug fixes have gone into 
the library since.

The Commons Net 3.2 API is mostly unchanged, but we did find one regression in 
FTPClient#printWorkingDirectory() .
That regression was easy to work around on our side, and initial testing is 
going well though we haven't yet made a final decision whether we'll actually 
make the update for Kepler.

This is a heads-up for other projects to consider start testing against Commons 
Net 3.2 - more information here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=408242

To consume Commons Net 3.2, use this Orbit build:
http://build.eclipse.org/orbit/committers/orbit-I/20130514212025/I20130514212025/

Don't forget filing a "re-use from Orbit" CQ when you decide on updating.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Feature names and descriptions

[Oberhuber, Martin]

Hi Wayne,

Can you provide a preview URL of the packages pages ?

That would greatly help understanding what the final thing will look like, and 
how my feature's text blends with other feature's text.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton
Sent: Monday, May 13, 2013 9:19 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Feature names and descriptions

Greetings folks!

We're working on some updates to the packages pages. As part of this, we're 
going to display actual feature information rather than just a bunch of ids.

e.g on the "details" page for the Eclipse IDE for Java EE Developers [1], 
instead of showing the feature id, " org.eclipse.jdt", we'll show the feature 
label, "Eclipse Java development tools (binary runtime and user 
documentation).".

We haven't quite decided yet, but we may try to work in the description.

I've written a little script to extract this information directly from the 
features as they exist in the Kepler repository.

I've done a quick review, and have found a few misspelling and some other odd 
things. Since this information is used in other places, I think that it's 
pretty important to get it right.

For example, the description for "Acceleo" (org.eclipse.acceleo) is "Acceleo". 
I'm not sure that this provides anybody with a compelling reason to install 
this feature.

There are several features with descriptions that seem to assume that the 
reader will know what it is based on the project name (MoDisco, QVT, and some 
of the Mylyn subprojects stand out). IMHO, these descriptions should give me a 
reason to look into the project and find out more.

There are inconsistencies in format as well. Some are a few words or a phrase, 
some are complete sentences, some are short paragraphs, and some use bullets. 
I'm a fan of providing one or two sentences (no bullets or newlines) to 
concisely describe the feature.

Please take a few minutes to look at your feature labels and descriptions to 
make sure that the information that you're providing is helpful for your 
intended audience. Please take a few minutes to makes sure that the 
descriptions use correct spelling and grammar.

Thanks,

Wayne


[1] http://eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
[EclipseConFrance 2013]
___
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] Request for comment: Provide standard update site locations

[Oberhuber, Martin]

Hi Michael,

> Likewise it is also sometimes *very* difficult to find the git/svn repository 
> of a given plug-in.

This is technically solved already with the Eclipse-SourceReferences header in 
the MANIFEST.MF file.
EGit supports this since version 2.0: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=327381

The Eclipse Platform acutally uses this, and the workflow for end users is 
really nice:
- Open the Plug-Ins view in the Plug-In Development Perspective
- Pick your plugin, right-click > Import As > Project from a Repository...
- It clones the git repo into your workspace and you're all set. 

Not being able to pick a location for the cloned repo is one of the known 
limitations right now, but for an occasional look-up in a plugin that you don't 
need too often, or for a quick patch, that is still good enough.

What I don't know at this time is in what respect Tycho / CBI already supports 
generating the Eclipse-SourceReferences header,
and what a project needs to do to adopt this.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Michael 
Scharf
Sent: Friday, March 15, 2013 4:02 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Request for comment: Provide standard 
update site locations

Hi all,

I wonder what the sate of "findable" updates sites is? There has not been much 
progress on the issue recently. I think one problem is to have a common pattern 
but another problem is "how to find the update site". Today I was looking for 
the update site of EMF 2.9.
This is not easy. Once I found it, it could not update because the plug-ins I 
needed also needed a new version of xtext. So another round of hunting started.

As a user this is really difficult. P2 solved a lot of dependency problems but 
the new type of dependency is to find the correct update site. Once they are 
found, p2 does a great job...


Ideally there should be a simple update site and repository search facility 
that allows to look up the update sites and the repository for a given plug-in 
or feature.

Hmm, thinking of it, it would be nice to get form a package or a class to the 
project, the update site, to the repository, mailing list, newsgroup, and to 
the correct component in bugzilla etc.

E.g. on the http://projects.eclipse.org page could be a search button that 
would find the resources associated with a package, plug-in or feature.

Or does such a facility already exist and I have not found it?

Michael

On 4/18/12 6:57 PM, Miles Parker wrote:
> Hi all,
>
> Please see the bug below. Isn't it about time we had a good common approach 
> to this?
>
> 377111: Provide standard update site locations 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=377111
>
> Please follow up on bug.
>
> cheers,
>
> Miles
> ___
> 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] Wait ... don't release yet! ... delay one week, Friday 3/1

[Oberhuber, Martin]

Thanks Matthias –

So then in my understanding there is no contribution in Simrel outside egit 
itself, that would require egit-2.3 and thus the rollback should be fine.
Using 2.2 seems preferable to me, to get the fix for bug 391377 that Chuck 
Bridgham has mentioned.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn
Sent: Friday, February 22, 2013 11:34 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay 
one week, Friday 3/1

2013/2/22 Oberhuber, Martin 
mailto:martin.oberhu...@windriver.com>>
Kosta has a very good point here:

moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900<mailto:moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900>>
  unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 
'required.*git.*2\.3' | less

   


[…]



[…]
   



That should be all dependencies onto egit-2.3.
I think that egit.mylyn.ui comes from egit itself, but where does the mylyn 
github feature actually come from ?

yes, egit.mylyn.ui is egit's mylyn integration and comes with egit

mylyn github feature is the Mylyn GitHub connector which is part of the EGit 
contribution since it's
developed in the EGit project. So if the EGit contribution is rolled back to 
SR1 this would include
rolling back the Mylyn GitHub connector to 2.1, same holds true for 2.2.0 since 
all these features
come in the same egit.b3aggrcon file.

--
Matthias
___
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] Wait ... don't release yet! ... delay one week, Friday 3/1

[Oberhuber, Martin]

Kosta has a very good point here:

moberhuber@build:/home/data/httpd/download.eclipse.org/releases/juno/201302220900>
  unzip -p content.jar | egrep 'unit id=|required.*eclipse..git' | grep -B 10 
'required.*git.*2\.3' | less

   


[…]



[…]
   



That should be all dependencies onto egit-2.3.
I think that egit.mylyn.ui comes from egit itself, but where does the mylyn 
github feature actually come from ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin 
Komissarchik
Sent: Friday, February 22, 2013 9:24 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay 
one week, Friday 3/1

I hate to throw a stick in the spokes, but what happens if another project in 
the aggregate repository already has a min dependency on EGit 2.2 or even 2.3?

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias 
Sohn
Sent: Friday, February 22, 2013 12:15 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay 
one week, Friday 3/1

2013/2/22 David M Williams 
mailto:david_willi...@us.ibm.com>>
After some painful conversation with the Planning Council members, the 
conclusion was to delay the release 1 week, but not do a full respin, to only 
revert the EGit contribution.

The plan is to redo the common repository and EPP packages, with the EGit 
contribution reverted to what it was in SR1, which I believe is identical to 
what it was in RC3. There are a few "technical tricks" I can try to accomplish 
this, so all other projects do not have to do any re-work ... just wait until 
Friday 3/1, before making your releases "visible".

no, SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 
contains EGit 2.1.0
I'd prefer if you could rollback to 2.2.0 but if the planning council decided 
otherwise be it like that.

[1] 
https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno_maintenance&id=e5209e06bfbe2284a96b1ce357b9fcd1053072d1

--
Matthias
___
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] Wait ... don't release yet!

[Oberhuber, Martin]

Simrel is a composite repo, isn't it ?

So what about simply adding 1 branch to the composite which contains egit-2.3.1 
and then respinnnig the packages ?
That shouldn't take more than the week-end , even including all mirroring ?

I sympathize with Alexander (GEF) and Fred (m2e), but IMO any risk should be 
avoided at this time ...
I'm sure the PC will make a good decision how to proceed , based on technical 
feasibility and risk.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Friday, February 22, 2013 3:15 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Wait ... don't release yet!

I'm obviously a little late with my "Wait" message, but given the "data 
damaging" bug reported by EGit, We need to think this through and come up with 
an alternative plan.

All those plans would involve not releasing today.

I'll call for an "Emergency meeting" of the Planning Council today at 1:00 PM 
Eastern to discuss possible approaches, solutions, and actions required.

Off hand, a complete respin cycle would take at least a week, maybe two, but 
there might be ways to simply remove EGit, putting it back at its SR1 level, 
producing that better known quantity, and letting EGit follow their own release 
schedule, as they have been.

Sorry for the late "Wait" notice.

___
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] Reminders for Juno SR2 final steps

[Oberhuber, Martin]

+1 for respinning, and declaring Juno SR2 early next week.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Skerrett
Sent: Friday, February 22, 2013 2:19 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps

I think we need to look at respinning SR2.  For the last 18 months we have been 
pushing the entire community towards git, so now introducing a significant 
regression into eGit would just be bad news for our users.



From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus 
Knauer
Sent: February-22-13 5:33 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps

No, I wasn't aware of this bug which is a bit scary, thanks for bringing it up 
here on cross-projects. Today I am trying very hard to stay calm, but it seems 
that this is not that easy.

Some of my thoughts...

- I think it's too late to stop Juno SR2 with this kind of bug. I would proceed 
today as planned, everything else seems to involve a very high risk.
- Discuss possible workarounds/solutions for Juno SR2 in parallel...
- If I were a member of the EGit team, I would try to educate my users how to 
upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing list, other 
channels...

Regards,
Markus
On Fri, Feb 22, 2013 at 10:44 AM, Gunnar Wagenknecht 
mailto:gun...@wagenknecht.org>> wrote:
Greetings,

I'm sorry if this has been brought up and discussed elsewhere already. But 
there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno SR2 a high 
risk for users.

See here for details:
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html

Am 19.02.2013 18:04, schrieb David M Williams:

This week or next, update your b3aggrcon files with your "final
location" so the Juno aggregator could in theory be ran again. We don't
plan to, but, you never know. (And, don't forget to update Kepler, if
you are using the same input for that.)

Given that there is a severe bug in EGit. Isn't there a chance to update the 
repo and the packages with EGit 2.3.1?

I understand that it's very late in the game. But the packages will stay there 
forever on Eclipse.org for download by everbody. Those packages will contain an 
EGit version that contains a know bug which may delete uncommitted source code 
in a working copy.

-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



--


###
EclipseSource Group
Telefon: +49 721 664733-0 (GMT +2)
Telefax: +49 721 66473329

http://eclipsesource.com



Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] RC3 and M5 staging repositories are complete

[Oberhuber, Martin]

Thanks Dave.

Quick reminder also that eclipse.org servers are moving on Saturday Feb 9, 
leaving the repos
unreachable, so there's a risk that week-end work can't make it into the Monday 
builds.
I guess that +1 projects best be "done" Friday night for SR2, just in case.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Thursday, February 07, 2013 2:15 AM
To: Cross project issues
Subject: [cross-project-issues-dev] RC3 and M5 staging repositories are complete

These repos are ready for testing and EPP packages to be created.

http://download.eclipse.org/releases/maintenance/
http://download.eclipse.org/releases/staging/

Be sure to check the "repo reports".

http://build.eclipse.org/simrel/juno/reporeports/
gmf appears to be missing a lot of about.html files, and
rse, rap, jetty and others appear to be unsigned.
This is RC3 folks ... only one week to correct these problems.

http://build.eclipse.org/simrel/kepler/reporeports/
Similar but much worse (but, congratulations to stardust and m2e-wtp for 
getting into M5 ... even if I only know that because you stand out on some of 
the "needs work" lists :)

'maintenance' I'll leave alone until late Monday, in case people need a 
consistent repo to test against, but feel free to make new contributions 
beginning Friday.
I've disabled the "run aggregation" jobs until Friday, to avoid confusion.

'staging' I'll promote as M5 so that on Friday it will join with M4 in the 
composite repo at .../releases/kepler.

NOTE: at one point, we mentioned possibly "not announcing" on Friday, since 
"eclipse.org" will be offline this weekend but my current thinking is to go 
ahead and announce like usual, but just include a reminder that "eclipse.org" 
will be offline and provide a pointer for people to read (on Friday :), such as
http://eclipse.org/org/press-release/20130111_EclipseDownDueToMove.php
I think it'd be about as confusing either way ... though might cause a "rush to 
download" on Friday?

Thanks,

___
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] aggregation conflict of TM Terminal with PTP

[Oberhuber, Martin]

It looks like org.eclipse.ptp.remote.terminal has an "includes" statement for 
the Terminal with an old version:

cd 
/home/data/httpd/download.eclipse.org/tools/ptp/builds/kepler/milestones/M5/features
unzip -p org.eclipse.ptp.remote.terminal_7.0.0.201301162143.jar feature.xml


[...]
   
   

I'm not sure what's the best way resolving this. It might work if PTP simply 
builds after TM
(assuming that it can pull in the TM milestone contribution).

There used to be some conversation about "includes" vs "requires" of features, 
and I seem
To remember that "requires" was always considered better...

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David Dykstal
Sent: Sunday, February 03, 2013 7:51 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] aggregation conflict of TM Terminal with PTP

I get the following problem when validating the TM M5 contribution for Kepler. 
It appears that PTP has a strict requirement for a particular version of 
tm.terminal. Can this be corrected?
I haven't yet filed a PTP bug, but will if it is necessary.

Cannot complete the install because of a conflicting dependency.
Only one of the following can be installed at once:
  Target Management Terminal Widget 3.2.1.201209191030 (org.eclipse.tm.terminal 
3.2.1.201209191030)
  Target Management Terminal Widget 3.2.2.201301071106 (org.eclipse.tm.terminal 
3.2.2.201301071106)
  Target Management Terminal Widget 3.2.0.201205300905 (org.eclipse.tm.terminal 
3.2.0.201205300905)

bundle(org.eclipse.tm.terminal 3.2.2.201301071106) is required by:
  ValidationSet(main)
Contribution(TM)
  MappedRepository(http://download.eclipse.org/tm/updates/3.5milestones)
Feature(org.eclipse.tm.terminal.local.feature.group 0.2.100)
bundle(org.eclipse.tm.terminal 3.2.0.201205300905) is required by:
  ValidationSet(main)
Contribution(PTP)
  
MappedRepository(http://download.eclipse.org/tools/ptp/builds/kepler/milestones/M5)
Feature(org.eclipse.ptp.feature.group 6.0.4.201212181107)
  InstallableUnit(org.eclipse.ptp.remote.terminal.feature.group 
7.0.0.201301162143)
InstallableUnit(org.eclipse.tm.terminal.feature.group 
3.2.0.201205300905-41-312316411A16)



-- David Dykstal,  Architect - Rational Developer for Power Systems
___
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] Heads up ... new "Recommended" Orbit repo for Juno SR2

[Oberhuber, Martin]

Hi Stephan,

I’d love to provide Commons Net 3.2 for Kepler but it has not been ip-approved 
yet.

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=7026

The release was cast by Apache on 3-Dec-2012 – definitely too late to get it 
approved and included in Juno SR2 but I much hope Kepler will work.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=346892#c7

For the records, I had reported the deadlock problem with the 3.x version to 
Apache on 24-May-2012,
(that was after we had got 3.1 ip-approved and put into Orbit), but we’ve been 
happily living with
Commons Net 2.2 so far though I’m glad the issue is finally fixed.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Tuesday, January 29, 2013 9:17 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit 
repo for Juno SR2


It is too late for SR2, for several reasons, but a great suggestion for Kepler, 
if the TM project (or others) want it.

Just to briefly outline the reasons, we are already up to RC2 and RC3, so I 
think it'd have to be a "blocking problem" to cause all that stress, and it 
doesn't sound like a blocking problem, from what I've heard. I don't know who 
else uses it, but typically it's only reasonable to give the "community" of 
projects and adopters a minimum of a month, or two, notice of what's coming in 
a maintenance release, especially if it involves a "major" version change [And, 
I mean a month or two before the first release candidate, not the "GA date"]. 
We in Orbit do have a generic "ramp down" process for the purpose of stability, 
so it'd have to be a pretty strong case.  But, if you and the TM project think 
it is a blocking problem, and worth the churn, feel free to open bugs, CQs, 
etc., and continue to make your case. I'm just giving you my impression from 
the little I know.

[I would say it would have been a good suggestion a month or two ago, but not 
sure when 3.2 was released, since the date on their web site says "TBA" (even 
though it appears to be available for download), so, maybe just released?]

And, Kepler is not that far away. I don't recall seeing the "CQ deadline" for 
Kepler officially announced recently by the Eclipse Foundation, but its 
typically "M5" which is just a couple of weeks away (February 8). (Its not that 
they can not be submitted after that, but those submitted by the M5 deadline 
allows for proper planning, etc. and thus given higher priority, all else being 
equal). But, I'm not specking for the Eclipse Foundation ... I hope they 
weren't waiting for me :)  just saying what it has been in the past several 
yearly releases.

This is probably not a very constructive reply (and not what you wanted to 
hear) ... but, I do think we need to focus on stability for Juno, and new 
things for Kepler.

Thanks for bringing it up, though.





From:Stephan Leicht Vogt 
mailto:stephan.lei...@bsiag.com>>
To:
"cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>"
 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:01/29/2013 01:51 AM
Subject:Re: [cross-project-issues-dev] Heads up ... new "Recommended" 
Orbit repo for Juno SR2
Sent by:
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>




Hi

Some text went missing in the last mail. At least a:

Greetings
Stephan

---
Stephan Leicht Vogt
Senior Software Engineer

BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com<http://www.bsiag.com/>

On Jan 29, 2013, at 6:48 AM, Stephan Leicht Vogt 
mailto:stephan.lei...@bsiag.com>> wrote:

Hi all

Wouldn't it be better in this situation to pack the newest Version 3.2 from 
commons net to Orbit. Even if this comes up a little late and the R Version of 
Orbit is already promoted for Juno SR2. As Apache has released 3.2 this would 
be IMHO the better way than to pack an version which is two years old into the 
EPP. I would do the update but David Dykstal would have to open a (high prio?) 
CQ from the TM Project to use Apache Commons Net 3.2 so Orbit could open a 
piggyback.

What do you think? Or
· From: "Oberhuber, Martin" 
mailto:Martin.Oberhuber@DOMAIN.HIDDEN>>
· Date: Thu, 24 Jan 2013 18:30:34 +
· Accept-language: en-US
· Delivered-to: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
· Thread-index: AQHN+leHmRtU+ONw4kCQt/T6cQ

Re: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit repo for Juno SR2

[Oberhuber, Martin]

Hi David (and all),

We only want a build-time selection of Commons Net 2.2 from Orbit.

The MANIFEST.MF at runtime should be open to allow [2.2,4.0) or even higher (as 
per the recent ICU4J discussion).
The reason for picking 2.2 by default is that it's known to work safely whereas 
3.1 can produce a deadlock in some situations with Telnet.
End users should be able to deploy 3.2 (which is not in Orbit yet) or 3.1 (if 
they are not affected by the deadlock situation).

Does anybody know how to enforce a particular bundle version install at build 
time with Maven ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Thursday, January 24, 2013 7:11 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit 
repo for Juno SR2

To make the problem explicit, there's several versions in that repo:

org.apache.commons.net  1.4.0
org.apache.commons.net  2.1.0
org.apache.commons.net  2.2.0
org.apache.commons.net  3.1.0


There are likely 100 readers of this list that could give better "pom advice" 
than I could ... but, I could give some.

My main advice is "don't do that". :)  That is, don't put the restriction in 
the "pom" ... again, others can chime in here.

But, I suspect you not only want the restriction at "build time", but also at 
"run time", right?

If so, your manifest.mf files that "prereq" org.apache.commons.net should 
specify a range that is acceptable to you at runtime, and then, I believe, it 
doesn't matter what's in the Orbit repository, your build will "pull" an 
acceptable version. You can do it with "require bundle", but for many of these 
"common packages" its recommended to use "import package", for example,

Import-Package: org.apache.commons.net;version="[2.2.0,3.0.0)"
(or, what ever exact packages you need from that bundle).

Its my understanding that will suffice to get that specific version you want an 
"skip" the 2.1 and 3.1 versions. (But, I'm still learning maven and tycho).

Does this make sense? Do you currently specify a "minimum" version only?

I could be wrong and maybe there is some pom restrictions to apply too ... but, 
know these manifest restrictions are important.

If you are already doing that, though, and still not working ... then suspect 
others can better advice how to use "targets" in your pom file.
http://wiki.eclipse.org/Tycho/Target_Platform#Target_platform_configuration

I'll look forward to learning myself!





From:David Dykstal/Rochester/IBM@IBMUS
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:01/24/2013 12:45 PM
Subject:Re: [cross-project-issues-dev] Heads up ... new "Recommended" 
Orbitrepo for Juno SR2
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Dave --

TM needs to use version 2.2 of org.apache.commons.net from the repository. I 
haven't yet figured out how to specify this version restriction in our pom.xml 
file. Can you offer any advice here?

-- David Dykstal,  Architect - Rational Developer for Power Systems



From:David M Williams/Raleigh/IBM@IBMUS
To:Cross project issues 
(cross-project-issues-dev@eclipse.org)
 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:01/24/2013 11:23 AM
Subject:[cross-project-issues-dev] Heads up ... new "Recommended" Orbit 
   repo for Juno SR2
Sent by:
cross-project-issues-dev-boun...@eclipse.org




This morning I renamed our latest "M build" to an "R build" for use in Juno SR2.

http://download.eclipse.org/tools/orbit/downloads/drops/R20130118183705/

I will leave M builds in place until Tuesday, 1/27, to give time for anyone 
using them time to switch their builds scripts (or pom.xml files) ... but 
remove them on 1/28 as a not-so-friendly-reminder to update if you haven't 
already. (Of course, if anyone needs an extra day or two, just ask).

The only bundle that's changed from previous R build is org.apache.ant (to fix 
a label/name problem) but several new ones were added for project(s) that need 
them in an R-build.

< org.apache.ant_1.8.3.v20120321-1730.jar
< org.apache.ant.source_1.8.3.v20120321-1730.jar

> org.apache.ant_1.8.3.v201301120609.jar
> org.apache.ant.source_1.8.3.v201301120609.jar

> javaewah_0.5.6.v201210150900.jar
> javaewah.source_0.5.6.v201210150900.jar
> org.apache.commons.compress_1.3.0.v201212111400.jar
> org.apache.commons.compress_1.4.1.v201301140946.jar
> org.apache.commons.compress.source_1.3.0.v201212111400.jar
> org.apache.commons.com

Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository

[Oberhuber, Martin]

Hi all,

The reason why I (and others, eg CDT) started using "loose version specifiers" 
and composite repos was,
That we wanted to avoid the manual task of editing our versions in the B3 
editor with every contribution.

I was not aware of the recommendation to use explicit versions so far.

So if that is the recommendation, the next question is :
Does anybody have any automated way of promoting builds with explicit version 
specifiers to the simrel ?
What is the Planning Council's recommendation how to update the .b3aggr files ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Thursday, January 17, 2013 7:43 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up repository

What versions were you trying to contribute? I notice your Juno_maintenance 
version and master version point to different repositories, but each specify 
the same version of features ... there's nothing wrong with that! ... but, just 
wondering if that's what you intended?

Just going by the file system, I see you specified
org.eclipse.rse versionRange="3.4.0"
and what's on the ../releases/maintenance file system is
org.eclipse.rse_3.4.1.201209191030-7L7IFBY83omx__z0RFpKdWB-r5MS
but you have a more recent version in
/3.4milestones/SR2_RC1a/features/org.eclipse.rse_3.4.1.201301071106.jar

There is a couple of ways the aggregator (actually p2) could get the "wrong" 
version. It is basically just looking for a solution "that satisfies all the 
constrains". And yes it will try to 'get the highest version' but a) not sure 
that's guaranteed 100% and (more likely) someone else could say "I want exactly 
version of XYZ" in which case p2 might well be able to satisfy their 
requirement, with your "loose" requirement of one repository, that has lots of 
versions in it, and the only thing you specify is 'higher than 3.4.0'.

All of that leads me to my point ... I always recommend people specify 
_exactly_ what they want in the versionRange attribute, such as one example I 
saw as
versionRange="1.6.0.v20120328-0001-67T-95GFz05DNIrNLOSNK_NPj507"

OR, often easier, to me, is to specify a very specific repo that has only one 
version of that you want to contribute, such as for you ...

.../tm/updates/3.4milestones/SR2_RC1a

(If that was the one you wanted).

Occasionally this might lead to "early warnings", such as the aggregator (p2) 
will complain "so and so wants exactly version XYZ but was not found" and then 
everyone knows ... but, without specific constraints, p2 is doing its job of 
finding "a solution". For builds, you normally want to be sure they are exact, 
and repeatable.

Oh, and there are probably many less interesting things that could be going 
wrong :) ... but, that's the basics.

HTH





From:David Dykstal/Rochester/IBM@IBMUS
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:01/17/2013 12:14 PM
Subject:Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up 
repository
Sent by:
cross-project-issues-dev-boun...@eclipse.org




I agree. Warmups are good.

I really did mean /tm/updates/3.4milestones. I could have created one 
specifically for SR2, but we have been storing our milestone builds for our 
service releases in the directory I used. Seemed like the right spot for the 
repo.

The aggregation editor does show the features existing under "available 
versions" and I am on the Juno_maintenance branch. Is there some sort of 
filtering going on that is missing that version?

-- David Dykstal,  Architect - Rational Developer for Power Systems



From:David M Williams/Raleigh/IBM@IBMUS
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:01/17/2013 10:37 AM
Subject:Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up 
repository
Sent by:
cross-project-issues-dev-boun...@eclipse.org




Well, that's why we do a warmup :)

Did you meant to contribute .../tm/updates/3.4 to Juno or ... 
/tm/updates/3.4milestones?

I see the former in 'master' and later in 'Juno_maintenance'. I can't tell by 
the names, but often XXMilestones implies something older than XX repository? 
You need to use the Juno_maintenance branch of  org.eclipse.simrel.builds 
project.

HTH




From:David Dykstal/Rochester/IBM@IBMUS
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>,
Date:01/17/2013 11:19 AM
Subject:Re: [cross-project-issues-dev] Concluding SR2 RC1 warm-up 
repository
Sent by:
cross-project-issues-dev-boun...@eclips

Re: [cross-project-issues-dev] CVS access to Orbit

[Oberhuber, Martin]

This is an interesting suggestion...

but when the revision numbers are not the original CVS ones
(and for many repos also the module structure changed),
I'm not sure how much help that would be for the legacy cases
that Ed and others are interested in.

To me, the goal is not making our git repos CVS-accessible (we better use git 
for git).
The goal would be carrying forward some old functionality for old stuff rather 
than
breaking it, until the most relevant bits have been migrated.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Brian de 
Alwis
Sent: Wednesday, January 16, 2013 3:25 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] CVS access to Orbit

On 15-Jan-2013, at 2:22 PM, Denis Roy wrote:
> Maintaining pserver for all our old repos is possible -- after all, we've 
> been doing it for 13 years!  But cvs is arguably no longer maintained, it has 
> a habit of not always exiting cleanly leaving zombie processes, its archaic 
> file locking is prone to errors and it is Yet Another Service your webmaster 
> team would need to actively maintain.  We've added Git and Gerrit was simply 
> too cool to pass up, so CVS just had to go.

I wonder how difficult it would be to set up a sandboxed git-cvsserver 
instance?  It serves up a CVS pserver from a git repository.  It does require 
being able to create a database within the repository's .git directory to map 
hashes to revision numbers (hence the sandbox), which I'd guess are synthesized 
and may not actually match the revision numbers used in our actual CVS 
repositories.

http://schacon.github.com/git/git-cvsserver.html

Brian.
___
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] Status and outlook for Kepler M3

[Oberhuber, Martin]

I have re-enabled the TM and TCF features that depend on CDT - thanks for the 
reminder.

No version update of any kind, just re-enabling the bits at this point.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Wednesday, November 14, 2012 8:53 PM
To: Cross project issues
Subject: [cross-project-issues-dev] Status and outlook for Kepler M3

We've been without a clean build for past day or so but "we" just got one, so I 
promoted it to staging.

http://download.eclipse.org/releases/staging/

I hope that everyone can check/confirm and get any other contributions made by 
5 PM, as today is +3 day of Kepler M3.

Let us know if anyone needs an extra hour or two ... otherwise we'll assume 
done at 5 PM (

Looks like we are nearly complete with contributions being enabled with only 
three remaining:

emf-query2.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build

But still several others with some features or repositories disabled:

amp.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build (2 matches)
egit.b3aggrcon - org.eclipse.simrel.build
emf-emf.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build (2 matches)
tm.b3aggrcon - org.eclipse.simrel.build
webtools.b3aggrcon - org.eclipse.simrel.build
___
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] Sporadic download failures

[Oberhuber, Martin]

I got an error from the download server today at 11:21 CEST for this URL:

http://download.eclipse.org/eclipse/downloads/drops4/M20120914-1800/download.php?dropFile=eclipse-SDK-M20120914-1800-win32.zip
going "back" and clicking the URL again, the download worked.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin 
Komissarchik
Sent: Thursday, September 13, 2012 4:53 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Sporadic download failures

If this is the same issue as what I was seeing yesterday, then I would expect 
it to flip back-n-forth between available/unavailable modes. Whatever Denis 
fixed yesterday did have an immediate effect for my usage at least.

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.org
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]
 On Behalf Of Daniel Megert
Sent: Thursday, September 13, 2012 7:48 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Sporadic download failures

Nope, I simply tried two or three times and then it worked (though the download 
was really slow).

Dani
From:

Denis Roy mailto:denis@eclipse.org>>

To:

cross-project-issues-dev@eclipse.org,

Date:

13.09.2012 16:40

Subject:

Re: [cross-project-issues-dev] Sporadic download failures






That file has a timestamp of 1:46am localtime.

Perhaps the M-build's download page simply arrived before all the files were in 
place.



On 09/13/2012 10:31 AM, Daniel Megert wrote:
http://download.eclipse.org/eclipse/downloads/drops4/M20120912-1200/download.php?dropFile=eclipse-SDK-M20120912-1200-win32.zip

Dani
From:

Denis Roy 

To:

cross-project-issues-dev@eclipse.org,

Date:

13.09.2012 16:20

Subject:

Re: [cross-project-issues-dev] Sporadic download failures






I thought I had, but I guess not.

Do you have a link I can use?  Is it on download.eclipse.org or on 
www.eclipse.org?



On 09/13/2012 04:54 AM, Daniel Megert wrote:
Hi Denis

Did you fix it? I ask because I ran into this several times this morning.

Dani
From:

Denis Roy 

To:

cross-project-issues-dev@eclipse.org,

Date:

12.09.2012 21:21

Subject:

Re: [cross-project-issues-dev] Sporadic download failures






I know what that is.  I will fix.

On 09/12/2012 02:44 PM, Konstantin Komissarchik wrote:
I am seeing sporadic cases where the download server returns "download is 
invalid" page one minute and processes the download just fine the next. Is 
anyone else seeing this?

- Konstantin  ___
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] [tools-pmc] Does this behavior violate EPL or community prinicples

[Oberhuber, Martin]

Hi David and all,

I’m sorry if my sort message caused too much concern or disruption …

When I couldn’t find PDT on a quick search, I remembered that there had been 
this old thread around and noticed that the bugzilla was still open. So I 
simply replied to the old thread without looking at the subject line.

Turns out that Jacek and the PDT team have done a great job, PDT is happy (just 
not yet in Kepler), I had looked in the wrong spot and I apologize for the 
confusion.

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: tools-pmc-boun...@eclipse.org [mailto:tools-pmc-boun...@eclipse.org] On 
Behalf Of David M Williams
Sent: Friday, September 14, 2012 7:39 PM
To: Cross project issues
Cc: 'Tools PMC mailing list'; pdt-...@eclipse.org
Subject: Re: [tools-pmc] [cross-project-issues-dev] Does this behavior violate 
EPL or community prinicples

Can you clarify what you mean? So far there are still 10 projects in Juno that 
have not enabled their contribution for Kepler and hence not on "staging". [1]  
Perhaps you meant to look on .../releases/maintenance?

If you do mean something more about Juno SR1, I got the impression from this 
chain of notes there was a "naming" issue in a few places. So, that's why I ask 
to clarify what you mean. I'd say "no, there is no violation of EPL or 
community principles" If that's what you are asking. If you just want to know 
more about their plans, I think a note to pdt-dev list would suffice, instead 
of a blanket note with this subject line.

I do know a PDT committer recently requested access to update b3aggrcon files 
(bug 389017), admittedly just a few days ago, so assume they plan on 
contributing to SR1. But again, should ask on pdt-dev if you have questions 
about their exact plans.

I may be missing your point, but a blanket note with the subject line this note 
has seems overly dramatic and carries a negative connotation that I don't see 
(sorry if I'm being dense, but you'll have to spell it out to me if I'm missing 
the point and you have real concerns that they are not following Eclipse 
Development Process?). [And, "we'd like them to do more, faster", doesn't count 
... since we'd like that from everyone :) ]

Let me know how I can help.


[1] The 10 projects not enabled for Kepler ... M2 coming right up!

amp.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
emf-query2.b3aggrcon - org.eclipse.simrel.build
gyrex.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build





From:"Oberhuber, Martin" 
mailto:martin.oberhu...@windriver.com>>
To:"mike.milinkov...@eclipse.org<mailto:mike.milinkov...@eclipse.org>" 
mailto:mike.milinkov...@eclipse.org>>, "Cross 
   project issues" 
mailto:cross-project-issues-dev@eclipse.org>>,
Cc:"'Tools PMC mailing list'" 
mailto:tools-...@eclipse.org>>, 
"pdt-...@eclipse.org<mailto:pdt-...@eclipse.org>" 
mailto:pdt-...@eclipse.org>>
Date:09/14/2012 12:21 PM
Subject:Re: [cross-project-issues-dev] Does this behavior violate EPL   
 orcommunity prinicples
Sent by:
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>




Is PDT missing the boat on Juno SR1 ?

I don’t see PDT on http://download.eclipse.org/releases/staging .

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977 which is still in 
NEW state (reported 30-Jun).

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

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 Mike 
Milinkovich
Sent: Thursday, July 05, 2012 3:24 PM
To: 'Cross project issues'
Cc: 'Tools PMC mailing list'; pdt-...@eclipse.org<mailto:pdt-...@eclipse.org>
Subject: Re: [cross-project-issues-dev] Does this behavior violate EPL or 
community prinicples

+Tools PMC (note bolded comment below)
+PDT dev list (please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977)

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]<mailto:[mailto:cross-project-issues-dev-boun...@eclipse.org]>
 On Behalf Of zhu kane
Sent: July-05-12 1:53 A

Re: [cross-project-issues-dev] [pdt-dev] Does this behavior violate EPL or community prinicples

[Oberhuber, Martin]

Glad to hear PDT is not missing the boat :)

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: pdt-dev-boun...@eclipse.org [mailto:pdt-dev-boun...@eclipse.org] On 
Behalf Of Jacek Pospychala
Sent: Friday, September 14, 2012 8:13 PM
To: PDT Developers; mike.milinkov...@eclipse.org; Cross project issues
Cc: 'Tools PMC mailing list'
Subject: Re: [pdt-dev] [cross-project-issues-dev] Does this behavior violate 
EPL or community prinicples

hi Martin,

isn't Juno SR1 repository in http://download.eclipse.org/releases/maintenance/ ?
At least that's what I thought reading David's post:
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08177.html

I do see PDT in that repo (v. 3.1.1.201209101312).

I haven't enabled PDT for Kepler yet, that's true but I thought there's no 
requirement to join as early as M2.

thanks for remembering about PDT :-)

Jacek,
PDT Project Lead


From: pdt-dev-boun...@eclipse.org<mailto:pdt-dev-boun...@eclipse.org> 
[pdt-dev-boun...@eclipse.org] on behalf of Oberhuber, Martin 
[martin.oberhu...@windriver.com]
Sent: 14 September 2012 18:20
To: mike.milinkov...@eclipse.org<mailto:mike.milinkov...@eclipse.org>; Cross 
project issues
Cc: 'Tools PMC mailing list'; pdt-...@eclipse.org<mailto:pdt-...@eclipse.org>
Subject: Re: [pdt-dev] [cross-project-issues-dev] Does this behavior violate 
EPL or community prinicples
Is PDT missing the boat on Juno SR1 ?

I don't see PDT on http://download.eclipse.org/releases/staging .

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977 which is still in 
NEW state (reported 30-Jun).

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]<mailto:[mailto:cross-project-issues-dev-boun...@eclipse.org]>
 On Behalf Of Mike Milinkovich
Sent: Thursday, July 05, 2012 3:24 PM
To: 'Cross project issues'
Cc: 'Tools PMC mailing list'; pdt-...@eclipse.org<mailto:pdt-...@eclipse.org>
Subject: Re: [cross-project-issues-dev] Does this behavior violate EPL or 
community prinicples

+Tools PMC (note bolded comment below)
+PDT dev list (please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977)

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]<mailto:[mailto:cross-project-issues-dev-boun...@eclipse.org]>
 On Behalf Of zhu kane
Sent: July-05-12 1:53 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Does this behavior violate EPL or 
community prinicples

I also appreciate the effort of PDT team made, it's great to release 
maintenance version in Indigo SR2 time frame. And it still works well in Juno.

I don't think development team is possible to mess up the release version. 
Anyway I would like to see comments from PDT and PMC.

Mengxin
On Wed, Jul 4, 2012 at 3:04 PM, Ed Willink 
mailto:e...@willink.me.uk>> wrote:
Hi

The situation doesn't seem nearly as bad as you make out.

The public promoted builds on http://www.eclipse.org/pdt/downloads/ show a 
2-Jan-2012 3.0.0 Maintenance build as the most recent and examining the ZIP 
content reveals 3.0.1 content.

Installing the Juno release train installs a 2-Jan-2012 3.0.1, which correlates 
with the Eclipse CVS.

The Hudson build job 
https://hudson.eclipse.org/hudson/job/cbi-pdt-3.0-juno/changes shows active 
public development of 3.1 in the Eclipse CVS.

So it seems there are some releng difficulties that cause 3.0.1 to be listed as 
3.0.0 on the download page, and some over-enthusiasm that causes a 3.0.1 
contribution to be called 3.1.

A rename can fix the download page. A resubmission of the review slides can fix 
the misleading version claim. Perhaps Kepler should be 3.2 to avoid more 
confusion.

Regards

Ed Willink


On 04/07/2012 06:17, zhu kane wrote:
Hello community,

I hesitated about raising such question in here. But I can't get any response 
from PDT project even if filing critical bug for it[1].

PDT team announced PDT 3.1 was released[2] with Juno simultaneous release. PDT 
3.1 also is listed in highlighted Juno project
list[3]. But none of Eclipse users knows how to install it.

I would like to believe it's just a bug, however nobody of PDT project takes 
action for it. In my understanding all projects of Eclipse.org are open source, 
everybody can browse the latest source code even under developing. I'm 
astonished that I can't find any commit related to PDT 3.1 from its source 
repository[4]. Looks like PDT 3.1 d

Re: [cross-project-issues-dev] Does this behavior violate EPL or community prinicples

[Oberhuber, Martin]

Is PDT missing the boat on Juno SR1 ?

I don’t see PDT on http://download.eclipse.org/releases/staging .

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977 which is still in 
NEW state (reported 30-Jun).

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mike 
Milinkovich
Sent: Thursday, July 05, 2012 3:24 PM
To: 'Cross project issues'
Cc: 'Tools PMC mailing list'; pdt-...@eclipse.org
Subject: Re: [cross-project-issues-dev] Does this behavior violate EPL or 
community prinicples

+Tools PMC (note bolded comment below)
+PDT dev list (please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977)

From: 
cross-project-issues-dev-boun...@eclipse.org
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]
 On Behalf Of zhu kane
Sent: July-05-12 1:53 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Does this behavior violate EPL or 
community prinicples

I also appreciate the effort of PDT team made, it's great to release 
maintenance version in Indigo SR2 time frame. And it still works well in Juno.

I don't think development team is possible to mess up the release version. 
Anyway I would like to see comments from PDT and PMC.

Mengxin
On Wed, Jul 4, 2012 at 3:04 PM, Ed Willink 
mailto:e...@willink.me.uk>> wrote:
Hi

The situation doesn't seem nearly as bad as you make out.

The public promoted builds on http://www.eclipse.org/pdt/downloads/ show a 
2-Jan-2012 3.0.0 Maintenance build as the most recent and examining the ZIP 
content reveals 3.0.1 content.

Installing the Juno release train installs a 2-Jan-2012 3.0.1, which correlates 
with the Eclipse CVS.

The Hudson build job 
https://hudson.eclipse.org/hudson/job/cbi-pdt-3.0-juno/changes shows active 
public development of 3.1 in the Eclipse CVS.

So it seems there are some releng difficulties that cause 3.0.1 to be listed as 
3.0.0 on the download page, and some over-enthusiasm that causes a 3.0.1 
contribution to be called 3.1.

A rename can fix the download page. A resubmission of the review slides can fix 
the misleading version claim. Perhaps Kepler should be 3.2 to avoid more 
confusion.

Regards

Ed Willink


On 04/07/2012 06:17, zhu kane wrote:
Hello community,

I hesitated about raising such question in here. But I can't get any response 
from PDT project even if filing critical bug for it[1].

PDT team announced PDT 3.1 was released[2] with Juno simultaneous release. PDT 
3.1 also is listed in highlighted Juno project
list[3]. But none of Eclipse users knows how to install it.

I would like to believe it's just a bug, however nobody of PDT project takes 
action for it. In my understanding all projects of Eclipse.org are open source, 
everybody can browse the latest source code even under developing. I'm 
astonished that I can't find any commit related to PDT 3.1 from its source 
repository[4]. Looks like PDT 3.1 doesn't have any public nightly build and 
integration build. I only find a build[5] for 3.0 in Hudson.

I'm wondering whether Eclipse.org/EPL allows a project under it that is not 
really open source and just declared its new release. Hope experienced people 
help resolve my doubts.

Thank you.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=383977
[2] https://bugs.eclipse.org/bugs/attachment.cgi?id=216929
[3] http://eclipse.org/juno/projects.php
[4] 
http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.pdt/features/org.eclipse.php-feature/?root=Tools_Project
[5] https://hudson.eclipse.org/hudson/job/cbi-pdt-3.0-juno/changes

Mengxin Zhu

___
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] Juno RC1 RC2 Staging (maintenance) repository is complete

[Oberhuber, Martin]

Actually I’d think that if Orbit uses a “Juno” builder, any optional 
dependencies should be non-greedy automatically…

David, do you have an idea why this doesn’t work here ?

Martin


From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn
Sent: Thursday, September 06, 2012 4:28 PM
To: Cross project issues; Chris Aniszczyk
Subject: Re: [cross-project-issues-dev] Juno RC1 RC2 Staging (maintenance) 
repository is complete

aha, this makes more sense.

This means the following Orbit bundles need to be fixed

com.google.gerrit.common
com.google.gerrit.prettify
@Chris: you are listed as the contact for these Orbit bundles,
could you take care ?

--
Matthias
2012/9/6 Oberhuber, Martin 
mailto:martin.oberhu...@windriver.com>>
Hi Matthias,

I think it is the other way round :

The culprits are com.google.gerrit.(common|prettify),
And they have an optional greedy dependency on the _package_ 
org.eclipse.jgit.diff.

Here’s how you can check:

ssh build.eclipse.org<http://build.eclipse.org>
cd 
/home/data/httpd/download.eclipse.org/releases/staging<http://download.eclipse.org/releases/staging>
unzip -p content.jar | grep -B 40 'require.*jgit\.diff.*optional' | less

Martin

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto: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 Matthias Sohn
Sent: Thursday, September 06, 2012 1:29 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Juno RC1 RC2 Staging (maintenance) 
repository is complete

2012/9/5 David M Williams 
mailto:david_willi...@us.ibm.com>>
http://download.eclipse.org/releases/maintenance/

I did open bug 388890 to track the missing "about.html" files.

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

For complete reports, see
http://build.eclipse.org/simrel/juno/reporeports/

looking at the report
http://build.eclipse.org/simrel/juno/reporeports/reports/greedyReport.html

I found the following entry:

65. org.eclipse.jgit.diff

Number of IUs using optional, but greedy for this case: 2

 *   com.google.gerrit.common
 *   com.google.gerrit.prettify
but JGit doesn't have a bundle or feature called org.eclipse.jgit.diff,
also we have no dependency on the listed gerrit bundles

So which other project has borrowed our project's namespace for this bundle ?
I think this should be fixed.

--
Matthias

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



--
Matthias
___
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] Juno RC1 RC2 Staging (maintenance) repository is complete

[Oberhuber, Martin]

Hi Matthias,

I think it is the other way round :

The culprits are com.google.gerrit.(common|prettify),
And they have an optional greedy dependency on the _package_ 
org.eclipse.jgit.diff.

Here’s how you can check:

ssh build.eclipse.org
cd /home/data/httpd/download.eclipse.org/releases/staging
unzip -p content.jar | grep -B 40 'require.*jgit\.diff.*optional' | less

Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias Sohn
Sent: Thursday, September 06, 2012 1:29 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Juno RC1 RC2 Staging (maintenance) 
repository is complete

2012/9/5 David M Williams 
mailto:david_willi...@us.ibm.com>>
http://download.eclipse.org/releases/maintenance/

I did open bug 388890 to track the missing "about.html" files.

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

For complete reports, see
http://build.eclipse.org/simrel/juno/reporeports/

looking at the report
http://build.eclipse.org/simrel/juno/reporeports/reports/greedyReport.html

I found the following entry:

65. org.eclipse.jgit.diff

Number of IUs using optional, but greedy for this case: 2

 *   com.google.gerrit.common
 *   com.google.gerrit.prettify
but JGit doesn't have a bundle or feature called org.eclipse.jgit.diff,
also we have no dependency on the listed gerrit bundles

So which other project has borrowed our project's namespace for this bundle ?
I think this should be fixed.

--
Matthias
___
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] Status and readiness for Kepler M1

[Oberhuber, Martin]

In fact I've enjoyed my vacation not checking Eclipse mailing lists recently :)

I'm going to enable the tm.b3aggrcon and tcf.b3aggrcon as soon as my SSH access 
to Eclipse.org is back
https://bugs.eclipse.org/bugs/show_bug.cgi?id=387782

Martin


From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Wednesday, August 22, 2012 7:10 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Status and readiness for Kepler M1

Still 26 projects not enabled for Kepler M1.

Can some one explain to me what this is about? Some passive aggressive protest? 
Too many people take vacation all summer and don't even check Eclipse mailing 
lists?
Are projects just indecisive and think a commitment now means it is a written 
in stone promise (which is never the case).
I know one or two people have mentioned they have special problems that will 
likely prevent participation in M1, but,
If I hear nothing, I'll assume the remaining 24 or so are dropping out, and 
will remove those files from the 'master'  branch.
For those projects to rejoin later will take an exception since there's a 
requirement for those participating to "keep participating" or else inform us 
all you no longer plan to.
The M4 deadline only applies to branch new projects, others (in previous 
release) expected to be in M1.
http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Integrate_Early_and_Often

I should emphasize, if people do not want to be in sim. release, that's fine. 
It is a voluntary choice, and does take some amount of extra work. So, it 
doesn't mean you are a "bad project" or anything if you decide not to.
But, it is only common courtesy to keep us informed explicitly.

Thanks,



amp.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
emf-query2.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
emft-emffacet.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gyrex.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
rap.b3aggrcon - org.eclipse.simrel.build
recommenders.b3aggrcon - org.eclipse.simrel.build
rtp.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build
tm.b3aggrcon - org.eclipse.simrel.build
___
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] List of files on Eclipse Mirror servers

[Oberhuber, Martin]

Ø  If there are resources available to work on this, it would be much better if 
download.eclipse.org served as central gateway to both the primary download 
server and the archive.

And, potentially, mirrors !

I think this has been discussed before (can't find the exact reference now), 
but having to serve artifacts.jar (400K) and content.jar (> 2MB !) from a 
single server looks like a bad bottleneck to me.

For me, sitting in Europe, performing a "check for updates" is still 
ridiculously slow with Eclipse. Installing something from the train repository 
is OK once I have chosen what to install  But building the list to choose 
from is annoyingly slow even when there is no train release (typically > 2 
minutes, see also bug 347403 
[1]). The workaround 
redirecting all master traffic to OSUOSL has caused issues in the past (bug 
329923 [2]).

Composite repositories have small master files - that would seem like a good 
chance using the composite only from the central server, but then allowing to 
mirror metadata files from the children when timestamps are OK (or, pull in 
child repos from a different server like archive.eclipse.org etc).

Or has this been implemented by now and I'm not up-to-date with the latest ?

Martin

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=347403
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=329923

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin 
Komissarchik
Sent: Tuesday, June 19, 2012 9:41 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] List of files on Eclipse Mirror servers

One of the problems with the archival process is handling of p2 repositories 
which do not go through the mirror selection script.

http://wiki.eclipse.org/IT_Infrastructure_Doc#Move_files_to_archive.eclipse.org.3F

Currently, only the mirror selection script is able to delegate to 
archive.eclipse.org, so auto-archiving would break those repositories.

If there are resources available to work on this, it would be much better if 
download.eclipse.org served as central gateway to both the primary download 
server and the archive. Then one can implement all sort of archiving policies 
without involving projects or affecting end users referencing these URLs... You 
can auto-archive based on age, you can auto-archive based on demand, heck you 
can even pick a goal for how much to mirror and have a heuristic that shuffles 
between primary and archive to meet that goal.

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.org
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]
 On Behalf Of Wayne Beaton
Sent: Tuesday, June 19, 2012 12:15 PM
To: 
cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] List of files on Eclipse Mirror servers

Does it make sense to consider moving files that are old--say three or more 
years old--to the archive server automatically?

Wayne

On 06/19/2012 10:33 AM, Denis Roy wrote:
To help you clean up older builds and files from the Eclipse download server, 
I've compiled a list of files that are actually sync'ed to our mirrors.

http://download.eclipse.org/technology/phoenix/download.eclipse.org-filelist.txt.gz

I each project to look at the file list, and either remove files that are no 
longer needed, or move older releases[1] to the archives.

Thanks,

Denis


[1] http://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads

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

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

Re: [cross-project-issues-dev] Target audience of Juno repo

[Oberhuber, Martin]

Cool, thanks !
Looking at our Juno endgame plan, it looks like this is something to be done at 
or shortly after the release day ?
Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Konstantin 
Komissarchik
Sent: Tuesday, June 12, 2012 8:25 PM
To: 'Cross project issues'; mike.milinkov...@eclipse.org
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

1. http://marketplace.eclipse.org/
2. Click on Add Content link
3. The rest should be self explanatory... :)

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]<mailto:[mailto:cross-project-issues-dev-boun...@eclipse.org]>
 On Behalf Of Oberhuber, Martin
Sent: Tuesday, June 12, 2012 11:16 AM
To: mike.milinkov...@eclipse.org<mailto:mike.milinkov...@eclipse.org>; Cross 
project issues
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

Good point,

Is there a quick HOWTO for adding a project's listing to marketplace ?

Martin

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 Mike 
Milinkovich
Sent: Tuesday, May 29, 2012 6:42 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

Just my personal opinion, but given that the Marketplace Client is quite 
popular and is included in almost all of the packages, I would recommend that 
Eclipse projects take the time to make their project distributions available 
via that channel.

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]<mailto:[mailto:cross-project-issues-dev-boun...@eclipse.org]>
 On Behalf Of Konstantin Komissarchik
Sent: May-29-12 12:39 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

Trying to fragment the repository around user profiles isn't going to be easy 
or clean. Many users and use cases will not easily fit into neat profiles.

On the other hand, we already have a venue for presenting users with an easier 
to use course-granularity installation option... Eclipse Marketplace.

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]<mailto:[mailto:cross-project-issues-dev-boun...@eclipse.org]>
 On Behalf Of Miles Parker
Sent: Tuesday, May 29, 2012 9:25 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo


+1, but probably way too late to be asking people to make these kind of changes 
now. Something that people should be thinking hard about for Kepler. There is a 
major need for a higher level of granularity on the features. Ideally it would 
be one per project but that isn't practical in many cases.

On 2012-05-29, at 8:29 AM, Pascal Rapicault wrote:
Once in a while I go through the content of the Juno repo to see what's there; 
and I try to see if I can make any sense of what is made available. 
Unfortunately this year it reached a point where I just can't. There are way 
too many entries that are subtle variations around the same project and whose 
installation result in unexpected results or non functional additions to my 
install. For example there is 11 entries for Sapphire, 5 entries for 
windowBuilder, an infinity of Mylyn related entries...?

I understand that we are all trying to promote our project and brand, but I 
would argue that the plethora of entries has a reverse effect that let the user 
confused as to what to install.

So the main question is "what is the primary target audience of the Juno repo?"
- an eclipse user - e.g. a JEE programmer
- an eclipse extender - e.g. someone using eclipse technologies to 
build an app

At this point, the content of the repo looks like what we are addressing both 
audience which may be a convenience for us but a nuisance for the end users.

IMO, the Juno repo should be "end user" focused and only include entries whose 
installation will result in new functionalities to be added to the IDE. Also 
each entry should have
- a descriptive name (which include removing adjectives such as 
incubation, extender)
- a minimal number of entries returned when I search for the name
- be adequately categorized

How do we go about exposing the rest of the content for extenders?
- Different repo URLs (e.g. 
download.eclipse.org/releases/juno/developer<http://download.eclipse.org/releases/juno/developer>)
- Addition of a developer focused category (w

Re: [cross-project-issues-dev] Target audience of Juno repo

[Oberhuber, Martin]

Good point,

Is there a quick HOWTO for adding a project's listing to marketplace ?

Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mike 
Milinkovich
Sent: Tuesday, May 29, 2012 6:42 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

Just my personal opinion, but given that the Marketplace Client is quite 
popular and is included in almost all of the packages, I would recommend that 
Eclipse projects take the time to make their project distributions available 
via that channel.

From: 
cross-project-issues-dev-boun...@eclipse.org
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]
 On Behalf Of Konstantin Komissarchik
Sent: May-29-12 12:39 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo

Trying to fragment the repository around user profiles isn't going to be easy 
or clean. Many users and use cases will not easily fit into neat profiles.

On the other hand, we already have a venue for presenting users with an easier 
to use course-granularity installation option... Eclipse Marketplace.

- Konstantin


From: 
cross-project-issues-dev-boun...@eclipse.org
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]
 On Behalf Of Miles Parker
Sent: Tuesday, May 29, 2012 9:25 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo


+1, but probably way too late to be asking people to make these kind of changes 
now. Something that people should be thinking hard about for Kepler. There is a 
major need for a higher level of granularity on the features. Ideally it would 
be one per project but that isn't practical in many cases.

On 2012-05-29, at 8:29 AM, Pascal Rapicault wrote:
Once in a while I go through the content of the Juno repo to see what's there; 
and I try to see if I can make any sense of what is made available. 
Unfortunately this year it reached a point where I just can't. There are way 
too many entries that are subtle variations around the same project and whose 
installation result in unexpected results or non functional additions to my 
install. For example there is 11 entries for Sapphire, 5 entries for 
windowBuilder, an infinity of Mylyn related entries...?

I understand that we are all trying to promote our project and brand, but I 
would argue that the plethora of entries has a reverse effect that let the user 
confused as to what to install.

So the main question is "what is the primary target audience of the Juno repo?"
- an eclipse user - e.g. a JEE programmer
- an eclipse extender - e.g. someone using eclipse technologies to 
build an app

At this point, the content of the repo looks like what we are addressing both 
audience which may be a convenience for us but a nuisance for the end users.

IMO, the Juno repo should be "end user" focused and only include entries whose 
installation will result in new functionalities to be added to the IDE. Also 
each entry should have
- a descriptive name (which include removing adjectives such as 
incubation, extender)
- a minimal number of entries returned when I search for the name
- be adequately categorized

How do we go about exposing the rest of the content for extenders?
- Different repo URLs (e.g. 
download.eclipse.org/releases/juno/developer)
- Addition of a developer focused category (with nested categories)

wdyt?

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

__
Miles T. Parker
Senior Solutions Architect
Tasktop
http://tasktop.com
Committer, Eclipse Mylyn and Virgo
Project Lead, Model Focussing Tools and AMP
http://milesparker.blogspot.com
skype: milestravisparker




___
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] More on greediness report

[Oberhuber, Martin]

Hi all,

Here is a very quick and easy way for any project contributing to Juno to see 
whether their contribution has any unwanted “greedy default optional” 
contributions:

cd /your/contribution/repo
unzip -p content.jar | grep optional=.true | grep -v greedy

This shows whether YOU are declaring any optional dependencies which are not 
explicitly set as greedy=true or greedy=false.
(And should relieve David from writing the Blame script since you can easily 
find out yourself).

If you find any, you’ll need to use the new p2 publisher (from Eclipse 3.8 or 
4.2) for your repo.

Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Friday, May 25, 2012 12:33 AM
To: Cross project issues
Subject: [cross-project-issues-dev] More on greediness report


> ... since that bundle doesn’t declare anything optional in its Manifest
>
> Could it be that the report blames the wrong bundle?
> http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html
>

I see now there is some confusion about what the report is showing. It is not 
showing "blame" as most reports do.

It is Just showing bundles that are required ... by someone else ... optionally 
but without greedy attribute.  So, yes, it is that "someone else" that is to 
blame,
and is very hard to "track down". Manually or programmatically.

I wrote this "quick and easy" report as a sanity check that everyone was moving 
to new publisher, and hoped we would not have to get to the point of tracking 
down "blame".

If everyone had moved, and the report was "clean", we'd be done. with no blame 
report needed. But, as it is ... sounds like a case of "you get what you 
measure" ... so we need to measure "blame".

Sorry I didn't read your comments closely enough previously.

I'll see if I can improve the report some to keep track of "blame" ... not sure 
I can easily, but, we'll see.





[Inactive hide details for "Oberhuber, Martin" ---05/24/2012 08:10:44 AM---Hi 
David, Given that I also found "219. org.eclipse.r]"Oberhuber, Martin" 
---05/24/2012 08:10:44 AM---Hi David, Given that I also found "219. 
org.eclipse.rse.services.ssh" in your greediness report, I w

From: "Oberhuber, Martin" 
mailto:martin.oberhu...@windriver.com>>
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>,
Date: 05/24/2012 08:10 AM
Subject: [cross-project-issues-dev] Simrel Greediness Report (was: Yet another 
nag note)
Sent by: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>





Hi David,

Given that I also found “219. org.eclipse.rse.services.ssh” in your greediness 
report, I was confused (since that bundle doesn’t declare anything optional in 
its Manifest).

Could it be that the report blames the wrong bundle?
http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html

I just performed an “unzip –p …/releases/staging/content.jar | less” and I see 
that my 2 bundles are
“required optional with defaults” by org.eclipse.dltk.rse.core so I believe 
that bundle is to blame in this case…

I am likely responsible for fixing the “7. Gnu.io” one which should definitely 
be non-greedy especially given
that we don’t ship it from Eclipse (it’s a “works-with” pre-req).
Investigating now…

Martin


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 Dennis 
Hübner
Sent: Thursday, May 24, 2012 9:19 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it 
this time!

Hi David,
Still scores of projects that have not bothered to move to a current repo 
publisher so there are hundreds of incorrect "greediness" attributes.

Sure there are greedy optional dependencies in the repository, because it often 
just intended by projects. I don't understand, why are you talking about 
incorrect greediness? "Not a default" it not the same as "wrong".
IMHO this [1] report  is only useful for statistic purpose.

Regards,
Dennis Hübner

[1]  http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17396687
Telefon: +49 (0) 431 / 99026870
Fax: +49 (0) 431 / 99026872

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Am 24.05.2012 um 06:40 schrieb David M Williams:

 

Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time!

[Oberhuber, Martin]

Hmm, 

I thought we had been through all that discussion on bugzilla already (I can't 
find the ref right now since bugzilla is down).

In a nutshell,

- Optional greedy is bad since it can cause side-effects : 
  When I install A and optional greedy B,C happen to be available they get 
installed even when I don't ask for them, causing unexpected side-effects.

- Yes Optional non-greedy has no effect on the installer;
   But, the p2 metadata also serves as documenting the OSGi/runtime 
dependencies from all MANIFEST.MF in a repo so having it in there is extra 
information that may help some and doesn't hurt.

Martin



-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas 
Hallgren
Sent: Thursday, May 24, 2012 3:37 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it 
this time!

On 05/24/2012 03:13 PM, Gunnar Wagenknecht wrote:
> Am 24.05.2012 14:57, schrieb Thomas Hallgren:
>> One could very well argue that an optional non-greedy dependency is 
>> completely useless and doesn't fulfill any other purpose but documentation.
> We have a bunch of bundles in place that have optional non-greedy 
> dependencies to allow flexibility at runtime. For example, Logback can 
> be configured via API, XML or Groovy. Groovy as well as XML 
> configuration require additional dependencies. Imaging all those 
> dependencies were greedy.
Then they would be installed of course. Now they are not installed and the 
dependencies have no purpose aside from what I mentioned earlier, documentation.

> BTW, they need to be optional for the bundles to properly resolve if 
> the dependencies aren't there. They need to be declared to allow the 
> bundle class loader to load them if they are available.
To my knowledge, the bundle class loader is using the MANIFEST.MF, not the p2 
meta-data. So my argument still stands.

- thomas

___
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] Simrel Greediness Report (was: Yet another nag note)

[Oberhuber, Martin]

Hi David,

Given that I also found "219. org.eclipse.rse.services.ssh" in your greediness 
report, I was confused (since that bundle doesn't declare anything optional in 
its Manifest).

Could it be that the report blames the wrong bundle?
http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html

I just performed an "unzip -p .../releases/staging/content.jar | less" and I 
see that my 2 bundles are
"required optional with defaults" by org.eclipse.dltk.rse.core so I believe 
that bundle is to blame in this case...

I am likely responsible for fixing the "7. Gnu.io" one which should definitely 
be non-greedy especially given
that we don't ship it from Eclipse (it's a "works-with" pre-req).
Investigating now...

Martin


From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Dennis Hübner
Sent: Thursday, May 24, 2012 9:19 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it 
this time!

Hi David,
Still scores of projects that have not bothered to move to a current repo 
publisher so there are hundreds of incorrect "greediness" attributes.


Sure there are greedy optional dependencies in the repository, because it often 
just intended by projects. I don't understand, why are you talking about 
incorrect greediness? "Not a default" it not the same as "wrong".
IMHO this [1] report  is only useful for statistic purpose.

Regards,
Dennis Hübner

[1]  http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html

Xtext Commiter / Build Engineer

Mobile: +49 (0) 151 / 17396687
Telefon: +49 (0) 431 / 99026870
Fax: +49 (0) 431 / 99026872

itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
http://www.itemis.de/

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Am 24.05.2012 um 06:40 schrieb David M Williams:


___
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] Heads up : TCF rename for 1.0 version

[Oberhuber, Martin]

Actually,

David reminded me that a Bug is a better channel for feedback, so questions and 
comments there please:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=378286

Thanks
Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Oberhuber, 
Martin
Sent: Wednesday, May 02, 2012 6:37 PM
To: Cross project issues (cross-project-issues-dev@eclipse.org)
Subject: [cross-project-issues-dev] Heads up : TCF rename for 1.0 version

Hi all,

If you have any bundles which depend on TCF, please read on - if not, feel free 
to ignore.

Earlier this year the TCF project performed a refactoring of its namespace in 
order
to better comply with Eclipse naming after its separation from the TM project 
[1].

The change has now matured, and we consider TCF-1.0 the latest, greatest and 
most
stable version which we'll want to hit the Simulataneous Release.
Bundle ID's, Java packages and extension point identifiers change as follows :


-  TCF 0.5 Stream (up until Juno M6) : org.eclipse.tm.tcf

-  TCF 1.0 Stream (Juno M7 and on) : org.eclipse.tcf

A preview of the TCF M7 contribution (with TCF 1.0) is available here:

http://download.eclipse.org/tcf/builds/juno/milestones
and should be on the Simultaneous Release Staging repo shortly.

I believe that the older tcf-0.5 builds will also be available from the
Simultaneous repo due to still exposing M6 and older milestone repos,
but we encourage all adopters upgrade to the 1.0 version since 0.5
is not maintained any more.

Your work for adopting 1.0 should simply be a textual "search and replace"
As per above.

Let me know if there are any questions or concerns.

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

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

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

[cross-project-issues-dev] Heads up : TCF rename for 1.0 version

[Oberhuber, Martin]

Hi all,

If you have any bundles which depend on TCF, please read on - if not, feel free 
to ignore.

Earlier this year the TCF project performed a refactoring of its namespace in 
order
to better comply with Eclipse naming after its separation from the TM project 
[1].

The change has now matured, and we consider TCF-1.0 the latest, greatest and 
most
stable version which we'll want to hit the Simulataneous Release.
Bundle ID's, Java packages and extension point identifiers change as follows :


-  TCF 0.5 Stream (up until Juno M6) : org.eclipse.tm.tcf

-  TCF 1.0 Stream (Juno M7 and on) : org.eclipse.tcf

A preview of the TCF M7 contribution (with TCF 1.0) is available here:

http://download.eclipse.org/tcf/builds/juno/milestones
and should be on the Simultaneous Release Staging repo shortly.

I believe that the older tcf-0.5 builds will also be available from the
Simultaneous repo due to still exposing M6 and older milestone repos,
but we encourage all adopters upgrade to the 1.0 version since 0.5
is not maintained any more.

Your work for adopting 1.0 should simply be a textual "search and replace"
As per above.

Let me know if there are any questions or concerns.

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

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Indigo SR2 not mirrored ?

[Oberhuber, Martin]

Hm...

I tried again today, and this time artifacts were fetched from 2 mirrors in 
brazil (!) which was again a rather slow operation.

Seems to me that the p2 mechanisms for picking a mirror could be more 
intelligent, picking something from Germany for instance in my case... I also 
noticed that once p2 started downloading a large artifact from some mirror it 
doesn't try any other mirrors for that one. Which can also quite limit 
performance if you're unlucky on a large artifact like linuxtools.autotools.doc 
in my case.

Are these known limitations ? Could I enable any additional logging to capture 
more data ?

In the past, installing from the SimRel repo was always fast for me (only 
fetching initial metadata was painfully slow, taking in the range of minutes 
until the UI was usable).

Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus Knauer
Sent: Thursday, April 12, 2012 3:39 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Indigo SR2 not mirrored ?

The important files to look for are the artifacts.jar files that are referenced 
by a cascade of compositeArtifacts.jar. And the most important one, 
releases/indigo/201202240900/aggregate/artifacts.jar, contains the following 
line which looks correct to me:



The other one, eclipse/updates/3.7/R-3.7.2-201202080800/artifacts.jar, looks 
good as well and contains the p2.mirrorsURL value.

Regards,
Markus
On Thu, Apr 12, 2012 at 15:30, Denis Roy 
mailto:denis@eclipse.org>> wrote:
Martin,

The SR2 release is indeed mirrored: 
http://ftp.osuosl.org/pub/eclipse/releases/indigo/201202240900/

And a hit to the mirrors list shows plenty of mirrors: 
http://eclipse.org/downloads/download.php?file=/releases/indigo/201202240900/

I've examined the content.jar and compositeArtifacts.jar files and couldn't 
find any references to mirrors, but I'm not sure that's where they should be.

I'm not sure where else to look to see if mirrors are properly enabled.  That's 
why it's just so much easier for me to redirect downloads at the Apache level, 
but David doesn't like it when I do that  :)

Denis



On 04/10/2012 02:33 PM, Oberhuber, Martin wrote:
Hi all,

I've just initiated an update from a CDT I-build (mid-january) on top of 
Platform 3.7.1 to CDT Indigo SR2, using the standard release URL:
   http://download.eclipse.org/releases/indigo
picking the CDT SDK.

Download is very slow, and progress seems to indicate that all *.pack.gz 
artifcats are actually fetched from 
download.eclipse.org/releases/indigo/sr2/<http://download.eclipse.org/releases/indigo/sr2/>...

Could it be that mirroring is broken somehow for Indigo SR2 ?
Or is my Eclipse 3.7.1 Platform broken somehow ?

Do others see something similar ?
I know that when I install stuff from Juno it's typically a LOT faster and 
getting stuff from all over the place...

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax 
+43.662.457915.6




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org<mailto: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] Indigo SR2 not mirrored ?

[Oberhuber, Martin]

Hi all,

I've just initiated an update from a CDT I-build (mid-january) on top of 
Platform 3.7.1 to CDT Indigo SR2, using the standard release URL:
   http://download.eclipse.org/releases/indigo
picking the CDT SDK.

Download is very slow, and progress seems to indicate that all *.pack.gz 
artifcats are actually fetched from download.eclipse.org/releases/indigo/sr2/...

Could it be that mirroring is broken somehow for Indigo SR2 ?
Or is my Eclipse 3.7.1 Platform broken somehow ?

Do others see something similar ?
I know that when I install stuff from Juno it's typically a LOT faster and 
getting stuff from all over the place...

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Junit tests crash in Hudson with 4.2M6

[Oberhuber, Martin]

I have also uploaded the log to here for easier access:
http://download.eclipse.org/tm/div/hs_err_pid1355.log

It looks like the crash is in libmozjs.so, after disposing of a couple SWT 
widgets triggered by hiding a view.
The issue seems to be reproducible.
Excerpt from the logs:


Stack: [0x7f188623d000,0x7f188633e000],  sp=0x7f18863376f0,  free 
space=3e90018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libmozjs.so+0x4d140]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  
org.eclipse.swt.internal.mozilla.XPCOM._JS_EvaluateUCScriptForPrincipals([BJJJ[CI[BI[J)I+0
j  
org.eclipse.swt.internal.mozilla.XPCOM.JS_EvaluateUCScriptForPrincipals([BJJJ[CI[BI[J)I+22
j  org.eclipse.swt.browser.Mozilla.execute(Ljava/lang/String;)Z+829
j  
org.eclipse.swt.browser.Mozilla.onDispose(Lorg/eclipse/swt/widgets/Display;)V+42
[...]
j  
org.eclipse.e4.ui.model.application.ui.impl.UIElementImpl.setToBeRendered(Z)V+34
j  
org.eclipse.e4.ui.internal.workbench.PartServiceImpl.hidePart(Lorg/eclipse/e4/ui/model/application/ui/basic/MPart;Z)V+318
j  
org.eclipse.ui.internal.WorkbenchPage.hidePart(Lorg/eclipse/e4/ui/model/application/ui/basic/MPart;)Z+190
[...]
j  
org.eclipse.rse.tests.core.RSECoreTestCase.hideView(Ljava/lang/String;Ljava/lang/String;)V+56
j  org.eclipse.rse.tests.core.RSECoreTestCase$2.run()V+10
j  org.eclipse.swt.widgets.Synchronizer.syncExec(Ljava/lang/Runnable;)V+121
j  org.eclipse.ui.internal.UISynchronizer.syncExec(Ljava/lang/Runnable;)V+91
j  org.eclipse.swt.widgets.Display.syncExec(Ljava/lang/Runnable;)V+108
j  org.eclipse.rse.tests.core.RSECoreTestCase.switchMaximizeSystemsView()V+31


Martin

-Original Message-
From: Anna Dushistova [mailto:anna.dushist...@gmail.com] 
Sent: Monday, April 09, 2012 5:20 AM
To: cross-project-issues-dev; david_dyks...@us.ibm.com; Oberhuber, Martin
Subject: Junit tests crash in Hudson with 4.2M6

Hi All,

I am experiencing a JVM crash while running plugin junit tests with 4.2M6.
The same tests run fine with 3.7.
Here is the log:
https://hudson.eclipse.org/hudson/job/tm-master-nightly/ws/org.eclipse.tm.rse/tests/org.eclipse.rse.tests/hs_err_pid4432.log/*view*/

Has anyone seen anything like this?
Any ideas what went wrong?

Thanks!
Anna.
___
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] Hudson changes

[Oberhuber, Martin]

> http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg07116.html

Cool. Thanks. I intuitively knew that you guys just rock :)

Thanks
Martin

___
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] Hudson changes

[Oberhuber, Martin]

Hi Denis,

Was the addition of slave6 announced somewhere ?

Apparently even addition of a new slave has potential for odd behavior and 
breaking things. As we have seen, advance notice of _any_ modification to 
Hudson would be helpful such that we get an idea what to consider when our 
build fails.

I apologize if such announcements were made and I've been missing them ...

Thanks
Martin

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
Sent: Thursday, February 09, 2012 8:07 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Hudson changes


On 02/09/2012 11:46 AM, Greg Watson wrote:
> On Feb 8, 2012, at 6:56 PM, Greg Watson wrote:
>
>> Has something changed on hudson? Our builds, which were previously working 
>> fine, are now failing because /usr/local/bin/java can't be found.
>>
>> Thanks,
>> Greg
>>
> It magically started working again.
>
> Greg
We were missing a symlinnk on the new hudson-slave6, and I added it last night 
after you posted this.

Thanks
___
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] Heads up: Eclipse Platform 3.7.2 is going to ship a newer JSch

[Oberhuber, Martin]

Hi all,

This is just a quick heads up that Eclipse Platform 3.7.2 (Indigo SR2) is going 
to ship with the JSch-0.1.44 library for SSH transport, while Indigo and SR1 
used JSch-0.1.41.

We do not expect any regression or breakage ... but I did want to mention the 
change, since JSch deals with encryption, so some adopters may need to go 
through specific legal procedures to announce the version update when 
redistributing it in their products on top of Eclipse.

The newer JSch-0.1.44 has been in Orbit for a long time and has been included 
by egit as well as the Eclipse Juno builds so it has received a good deal of 
testing.

Comments or concerns on the bug, please:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=344469

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

___
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] Orbit and WTP are not greedy, how about you?

[Oberhuber, Martin]

Hi Dave,

Many thanks for this notice and all the background.
I'd like to have just few things clarified,

1. What triggered the change for Orbit and WTP was simply upgrading to a 3.8 or 
4.2 based builder (and thus newer p2 publisher) no change in any settings. As a 
corollary, anybody who already uses a 3.8 or 4.2 based builder already performs 
builds using the new strategy. Correct ?

2. Since only upgrading the builder may affect build output of plugins which 
were not modified in source, it may be adviseable to force updating the 
qualifier for any plugins that have been completely unmodified since the Indigo 
releases and contain any optional dependencies ... or we'd have two artifacts 
with exactly the same ID but different binary content. Correct ?

I have no idea how Tycho based builds behave regarding optional dependencies, 
does anybody know how their p2 publisher works ?

Thanks
Martin

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Saturday, January 21, 2012 3:14 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Orbit and WTP are not greedy, how about you?



I wanted to give some advance warning that I have upgraded the Orbit and WTP 
build so it produces repositories where the run-time optional bundles are 
specified as non-greedy. This will take effect for M5, in particular, for 
Orbit, the for-M5 Orbit build of 
http://download.eclipse.org/tools/orbit/downloads/drops/S20120120232307/

See bug 247099 [1] and the p2 Publisher wiki [2] for some history and details 
on this issue of greedy vs. non-greedy requirements.

In short, p2 assumes greedy='true' if it is not specified and in the past the 
publisher did not specify it, so there have been many cases in the past where 
users and adopters get things installed that they did not want or need. Plus, 
it would depend on which repo was "pointed to" or what was available in that 
repo at the time of the install, making things a little indeterminate. Rather 
than change the way p2 works (which would have had compatibility issues) it was 
decided to change the way the p2 publisher works.

Most of the time, this change will be nothing but goodness, but I'm giving this 
notice since it does have the potential to "break" something ... or, at least, 
not work as expected.

Potentially it could effect builds, if you use p2 to fetch Orbit pre-reqs and 
if you really required some optional thing, but did not specify it explicitly, 
getting it "by accident" before, due to a bundle having it as an optional 
dependencies.

The more likely impact would be in distribution packages or user installs which 
might have the same issue, of wanting something they got before "by accident" 
but would not now be installed, unless explicitly specified in a feature.

The fix, if any required, in most cases will be to add some missing optional 
item to a feature; sometimes it would be an existing feature, but often might 
be a new feature, in order to let users or adopters decide if they want that 
optional thing or not.

If you do encounter an issue where this change effects your project, especially 
in a negative way, I would appreciate a note in bug 368999 so we understand 
unanticipated impacts.

How about your repo?

I mean this as a rhetorical question, for now, but encourage everyone to move 
to this type of repository for Juno (not for Indigo SR2) where "optional at 
runtime" is not "greedily installed". If we have a mix of some specifying them 
as greedy and some not, I suspect the resulting builds, package distributions, 
and common repository will be indeterminate when we aggregate. And 
indeterminate is bad. We'll discuss this more for M6 as we gain experience with 
M5.

Thanks everyone,

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099
[2] http://wiki.eclipse.org/Equinox/p2/Publisher
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=368999





___
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] Confusion trying to install outdated add-ons (was: Version names rather than Version numbers)

[Oberhuber, Martin]

Hi Ed,

I just found this message drowned way down in my inbox.

I fully agree with the problem statement (it's too easy to install old, 
outdated versions of stuff rather than the recommended line-up).

I've seen this multiple times by our customers too : They installed "Wind River 
Workbench 3.3" and not knowing what Eclipse Train it was built on they 
installed a wrong version of JDT or PDE on top of it. And the p2 error messages 
in such a case a dependency conflict occurs with trying such a thing are not 
helpful at all, nobody can understand them.

I disagree with the proposed solution of naming features etc. after the release 
train. Problems include eg
- A feature may remain unchanged between 2 train releases, eg Eclipse Platform 
CVS .. makes no sense renaming just for the sake of the name
- Multi-version releases like Cedric mentioned
- In custom products the Eclipse train name may also not be known

I feel like a better approach would be making a line-up (like Indigo, or Juno) 
have more influence such that the line-up could "recommend" particular versions 
of add-ons to be installed and/or warn when a non-recommended version of a 
known IU is about to be installed.

How does that sound?
Who would care opening a bug to further explore solutions to the problem ?

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink
Sent: Monday, December 05, 2011 8:25 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Version names rather than Version numbers

Hi

Eclipse release names such as "Indigo" have had a fantastic coordinating 
effect, but they do not go far enough. Behind the scenes users and developers 
need to understand each project's numbering system and for complex projects, 
each plugin's numbering system.

Users: I've just picked up a newsgroup message from a user who followed a 
Vogella tutorial too literally and had initial success installing Galileo 
features on Indigo before getting totally confused by a P2 message when going a 
step further. If the user's choice is Galileo or Helios or Indigo EMF rather 
than EMF 2.5 or 2.6 or 2.7, many more users may manage to make the right 
choice. If the user reviews installed software, the version mismatch will be 
obvious.

Releng: OCL has moved from 3.1 (Indigo) to 3.2 (Juno M1) to 4.0 (Juno
 >M1) so all downstream project relengs must react twice. If instead each 
 >project published a Juno release, all downstream projects would react once 
 >and change all dependencies from Indigo to Juno. Once again, releng might 
 >make the right choice more often, and not need to know about project detail.

Projects: Complex projects add new plugins starting at 1.0, and so may have a 
very diverse range of versions making the overall project version number 
unhelpful.

It would seem quite straightforward to have version names in many locations 
such as update site folders, and fairly easy to allow a
(Indigo) parenthesis on project names in the portal. Allowing version names in 
ZIP builds may also be easy. But moving further to version names for features 
may require an extra attribute in the Juno b3.aggrcon to define the Juno to 
4.1.0 alias. Supporting plugin version names may require extra detail in 
feature files.

Is this a desirable direction?

What is necessary to enthuse, presumably P2, to support it?

 Regards

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

Re: [cross-project-issues-dev] New PDE error reporting in 4.2m4

[Oberhuber, Martin]

Thanks Eric, Dani and John.

Turns out that in fact somehow my PDE Compiler Warning Preferences were messed 
up to all be Error.
And what’s oddest: After a quit and restart, they were all back to the normal 
default settings.

Fortunately I had collected all kinds of logs as well as a stripped-down ZIP of 
my .metadata before the quit-and-restart.
Filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=369182 to follow up.

Regarding Dani’s advice to fix all the errors … that would not have been 
possible since it were just too many. We’re talking about 10 or more different 
kinds of errors, and 500 or so in total. Some of them I didn’t _want_ to fix. 
For others, I tried fixing them as a group but having the properly sorted group 
selected and applying Quickfix the tool insisted that they can’t be fixed as a 
group (I think I tried some encoding errors where the tool thought that 
build.properties should reproduce my project encoding setting).

I haven’t filed a bug yet for making it easier to change warning levels right 
from the Problems view but I think this would be a good approach. Reproducing 
the problem is easy by just setting all PDE > Compiler warning levels to 
“Error”. I’m wondering how many errors jdt.core / jdt.ui would report if that 
is done?

Thanks,
Martin

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, January 19, 2012 4:45 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] New PDE error reporting in 4.2m4

I suggest entering a bug against PDE and we can track it down from there. 
According to Curtis the default severity for missing versions is "ignore" and 
this hasn't changed in Juno. I quickly checked these settings in latest 4.2 
build and I also see them as "ignore". It could be something peculiar about 
your target platform or about how your workspace was upgraded.

John


"Oberhuber, Martin" 
mailto:martin.oberhu...@windriver.com>>
Sent by: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>

01/19/2012 09:36 AM
Please respond to
Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>


To

"Cross project issues 
(cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>)"
 
mailto:cross-project-issues-dev@eclipse.org>>

cc

Subject

[cross-project-issues-dev] New PDE error reporting in 4.2m4







Hi all,

Updating to 4.2m4 as my SDK for development, I’m finding myself swamped with 
tons of new errors such that I can’t compile my code any more.

I do see some value in reporting issues such as version constraints in 
require-bundle, but …
-  Some messages do not seem appropriate to report as errors (eg 
exporting an “internal” package with x-friends should not require specifying a 
version with the package; or, adding additional files to the source build 
should not be an error).
-  And it should be easier to turn them from “error” to “warning” 
(which Preference Page item corresponds to what error?)

The effort needed before I can compile my code which has been running fine for 
years seems not acceptable for me.
For instance, I’d expect a quickfix “convert this error into a warning” with 
each of the new reports introduced.

Is this already discussed in a bug anywhere ?
What are other projects doing ?

Thanks,
Martin___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org<mailto: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] New PDE error reporting in 4.2m4

[Oberhuber, Martin]

Hi all,

Updating to 4.2m4 as my SDK for development, I'm finding myself swamped with 
tons of new errors such that I can't compile my code any more.

I do see some value in reporting issues such as version constraints in 
require-bundle, but ...

-  Some messages do not seem appropriate to report as errors (eg 
exporting an "internal" package with x-friends should not require specifying a 
version with the package; or, adding additional files to the source build 
should not be an error).

-  And it should be easier to turn them from "error" to "warning" 
(which Preference Page item corresponds to what error?)

The effort needed before I can compile my code which has been running fine for 
years seems not acceptable for me.
For instance, I'd expect a quickfix "convert this error into a warning" with 
each of the new reports introduced.

Is this already discussed in a bug anywhere ?
What are other projects doing ?

Thanks,
Martin
___
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] Tycho and FeatureID == BundleID

[Oberhuber, Martin]

Hi all,

As our TM/RSE project is starting migration to Tycho, we're running into the 
Tycho limitation that some of our features include a branding plugin with the 
same name; and featureID == bundleID needs to be treated specially for 
Maven/Tycho. From what I've seen so far,


-  New / incubating projects typically rename their features e.g. by 
appending a ".feature" postfix, e.g. "org.eclipse.rse.feature"


-  But this is a breaking change for consumers including features, so 
some projects rename the branding plugin instead (e.g. appending a ".core" 
postfix)


-  But this is a breaking change for consumers which depend on the 
bundle, so some (particularly older) projects use a special Maven groupID for 
the features as per https://bugs.eclipse.org/bugs/show_bug.cgi?id=353384#c7

I'm leaning towards the 3rd option (special Maven GroupID for features) since I 
don't want to break existing adopters. I've seen comments saying that two 
groupID's in one project is confusing when cleaning a repo, but on the other 
hand I understand that the groupID translates into a directory hierarchy in 
Maven. So appending a ".features" to the groupID ends up as a subdirectory 
which seems OK to me.

Any comments on the approach ?
What have others done ?

Regarding the groupID itself, there was discussion 
[1] between "org.eclipse" 
flat for all, or "org.eclipse.(3rdBundleSegment)", or "org.eclipse.(projectID)" 
... we have never officially resolved the original question, but it seems to me 
that the de-facto trend goes towards the 2nd option with very few exceptions. 
So it looks like in TM/RSE we're going to get 5 groupIDs in total:

-  org.eclipse.dstore

-  org.eclipse.rse

-  org.eclipse.rse.features

-  org.eclipse.tm

-  org.eclipse.tm.features

Does that sound acceptable, or should we rather fold the .dstore groupID into 
the .rse namespace ?

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

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

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