Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

[Konstantin Komissarchik]

Both "you must integrate often" and "you must use OSGi version convention" are 
already Simrel rules. Simrel process is filled with rules that half the 
projects ignore. Enforcement is difficult since the only available stick is to 
drop the project and everything that depends on it from Simrel, yet no one 
wants to see Simrel reduced to a fraction of projects that it currently 
contains and be in a state where we can't even produce some of the most popular 
packages.


The current simrel process was designed at a time when there were significantly 
fewer projects, these projects were well staffed and everyone following the 
platform's release schedule. That's not today. The modern simrel should have 
fewer rules (let's accept the reality) and be able to accommodate projects that 
have radically different release cadence. Both very active projects that 
release every month and projects that release once every few years should be 
able to participate at their own pace.


Thanks,


- Konstantin



From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Stephan Herrmann 
<stephan.herrm...@berlin.de>
Sent: Saturday, December 16, 2017 4:54 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

Another option could be: even "inactive" projects could be required,
to perform builds against each SimRel milestone, even when contributing
a previous version. This should ensure that code still works (compiles
and passes tests) against updated dependencies.

I don't think this should be much of a burden on "maintainers".

Stephan

On 16.12.2017 17:43, Konstantin Komissarchik wrote:
> Dani,
>
>
> DTD did participate in Oxygen, but DTP is in maintenance mode with no one 
> actively working on it. The only time a new build or
> release is made is when a critical need arises. Such event happened in Oxygen 
> M4 with Lucene changes, so DTP produced a 1.14 build
> at that point and went dormant again. In particular, it was not rebuilt with 
> the following milestones.
>
>
> In my opinion, the deprecate and announce policy of API removal isn't 
> effective for projects like DTP. There is a huge code base.
> Only a small part is going to be examined and only when something breaks. 
> There is no one to notice the deprecation warnings.
> Similarly, when the announcement comes, it relies on someone either (a) 
> recognizing that their project depends on that API, or (b)
> proactively searching through the code base for references. Neither of these 
> is very likely to happen for a maintenance mode
> project. What would have helped is strict adherence to OSGi versioning 
> convention (major version bump) as that would have broken DTP
> aggregation and triggered a need for a rebuild, so problematic references 
> would have been caught and fixed.
>
>
> Thanks,
>
>
> - Konstantin
>
>
>
>
> 
> *From:* cross-project-issues-dev-boun...@eclipse.org 
> <cross-project-issues-dev-boun...@eclipse.org> on behalf of Daniel Megert
> <daniel_meg...@ch.ibm.com>
> *Sent:* Saturday, December 16, 2017 9:25 AM
> *To:* Cross project issues
> *Subject:* Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 
> respin?
> Hi Konstantin
>
> Did DTP not participate in Oxygen in June? There the class was already 
> deleted, so, DTP should have run into this in June already.
>
> Note that we announced the deletion on this mailing list.
>
> Dani
>
>
>
> From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
> To: Cross project issues <cross-project-issues-dev@eclipse.org>
> Date: 15.12.2017 17:46
> Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> 
>
>
> Dani,
>
> It wasn’t an internal. It was a deprecated class that was removed. Since DTP 
> isn’t actively being developed, no one saw the
> deprecation warnings. A major version bump would have allowed the removal to 
> be caught earlier…
>
> org.eclipse.jface.util.ListenerList (removed)
>
> org.eclipse.core.runtime.ListenerList (replacement)
>
>
> Thanks,
>
> - Konstantin
>
> *From: *_Daniel Megert_ <mailto:daniel_meg...@ch.ibm.com>*
> Sent: *Friday, December 15, 2017 3:17 AM*
> To: *_Cross project issues_ <mailto:cross-project-issues-dev@eclipse.org>*
> 

Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

[Konstantin Komissarchik]

Dani,


DTD did participate in Oxygen, but DTP is in maintenance mode with no one 
actively working on it. The only time a new build or release is made is when a 
critical need arises. Such event happened in Oxygen M4 with Lucene changes, so 
DTP produced a 1.14 build at that point and went dormant again. In particular, 
it was not rebuilt with the following milestones.


In my opinion, the deprecate and announce policy of API removal isn't effective 
for projects like DTP. There is a huge code base. Only a small part is going to 
be examined and only when something breaks. There is no one to notice the 
deprecation warnings. Similarly, when the announcement comes, it relies on 
someone either (a) recognizing that their project depends on that API, or (b) 
proactively searching through the code base for references. Neither of these is 
very likely to happen for a maintenance mode project. What would have helped is 
strict adherence to OSGi versioning convention (major version bump) as that 
would have broken DTP aggregation and triggered a need for a rebuild, so 
problematic references would have been caught and fixed.


Thanks,


- Konstantin




From: cross-project-issues-dev-boun...@eclipse.org 
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Daniel Megert 
<daniel_meg...@ch.ibm.com>
Sent: Saturday, December 16, 2017 9:25 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

Hi Konstantin

Did DTP not participate in Oxygen in June? There the class was already deleted, 
so, DTP should have run into this in June already.

Note that we announced the deletion on this mailing list.

Dani



From:    Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:Cross project issues <cross-project-issues-dev@eclipse.org>
Date:15.12.2017 17:46
Subject:Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 
respin?
Sent by:cross-project-issues-dev-boun...@eclipse.org




Dani,



It wasn’t an internal. It was a deprecated class that was removed. Since DTP 
isn’t actively being developed, no one saw the deprecation warnings. A major 
version bump would have allowed the removal to be caught earlier…



org.eclipse.jface.util.ListenerList (removed)

org.eclipse.core.runtime.ListenerList (replacement)

Thanks,



- Konstantin





From: Daniel Megert<mailto:daniel_meg...@ch.ibm.com>
Sent: Friday, December 15, 2017 3:17 AM
To: Cross project issues<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?



> platform made an API change after that which broke some of the DTP 
> functionality

Do you have a bug report for that? The platform usually doesn't break APIs. Did 
DTP maybe use internals?

Dani



From:Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:"cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>
Date:14.12.2017 22:11
Subject:[cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Could someone forward this to the Planning Council, please?



I am currently working with Nick Boldt to transition DTP releng responsibility. 
In the meantime, the version of DTP in Oxygen.2 has compatibility issues. It 
was last build with Oxygen.0.M4 and platform made an API change after that 
which broke some of the DTP functionality. The 1.14.1 release that contains the 
fix is ready to go. Since EGit has initiated a respin, would it be possible for 
DTP to join. The change is low risk. Basically changing package names for a 
class that now must be found in a different plugin and corresponding version 
updates.



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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=MMH7LYZwjbox0bC45973M-gJrSog1mXSz-ZAj-pQA5o=zClipTo-omiP3JZ6zQMGb9SCOYmx8UlKgF9USHmCOl8=<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev%26d%3DDwICAg%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y%26m%3DMMH7LYZwjbox0bC45973M-gJrSog1mXSz-ZAj-pQA5o%26s%3DzClipTo-omiP3JZ6zQMGb9SCOYmx8UlKgF9USHmCOl8%26e%3D=02%7C01%7C%7Cd2192413a95344bc57f508d54466e4d0%7C84df9e7fe9f640afb435%7C1%7C0%7C636490131068023882=UZ9dKKx9ptnLbkdi1oRgwWGNBJqUIc35h7UipOsf8t8%3D=0>

 [attachment &

[cross-project-issues-dev] Sapphire in Photon

[Konstantin Komissarchik]

Sapphire will participate in Photon with +3 offset. For now, the contributed 
release will remain 9.1 (same as Oxygen).

___
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] Can DTP join EGit in Oxygen.2 respin?

[Konstantin Komissarchik]

Dani,

It wasn’t an internal. It was a deprecated class that was removed. Since DTP 
isn’t actively being developed, no one saw the deprecation warnings. A major 
version bump would have allowed the removal to be caught earlier…

org.eclipse.jface.util.ListenerList (removed)
org.eclipse.core.runtime.ListenerList (replacement)

Thanks,

- Konstantin


From: Daniel Megert
Sent: Friday, December 15, 2017 3:17 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

> platform made an API change after that which broke some of the DTP 
> functionality

Do you have a bug report for that? The platform usually doesn't break APIs. Did 
DTP maybe use internals?

Dani



From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:        "cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>
Date:        14.12.2017 22:11
Subject:        [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?
Sent by:        cross-project-issues-dev-boun...@eclipse.org


Could someone forward this to the Planning Council, please?
 
I am currently working with Nick Boldt to transition DTP releng responsibility. 
In the meantime, the version of DTP in Oxygen.2 has compatibility issues. It 
was last build with Oxygen.0.M4 and platform made an API change after that 
which broke some of the DTP functionality. The 1.14.1 release that contains the 
fix is ready to go. Since EGit has initiated a respin, would it be possible for 
DTP to join. The change is low risk. Basically changing package names for a 
class that now must be found in a different plugin and corresponding version 
updates.
 
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=MMH7LYZwjbox0bC45973M-gJrSog1mXSz-ZAj-pQA5o=zClipTo-omiP3JZ6zQMGb9SCOYmx8UlKgF9USHmCOl8=


___
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] Can DTP join EGit in Oxygen.2 respin?

[Konstantin Komissarchik]

Could someone forward this to the Planning Council, please?

I am currently working with Nick Boldt to transition DTP releng responsibility. 
In the meantime, the version of DTP in Oxygen.2 has compatibility issues. It 
was last build with Oxygen.0.M4 and platform made an API change after that 
which broke some of the DTP functionality. The 1.14.1 release that contains the 
fix is ready to go. Since EGit has initiated a respin, would it be possible for 
DTP to join. The change is low risk. Basically changing package names for a 
class that now must be found in a different plugin and corresponding version 
updates.

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] DTP in Oxygen.2 and beyond

[Konstantin Komissarchik]

Brian,

Are you going to try to contribute DTP 1.14.1 to Oxygen.2? I think EGit is 
about to request a respin, so there might be an opening to fit it in. It would 
be better than staying with the version that’s known to be broken until 
Oxygen.3.

Thanks,

- Konstantin


From: Brian Payton
Sent: Monday, December 11, 2017 9:19 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DTP in Oxygen.2 and beyond

Thank you Konstantin for the build fix!

I will do some basic testing to verify that DTP is operating normally with 
Oxygen.2

Regards,
Brian

Brian Payton
Developer, Next Generation Platform for Analytics
IBM Silicon Valley Laboratory



Konstantin Komissarchik ---12/07/2017 04:24:11 PM---DTP 1.14.1 build with the 
fix for the previously described issue is now available. https://urldefens

From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Date: 12/07/2017 04:24 PM
Subject: Re: [cross-project-issues-dev] DTP in Oxygen.2 and beyond
Sent by: cross-project-issues-dev-boun...@eclipse.org




DTP 1.14.1 build with the fix for the previously described issue is now 
available.

https://www.eclipse.org/datatools/downloads.php

Thanks,

- Konstantin


From: Konstantin Komissarchik
Sent: Thursday, December 7, 2017 2:20 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] DTP in Oxygen.2 and beyond

Currently, DTP contributes version 1.14 to the aggregation, which actually has 
compile time errors against the Oxygen platform. The contributed build was 
produced for Oxygen M4. It appears that some time after that, a breaking change 
was made in the platform, but the major version of the bundle in question was 
not incremented. So aggregation wasn’t blocked requiring action from DTP, but 
presumably some subset of DTP functionality has not functioned as of Oxygen. 
Aleksandar Kurtakov did find and report the issue in May [1], but as folks 
probably know, DTP isn’t actively staffed by anyone, so non-blocking issues 
aren’t likely to get the time of day from anyone.
That’s enough history. I spent some time today to prepare a DTP 1.14.1 build 
that addresses this issue, but I don’t have the time to test this build or to 
shepherd the change into aggregation. Frankly, I can’t even tell you what 
functionality is currently broken. DTP is a large functional area and I am not 
an expert. I only got involved to unjam the last aggregation issue.

So, if someone is interested in testing DTP 1.14.1 and shepherding it into 
Oxygen.2 or another release, I will make a build available shortly. 

Thanks,

- Konstantin

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

___
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=i3C8LLIIwImQFxqhdfSv1S3ugiml39o_VQxMAWsoMWY=Oy8GgK-eybxM0W6J_hT-iL-RZPXAd5c24C0uVI-YTEM=MYBwiZF61EGom5rtBbEU_Md93MZKA3NPiL3d_euMbRo=


___
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] Moving on

[Konstantin Komissarchik]

After more than ten years of participation in the Eclipse Ecosystem, I am 
moving on to other pursuits. I will be leaving Oracle at the end of this year. 
My new employer (a startup called Prifender) is not involved in any way with 
Eclipse or tooling. Obviously, I will need to scale down my Eclipse involvement 
substantially.

I have fond memories of working with many folks in this community. I can be 
found on LinkedIn. I hope our paths cross again.

My plan is as follows:

1. Stay on as a committer and the lead of Sapphire to enable contributors as 
necessary. The project is in maintenance mode, but is staying current with 
Eclipse releases.

2. Withdraw as the lead of the upcoming GF Tools. Danny Ju would be the new 
lead and for now the sole committer.

3. Stay on (at least for a bit) on the Architecture Council so that I can 
mentor GF Tools. 

4. Archive the Java EE Configuration Editors project 
(https://projects.eclipse.org/projects/webtools.java-ee-config). I never did 
have the time to finish the work on the editors. The code base does contain a 
half-completed web.xml editor, but unless someone else wants to take on this 
work, we should archive the project.

5. Someone else will need to rescue DTP the next time it needs rescuing. DTP 
uses the build system (Corundum) that I wrote for Oracle and Sapphire. I will 
be around to answer questions about it, but someone else will need to take over 
the releng duties and move the build to CBI, if desired. 

6. Withdraw from everything else, including commit rights on other projects and 
Technology Project PMC.

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] DTP in Oxygen.2 and beyond

[Konstantin Komissarchik]

DTP 1.14.1 build with the fix for the previously described issue is now 
available.

https://www.eclipse.org/datatools/downloads.php

Thanks,

- Konstantin


From: Konstantin Komissarchik
Sent: Thursday, December 7, 2017 2:20 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] DTP in Oxygen.2 and beyond

Currently, DTP contributes version 1.14 to the aggregation, which actually has 
compile time errors against the Oxygen platform. The contributed build was 
produced for Oxygen M4. It appears that some time after that, a breaking change 
was made in the platform, but the major version of the bundle in question was 
not incremented. So aggregation wasn’t blocked requiring action from DTP, but 
presumably some subset of DTP functionality has not functioned as of Oxygen. 
Aleksandar Kurtakov did find and report the issue in May [1], but as folks 
probably know, DTP isn’t actively staffed by anyone, so non-blocking issues 
aren’t likely to get the time of day from anyone.
That’s enough history. I spent some time today to prepare a DTP 1.14.1 build 
that addresses this issue, but I don’t have the time to test this build or to 
shepherd the change into aggregation. Frankly, I can’t even tell you what 
functionality is currently broken. DTP is a large functional area and I am not 
an expert. I only got involved to unjam the last aggregation issue.

So, if someone is interested in testing DTP 1.14.1 and shepherding it into 
Oxygen.2 or another release, I will make a build available shortly. 

Thanks,

- Konstantin

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


___
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] DTP in Oxygen.2 and beyond

[Konstantin Komissarchik]

Currently, DTP contributes version 1.14 to the aggregation, which actually has 
compile time errors against the Oxygen platform. The contributed build was 
produced for Oxygen M4. It appears that some time after that, a breaking change 
was made in the platform, but the major version of the bundle in question was 
not incremented. So aggregation wasn’t blocked requiring action from DTP, but 
presumably some subset of DTP functionality has not functioned as of Oxygen. 
Aleksandar Kurtakov did find and report the issue in May [1], but as folks 
probably know, DTP isn’t actively staffed by anyone, so non-blocking issues 
aren’t likely to get the time of day from anyone.
 
That’s enough history. I spent some time today to prepare a DTP 1.14.1 build 
that addresses this issue, but I don’t have the time to test this build or to 
shepherd the change into aggregation. Frankly, I can’t even tell you what 
functionality is currently broken. DTP is a large functional area and I am not 
an expert. I only got involved to unjam the last aggregation issue.

So, if someone is interested in testing DTP 1.14.1 and shepherding it into 
Oxygen.2 or another release, I will make a build available shortly. 

Thanks,

- Konstantin

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

___
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] Problem withorg.apache.httpcomponents.httpclient bundle in Oxygen M5

[konstantin . komissarchik]

Thanks. I followed the discussion trail that tracks fixing the Orbit bundle to 
the following bug:

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

> 1. Where did version 4.5.2 in root Eclipse project repo come from, as it’s 
> not in Orbit M5 build?

I answered this question myself. This version is in Orbit M5 build, but I 
didn’t initially see it because the bundle inventory on the build page is not 
sorted, so version 4.5.2 is not listed with the other versions of this bundle.

- Konstantin


From: Andrey Loskutov
Sent: Friday, February 3, 2017 9:39 AM
To: Cross project issues; konstantin.komissarc...@oracle.com
Subject: Re: [cross-project-issues-dev] Problem 
withorg.apache.httpcomponents.httpclient bundle in Oxygen M5

I think this is your bug: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=508321

Am 3. Februar 2017 18:33:04 MEZ schrieb konstantin.komissarc...@oracle.com:
>We are having troubling building our plugin against Oxygen M5. The
>org.apache.httpcomponents.httpclient bundle in M5 build of root eclipse
>project is missing org.apache.http.entity.mime package.
>
>In M5 root Eclipse project repo, the version is 4.5.2 (771KB) and is
>missing the mime package
>In M5 Orbit repo, the latest version is 4.3.6 (845KB) and does contain
>the mime package
>On Apache.org, the version 4.5.2 is 1226KB and does contain the mime
>package
>
>So, I have the following questions:
>
>1. Where did version 4.5.2 in root Eclipse project repo come from, as
>it’s not in Orbit M5 build?
>2. Why is this version missing org.apache.http.entity.mime package?
>3. Why are we shipping a different bundle then what’s produced by the
>original third-party project? Since we are using the same bundle
>symbolic name, it’s a rather problematic situation.
>
>Thanks,
>
>- Konstantin

--
Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov

___
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] Problem withorg.apache.httpcomponents.httpclient bundle in Oxygen M5

[konstantin . komissarchik]

Yes, by root I mean platform, JDK, etc.

> But I can comment for the Eclipse top-level project (a.k.a. as SDK and 
> Platform): we never shipped 'org.apache.http.entity.mime'.

That’s false. The eclipse top-level project repository for 4.6.2 includes 
version 4.3.6 of the org.apache.httpcomponents.httpclient bundle that does 
include the mime package.

- Konstantin

From: Daniel Megert
Sent: Friday, February 3, 2017 9:42 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Problem 
withorg.apache.httpcomponents.httpclient bundle in Oxygen M5

Hi Konstantin

I have no clue what you mean with "root". But I can comment for the Eclipse 
top-level project (a.k.a. as SDK and Platform): we never shipped 
'org.apache.http.entity.mime'.

Dani



From:        
To:        Cross project issues 
Date:        03.02.2017 18:33
Subject:        [cross-project-issues-dev] Problem with 
org.apache.httpcomponents.httpclient bundle in Oxygen M5
Sent by:        cross-project-issues-dev-boun...@eclipse.org




We are having troubling building our plugin against Oxygen M5. The 
org.apache.httpcomponents.httpclient bundle in M5 build of root eclipse project 
is missing org.apache.http.entity.mime package.
 
In M5 root Eclipse project repo, the version is 4.5.2 (771KB) and is missing 
the mime package
In M5 Orbit repo, the latest version is 4.3.6 (845KB) and does contain the mime 
package
On Apache.org, the version 4.5.2is 1226KB and does contain the mime package
 
So, I have the following questions:
 
1. Where did version 4.5.2 in root Eclipse project repo come from, as it’s not 
in Orbit M5 build?
2. Why is this version missing org.apache.http.entity.mime package?
3. Why are we shipping a different bundle then what’s produced by the original 
third-party project? Since we are using the same bundle symbolic name, it’s a 
rather problematic situation.
 
Thanks,
 
- Konstantin___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


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

Re: [cross-project-issues-dev] How to provide HDPI icons in yourplug-in

[Konstantin Komissarchik]

An alternative that would not degrade startup performance is to ship one res 
bmp along with vector files. When an image is referenced initially, use the 
shipped bmp and start a background render job from the vector file. Once render 
completes, cache the result to disk and swap in the correct res image into the 
running instance. This would make Eclipse behave analogous to progressive 
resolution image loading.

Just a thought and I am certainly not in a position to volunteer to implement 
something like this. :)

Konstantin


On Sep 21, 2016, at 10:36, Antoine THOMAS  wrote:

>> 
>> Performance and footprint.
> 
> Dani, performance, ok, I can understand that, even if many operating system 
> today are using SVG icons (or vector graphics in general). But footprint? 
> vector graphic files are very light compared to bitmap, especially if you 
> consider that you need to generate different sizes for different screen 
> resolutions. That would help to decrease the footprint of packages.
>  
>  __
>> Antoine THOMAS aka ttoine
>> Product Manager
>> Eclipse Foundation
>> antoine.tho...@eclipse.org
>> +33663137906
>> @ttoine
>> 
>> 
>> 
> ___
> 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] Sapphire to participate in Oxygen

[Konstantin Komissarchik]

Sapphire project will participate in Oxygen with +3 offset. The initial version 
contributed will be the 9.1 release that is slated for release in September.

https://projects.eclipse.org/projects/technology.sapphire/releases/9.1

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] CodeEnvy continues to use deceptivewording that's harmful to Eclipse

[Konstantin Komissarchik]

> I do not believe the foundation as such should restrict a specific projects
> ability to market it self as long as it is not directly deceiving nor 
> outright lying.

I contend that the wording is used expressly for the purpose of deceiving 
Eclipse user base into thinking that Che is the future roadmap for the 
traditional Eclipse IDE.

People wouldn’t object if Che marketed itself based on merits of it’s features 
or even if it had a slogan, such as:

“Eclipse Che, the next generation IDE”

Since “IDE” is understood to be a generic term, everyone in the industry would 
read that statement as a marketing promotion.

Since “Eclipse IDE” is not understood by vast majority of people familiar with 
the brand to be a generic term, the wording is easily interpreted as a 
statement of technical roadmap and seeds confusion in the marketplace.

I understand that there are some that wish “Eclipse IDE” to be a generic term, 
but wishes don’t make fishes.

Just like Ford wouldn’t get away with marketing itself as the next generation 
Chevy, Che shouldn’t be allowed to promote itself in this manner.

Of course, continued investment in the desktop IDE is paramount, but that 
doesn’t mean that we should let the brand that some of us invested close to a 
decade into deteriorate.

Thanks,

- Konstant





From: Max Andersen___
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] CodeEnvy continues to use deceptivewording that's harmful to Eclipse

[Konstantin Komissarchik]

> I guess one question, is that really the Foundation’s role?

Yes, it is. We entrust the foundation to safeguard various Eclipse trademarks 
and this looks like a clear case of misuse.

> Is it not up to us, the community, to make sure the messaging is clear?

Even if others put out clarifying and contradicting statements, the confusion 
will remain and only get worse as more people are exposed to this statement.

> I gave a short talk to a local Ottawa IoT meetup and used the term “Eclipse” 
> and they knew exactly what I was talking about

Of course they did, which is exactly why claims that Che is the next generation 
Eclipse IDE is so damaging as most don’t understand that this isn’t saying that 
Che is the next version of what they understand to be Eclipse. In trademark 
terms, “Eclipse” and “Eclipse IDE” are established trademarks of the 
traditional Eclipse product. Even if that wasn’t an explicit overt decision, 
it’s a fact. In retrospect, perhaps the foundation and the product should not 
have used the same trademark, but we can’t fix the history. Trying to invent a 
new trademark for the traditional Eclipse IDE or the current quasi state where 
we are supposed to pretend that “Eclipse IDE” means any number of things to the 
user base is deeply damaging and expensive to everyone involved. Now is the 
time to stop it, before the damage spreads further.

> Aside from that, the language server protocol is a great initiative and 
> something our tooling really needs.

I agree with that. That’s why I was reading the press release, before I got 
sidetracked by this.

- Konstantin



From: Doug Schaefer___
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] CodeEnvy continues to use deceptive wording that's harmful to Eclipse

[Konstantin Komissarchik]

I was just reading the latest Microsoft/RedHat/Codenvy press release and came 
across the problematic wording that we’ve seen before.

Microsoft Visual Studio Code and Eclipse Che, the next-generation Eclipse IDE, 
have added support for the protocol.

https://www.redhat.com/en/about/press-releases/red-hat-codenvy-and-microsoft-collaborate-language-server-protocol

I think it’s great that Eclipse Foundation is getting more technologically 
diverse, but I find it very concerning that Eclipse Foundation is allowing 
Codenvy/Che to continue to use wording like this. Current Eclipse users will 
read this statement as an official statement of the roadmap for the desktop 
Eclipse IDE or whatever the hell we are supposed to call it now that Eclipse 
IDE doesn’t mean anything, apparently.

I understand why Codenvy would use wording like this as it helps them to 
promote Che. What I don’t understand is why Eclipse Foundation, through 
inaction, is allowing this to continue. 

Thanks,

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

[cross-project-issues-dev] Sapphire falls back to 9.0.5 for Neon

[Konstantin Komissarchik]

The original plan was to release Sapphire 10 for Neon, but work on v10 was not 
completed due to other priorities. As a consequence, we are falling back to the 
latest service release (9.0.5) for Neon. 

As far as I know, there are no consumers of Sapphire on the train, so no one on 
the train would be affected by this change. If that’s not the case, please send 
a note to sapphire-...@eclipse.org and we will look at other options.

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] Declaring Neon M7 staging repositorycomplete

[Konstantin Komissarchik]

Would it be possible to convert reports to e-mail alerts sent to project’s 
mailing list? I suspect we’d get better compliance that way.

Thanks,

- Konstantin



From: David M Williams
Sent: Wednesday, May 4, 2016 5:42 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Declaring Neon M7 staging repositorycomplete

The iron is cooling and the last Git commit is the last one in "recent changes" 
so I am assuming all is done for M7. 

While EPP packages are being created and tested, be sure to sanity check 
"staging", which is (still) at 

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

In parallel, this is a good time for project leads to look through the most 
important "repo reports". (There are too many violations for me to open bugs on 
them all). 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/?d

Lots of unsigned jars: (the primary "third segments" are andmore, eef, and  
m2m. 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/unsigned8.txt

A surprising number of features and bundles missing legal files: (primarily in 
what are new this release: cft and wst.jstd and wst.json) 

http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/layoutCheck.txt

Other reports are interesting and important for professional looking software, 
but not as "blocking" as the two reports above will become. 

Unless blocking problems are found soon, this staging repo will be promoted to 
.../releases/neon on Friday morning, approximately 10 AM (Eastern). 

As usual, I have temporarily paused the Hudson jobs to avoid confusion (except 
for the Gerrit triggered one) and will re-enable them the first of next week.

Thanks, 

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

Re: [cross-project-issues-dev] On the issue of building withthelatest Orbit repository

[Konstantin Komissarchik]

> 1) Ensure that none of the features contributed to simrel include any Orbit 
> bundles,
> but only refer to them via dependencies (and ensure that proper version 
> constraints
> are used in addition).

+1 to not using feature includes on Orbit bundles from project’s features. The 
actual presence of Orbit bundles in project’s repository is not particularly 
harmful as long as the dependencies on these bundles are expressed using 
version ranges.

> 2) Use specific all-in-one features that include the required Orbit bundles 
> (and the
> features deployed to simrel), but only use them to produce self-contained 
> local drop
> files (zip).

That’s one implementation approach of achieving #1. There are other options 
that I have outlined in another response.

> 3) Do not publish all-in-one features on your local update sites either, but 
> rather
> have your local update-sites refer to the simrel update-site via an 
> associate-site entry
> (so Orbit dependencies get pulled in from there).

It’s not a good idea to mix project release repositories and simrel update 
stream. The project’s release should be a fixed point in time, so it’s entirely 
appropriate for the repository to contain the necessary dependendencies at 
versions used during the release process. 

Using an associate-site in the manner you are proposing would mix release 
artifacts and a certain particular update policy in a way that would make it 
difficult for other update policies to exist. The problems with this are 
discussed in more details in other threads on this mailing list. In short, to 
maintain the flexibility of supporting multiple update policies, project’s 
release repositories should never use associate sites (referenced 
repositories). Only an update stream repository (such as simrel or one 
maintained by the project) should do this.

Thanks,

- Konstantin


From: Alexander Nyßen
Sent: Saturday, February 6, 2016 6:14 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] On the issue of building withthelatest 
Orbit repository

What about the following policy?

1) Ensure that none of the features contributed to simrel include any Orbit 
bundles, but only refer to them via dependencies (and ensure that proper 
version constraints are used in addition).
2) Use specific all-in-one features that include the required Orbit bundles 
(and the features deployed to simrel), but only use them to produce 
self-contained local drop files (zip).
3) Do not publish all-in-one features on your local update sites either, but 
rather have your local update-sites refer to the simrel update-site via an 
associate-site entry (so Orbit dependencies get pulled in from there).

With 1) we would have a single authority that controls which Orbit bundles are 
actually provided in a release, namely the simrel aggregator. 2) would cover 
your use case, Ed. 3) would ensure that newer Orbit bundles (added in a 
maintenance release) would also get picked up when installing from a local 
update-site.

Cheers
Alexander

Am 05.02.2016 um 20:22 schrieb Ed Willink <e...@willink.me.uk>:

Hi Konstantin

I have no idea how a download ZIP can easily mirror something.

But I presume what you really mean is that we should produce two 
ZIPs/categories.

- A contribution ZIP/category that replicates the features contributed to 
SimRel.
- An All-in-One ZIP/category that additionally bundles Orbit facilities 
avoiding the need for users to learn how to include Orbit in the available 
sites.

    Regards

        Ed Willink

On 05/02/2016 17:33, Konstantin Komissarchik wrote:
I would advise strongly against using the feature includes directive for Orbit 
bundles. While doing so provides a cheap way to mirror the Orbit bundle into 
the produced project repository, it also locks you down to using that one 
version of the bundle and we end up with multiple versions of various bundles 
in the install, often for no good reason. It’s easy enough to mirror the 
required Orbit bundles using a separate step at the end of the project build 
and be free to require the bundle via whatever version range is most 
appropriate.
 
If everyone did this and simrel aggregation included the latest Orbit 
repository, the result of aggregation would contain fewer duplicate Orbit 
bundles without requiring projects to issue a new release just to move to a 
newer version of an Orbit bundle.
 
Thanks,
 
- Konstantin
 
 
From: Ed Willink
Sent: Thursday, February 4, 2016 11:11 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] On the issue of building with thelatest 
Orbit repository
 
Hi David

Interesting if you're right. I thought projects needed to bundle what wasn't 
bundled upstream. Thus OCL bundles LPG since no one else does. OCL includes 
ASM, Guava that someone else bundles.

You suggest that OCL could stop bundling LPG since LPG would appear in the 
SimRel repo automatically.

However OCL

Re: [cross-project-issues-dev] On the issue of building withthelatest Orbit repository

[Konstantin Komissarchik]

> I have no idea how a download ZIP can easily mirror something.

The exact details depend on the build system you are using. Here are some 
options:

1. If you can inject logic before repository metadata is generated, all you 
need to do is copy the Orbit bundle into your repository. That’s what I do in 
the Sapphire build to include ASM. 

2. If you can’t inject logic before repository metadata is generated, you can 
use a p2 mirror command as a post-processing step. The mirroring command can do 
a partial mirroring (the bundles you specify).

http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_mirror.html=2_0_20_3_0
https://wiki.eclipse.org/Equinox/p2/Ant_Tasks#Partial_Mirroring

3. Alternatively, you can create a root feature that includes your actual 
project feature and the Orbit bundles you require. You point your build at this 
feature, but you do not contribute this feature to simrel and you do not making 
it visible in your own categories file. For the cleanest result, you’d remove 
this feature as a post-build step, but it wouldn’t hurt anything if it were to 
remain as “hidden” feature in your repository that never gets aggregated or 
installed.

> But I presume what you really mean is that we should produce two 
> ZIPs/categories.
> 
> - A contribution ZIP/category that replicates the features contributed to 
> SimRel.
> - An All-in-One ZIP/category that additionally bundles Orbit facilities 
> avoiding
> the need for users to learn how to include Orbit in the available sites.

There is no need to prepare two separate zips. The presence of a particular 
version of an Orbit bundle in a project’s release repository will not prevent 
aggregation from using a newer version, if one is available elsewhere, as long 
as your project’s bundles and features specify the dependency via a version 
range. That is, you aren’t using the feature’s include facility in your 
aggregated project features, which ties you to one exact version of the bundle.

Hope that helps,

- Konstantin


From: Ed Willink
Sent: Friday, February 5, 2016 11:23 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] On the issue of building withthelatest 
Orbit repository

Hi Konstantin

I have no idea how a download ZIP can easily mirror something.

But I presume what you really mean is that we should produce two 
ZIPs/categories.

- A contribution ZIP/category that replicates the features contributed to 
SimRel.
- An All-in-One ZIP/category that additionally bundles Orbit facilities 
avoiding the need for users to learn how to include Orbit in the available 
sites.

    Regards

        Ed Willink
On 05/02/2016 17:33, Konstantin Komissarchik wrote:
I would advise strongly against using the feature includes directive for Orbit 
bundles. While doing so provides a cheap way to mirror the Orbit bundle into 
the produced project repository, it also locks you down to using that one 
version of the bundle and we end up with multiple versions of various bundles 
in the install, often for no good reason. It’s easy enough to mirror the 
required Orbit bundles using a separate step at the end of the project build 
and be free to require the bundle via whatever version range is most 
appropriate.
 
If everyone did this and simrel aggregation included the latest Orbit 
repository, the result of aggregation would contain fewer duplicate Orbit 
bundles without requiring projects to issue a new release just to move to a 
newer version of an Orbit bundle.
 
Thanks,
 
- Konstantin
 
 
From: Ed Willink
Sent: Thursday, February 4, 2016 11:11 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] On the issue of building with thelatest 
Orbit repository
 
Hi David

Interesting if you're right. I thought projects needed to bundle what wasn't 
bundled upstream. Thus OCL bundles LPG since no one else does. OCL includes 
ASM, Guava that someone else bundles.

You suggest that OCL could stop bundling LPG since LPG would appear in the 
SimRel repo automatically.

However OCL still needs to bundle LPG in order for the install from ZIPs to 
work offline. AFAIK there is no SimRel ZIP distribution. If there was, it would 
probably be so big that few would use it. However if there was a 
used-in-SimRel-Orbit ZIP distribution that could be useful and could help you 
enforce limited usage.

    Regards

        Ed Willink
On 04/02/2016 21:35, David M Williams wrote:
Off the top of my head, I think features are suppose to 'include' them, since 
that is the only way to have a reproducible build or install. If it was left up 
to "requires" then who knows what you would get. 
Granted, there should not be anything breaking, if you simply took a what ever 
was there, within some specified range, but especially with third party 
bundles, you never know. Some are real good at following good versioning 
practices, some are not.  Plus, kee

Re: [cross-project-issues-dev] On the issue of building withthelatestOrbit repository

[Konstantin Komissarchik]

Yes, if another project references the hidden all-in-one feature, it will be 
slurped up by aggregation and we are back to square one. If you aren’t able to 
remove this feature from your project’s repository completely as a post-build 
step (the ideal solution), I would recommend naming it in a way that 
discourages its use…

org.eclipse.project.Internal_Root_DoNotReference or some such

Thanks,

- Konstantin



From: David M Williams
Sent: Monday, February 8, 2016 10:17 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] On the issue of building 
withthelatestOrbit repository

 
> 3. Alternatively, you can create a root feature that includes your 
> actual project feature and the Orbit bundles you require. You point 
> your build at this feature, but you do not contribute this feature 
> to simrel and you do not making it visible in your own categories 
> file. For the cleanest result, you’d remove this feature as a post-
> build step, but it wouldn’t hurt anything if it were to remain as 
> “hidden” feature in your repository that never gets aggregated or installed.

I have a lot more to say on the general topic being discussed, but thought I'd 
try to clear up this one point quickly. 

If there is something "in your repository" that you name in your b3aggrcon 
file, then p2 considers anything in there as "fair game" to pull, if it 
satisfies some constraint it is trying to satisfy. 

It may pick something from there rarely, but it has been a "real life" problem 
over the years, where people mistakenly think that only the features they name 
are installed from their repository. Whether not it would be a problem depends 
on many things -- some of which is what other projects do or specify, which you 
could never know or be in control of. 

While some are surprised at this, it is also the way p2 works when a user 
installs something. 


___
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] On the issue of building with thelatest Orbit repository

[Konstantin Komissarchik]

I would advise strongly against using the feature includes directive for Orbit 
bundles. While doing so provides a cheap way to mirror the Orbit bundle into 
the produced project repository, it also locks you down to using that one 
version of the bundle and we end up with multiple versions of various bundles 
in the install, often for no good reason. It’s easy enough to mirror the 
required Orbit bundles using a separate step at the end of the project build 
and be free to require the bundle via whatever version range is most 
appropriate.

If everyone did this and simrel aggregation included the latest Orbit 
repository, the result of aggregation would contain fewer duplicate Orbit 
bundles without requiring projects to issue a new release just to move to a 
newer version of an Orbit bundle.

Thanks,

- Konstantin


From: Ed Willink
Sent: Thursday, February 4, 2016 11:11 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] On the issue of building with thelatest 
Orbit repository

Hi David

Interesting if you're right. I thought projects needed to bundle what wasn't 
bundled upstream. Thus OCL bundles LPG since no one else does. OCL includes 
ASM, Guava that someone else bundles.

You suggest that OCL could stop bundling LPG since LPG would appear in the 
SimRel repo automatically.

However OCL still needs to bundle LPG in order for the install from ZIPs to 
work offline. AFAIK there is no SimRel ZIP distribution. If there was, it would 
probably be so big that few would use it. However if there was a 
used-in-SimRel-Orbit ZIP distribution that could be useful and could help you 
enforce limited usage.

    Regards

        Ed Willink
On 04/02/2016 21:35, David M Williams wrote:
Off the top of my head, I think features are suppose to 'include' them, since 
that is the only way to have a reproducible build or install. If it was left up 
to "requires" then who knows what you would get. 
Granted, there should not be anything breaking, if you simply took a what ever 
was there, within some specified range, but especially with third party 
bundles, you never know. Some are real good at following good versioning 
practices, some are not.  Plus, keep in mind, the "aggregated repository" is 
supposed to be a simple grouping of a subset of what ever is in the project 
repositories. We do not want a situation where if someone installs directly 
from "your" repository, they get one set of things, and if they install from 
the Sim. Release repository they get another set of things. Maintenance would 
be very difficult, then. To repeat, that's off the top of my head. Maybe you 
meant something else. 




From:        Alexander Nyßen 
To:        Cross project issues , 
Date:        02/04/2016 04:20 PM
Subject:        Re: [cross-project-issues-dev] On the issue of building with 
the        latest Orbit repository
Sent by:        cross-project-issues-dev-boun...@eclipse.org




Hi David,

could you please clarify why exactly updates would be needed from projects 
because of changes to Orbit bundles? Does it result from the fact that Orbit 
bundles are actually re-bundled by project features? Or from the fact that 
requirements on them are specified too restrictive within project bundles or 
features?

I’m not sure if this is already covered by some simrel reports, but IMHO we 
would be pretty safe if we ensured that

1) no Orbit bundles were actually re-bundled in project features, but only 
required by them, and that
2) dependencies on Orbit bundles or packages would be specified in line with 
the respective Orbit main releases (based on proper version ranges),

because the aggregation could then pretty much control which Orbit bundles get 
pulled in. If we would in addition impose the same restrictions on Orbit 
releases as on project releases (namely that updates including breaking changes 
are not allowed in maintenance releases), I would assume no project should 
actually have to update its contribution for a maintenance release.

Cheers
Alexander

Am 04.02.2016 um 21:43 schrieb Ed Willink :

HI

"commons.collections" doesn't seem that well used. No version of it is my 
workspaces, so QVTd, (Xtext, EGIT, UML, QVTo, OCL) cannot have a dependency on 
it. No re-contribution needed.

   Regards

       Ed Willink

On 04/02/2016 20:19, David M Williams wrote:
Ed, 

Thanks for bringing this "no maintenance, no new Orbit" issue to my attention. 

While the Planning Council does not like to "make" people do extra work they 
would not normally do, I believe it was the intent of one of our requirements 
[1] that the latest Orbit be consumed every update release -- if there has been 
a new Orbit "released". Most often there is not a new Orbit release, since we 
in Orbit do that only for significant issues. This time, it was only for the 
'commons.collections' security bug, and a bad bug in Ant 1.9.4 that drove us to 

Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[Konstantin Komissarchik]

-1 to forcing the use of refs/for/x

The validation results are unreliable as the aggregation build is not safely 
reproducible. A failed validation result is just as likely to be due to someone 
changing their already-contributed repository.

Thanks,

- Konstantin




From: Mickael Istria
Sent: Thursday, January 7, 2016 8:03 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

On 01/07/2016 03:34 PM, David M Williams wrote:
It is already 'required' that contributors "go though Gerrit" ... but it is 
allowed that the 'review/validation' can be skipped, if "refs/heads/master" 
used instead of "refs/for/master". 
Right, by enforcing Gerrit, I was meaning "enforcing review".

But I myself would not like to see it *required* to go through 
"refs/for/master".
Why so? Have you tried using it?


I think most already do go through "refs/for/master" and the few times they do 
not
It's about half-half: 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/log/ . All changes 
that don't have a "refs/changes/..." tag where pushed directly to master, 
without review and preliminary validation.


I would assume they have a good reason for it. 
I would assume it's more that they need to be educated/encouraged/forced to use 
Gerrit.


Can you point out (or monitor for) cases where people go directly to 
"refs/heads/master" and it causes problems? 
First, there are all failing builds that pre-dates Gerrit usage ;)
I have troubles to identify where to get a history of the SimRel builds and to 
associate it with the actual commits that were involved. The CI jobs on 
http://hudson.eclipse.org/simrel do not show easy to consume data. Is there 
somewhere else I can look at to first get a list of recent-ish failure of 
simrel for Neon?
-- 
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
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] Enforce Gerrit for Simrel?

[Konstantin Komissarchik]

Interesting. When did this happen? There are many contributions still using 
mutable URLs.

- Konstantin



From: Doug Schaefer
Sent: Thursday, January 7, 2016 9:20 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

On Thu, Jan 7, 2016 at 12:14 PM, Mickael Istria <mist...@redhat.com> wrote:
On 01/07/2016 06:08 PM, Konstantin Komissarchik wrote:
-1 to forcing the use of refs/for/x
The validation results are unreliable as the aggregation build is not safely 
reproducible. A failed validation result is just as likely to be due to someone 
changing their already-contributed repository.
Is there a bug on the topic of unreliable validation results? I agree that 
having them reliable seems to be a preliminary requirement.
By the way, some time ago, we discussed the idea of policies about contributing 
immutable URLs and fully qualified versions to Simrel, in order to provide 
predictability and reproducibility. Have these ideas been abandoned? If we were 
to enforce review, we could put additional checks to verify at least that 
versions are fully qualified.

The planning council has made this a requirement for Neon. I'm not sure how 
enforceable this is going to be but if everyone follows the rules, the 
aggregate build will be reproducible.
 

-- 
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
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] core.jobs dependency on Java 8

[Konstantin Komissarchik]

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

Indeed. Java 8 is already supported by GlassFish (since version 4) and WebLogic 
Server (since version 12.1.3).

Thanks,

- Konstantin



From: Thomas Watson
Sent: Monday, December 7, 2015 9:13 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] core.jobs dependency on Java 8


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

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

Tom

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




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




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

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

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

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

John


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

Hi Ralf,

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

Best regards, Lars

On Mon, Dec 7, 2015 at 10:41 AM, Ralf Sternberg
 wrote:
> Hi,
>
> while we all want to use the new features in Java 8, some users of the
> RAP project still can't switch to Java 8 because they have to deploy
> on application servers that run on a (bundled) non-Java-8 VM. For
> example, looking at the IBM WebSphere JDK support list [1], it seems
> that for the server side, it's still a bit too early to require Java
> 8.
>
> Since one of the bundles RAP depends on (core.jobs) has recently been
> updated to Java 8, we find ourselves faced with the choice of either
> locking out those users or shipping RAP 3.1 with an older version of
> the platform. The latter would probably mean to abstain from the Neon
> simultaneous release.
>
> I wonder if there is a general consensus that the Eclipse platform
> (not the IDE) does not support Java 7 anymore. If this is the case, we
> have to live with it, however, I'd appreciate to keep at least the
> core Java-7-compatible for one more year. Looking at the respective
> change in core.jobs [2], it looks like a refactoring, not an API
> change that would require Java 8. Also on the Neon release plan [3],
> it's still marked as 1.7. Is there a chance to revert this change or
> are more of those going to come?
>
> Regards,
> Ralf
>
> [1] http://www-01.ibm.com/support/docview.wss?rs=180=swg27005002
> [2] 
> http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/bundles/org.eclipse.core.jobs?id=e0c1dc5111c5200d39f4611082b34110d735ac29
> [3] 
> https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_6.xml#appendix
>
> --
> Ralf Sternberg
> Project Lead, Remote Application Platform (RAP)
> EclipseSource
>
> Tel: +49 721 66 47 33-0
>
> Innoopract Informationssysteme GmbH
> Lammstraße 21, 76133 Karlsruhe, Germany
> General Manager: Jochen Krause
> Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



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

Haindaalwisch 17a, 22395 

Re: [cross-project-issues-dev] Known outage?

[Konstantin Komissarchik]

See Sapphire HIPP. The failure is seen consistently.

Konstantin Komissarchik
Senior Development Manager
Eclipse Tools Group
Oracle

> On Nov 20, 2015, at 11:26, Matthew Ward(Bt. Kt. SSA.) <matt.w...@eclipse.org> 
> wrote:
> 
> I'm tracking a transient issue with DNS resolution, but it's proving
> difficult to pin down.
> 
> -Matt.
> 
>> On 11/20/2015 02:12 PM, Konstantin Komissarchik wrote:
>> Is there a known outage at eclipse.org where HIPP instances cannot reach the 
>> download server and both HIPP and Bugzilla fail while sending mail? Note 
>> that the download server appears accessible externally.
>> 
>> Konstantin Komissarchik
>> Senior Development Manager
>> Eclipse Tools Group
>> Oracle
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
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] Known outage?

[Konstantin Komissarchik]

Is there a known outage at eclipse.org where HIPP instances cannot reach the 
download server and both HIPP and Bugzilla fail while sending mail? Note that 
the download server appears accessible externally.

Konstantin Komissarchik
Senior Development Manager
Eclipse Tools Group
Oracle
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Where's WST?

[Konstantin Komissarchik]

How do you create your target platform?

- Konstantin


From: Bob Brodt
Sent: Friday, November 13, 2015 12:40 PM
To: issues, Cross
Subject: [cross-project-issues-dev] Where's WST?


Hi all,
I'm having trouble building BPMN2 Modeler because of missing dependencies:
[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: org.eclipse.bpmn2.modeler.core 
1.3.0.qualifier
[ERROR]   Missing requirement: org.eclipse.bpmn2.modeler.core 1.3.0.qualifier 
requires 'bundle org.eclipse.wst.sse.ui 0.0.0' but it could not be found
[ERROR] 
[ERROR] Internal error: java.lang.RuntimeException: No solution found because 
the problem is unsatisfiable.: [Unable to satisfy dependency from 
org.eclipse.bpmn2.modeler.core 1.3.0.qualifier to bundle org.eclipse.wst.wsdl 
0.0.0.; Unable to satisfy dependency from org.eclipse.bpmn2.modeler.core 
1.3.0.qualifier to bundle org.eclipse.wst.xml.core 0.0.0.; Unable to satisfy 
dependency from org.eclipse.bpmn2.modeler.core 1.3.0.qualifier to bundle 
and so ...
Anyone know what happened to org.eclipse.wst.sse? Has it moved?
Thanks!
Bob



-- 

Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat



___
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] Error reporter and third-party code

[Konstantin Komissarchik]

Ok. Thanks for trying. Please remove Sapphire from the error reporting tool. 
The data that’s collected is not actionable.

- Konstantin



From: Marcel Bruch
Sent: Monday, November 9, 2015 7:55 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code


Konstantin,

I presented AERI to the board of directors at EclipseCon Europe last week. I 
also discussed with EMO whether there is a way that Eclipse would extend its 
current scope and start collecting error reports on behalf of others (member 
companies or other third parties). We came to the conclusion that the Eclipse 
Foundation will not collect error reports on behalf of other plug-in providers 
in foreseeable future. The risk that sensitive data might get shared is too 
high in such an uncontrolled environment and setting up a secured system that 
can handle this, the legal work this requires etc. is currently out of scope.

But the Foundation is open to extensions to the error reporting client which 
allow users to share errors with arbitrary (e.g., your own or other 
centralized) data end-points.


Marcel





Am 03.08.2015 um 17:49 schrieb Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com>:

I have filled out the survey, but I do want to stress one point that I think 
got missed in all the discussion…
 
Doing something about auto-censored stack frames is not entirely for 
third-party benefit. It is statistically improbably that all of the errors with 
third-party frames are caused by third-party code, yet all that I’ve seen 
collected for Sapphire are non-actionable in their current censored form. As 
such, we are losing on an opportunity to improve eclipse.org code as well as 
third-party code.
 
Thanks,
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch
Sent: Monday, August 03, 2015 2:49 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code
 
 
Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com>:
 
While we ponder broader process and infrastructure improvements
 
 
To follow up on this part: So far only a few actively discussed this request. 
To me, and likely to others, it’s hard to say who really is interested in 
extending the scope of the error reporting and whether it’s worth taking this 
to the board of directors now. 
 
If you (and others on this list) have a couple of minutes, please cast your 
voice at this short form [1].
 
 
Thank you
Marcel
 
 
[1] 
https://docs.google.com/forms/d/1LtQ8QyMnQ1cD5XTXBdVgynGRaiKEMaUi9a0nxeRoumM/viewform
 
___
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

-- 
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-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] Blocking regression in Neon M3 JDT

[Konstantin Komissarchik]

To close this thread…

I hit the same issue while working on Sapphire build. This gave me an 
opportunity to take another look at this issue. After some experimentation, I 
have determined that what I am hitting appears to be a PDE bug that was exposed 
by the referenced JDT compiler change in Neon M3.

Basically, the issue is that PDE feature does not require JDT feature. If you 
start with a base platform and install PDE feature, you get a portion of JDT 
installed since individual PDE bundles depend on various JDT bundles. This in 
turns causes PDE Build to invoke JDT compiler in a way that makes it trip on 
the error documented in Bug 478427.

I have opened a PDE bug.
 
Bug 481792

Two workarounds are available for those affected. Details in the two referenced 
bugs. Hopefully, this can be fixed for M4.

Thanks,

- Konstantin



From: Konstantin Komissarchik
Sent: Thursday, November 5, 2015 3:14 PM
To: Daniel Megert;Cross project issues
Subject: RE: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


To further clarify… The bug that I referenced is the one that introduced the 
regression. Whatever issue it was fixing was a severity “normal”. I reopened 
the bug when we hit the regression. Let me know if I should open a separate 
blocking bug instead.

- Konstantin



From: Konstantin Komissarchik
Sent: Thursday, November 5, 2015 3:09 PM
To: Daniel Megert;Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


In Neon M3, it’s not a message you can ignore. The build is aborted. See the 
Git diff in the bug.

- Konstantin



From: Daniel Megert
Sent: Thursday, November 5, 2015 3:06 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


I tend to ignore this message. The bug is marked as 'normal' and nothing is 
indicating that this is blocking something or someone. You should try to be 
more specific if you send out a note to this list that there is a blocking 
regression.

Dani



From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:        Cross project issues <cross-project-issues-dev@eclipse.org>
Date:        05.11.2015 21:06
Subject:        [cross-project-issues-dev] Blocking regression in Neon M3 JDT
Sent by:        cross-project-issues-dev-boun...@eclipse.org




See https://bugs.eclipse.org/bugs/show_bug.cgi?id=478427
 
 ___
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] Blocking regression in Neon M3 JDT

[Konstantin Komissarchik]

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


___
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] Blocking regression in Neon M3 JDT

[Konstantin Komissarchik]

To further clarify… The bug that I referenced is the one that introduced the 
regression. Whatever issue it was fixing was a severity “normal”. I reopened 
the bug when we hit the regression. Let me know if I should open a separate 
blocking bug instead.

- Konstantin



From: Konstantin Komissarchik
Sent: Thursday, November 5, 2015 3:09 PM
To: Daniel Megert;Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


In Neon M3, it’s not a message you can ignore. The build is aborted. See the 
Git diff in the bug.

- Konstantin



From: Daniel Megert
Sent: Thursday, November 5, 2015 3:06 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


I tend to ignore this message. The bug is marked as 'normal' and nothing is 
indicating that this is blocking something or someone. You should try to be 
more specific if you send out a note to this list that there is a blocking 
regression.

Dani



From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:        Cross project issues <cross-project-issues-dev@eclipse.org>
Date:        05.11.2015 21:06
Subject:        [cross-project-issues-dev] Blocking regression in Neon M3 JDT
Sent by:        cross-project-issues-dev-boun...@eclipse.org




See https://bugs.eclipse.org/bugs/show_bug.cgi?id=478427
 
 ___
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] Blocking regression in Neon M3 JDT

[Konstantin Komissarchik]

In Neon M3, it’s not a message you can ignore. The build is aborted. See the 
Git diff in the bug.

- Konstantin



From: Daniel Megert
Sent: Thursday, November 5, 2015 3:06 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Blocking regression in Neon M3 JDT


I tend to ignore this message. The bug is marked as 'normal' and nothing is 
indicating that this is blocking something or someone. You should try to be 
more specific if you send out a note to this list that there is a blocking 
regression.

Dani



From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:        Cross project issues <cross-project-issues-dev@eclipse.org>
Date:        05.11.2015 21:06
Subject:        [cross-project-issues-dev] Blocking regression in Neon M3 JDT
Sent by:        cross-project-issues-dev-boun...@eclipse.org




See https://bugs.eclipse.org/bugs/show_bug.cgi?id=478427
 
 ___
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] DTP major version bump for Neon

[Konstantin Komissarchik]

Ed,

I will not repeat the points I made earlier regarding what I consider to be a 
breaking change. I will also not engage in a debate of what constitutes 
responsible API evolution. Suffice it to say that there is more than one valid 
approach. I don’t fault you for how you are choosing to evolve EMF API. I don’t 
like being faulted for how I am choosing to evolve DTP API.

It seems like you feel that you must make a stand to try to force me to make 
this change, despite the minimal effort required on your part to uptake these 
changes. Fine. Please remove EMF ODA features from simrel aggregation so that I 
can see which project I need to engage with next.

Thanks,

- Konstantin



From: Ed Merks
Sent: Thursday, October 29, 2015 10:09 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


Konstantine,

You definitely get my big thumbs up for stepping up to prevent starvation! 
Unfortunately you also get my big thumbs down for the big box of sugar coated 
candies that tend to make children sick. I don't doubt at all that  your 
intentions are good.  Also, as the sole active committer on several projects, I 
can 100% empathize with your plight.  I am also sensitive to the fact that no 
good deed goes unpunished: no matter how hard one tries to do good things, 
someone will rag on it.  It's quite demoralizing so we must learn to keep the 
negaholics at bay.  You have my sympathy...

I do kindly, respectfully, and formally ask you to reconsider this disruptive 
move with DTP.    Major version increments are justifiable only as they relate 
to breakage of API, which is not the case here.  As participants on the release 
train and as leaders of our development communities we should (must) carefully 
consider the impact of our actions.   In this case, your actions are needlessly 
disruptive.  They fly in the face of the documented processes, and do so over 
the objections of other community leaders.  Please, please, please reconsider...

For those who will rail about Konstantine's right to do as he believes best, 
please don't turn this into an issue about "rights".   Yes of course 
Konstantine is free to break API.  Let's not belabor that point.  I too am free 
to break API for EMF, but I also know that it's an absolute no go for my 
community, so I live with the burden imposed by the restriction and continue to 
work on the fundamentally thankless task of making sure that everything I do is 
not disruptive and therefore mostly unnoticed.  Our community must stand up for 
individual rights, but anarchy is no solution...

Note that I will not change the build for EMF ODA to build against the 
version-bumped DTP ODA bundles, so the EMF bundles will continue to exclude API 
breaking versions of DTP ODA.  It's up to the DTP project to version their 
bundles semantically to reflect true API breakage.  If anyone has a problem 
with this, I regretfully offer to withdraw the EMF ODA feature from the train.

Regards,
Ed
On 29/10/2015 5:05 PM, Erdal Karaca wrote:
I think Konstantin has adopted an orphan (that is about to starve).
By incrementing the major version Konstantin is expressing that he is going to 
invest a lot of (mental) energy to prevent the child from starvation.
@Konstantin: What do you need to keep the major version number as-is?
@Community: How else could you express your gratitude to Konstantin for what he 
is doing?

2015-10-28 19:20 GMT+01:00 Lars Vogel <lars.vo...@vogella.com>:
> So in this case Konstantin (and rest of the active DTP committers) should get 
> our full support

I agree with Alexander. Kudos from my side to Konstantin for working
on the (almost) dead DTP components.

Content-wise I also think only the minor version needs increasement
with this change but it is also more important that DTP is available
at all in Neon.

I hope Konstantin does not get discouraged by this email storm and
leaves DTP so that is returns to be a dead project.

Best regards, Lars





On Wed, Oct 28, 2015 at 3:22 PM, Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
> - Original Message -
>> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
>> To: "Ed Willink" <e...@willink.me.uk>, cross-project-issues-dev@eclipse.org
>> Sent: Wednesday, 28 October, 2015 3:44:54 PM
>> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
>>
>>
>>
>> I gave the justification several times.
>
___
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 yo

Re: [cross-project-issues-dev] DTP major version bump for Neon

[Konstantin Komissarchik]

All DTP bundles received a major version bump, including the three that you’ve 
listed. As I’ve already explained, I consider the BREE bump to Java 8 a 
breaking API change on it’s own and all bundles received this change. Another 
likely-breaking change is that all DTP bundles now receive automatic 
calculation of required version ranges for outgoing dependencies based on Neon 
as the min-bound.

I see that WTP has contributed a build that adapts to these changes and EMF is 
next in line. Since EMF also uses automatic version range calculation, you 
should get the correct ranges once you build with DTP 2. Consider this as 
needed pain, if you must. It’s certainly the least that projects that benefit 
from DTP can do to help out.

https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.VALIDATE/133/console

I have no specific plans re ODA’s Java API.

- Konstantin




From: Ed Merks
Sent: Tuesday, October 27, 2015 11:50 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


Konstantin,

In not sure how this plan affects the following specific bundles:
org.eclipse.datatools.connectivity.oda.design.ui
 org.eclipse.datatools.connectivity.oda
 org.eclipse.datatools.connectivity.oda.profile
If they increment their major version, EMF's ODA adapter support will 
definitely stop working.  I would need to do one of two things:
1. Adapt to real API changes.
2. Increase the upper bound because there are no breaking API changes.
Choice number 1 is justifiable as needed pain for improvements to the API.  
Choice number 2 is justifiable only with the argument that you will 
likely/probably/definitely break the API later in the release cycle.  If I'm 
currently stuck with choice 2, I can do nothing except change the upper bound 
until I know what's been broken, simply waiting until you do break it. Are 
there such plans to break the ODA APIs?  If at the end of the release cycle you 
don't break their APIs, then when eventually in a later release when you do 
break them, you'll need to increment them again, causing yet more pain for the 
consumers.

So a fundamental question is the following:

    Do you plan breaking API changes to the ODA APIs?   

If not, please balance your philosophy against the established guidelines, 
i.e., please increment based on API semantics and please do so at the point in 
time that it happens because that's the point in time when the community can 
react.

Also, I would strongly encourage you to consider the community impact of your 
philosophy.  For example, I would love to make breaking changes to EMF.  As the 
sole active committer I can certainly argue that my decisions take precedence, 
right?   But I stop to consider the adverse impact on the community, and I 
refrain.  It's definitely a burden, so I empathize with your plight, but if 
many of us make decisions focused on lightening our own burden, the community 
would not function well.  Eventually our burden would be lightened by the 
non-existence of our community.

Regards,
Ed

On 28/10/2015 2:39 AM, Konstantin Komissarchik wrote:
Let’s set aside the question of whether or not a BREE bump requires a major 
version bump.
 
Simultaneous release process allows projects to contribute a major release, 
with all that it implies. Many projects have done so. The best time to bump the 
version is during the early milestones (now). The DTP items that I’d like to 
work on for the next few months will collectively require a major version bump, 
so I see no sense in continuing to debate whether any one particular change 
necessitates it. After all, we wouldn’t want to be trying to go through this in 
say m7.
 
I do not subscribe to the philosophy that projects should be averse to making 
API breaking changes. Maintaining backwards compatibility is costly both during 
the initial development and indefinitely in the future as legacy code continues 
to confuse both contributors and adopters. I find it better to spend the 
available time on a migration guide, working with adopters (see my Dali patch) 
and making further improvements.
 
Thanks,
 
- Konstantin
 
 

From: David M Williams
Sent: Tuesday, October 27, 2015 6:05 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
I would like to comment on this issue as well. 

If there are no breaking API changes, the major version should not increase. 
Typically increasing the BREE level is seen as "adding API" (from what ever is 
new in the JRE that the BREE is increased to) but not breaking API. And, adding 
API is recommended to be a 'minor' increase in version. Where Brian recommended 
"1.12 to 1.12.1" I would recommend 1.12 to 1.13, based on the guidelines. 

Konstantin, I think the place where your interpretation is too strict is where 
you say 

Here is my decision process… Can you take an Eclipse installation with the 
previous version of yo

Re: [cross-project-issues-dev] DTP major version bump for Neon

[Konstantin Komissarchik]

I gave the justification several times. You are choosing to disregard it. Java 
API is not bundle’s sole API. I don’t consider a restriction in requirements a 
compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 
and the version numbering truthfully communicates that fact. 

I understand the temptation to fudge the truth when it comes to version 
numbers, but that doesn’t make it a sound engineering practice.

- Konstantin



From: Ed Willink
Sent: Wednesday, October 28, 2015 6:29 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon



On 28/10/2015 13:13, Konstantin Komissarchik wrote:

 
I have no specific plans re ODA’s Java API.
 

So absolutely no justification for a change then. There is no need for all 
plugins to bump together. It is cosmetically nice to see all plugins with the 
same version, but it just isn't tenable long term.

For instance many OCL plugins remain at 3.x although those that have been 
affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is a major 
pain, particularly for those clients that are stable and consequently have 
minimal maintenance teams. In some cases useful but unmaintained tools, such as 
UML2 Tools, are killed by the major version change.

    Regards

        Ed Willink


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

Re: [cross-project-issues-dev] DTP major version bump for Neon

[Konstantin Komissarchik]

> potentially no impact on most consumers of your API 

And here lies the crux of our disagreement. I take an absolute position on this 
issue. Potentially not breaking a consumer with an existing DTP installation is 
not the same as not breaking them. Any other position throws into question why 
we even bother having a versioning convention. By definition, any API change 
can be characterized as potentially having no impact.

- Konstantin



From: John Arthorne
Sent: Wednesday, October 28, 2015 8:07 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


> I understand the temptation to fudge the truth when it comes to version 
>numbers, but that doesn’t make it a sound engineering practice.
 
You appear to be the first person to claim that making version numbers reflect 
changes to runtime dependencies is sound engineering practice. Even Java itself 
did not update its major version with Java 8 (which is officially version 1.8 
at the JVM level). Changes to your dependencies have no direct impact on your 
API, and potentially no impact on most consumers of your API. A consumer of 
your bundle may already have a dependency on Java 8 (or whatever the case may 
be), and therefore could not possibly be impacted by your change. By updating 
your BREE, you have ensured that your bundle will not even be loaded by OSGi in 
a runtime using Java 7 or earlier, which is already a strong enough hint to any 
consumer impacted by this change. Updating the bundle version number as well 
offers absolutely no benefit.
 
I will agree with Alex, that as the person doing the work you have the right to 
make these changes, however unjustified. The consumer community will have to 
react accordingly (by updating manifests, contributing to the project, removing 
the dependency, forking, etc).
 
John
 
- Original message -----
From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Ed Willink <e...@willink.me.uk>, "cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>
Cc:
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
Date: Wed, Oct 28, 2015 9:45 AM
 
I gave the justification several times. You are choosing to disregard it. Java 
API is not bundle’s sole API. I don’t consider a restriction in requirements a 
compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 
and the version numbering truthfully communicates that fact.
 
I understand the temptation to fudge the truth when it comes to version 
numbers, but that doesn’t make it a sound engineering practice.
 
- Konstantin
 
 

From: Ed Willink
Sent: Wednesday, October 28, 2015 6:29 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
 
On 28/10/2015 13:13, Konstantin Komissarchik wrote:
 
 
I have no specific plans re ODA’s Java API.
 
 
So absolutely no justification for a change then. There is no need for all 
plugins to bump together. It is cosmetically nice to see all plugins with the 
same version, but it just isn't tenable long term.

For instance many OCL plugins remain at 3.x although those that have been 
affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is a major 
pain, particularly for those clients that are stable and consequently have 
minimal maintenance teams. In some cases useful but unmaintained tools, such as 
UML2 Tools, are killed by the major version change.

    Regards

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



___
cross-project-issues-dev 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] DTP major version bump for Neon

[Konstantin Komissarchik]

Brian,

The version changes have already gone in and we are already contributing DTP v2 
to Neon aggregation. Making all the necessary updates took a non-trivial amount 
of my time.

I posted the version question on dtp-dev on 10/13, but no one responded, so I 
proceeded with the path that makes the most sense to me as the sole active DTP 
committer.

https://dev.eclipse.org/mhonarc/lists/dtp-dev/msg02320.html

Maintaining backwards compatibility as we undertake some sorely-needed 
improvements would use up contributor cycles that DTP does not have to spare. 
The simultaneous release process purposefully allows projects to ship 
API-breaking major releases once a year and many projects have gone this route.

Thanks,

- Konstantin



From: Brian Payton
Sent: Tuesday, October 27, 2015 3:19 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


Sorry, I was away for a few days on vacation and missed this exchange.

I agree with Ed and others that moving the BREE to Java 8 does not imply that 
we need to increment the DTP major version.  I think that moving the version 
from 1.12 to 1.12.1 is sufficient for that.

Refactoring the features is a different issue.  I agree that there are way too 
many DTP features, but we should be able to deal with that in a non-disruptive 
way.  As far as I can tell, only a couple of the features (the most cumulative 
ones) are the only ones actually used by other products.  

A move to version 2.0 would imply that DTP has significant breaking API changes 
(and imply major new function) which would not be correct.

Regards,
Brian

Brian Payton
DTP PMC Lead
Developer Tooling for Data Services
IBM Silicon Valley Laboratory





From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:        Ed Merks <ed.me...@gmail.com>, 
"cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>
Date:        10/24/2015 09:35 AM
Subject:        Re: [cross-project-issues-dev] DTP major version bump for Neon
Sent by:        cross-project-issues-dev-boun...@eclipse.org




Ed,
 
It all comes down to what you consider API. I don’t take the view that API is 
only Java API. I consider BREE to be part of the API, along with other 
dependency specifications. 
 
For instance, DTP 2 is further restricted to Neon. The previous version 
supported a number of previous Eclipse releases by virtue of never raising the 
min version in the version ranges. I am not certain how far back exactly as it 
was not systematically managed in the past. The new build system automatically 
calculates version ranges based on a policy and the policy for DTP 2 is Neon+.
 
The bottom line is that DTP 2 is not a drop-in replacement for DTP 1.12 and the 
version number conveys this fact.
 
A bit of the background… DTP used to have a large committer and contributor 
team, that over the years switched to other areas. The project has been 
essentially dead for the last year or so. This went somewhat unnoticed until 
the Luna version of DTP could no longer install into Neon, because the 
compatibility bundle was gone, which somehow did not mean that Neon platform 
should get a major version bump. Now, I am the only active (and brand new) 
committer on the project. My goal is to get the project into shape that can be 
more easily maintained by a much smaller team. The first step is to get the 
project building at eclipse.org and to have a build system that’s easy for 
anyone to run. That part is done now. If anyone is interested in helping out 
with getting DTP back on track, please send a note to dtp-dev mailing list. 
 
Thanks,
 
- Konstantin
 
 

From: Ed Merks
Sent: Saturday, October 24, 2015 8:31 AM
To: Konstantin Komissarchik;cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
Konstantin,

Comments below.
On 24/10/2015 4:46 PM, Konstantin Komissarchik wrote:
I use a strict interpretation of the versioning convention. 
The version numbers is about semantics and is quite carefully documented:  
https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment

Here is my decision process… Can you take an Eclipse installation with the 
previous version of your project where all dependencies only use your public 
API, update it to the new version and have the installation continue to 
function. The answer in the case of a BREE bump, is “maybe”, so the major 
version bump is required.
This has nothing to do with API and the version numbers is about API semantics 
and binary compatibility...

 
I know that many projects bump BREE without a major version bump. 
I know of none that have done so in the past.  BREE is not a basis for such 
decisions.

Platform even has a complex rubric where certain level of API-breaking changes 
are ok in a release without a major version bump. Projects are choosing this 
path for developer convenience reason, but risk

Re: [cross-project-issues-dev] DTP major version bump for Neon

[Konstantin Komissarchik]

Let’s set aside the question of whether or not a BREE bump requires a major 
version bump.

Simultaneous release process allows projects to contribute a major release, 
with all that it implies. Many projects have done so. The best time to bump the 
version is during the early milestones (now). The DTP items that I’d like to 
work on for the next few months will collectively require a major version bump, 
so I see no sense in continuing to debate whether any one particular change 
necessitates it. After all, we wouldn’t want to be trying to go through this in 
say m7.

I do not subscribe to the philosophy that projects should be averse to making 
API breaking changes. Maintaining backwards compatibility is costly both during 
the initial development and indefinitely in the future as legacy code continues 
to confuse both contributors and adopters. I find it better to spend the 
available time on a migration guide, working with adopters (see my Dali patch) 
and making further improvements.

Thanks,

- Konstantin



From: David M Williams
Sent: Tuesday, October 27, 2015 6:05 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


I would like to comment on this issue as well. 

If there are no breaking API changes, the major version should not increase. 
Typically increasing the BREE level is seen as "adding API" (from what ever is 
new in the JRE that the BREE is increased to) but not breaking API. And, adding 
API is recommended to be a 'minor' increase in version. Where Brian recommended 
"1.12 to 1.12.1" I would recommend 1.12 to 1.13, based on the guidelines. 

Konstantin, I think the place where your interpretation is too strict is where 
you say 

Here is my decision process… Can you take an Eclipse installation with the 
previous version of your project where all dependencies only use your public 
API, update it to the new version and have the installation continue to 
function. The answer in the case of a BREE bump, is “maybe”, so the major 
version bump is required.


There is no "maybe" in this case. Even though the BREE said 1.5, I can assure 
you anyone running DTP Tools for the past several years has not been using 1.5. 
Even if they had been, or, imagine instead the question was if the issue was 
"1.7" to "1.8". Requiring a higher level JRE to run is not consider "breaking". 
As you yourself admit, that's been done repeatedly as new versions of Java come 
out. 

Hence, I recommend you 'revert' the changes you made for the major version 
bump. This is a hard request for me make, so I don't make it lightly, because I 
know you stepped in to build DTP, before anyone else did. And that is much 
appreciated, by me and many others. But ... the change in major version will 
break many adapters needlessly, since no API is breaking. And, such breakage 
will cause Eclipse to be viewed less favorable by many adopters, perhaps even 
cause some smaller adopters to not "move up" -- which is already a problem that 
Eclipse as a whole has not dealt with well. And, we can be assured no users 
will be effected, since we all assume they will be running 1.8 anyway. (Even 
that change to 1.8 is questionable. Especially if headless versions of DTP 
Tools are used "server side", but, I do not know that to be the case, so I 
won't argue about that case. But, changing the BREE when it is not required by 
the bundle's source code is definitely more aggressive than the guidelines[1] 
given in the Simultaneous Release requirements [2]). 

So ... please! :) 

As a wordy aside, I heard 10 years ago, from some leaders that started Eclipse 
(that are no longer around) that "projects with one or two committers, are the 
ones most likely to break API [or adopters]". While not strictly applicable to 
this case, since you are not breaking API, I think the message is when there 
are only one or two committers on a project, they should be extra careful (that 
is, allow LOTS of time for review) before they make a change that would break 
adopters. I think this is especially relevant to DTP precisely because it "has 
not changed" in several releases, so adopters would be especially hard-hit by 
such a change and this, in turn, have an indirect negative impact on users. 

I've said enough, except to thank you again, for stepping in to build DTP 
quickly, when it was broken by the Platform removing the "runtime 
compatibility" bundle. I certainly do not fault you for trying to make things 
simpler for yourself, but in this case, simpler for you means a lot more 
complicated for many others. 

Thanks, 

[1] https://wiki.eclipse.org/Execution_Environments
[2] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29


 



From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
To:        Brian Payton/Santa Teres

Re: [cross-project-issues-dev] DTP major version bump for Neon

[Konstantin Komissarchik]

Ed,

It all comes down to what you consider API. I don’t take the view that API is 
only Java API. I consider BREE to be part of the API, along with other 
dependency specifications. 

For instance, DTP 2 is further restricted to Neon. The previous version 
supported a number of previous Eclipse releases by virtue of never raising the 
min version in the version ranges. I am not certain how far back exactly as it 
was not systematically managed in the past. The new build system automatically 
calculates version ranges based on a policy and the policy for DTP 2 is Neon+.

The bottom line is that DTP 2 is not a drop-in replacement for DTP 1.12 and the 
version number conveys this fact.

A bit of the background… DTP used to have a large committer and contributor 
team, that over the years switched to other areas. The project has been 
essentially dead for the last year or so. This went somewhat unnoticed until 
the Luna version of DTP could no longer install into Neon, because the 
compatibility bundle was gone, which somehow did not mean that Neon platform 
should get a major version bump. Now, I am the only active (and brand new) 
committer on the project. My goal is to get the project into shape that can be 
more easily maintained by a much smaller team. The first step is to get the 
project building at eclipse.org and to have a build system that’s easy for 
anyone to run. That part is done now. If anyone is interested in helping out 
with getting DTP back on track, please send a note to dtp-dev mailing list. 

Thanks,

- Konstantin



From: Ed Merks
Sent: Saturday, October 24, 2015 8:31 AM
To: Konstantin Komissarchik;cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


Konstantin,

Comments below.
On 24/10/2015 4:46 PM, Konstantin Komissarchik wrote:
I use a strict interpretation of the versioning convention. 
The version numbers is about semantics and is quite carefully documented:  
https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment

Here is my decision process… Can you take an Eclipse installation with the 
previous version of your project where all dependencies only use your public 
API, update it to the new version and have the installation continue to 
function. The answer in the case of a BREE bump, is “maybe”, so the major 
version bump is required.
This has nothing to do with API and the version numbers is about API semantics 
and binary compatibility...

 
I know that many projects bump BREE without a major version bump. 
I know of none that have done so in the past.  BREE is not a basis for such 
decisions.

Platform even has a complex rubric where certain level of API-breaking changes 
are ok in a release without a major version bump. Projects are choosing this 
path for developer convenience reason, but risk breaking user installations in 
the process. They are all doing it wrong. :)
Better would be to argue that an IDE shouldn't update to a bundle with a BREE 
that is not satisfied by the version of Java used in that running IDE.   One 
could argue it's a p2 bug if such updates are allowed...

 
Regarding DTP 2 in particular, the BREE bump is just the first of the breaking 
changes in this release. 
Breaking what?

The next target are the features. DTP features could use a round of 
consolidation and refactoring. They are far too many of them and they don’t 
break DTP into components that are useful to the user.
DTP breaking feature compatibility by removing features or removing bundles 
from features is a different issue...  Perhaps they can just introduce new 
features for better grouping...  Of course that makes it overall more 
complicated...

 
Thanks,
 
- Konstantin
 
 

From: Ed Merks
Sent: Saturday, October 24, 2015 5:12 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
Kaloyan,

No, a client that has compiled against your current version remains binary 
compatible with your new version.  No need to recompile or change their code.  
They just can't run anymore unless they satisfy the highest BREE of all their 
requirements.  The version increment should reflect changes in the APIs and 
implementations.  I think a BREE change just implies a content change which 
implies a micro version increment.

Cheers,
Ed


On 24/10/2015 11:55 AM, Kaloyan Raev wrote:
Hi, 
 
Does moving to Java 8 justify the bump of the major version? Many projects 
update their BREE without updating their major version.
 
Greetings,
Kaloyan
 
On Fri, Oct 23, 2015 at 12:37 PM, Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com> wrote:
DTP will soon contribute v2 to Neon aggregation stream. The current version is 
1.12.1. The reason for the major version bump is the move to  requiring Java 8. 
All DTP plugins and features will get a major version bump. 
 
I recommend all consuming projects to prepare for this ahead of time by 
relaxing the version 

Re: [cross-project-issues-dev] DTP major version bump for Neon

[Konstantin Komissarchik]

The initial DTP 2 contribution is now in. The first affected project is WTP’s 
Dali/JPA. 

https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.VALIDATE/131/console

I have created a bug and attached a patch.

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

Thanks,

- Konstantin



From: Konstantin Komissarchik
Sent: Friday, October 23, 2015 1:02 PM
To: Cross project issues
Subject: [cross-project-issues-dev] DTP major version bump for Neon


DTP will soon contribute v2 to Neon aggregation stream. The current version is 
1.12.1. The reason for the major version bump is the move to  requiring Java 8. 
All DTP plugins and features will get a major version bump. 

I recommend all consuming projects to prepare for this ahead of time by 
relaxing the version ranges.

Thanks,

- Konstantin



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

[cross-project-issues-dev] Make sure that you sign with Java 8 if you are building and packing with Java 8

[Konstantin Komissarchik]

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

[cross-project-issues-dev] Sapphire is participating in Neon

[Konstantin Komissarchik]

Offset: +3
Version: https://projects.eclipse.org/projects/technology.sapphire/releases/10
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Git outage?

[Konstantin Komissarchik]

Dani,

Your observations match up with mine. I tested the following configurations 
using the same workspace (same repository). All were fresh installs of the Java 
EE package.

juno sr2 - Algorithm negotiation fail
mars - End of IO Stream Read
neon m1 - End of IO Stream Read
mars.1 rc4a – works

I also have a custom Neon installation where platform is M1, but EGit is 4.1. 
This configuration also works.

Hopefully that’s enough for webmasters to figure out what changed.

Thanks,

- Konstantin



From: Daniel Megert
Sent: Tuesday, September 29, 2015 12:51 PM
To: Cross project issues;Eclipse Webmaster (Denis Roy);Denis Roy
Subject: Re: [cross-project-issues-dev] Git outage?
Importance: High


I have the same issue since today and reported it to the webmaster. I suspect a 
change in their config, however, they say there was no change. 

What I see is that it works if I use a current Mars.1 maintenance build or a 
current Neon build. When I use Mars (4.5) it fails. I definitely think that 
something changed on the server(s), e.g. some protocols got disabled or some 
other ssh related changes. 

To me it looks like currently everyone who uses Mars (4.5) can't use EGit with 
ssh. 

Dani 



From:        Konstantin Komissarchik <konstantin.komissarc...@oracle.com> 
To:        "cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org> 
Date:        29.09.2015 21:26 
Subject:        [cross-project-issues-dev] Git outage? 
Sent by:        cross-project-issues-dev-boun...@eclipse.org 




I am getting a failure when pushing or pulling from Git this morning. Is anyone 
else seeing this? 
  
org.eclipse.jgit.api.errors.TransportException: 
ssh://kkomissarc...@git.eclipse.org/gitroot/sapphire/org.eclipse.sapphire.git: 
Session.connect: java.io.IOException: End of IO Stream Read 
                at 
org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139) 
                at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:263) 
                at 
org.eclipse.egit.core.op.PullOperation$1.run(PullOperation.java:97) 
                at 
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2242) 
                at 
org.eclipse.egit.core.op.PullOperation.execute(PullOperation.java:128) 
                at 
org.eclipse.egit.ui.internal.pull.PullOperationUI.execute(PullOperationUI.java:140)
 
                at 
org.eclipse.egit.ui.internal.pull.PullOperationUI$1.runInWorkspace(PullOperationUI.java:115)
 
                at 
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
 
                at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) 
Caused by: org.eclipse.jgit.errors.TransportException: 
ssh://kkomissarc...@git.eclipse.org/gitroot/sapphire/org.eclipse.sapphire.git: 
Session.connect: java.io.IOException: End of IO Stream Read 
                at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:159)
 
                at 
org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:136) 
                at 
org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.(TransportGitSsh.java:262)
 
                at 
org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:161) 
                at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136) 
                at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122) 
                at 
org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138) 
                at 
org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130) 
                ... 8 more 
Caused by: com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: 
End of IO Stream Read 
                at com.jcraft.jsch.Session.connect(Session.java:558) 
                at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)
 
                ... 15 more 
  
  
 ___
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] DTP for Neon stream ...runtime.compatibility ... and LDT? ... and Neon M2

[Konstantin Komissarchik]

Brian,

Is there a bug tracking the work-in-progress to transition DTP to the common 
build infrastructure and building on eclipse.org systems?

- Konstantin



From: Brian Payton
Sent: Tuesday, September 29, 2015 10:31 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] DTP for Neon stream 
...runtime.compatibility ... and LDT? ... and Neon M2


Regarding the compatibility plugin issue for org.eclipse.datatools.oda.cshelp:  
we've been working that issue since last week.  See 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=478330

DTP builds have always been done by Acutate Corp. (as a "tag-along" to the BIRT 
builds), but due to personnel changes, Actuate no longer has any DTP 
committers.  So it's taking some time to make a new fixed DTP build available.

Regards,
Brian

Brian Payton
Developer Tooling for Data Services
IBM Silicon Valley Laboratory



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

[cross-project-issues-dev] Git outage?

[Konstantin Komissarchik]

I am getting a failure when pushing or pulling from Git this morning. Is anyone 
else seeing this?

org.eclipse.jgit.api.errors.TransportException: 
ssh://kkomissarc...@git.eclipse.org/gitroot/sapphire/org.eclipse.sapphire.git: 
Session.connect: java.io.IOException: End of IO Stream Read
    at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
    at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:263)
    at 
org.eclipse.egit.core.op.PullOperation$1.run(PullOperation.java:97)
    at 
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2242)
    at 
org.eclipse.egit.core.op.PullOperation.execute(PullOperation.java:128)
    at 
org.eclipse.egit.ui.internal.pull.PullOperationUI.execute(PullOperationUI.java:140)
    at 
org.eclipse.egit.ui.internal.pull.PullOperationUI$1.runInWorkspace(PullOperationUI.java:115)
    at 
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.eclipse.jgit.errors.TransportException: 
ssh://kkomissarc...@git.eclipse.org/gitroot/sapphire/org.eclipse.sapphire.git: 
Session.connect: java.io.IOException: End of IO Stream Read
    at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:159)
    at 
org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:136)
    at 
org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.(TransportGitSsh.java:262)
    at 
org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:161)
    at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
    at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
    at 
org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
    at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
    ... 8 more
Caused by: com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: 
End of IO Stream Read
    at com.jcraft.jsch.Session.connect(Session.java:558)
    at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)
    ... 15 more



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

Re: [cross-project-issues-dev] Maintenance builds (was Announcing a oneweek slip in the Mars.1 release (from 9/25 to 10/2))

[Konstantin Komissarchik]

The maintenance issue is a tricky one with no right answer for all consumers. 
Some want new features, some want bug fixes for this year’s release, some want 
bug fixes for last year’s release, some want bug fixes for the release three 
year’s ago, etc. 

Ideally, out aggregation processes and infrastructure should support creating 
new aggregation streams with different goals and rules, similarly to how we can 
create new EPP packages simply by having an interested party step forward to 
own it. 

This intersects with the topic of properly supporting check for updates and 
ensuring that no aggregation participant is injecting their own update site 
into check for updates list (currently under discussion at the architecture 
council), otherwise users will accidentally hop off the stream that they 
started on.

- Konstantin



From: Ed Willink
Sent: Thursday, September 24, 2015 8:13 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Maintenance builds (was Announcing a 
oneweek slip in the Mars.1 release (from 9/25 to 10/2))


Hi

That makes sense but shows that we are just shifting the problem.

I see a requirement for
- regular base releases (yearly)
- maintenance releases (four monthly)
- responsive releases (four monthly)

Recognising that maintenance releases were being abused to provide responsive 
releases is probably good, but waving goodbye to maintenance releases is bad.

IMHO we need all three and so long as we try to make do with two we will be in 
trouble with some user community. It seems wrong that because some projects 
have abused the principles of maintenance, users of other projects that have 
observed maintenance discipline suffer.

    Regards

        Ed Willink
On 24/09/2015 15:35, Ian Bull wrote:
Ed, 

The reason for the change from Mars SR1 to Mars 1 is because this is how we've 
been doing it for years. Many people (EGit / JGit, Mylyn, CDT -- to name a few) 
had been putting minor releases in the release train during the SRs. I ran some 
numbers last year, and > 1000 Installable Units had incremented their minor 
version number between SR0 and SR2. This means, assuming people are following 
the version guidelines, that up to 1,000 bundles had already been adding new 
API between SR0 and SR2. 

Changing the name of the train just means we are acknowledging what was already 
happening.

Cheers,
Ian 

On Wed, Sep 23, 2015 at 11:21 PM, Ed Willink  wrote:
HI

Surely this is the inevitable consequence of Mars.1 rather than Mars SR1?

SR1 required each component to be a safe upgrade so that exact release timing 
was irrelevant.

Mars.1 is a new release so users must get to see the co-ordinated new release 
in one go rather than incrementally. If A.1 pulls in B.1, but C uses B, users 
of C are in a mess until they get C.1.

    Regards

        Ed Willink



On 24/09/2015 05:26, Gunnar Wagenknecht wrote:
David,
Am 23.09.2015 um 23:37 schrieb David M Williams :
If not obvious, this means all participants in "coordinated release train" 
should not make your releases visible on 9/25, but wait until 10/2 10 AM to 
make them visible, and announce your official releases.
This seem unnecessarily restrictive. I don't bother with the announcement part. 
However, I don't recall there is something in the process that requires project 
to wait publishing the release bits. Not making them visible could have a huge 
effect on a project's adopter community.

-Gunnar

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




-- 
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource



___
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



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4419/10692 - Release Date: 09/24/15



___
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] New components in Mars.1 (was Re:Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

[Konstantin Komissarchik]

Thanks, John, for reminding me of this aspect. We will definitely need to 
address this aspect as well, otherwise only non-epp package users will receive 
the update benefits.

- Konstantin



From: John Arthorne
Sent: Wednesday, September 23, 2015 12:33 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was 
Re:Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)


I think the issue is that the whole product has to offer an update.. individual 
features in the product cannot publish updates independently that will be 
discovered by the update check. This is both a good thing and a bad thing, 
depending on your perspective.. I don't think there is a silver bullet solution 
to this (but I would also enjoy hearing proposals :).
 
John
 
- Original message -
From: Pascal Rapicault 
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: cross-project-issues-dev@eclipse.org
Cc:
Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re: 
Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)
Date: Wed, Sep 23, 2015 3:19 PM
  
I was about to ask the same :)

On 15-09-23 02:54 PM, Mike Milinkovich wrote:
> On 23/09/2015 1:49 PM, Doug Schaefer wrote:
>> if we could ever get Check for Updates working properly, this
>> wouldn't have been such a big issue.
>
> Doug (or anyone)
>
> Is there a written proposal anywhere on how "Check for Updates" should
> be modified?
>
> Is there an existing consensus around such a proposal?
>

___
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] DTP for Neon stream

[Konstantin Komissarchik]

 Has anyone reached out to DTP team yet regarding Neon M2 compatibility? I haven’t seen anything on cross-project and dtp-dev list is silent as well. DTP last released with Luna (version 1.12) and that’s what’s currently contributed to Neon aggregation, but it’s not compatible with the M2 build of the platform.  [java] Cannot complete the install because one or more required items could not be found. [java]  Software being installed: Data Tools Platform Enablement for Sqlite 1.12.0.v201406061321-542AkF7AJ7SAKAPBF (org.eclipse.datatools.enablement.sqlite.feature.feature.group 1.12.0.v201406061321-542AkF7AJ7SAKAPBF) [java]  Missing requirement: DTP ODA Context-sensitive Help 1.1.2.v201309200751 (org.eclipse.datatools.oda.cshelp 1.1.2.v201309200751) requires 'bundle org.eclipse.core.runtime.compatibility [3.1.100,4.0.0)' but it could not be found [java]  Cannot satisfy dependency: [java]   From: Data Tools Platform User Documentation 1.12.0.v201405281819-47C18w95FHAM87EJJD7 (org.eclipse.datatools.doc.user.feature.group 1.12.0.v201405281819-47C18w95FHAM87EJJD7) [java]   To: org.eclipse.datatools.oda.cshelp [1.1.2.v201309200751] [java]  Cannot satisfy dependency: [java]   From: Data Tools Platform Enablement for Sqlite 1.12.0.v201406061321-542AkF7AJ7SAKAPBF (org.eclipse.datatools.enablement.sqlite.feature.feature.group 1.12.0.v201406061321-542AkF7AJ7SAKAPBF) [java]   To: org.eclipse.datatools.sqldevtools.feature.feature.group 1.12.0 [java]  Cannot satisfy dependency: [java]   From: Data Tools Platform SQL Development Tools 1.12.0.v201406061321-7N8P7IFDri6qjCyg6Q61VhVsihvO (org.eclipse.datatools.sqldevtools.feature.feature.group 1.12.0.v201406061321-7N8P7IFDri6qjCyg6Q61VhVsihvO) [java]   To: org.eclipse.datatools.doc.user.feature.group 1.7.0  
___
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] DTP for Neon stream

[Konstantin Komissarchik]

 Has anyone reached out to DTP team yet regarding Neon M2 compatibility? I 
haven’t seen anything on cross-project and dtp-dev list is silent as well. DTP 
last released with Luna (version 1.12) and that’s what’s currently contributed 
to Neon aggregation, but it’s not compatible with the M2 build of the platform. 
 [java] Cannot complete the install because one or more required items 
could not be found. [java]  Software being installed: Data Tools Platform 
Enablement for Sqlite 1.12.0.v201406061321-542AkF7AJ7SAKAPBF 
(org.eclipse.datatools.enablement.sqlite.feature.feature.group 
1.12.0.v201406061321-542AkF7AJ7SAKAPBF) [java]  Missing requirement: DTP 
ODA Context-sensitive Help 1.1.2.v201309200751 
(org.eclipse.datatools.oda.cshelp 1.1.2.v201309200751) requires 'bundle 
org.eclipse.core.runtime.compatibility [3.1.100,4.0.0)' but it could not be 
found [java]  Cannot satisfy dependency: [java]   From: Data Tools 
Platform User Documentation 1.12.0.v201405281819-47C18w95FHAM87EJJD7 
(org.eclipse.datatools.doc.user.feature.group 
1.12.0.v201405281819-47C18w95FHAM87EJJD7) [java]   To: 
org.eclipse.datatools.oda.cshelp [1.1.2.v201309200751] [java]  Cannot 
satisfy dependency: [java]   From: Data Tools Platform Enablement for 
Sqlite 1.12.0.v201406061321-542AkF7AJ7SAKAPBF 
(org.eclipse.datatools.enablement.sqlite.feature.feature.group 
1.12.0.v201406061321-542AkF7AJ7SAKAPBF) [java]   To: 
org.eclipse.datatools.sqldevtools.feature.feature.group 1.12.0 [java]  
Cannot satisfy dependency: [java]   From: Data Tools Platform SQL 
Development Tools 1.12.0.v201406061321-7N8P7IFDri6qjCyg6Q61VhVsihvO 
(org.eclipse.datatools.sqldevtools.feature.feature.group 
1.12.0.v201406061321-7N8P7IFDri6qjCyg6Q61VhVsihvO) [java]   To: 
org.eclipse.datatools.doc.user.feature.group 1.7.0  ___
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] Unannounced Changes Have Unforeseen Consequences

[Konstantin Komissarchik]

I, for one, would like to have further discussion on the topic of platform 
strictly following Semantic Versioning as it’s an important tool in ensuring 
that we create valid installations that don’t break with class not found or 
method not found errors. 

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Monday, September 14, 2015 7:27 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences

 

Hi everyone,

 

This has been a great discussion. I have a few points to add:

 

- It is very important for the Platform (and other projects) to have the right 
to occasionally remove API. In a nutshell, maintaining API forever generally 
benefits existing consumers but adds pain and cost for those maintaining the 
API. As the number of API maintainers has dwindled, the Platform made a 
deliberate choice about 5 years ago to slightly relax its previous stringent 
API maintenance practices. There are APIs in Platform none of the remaining 
committers understand or use, and it creates a large burden on them to maintain 
it. The huge API surface area of the Platform also creates a burden for new 
consumers. When there are 5 available ways to do something with the Platform 
API, removing some of the oldest and least recommended options helps new 
adopters chose the right path. While this depends on your perspective, I think 
moving the needle slightly in favor of committers and new adopters is 
beneficial for the future of the Platform, even if there is some impact for 
legacy code consumers.

 

- In this particular case, the Platform API removal process was not completely 
followed [1, 2]. The removal is being reverted for the next Platform 
integration build. The API may still be removed in the June 2017 simultaneous 
release, so if you have already taken steps to adopt the changes, consider 
yourself ahead of the game :) It is important for API removals to be widely 
announced, and a justification given to the community who will be impacted by 
it. I apologize for this not being done in this case.

 

- On the topic of semantic versioning, there is no easy answer. Incrementing 
the major version number of a bundle in the Platform is guaranteed to have a 
massive impact on adopters, even if they did not use the particular API that 
was affected. Nearly every annual release of the Eclipse Platform has had some 
very minor API breakage, which is always carefully documented in the migration 
guide. If we strictly followed Semantic Versioning, the major version of much 
of the Platform would now be around 12 or so by now, and adopters would have 
learned to completely remove the upper bound from their version ranges to avoid 
being constantly broken at the bundle metadata level. What we have always done 
in the Platform is try to have the version numbers reflect the anticipated 
overall impact on clients. In most release, the API is 99.9% compatible and we 
don't let the rare exception dictate the overall version number. I still 
believe this approach minimizes the total impact on consumers, but if the 
community feels a stricter interpretation of SemVer is more valuable, it is 
worth discussing.

 

Links:

 

[1] https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy

[2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

 

john

 

- Original message -
From: Ed Merks 
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues 
Cc:
Subject: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences
Date: Sat, Sep 12, 2015 4:07 AM
  

Hi,

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

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

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

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

 

 

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

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Konstantin Komissarchik]

Commonly, if a feature includes a bundle or a feature whose version has 
updated, the feature’s version is updated in a similar fashion. Note that this 
doesn’t mean that versions will match, simply that an api breaking change in a 
bundle translates to an api breaking change in the feature, etc. I don’t know 
if this is formally documented somewhere.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull
Sent: Monday, September 14, 2015 8:03 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences

 

I may be wrong, but I don't think that updating a single bundles major version 
requires the product version number to be updated. Eclipse currently ships with 
bundles numbered from 1.x (jface.databinding) to 8.x (jetty) and we've been 
using 4.x as the product version for years. I agree that we should follow our 
semantic version rules for bundles & features. Our entire base platform (OSGi & 
p2) depend on this.

 

Does anyone have a link to how the product version relates to the bundles 
contained within the product?

 

Cheers,

Ian

 

 

 

On Mon, Sep 14, 2015 at 7:44 AM, Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com> wrote:

I, for one, would like to have further discussion on the topic of platform 
strictly following Semantic Versioning as it’s an important tool in ensuring 
that we create valid installations that don’t break with class not found or 
method not found errors. 

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Monday, September 14, 2015 7:27 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences

 

Hi everyone,

 

This has been a great discussion. I have a few points to add:

 

- It is very important for the Platform (and other projects) to have the right 
to occasionally remove API. In a nutshell, maintaining API forever generally 
benefits existing consumers but adds pain and cost for those maintaining the 
API. As the number of API maintainers has dwindled, the Platform made a 
deliberate choice about 5 years ago to slightly relax its previous stringent 
API maintenance practices. There are APIs in Platform none of the remaining 
committers understand or use, and it creates a large burden on them to maintain 
it. The huge API surface area of the Platform also creates a burden for new 
consumers. When there are 5 available ways to do something with the Platform 
API, removing some of the oldest and least recommended options helps new 
adopters chose the right path. While this depends on your perspective, I think 
moving the needle slightly in favor of committers and new adopters is 
beneficial for the future of the Platform, even if there is some impact for 
legacy code consumers.

 

- In this particular case, the Platform API removal process was not completely 
followed [1, 2]. The removal is being reverted for the next Platform 
integration build. The API may still be removed in the June 2017 simultaneous 
release, so if you have already taken steps to adopt the changes, consider 
yourself ahead of the game :) It is important for API removals to be widely 
announced, and a justification given to the community who will be impacted by 
it. I apologize for this not being done in this case.

 

- On the topic of semantic versioning, there is no easy answer. Incrementing 
the major version number of a bundle in the Platform is guaranteed to have a 
massive impact on adopters, even if they did not use the particular API that 
was affected. Nearly every annual release of the Eclipse Platform has had some 
very minor API breakage, which is always carefully documented in the migration 
guide. If we strictly followed Semantic Versioning, the major version of much 
of the Platform would now be around 12 or so by now, and adopters would have 
learned to completely remove the upper bound from their version ranges to avoid 
being constantly broken at the bundle metadata level. What we have always done 
in the Platform is try to have the version numbers reflect the anticipated 
overall impact on clients. In most release, the API is 99.9% compatible and we 
don't let the rare exception dictate the overall version number. I still 
believe this approach minimizes the total impact on consumers, but if the 
community feels a stricter interpretation of SemVer is more valuable, it is 
worth discussing.

 

Links:

 

[1] https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy

[2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

 

john

 

- Original message -
From: Ed Merks <ed.me...@gmail.com>
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues <c

Re: [cross-project-issues-dev] Error reporter and third-party code

[Konstantin Komissarchik]

I have filled out the survey, but I do want to stress one point that I think 
got missed in all the discussion…

 

Doing something about auto-censored stack frames is not entirely for 
third-party benefit. It is statistically improbably that all of the errors with 
third-party frames are caused by third-party code, yet all that I’ve seen 
collected for Sapphire are non-actionable in their current censored form. As 
such, we are losing on an opportunity to improve eclipse.org code as well as 
third-party code.

 

Thanks,

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch
Sent: Monday, August 03, 2015 2:49 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

 

 

Am 31.07.2015 um 22:01 schrieb Konstantin Komissarchik 
konstantin.komissarc...@oracle.com:

 

While we ponder broader process and infrastructure improvements

 

 

To follow up on this part: So far only a few actively discussed this request. 
To me, and likely to others, it’s hard to say who really is interested in 
extending the scope of the error reporting and whether it’s worth taking this 
to the board of directors now. 

 

If you (and others on this list) have a couple of minutes, please cast your 
voice at this short form [1].

 

 

Thank you

Marcel

 

 

[1] 
https://docs.google.com/forms/d/1LtQ8QyMnQ1cD5XTXBdVgynGRaiKEMaUi9a0nxeRoumM/viewform

 

___
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] Error reporter and third-party code

[Konstantin Komissarchik]

While we ponder broader process and infrastructure improvements, would it be 
possible to make an improvement to the triage screen to handle the case of a 
non-actionable error report due to hidden stack frames? Currently, what I do is 
check this is (may be) a bug option and add the following text:

This issue appears to be caused by a third-party plugin. Due to current 
privacy rules, we are unable to determine the identity of this plugin, so 
unfortunately this report is not actionable. We are working on a process 
improvement to be able to handle reports like this one in the future.

Perhaps we could have a checkbox to do this in one gesture, ideally also 
accessible from quick actions menu.

Thanks,

- Konstantin

 

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch
Sent: Saturday, July 25, 2015 2:55 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code


 Am 25.07.2015 um 15:32 schrieb Konstantin Komissarchik 
 konstantin.komissarc...@oracle.com:
 
  is opening and extending automated error reporting to 
  non-eclipse.org plugins, e.g. to member companies, worth these efforts?
  
 In my opinion, it’s the only way to achieve the goals you set out to achieve 
 at the beginning of this project. Users view Eclipse as a whole that 
 encompasses third-party plugins and we need to act accordingly to remain 
 competitive.

I appreciate your view point and foresight on this. I agree to your assessment 
that knowing about errors (and fixing them) is important to remain competitive.

Just a minor correction about the goals I set out: My goal was to help Eclipse 
projects to quickly see where their code breaks during the Mars milestone 
builds (cf. my first email on error reporting [1]). Later, and with support of 
the Eclipse Foundation, we extended the scope and kept the error reporter in 
Mars release. Still, the goal then was to help Eclipse projects to learn where 
their code breaks in the (larger) field. As a community we achieved impressive 
360 FIXED bugs - alone 85 in the last month. But there is still a lot work to 
do.


If we want to broaden the scope to the whole Eclipse ecosystem, we’d need to 
get serious about how much work this will cause. To be sustainable, the 
Foundation would need to allocate resources for such a service for a longer 
period and the system needs continuous improvement and maintenance to scale 
properly with the new demands. If we go down that road (assuming we get legal 
right at some point), this can’t continue as someone’s side project. It needs a 
commitment. How can we ensure this project will stay healthy?

Marcel

[1] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10902.html
___
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] Error reporter and third-party code

[Konstantin Komissarchik]

There are two separate aspects...

1. Allowing the vendors to actually subscribe to the error reports. This is 
aimed at letting vendors help themselves.

2. Revising the system for censoring stack frames. This is aimed at 
facilitating project committers in investigating the error reports that land in 
their inbox by allowing them to know who they should be talking to. A more 
flexible system allowing parties to be added to the list of namespaces that 
aren't censored would be valuable, especially if coupled with improved 
defaulting/prompting on the client. One thing to consider is how would we 
handle vendors who are not aware of the error reporting system operated by 
Eclipse Foundation or at least are not aware that they can take advantage of 
it. We could collect a list of namespaces that are being censored and have 
someone in an elevated trust position (Eclipse Foundation staff?) attempt to 
contact these vendors to inform them of the error collection system and how 
they can advantage of it.

Ideally, we address both of these aspects. #2 may be more achievable in the 
short term (SR1).

Thanks,

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Gunnar 
Wagenknecht
Sent: Saturday, July 25, 2015 7:33 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

 Am 25.07.2015 um 06:32 schrieb Konstantin Komissarchik 
 konstantin.komissarc...@oracle.com:
 
  is opening and extending automated error reporting to 
  non-eclipse.org plugins, e.g. to member companies, worth these efforts?
  
 In my opinion, it’s the only way to achieve the goals you set out to achieve 
 at the beginning of this project. Users view Eclipse as a whole that 
 encompasses third-party plugins and we need to act accordingly to remain 
 competitive.


Marcel,

What about a program that allows any vendor to opt-out of the filtering? It 
could be as simple as requesting a vendor to open a Bugzilla and/or submit an 
agreement form to the Eclipse Foundation listening the package namespaces which 
should not be filtered anymore.

-Gunnar

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

___
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] Error reporter and third-party code

[Konstantin Komissarchik]

-1

We have no reliable means at assigning blame. Only guesses that are likely 
wrong as many times as they are right. Presenting unreliable blame information 
to the end user will cause many problems.

Konstantin Komissarchik
Senior Development Manager
Eclipse Tools Group
Oracle

 On Jul 25, 2015, at 06:54, Ed Willink e...@willink.me.uk wrote:
 
 Hi
 
 I agree. I think that the Eclipse-is-buggy hazard can be mitigated by 
 ensuring that any pop-up on behalf of a third party has a prominent logo for 
 that third party in the dialog. It may be a good idea for Eclipse project 
 logos to have similar prominence.
 
 Regards
 
 Ed Willink
 
 On 25/07/2015 14:32, Konstantin Komissarchik wrote:
  is opening and extending automated error reporting to non-eclipse.org 
  plugins,
  e.g. to member companies, worth these efforts?
  
 In my opinion, it’s the only way to achieve the goals you set out to achieve 
 at the beginning of this project. Users view Eclipse as a whole that 
 encompasses third-party plugins and we need to act accordingly to remain 
 competitive.
  
 Thanks,
  
 - Konstantin
  
  
  
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel 
 Bruch
 Sent: Saturday, July 25, 2015 1:08 AM
 To: Cross project issues
 Subject: Re: [cross-project-issues-dev] Error reporter and third-party code
  
 I'll try to summarize the discussion up to the current point.
 
 The error reporting currently collects errors logged by eclipse plugins, 
 i.e., the plugin-id of the log message needs start with org.eclipse. Log 
 messages logged by 3rd parties (e.g., oracle.tools) are ignored (some 
 exceptions here, e.g. for logging libs).
 
 In stacktraces, class names that do not stem from org.eclipse are anonymized 
 by default (some exceptions here, e.g. for logging libs).
 
 We initially started from the question whether 3rd party class names should 
 be anonymized in general. In the meantime we are discussing whether we 
 should open the error reporting to 3rd parties out there to allow them to 
 get notified about problems in their code.
  
 If we do so (just hypothetically), there are a few more things to consider.
  
 Legal:
 3rd parties would get access to confidential data. Then these parties would 
 certainly need to sign some kind of NDA.
  
 Resources:
 We currently run the error reporting on a small VM. If the system should 
 collect error reports for   every plugin out there, this will 
 need better hardware resources, more network bandwidth, and EF webmaster 
 powers to administrate those machines.
  
 Technical:
 The system may need to support legal requirements in some way. So far it’s 
 build on trust that Eclipse committers are in itself a trusted group. When 
 opening it, it needs all the things like a rights management, different 
 duplicate detection and project guessing mechanisms etc.
  
  
 Konstantin,
 is opening and extending automated error reporting to non-eclipse.org 
 plugins, e.g. to member companies, worth these efforts?
  
 Marcel
  
  
 
 
 Am 24.07.2015 um 20:09 schrieb Konstantin Komissarchik 
 konstantin.komissarc...@oracle.com:
 
  I dug a bit deeper into Sapphire error reports. My conclusion: Adding more 
  open source namespaces wont help much in your (and Nebula’s) case.
  
  Most reports mentioning Sapphire are from the namespaces 
  oracle.eclipse.tools.*
  and com.liferay.* Some reports show that Sapphire clients even do not 
  follow
  the bundle name to package name conventions. Neither oracle.eclipse.*
  nor com.liferay.* seem to be open source namespaces.
  
 RedHat is an adopter of Sapphire and Liferay is LGPL 
 (http://www.liferay.com/downloads/liferay-portal/license-ce)
  
  Regarding your popup question:
  I sense that asking a user for permission whenever a non-eclipse namespace
  was discovered in the trace will quickly be very   annoying.
  
 My thinking is that you only ask regarding the first two or three segments 
 of the namespace and then you persist the choice. So if we already asked you 
 about oracle.eclipse namespace, you aren’t going to be bugged again 
 regarding this. An average user is unlikely to have that many plugins from 
 varied sources installed for these popups to be a big annoyance.
  
  We only send errors that are logged by eclipse.org / apache.org plugins. 
  However, 
  it's likely that com.liferay will log errors that reference Sapphire 
  classes. Following
  your previous arguments, you would be interested in those as well. 
  
 I am surprised to hear that we don’t report these today.
  
  Here we get into trouble. If we do so, we would need to send every error 
  report 
  that mentions at least one Eclipse class to eclipse.org. if we do so, 
  users will notice
  dozens of „an error was logged“ popup appears per day (b/c some 3rd party 
  plugins
  causes trouble) and will conclude that Eclipse is extremely buggy. 
  
 I disagree

Re: [cross-project-issues-dev] Error reporter and third-party code

[Konstantin Komissarchik]

 is opening and extending automated error reporting to non-eclipse.org plugins,

 e.g. to member companies, worth these efforts?

 

In my opinion, it’s the only way to achieve the goals you set out to achieve at 
the beginning of this project. Users view Eclipse as a whole that encompasses 
third-party plugins and we need to act accordingly to remain competitive.

 

Thanks,

 

- Konstantin

 

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch
Sent: Saturday, July 25, 2015 1:08 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

 

I'll try to summarize the discussion up to the current point.

The error reporting currently collects errors logged by eclipse plugins, i.e., 
the plugin-id of the log message needs start with org.eclipse. Log messages 
logged by 3rd parties (e.g., oracle.tools) are ignored (some exceptions here, 
e.g. for logging libs).

In stacktraces, class names that do not stem from org.eclipse are anonymized by 
default (some exceptions here, e.g. for logging libs).

We initially started from the question whether 3rd party class names should be 
anonymized in general. In the meantime we are discussing whether we should open 
the error reporting to 3rd parties out there to allow them to get notified 
about problems in their code.

 

If we do so (just hypothetically), there are a few more things to consider.

 

Legal:

3rd parties would get access to confidential data. Then these parties would 
certainly need to sign some kind of NDA.

 

Resources:

We currently run the error reporting on a small VM. If the system should 
collect error reports for every plugin out there, this will need better 
hardware resources, more network bandwidth, and EF webmaster powers to 
administrate those machines.

 

Technical:

The system may need to support legal requirements in some way. So far it’s 
build on trust that Eclipse committers are in itself a trusted group. When 
opening it, it needs all the things like a rights management, different 
duplicate detection and project guessing mechanisms etc.

 

 

Konstantin,

is opening and extending automated error reporting to non-eclipse.org plugins, 
e.g. to member companies, worth these efforts?

 

Marcel

 

 





Am 24.07.2015 um 20:09 schrieb Konstantin Komissarchik 
konstantin.komissarc...@oracle.com:

 I dug a bit deeper into Sapphire error reports. My conclusion: Adding more 
 open source namespaces wont help much in your (and Nebula’s) case.
 
 Most reports mentioning Sapphire are from the namespaces 
 oracle.eclipse.tools.*
 and com.liferay.* Some reports show that Sapphire clients even do not follow
 the bundle name to package name conventions. Neither oracle.eclipse.*
 nor com.liferay.* seem to be open source namespaces.
 
RedHat is an adopter of Sapphire and Liferay is LGPL 
(http://www.liferay.com/downloads/liferay-portal/license-ce)
 
 Regarding your popup question:
 I sense that asking a user for permission whenever a non-eclipse namespace
 was discovered in the trace will quickly be very annoying.
 
My thinking is that you only ask regarding the first two or three segments of 
the namespace and then you persist the choice. So if we already asked you about 
oracle.eclipse namespace, you aren’t going to be bugged again regarding this. 
An average user is unlikely to have that many plugins from varied sources 
installed for these popups to be a big annoyance.
 
 We only send errors that are logged by eclipse.org / apache.org plugins. 
 However, 
 it's likely that com.liferay will log errors that reference Sapphire classes. 
 Following
 your previous arguments, you would be interested in those as well. 
 
I am surprised to hear that we don’t report these today.
 
 Here we get into trouble. If we do so, we would need to send every error 
 report 
 that mentions at least one Eclipse class to eclipse.org. if we do so, users 
 will notice
 dozens of „an error was logged“ popup appears per day (b/c some 3rd party 
 plugins
 causes trouble) and will conclude that Eclipse is extremely buggy. 
 
I disagree with the conclusions you draw in these statements.
 
1. The identity of the party that logged the error is not a predictor of which 
party is responsible for the error, as clearly evident by the captured error 
reports that we have. All you know is where the catch clause was located.
 
2. Users view Eclipse as a whole, in comparison to other IDE choices. They 
don’t really care that much that the party that’s causing them grief is a 
third-party plugin, especially if it’s an essential plugin to get Eclipse to 
fulfill a given function.
 
 I’m not sure I wanna go down this road. At some point we need to draw a line
 between error that are caused by third-party plugins (like Liferay or Oracle) 
 and
 those caused by Eclipse plugins.
 
There is no automated system for making that determination in a reliable

Re: [cross-project-issues-dev] Error reporter and third-party code

[Konstantin Komissarchik]

 buggy. 

 

I’m not sure I wanna go down this road. At some point we need to draw a line 
between error that are caused by third-party plugins (like Liferay or Oracle) 
and those caused by Eclipse plugins.

 

I agree to your previous statement that if we can't make sense of error reports 
containing third-party traces, we should not collect them. 

This will certainly lead to a better user experience and is something we should 
definitely change for SR1.

 

I see that this does not solve your issue with Sapphire clients but in this 
regard I’m more with Gunnar. I think those clients (which currently make ~28% 
of the error reports) should actually sign-up and subscribe to their error 
reports - or set up their own error collection to review and fix their issues 
themselves. But if we collect them for them, it must be clear to the users that 
these errors are caused by Liferay, Oracle, Findbugs or whatever third-party 
plugin. Eclipse should not make the impression of being buggy if third party 
plugins are behaving badly.

 

Marcel




Am 23.07.2015 um 19:23 schrieb Konstantin Komissarchik 
konstantin.komissarc...@oracle.com:

A big +1

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Max Rydahl 
Andersen
Sent: Thursday, July 23, 2015 5:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

On 22 Jul 2015, at 20:37, Marcel Bruch wrote:




Konstantin,
I assume you understand that user may find stacktraces to contain 
potentially sensitive data (if not - let’s assume it hypothetically), 
which options would you propose?


I'll repeat what I've suggested in the past: add more to the list of OSS 
packages, i.e. add org.jboss.*, *.redhat.* and org.spring.* and possible more 
from the top 10 OSS plugins on marketplace.

So at least the OSS collaborators can be contacted and we can help improve ;) 
/max http://about.me/maxandersen ___
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

 

-- 
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-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] Error reporter and third-party code

[Konstantin Komissarchik]

  Stack frames should not be considered sensitive just because they are
from
  a non-OSS code base. Users post stack traces with commercial code
references
  in forums all the time. 
 
 Just because they can doesn't imply the are allowed to. There are all
sorts
 of liability questions in here which I can understand as a reason to hide
those.
 I think there is no other option. For most commercial code, the user can
not
 simply allow disclosing such information but a vendor would have to
approve.

As long as we make it an explicit user choice whether convey this
information to eclipse.org, I don't see how it's any different from user
making an explicit choice to convey this information to say stackoverflow.
The burden is on the user to comply with whatever policy or license
obligations might bind them.

How about this system:

1. The top-level package names are extracted from the stack trace.
2. The list is checked against an authorized list, which starts out
populated with OSS namespaces.
3. If entries are found that aren't on the authorized list, the user gets a
prompt like the following:

An error was detected that includes stack frames with the following
namespaces that you have not yet authorized for reporting to Eclipse
Foundation.

[list of namespaces]

[Authorize] [Authorize Once] [Do Not Report]

 Looking at the stack trace, I read it as some Sapphire code is
initializing a data
 service which is implemented/provided by an adopter. That adopter calls
some WTP code
 which fails. From a Sapphire perspective it shouldn't matter if it's a WTP
issue, 
 i.e. it's the adopter's code which is failing. This should be handled in a
way that
 an adopter realizes it. For example, Sapphire should catch the root
exception and
 wrap it into a Sapphire specific error message which is then either
presented to
 the user or logged to a log file. From an Eclipse.org error handler
perspective,
 this error message should probably then be marked as log message. It
really
 isn't Sapphires fault here.

My goal is not to remove blame from Sapphire, but to improve the quality
across the Eclipse ecosystem. As such, the proposed strategy doesn't help.

My bottom line... Censored stack traces are useless. At the minimum,
anything that would be censored should not be reported. Ideally, we should
have a better system in place that avoids the need to censor so that we can
help adopters improve their code and let them help us by exposing errors
that are only evident in adopter scenarios.

Thanks,

- Konstantin



-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Gunnar
Wagenknecht
Sent: Thursday, July 23, 2015 9:29 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

Konstantin,

 Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik
konstantin.komissarc...@oracle.com:
 
 Stack frames should not be considered sensitive just because they are from
a non-OSS code base. Users post stack traces with commercial code references
in forums all the time. 

Just because they can doesn't imply the are allowed to. There are all
sorts of liability questions in here which I can understand as a reason to
hide those. I think there is no other option. For most commercial code, the
user can not simply allow disclosing such information but a vendor would
have to approve.

Anyway, I have a different view on your particular topic, which might be a
possible approach for other adopters.

Looking at the stack trace, I read it as some Sapphire code is initializing
a data service which is implemented/provided by an adopter. That adopter
calls some WTP code which fails. From a Sapphire perspective it shouldn't
matter if it's a WTP issue, i.e. it's the adopter's code which is failing.
This should be handled in a way that an adopter realizes it. For example,
Sapphire should catch the root exception and wrap it into a Sapphire
specific error message which is then either presented to the user or logged
to a log file. From an Eclipse.org error handler perspective, this error
message should probably then be marked as log message. It really isn't
Sapphires fault here.

BTW, the NPE in WTP is bad, though. But we simply can't now if it's a bug in
WTP or if the adopter failed to initialize/setup some expected variables.
But it should be the adopter investigating it.

-Gunnar


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







___
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

Re: [cross-project-issues-dev] Error reporter and third-party code

[Konstantin Komissarchik]

A big +1

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Max Rydahl 
Andersen
Sent: Thursday, July 23, 2015 5:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

On 22 Jul 2015, at 20:37, Marcel Bruch wrote:

 Konstantin,
 I assume you understand that user may find stacktraces to contain 
 potentially sensitive data (if not - let’s assume it hypothetically), 
 which options would you propose?

I'll repeat what I've suggested in the past: add more to the list of OSS 
packages, i.e. add org.jboss.*, *.redhat.* and org.spring.* and possible more 
from the top 10 OSS plugins on marketplace.

So at least the OSS collaborators can be contacted and we can help improve ;) 
/max http://about.me/maxandersen ___
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] Error reporter and third-party code

[Konstantin Komissarchik]

 'instance of Eclipse' is ambiguous.

I mean the Eclipse installation. The reason I think this scope is the correct 
one is as that's where the plugins reside that the user is asked to make a 
choice regarding. For instance, I might have one installation with pre-release 
code that's private and another installation with all released code that's ok 
to report.

 If the choice is persisted in the workspace that seems too dangerous, 
 one accidental answer and Eclipse becomes leaky.

Accidental answers can happen regardless of which approach we use. Obviously, 
we would need a preference system for changing the preference after the initial 
prompt.

 Persisting only until the next Eclipse restart seems like a good idea.

That seems highly unworkable. I don't know of any user who would tolerate 
constant prompting like that.

Thanks,

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed Willink
Sent: Wednesday, July 22, 2015 9:28 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

Hi

IMHO, the 20% who explicitly enabled message anonymization will also enable 
method anonymization because they are avoiding the problem of needing corporate 
approval of any release of data. A method name such as
SHA4096 may reveal what algorithm is being exploited/developed. Too risky if 
you are not sure.

  My proposal: When a we detect a non-OSS stack frame,   we actively ask the 
  user to make a choice that’s then persisted for that instance of Eclipse.

'instance of Eclipse' is ambiguous.

If the choice is persisted in the workspace that seems too dangerous, one 
accidental answer and Eclipse becomes leaky.

Persisting only until the next Eclipse restart seems like a good idea.

 Regards

 Ed Willink


On 22/07/2015 22:39, Marcel Bruch wrote:
 My proposal:…

 Sounds okay to me. I wonder if the short cut „not to enable 3rd party class 
 names in stack traces by default“ would be acceptable as well since it’s 
 right on the configure dialog and easy to grasp (IMHO).

 Wayne,
 any thoughts on this? I can change the defaults (for SR1) if the EF would 
 agree.

 FWIW, during the milestone build (until June 20th) 20% of the users 
 explicitly enabled „message anonymization“ because they feared that the 
 message may contains sensitive data. I’d expect that users are less concerned 
 about method names. I’d need to validate this number with the current 
 reporter base to give a more reliable statement, though.

   
 I strongly conclude that if someone would have cared at that time, they 
 would have had the chance to participate from the very first moment.
   
 I brought up the issue of better handling third-party plugins several times 
 from the very beginning and was brushed off.

 I did a quick search for earlier discussions on this topic and found [1] from 
 August 2014. I don’t have the impression you were brushed off in that 
 discussion - but nevertheless: If I did (there or somewhere else) I apologize 
 for that.

 Best,
 Marcel

 [1] https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03193.html

   
 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

 -
 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 2015.0.6081 / Virus Database: 4392/10286 - Release Date: 
 07/22/15

___
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] Error reporter and third-party code

[Konstantin Komissarchik]

 I assume that you and everyone else understands why classnames from 
 non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default.

 

I can imagine cases, such as pre-release products and internal solutions, where 
stack frames contain sensitive information, but that isn’t the general case. 
Stack frames should not be considered sensitive just because they are from a 
non-OSS code base. Users post stack traces with commercial code references in 
forums all the time. Companies that worry about this sort of thing scramble 
their bytecode. User should not be expected to know how to change preferences 
to turn off filtering as none of them will bother to do so, especially as the 
error reporting system gives them the impression that the error reports are 
actionable with information omitted.

 

My proposal: When a we detect a non-OSS stack frame, we actively ask the user 
to make a choice that’s then persisted for that instance of Eclipse. If they 
make a choice indicating that non-OSS references are sensitive, we don’t even 
bother sending an error report. I have yet to see an error report with hidden 
frames that was actionable. This active choice should be viewed as equivalent 
to user making a choice to grab a stack from the log and post it on the forum.

 

 I strongly conclude that if someone would have cared at that time, they would 
 have had the chance to participate from the very first moment.

 

I brought up the issue of better handling third-party plugins several times 
from the very beginning and was brushed off.

 

Thanks,

 

- Konstantin

 

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Marcel Bruch
Sent: Wednesday, July 22, 2015 11:37 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

 

Konstantin,

 

let me send this at the beginning: this discussion is greatly appreciated - 
although my personal answer might not be satisfying yet…

 

Library projects like Sapphire or Nebula are somewhat special because they are 
(more or less) exclusively used by third-party plugins. Hence they do not 
benefit that much from the privacy defaults.

 

First question… Why are third-party stack frames hidden? 

 

Although your questions may give a different impression, I assume that you and 
everyone else understands why classnames from non-eclipse/non-apache bundles 
are replaced by HIDDEN.HIDDEN by default.

 

No matter if one does or not, one may ask the following questions (again) and 
judge differently now (after ten thousands of users reported ~170K errors in 
the last 30 days): 

 

(i) whether a class name in a stacktrace should be considered as potentially 
private information“, and

(ii) whether it should be anonymized by default.

 

When we (Eclipse Foundation staff and me) discussed the legal implications of 
the error reporting we came to the conclusion that a class name may reveal 
sensitive information and thus should be anonymized by default.

 

Are the notes from when this was originally considered captured somewhere? 

 

The discussion about what to anonymize and how took place on August 2014. First 
with the Eclipse Foundation Staff in a couple of conference calls and then 
published and summarized in several mails to 
cross-projects-issues-...@eclipse.org. I strongly conclude that if someone 
would have cared at that time, they would have had the chance to participate 
from the very first moment. Let me know if you need me to pull up all emails 
and slides I sent to cross-projects regarding the error reporting at that time. 
I’m pretty sure the whole process was quite transparent at any time and visible 
to everyone starting from M1 to RC4 :-)

 

 

I have contact info for many Sapphire adopters. If I knew who to contact, I 
could actually follow up on these error reports.

 

 

IMHO this is more a legal question then a technical one. It all depends how 
lawyers (and users) judge on the two questions above.

I can imagine that - if member companies agree to collect their error reports 
at eclipse.org OR to opt-in to disable anonymization for their bundles and 
namespaces - we can reduce the number of HIDDEN in your error reports. But as I 
said, this would need the support of the Eclipse foundation and like of the 
member companies.

 

 

Konstantin,

I assume you understand that user may find stacktraces to contain potentially 
sensitive data (if not - let’s assume it hypothetically), which options would 
you propose?

 

 

Regards,

Marcel

 

___
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] Error reporter and third-party code

[Konstantin Komissarchik]

I've been watching the error reports trickling into the Sapphire inbox, but
unfortunately none of them have been actionable so far. The issue is
interaction with third-party code. Consider the following stack trace:

 

java.lang.NullPointerException: HIDDEN

at
org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProvid
erManager.java:101)

at
org.eclipse.jst.j2ee.model.ModelProviderManager.getModelProvider(ModelProvid
erManager.java:281)

at HIDDEN.HIDDEN(HIDDEN:-1)

at HIDDEN.HIDDEN(HIDDEN:-1)

at
org.eclipse.sapphire.PossibleValuesService.initDataService(PossibleValuesSer
vice.java:68)

at org.eclipse.sapphire.services.DataService.init(DataService.java:54)

at org.eclipse.sapphire.services.Service.initIfNecessary(Service.java:60)

at
org.eclipse.sapphire.services.ServiceContext.services(ServiceContext.java:21
7)

at org.eclipse.sapphire.Property.services(Property.java:535)

at org.eclipse.sapphire.Property.service(Property.java:505)

at
org.eclipse.sapphire.services.internal.PossibleValuesValidationService$Condi
tion.applicable(PossibleValuesValidationService.java:82)

at org.eclipse.sapphire.services.ServiceProxy.service(ServiceProxy.java:99)

at
org.eclipse.sapphire.services.ServiceContext.services(ServiceContext.java:17
6)

 

There are three codebases interacting here: Sapphire, WTP and some unknown
third-party plugin. Without knowing the hidden details in order to be able
to initiate a discussion with the third-party, this error report is not
actionable. This is not an isolated case or a minority of cases. Literally
all reports received so far for Sapphire are like that. I know that there
are other leaf projects with a similar issue.

 

Now that we have a solution for capturing and hopefully handling errors that
only involve eclipse.org code, let's have a serious discussion on how we can
handle error reports involving third-party code.

 

First question. Why are third-party stack frames hidden? Are the notes from
when this was originally considered captured somewhere? I have contact info
for many Sapphire adopters. If I knew who to contact, I could actually
follow up on these error reports.

 

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] Rebuild process ... and question for sapphire

[Konstantin Komissarchik]

Sapphire is in the would like to contribute a new build, but not critical
to ask for a respin category. RC4/Final includes a couple of minor fixes
and documentation polish.I was caught up with family responsibilities and
unable to contribute the build in time last night. It wouldn't be the end of
the world if simrel included our RC3, but there is no risk to anyone on the
train from RC4 as fixes are safe and no one on the train is consuming
Sapphire.

 

Thanks,

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M
Williams
Sent: Thursday, June 11, 2015 10:37 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Rebuild process ... and question for
sapphire

 

Often, when doing a rebuild, as motivated by serious WindowBuilder problem,
I would freeze all other content (to what is already in repository) except
for the projects we specifically know are re-submitting. 

In this case, I am going to first try a normal re-build, and will just trust
that no one else is sneaking in changes AND that everyone's repo is still
build-able. 

At the fist sign of trouble, though, I will go back to the frozen content
method. Which brings me to my question for Sapphire. 

I noticed Sapphire changed URLs and qualifiers in b3aggrcon file. Is that
only a move to final URL? Or were there some changes you want in the final
version? I'm asking only to know if I should include Sapphire in frozen
group (if needed) or in known-rebuilding group? (If the later, please
document what's changed via bug numbers, etc., so everyone knows. 

Thanks, 

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

Re: [cross-project-issues-dev] When are Gerrit commits automatically applied?

[Konstantin Komissarchik]

Umm... As software guys, our raison d'etre is to rid the world of manual
steps wherever we see them. :)

If I squint just right, I can sort of see the reason that Hudson is a useful
contributor to the process here (see my prior objections), but once that
verification has been done, what's the value of waiting for the developer to
click on things?

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Stephan
Herrmann
Sent: Wednesday, May 20, 2015 2:42 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] When are Gerrit commits
automatically applied?

I'm not sure what's the goal here?
Enable submit-to-gerrit-and-leave -
without awaiting the result from hudson? ;P If you wait for success, what
harm is done by having to do two more clicks?

my 2c.
Stephan

On 05/20/2015 07:44 AM, Eike Stepper wrote:
 Hi,

 I'm not a Gerrit expert, but a quick search for gerrit auto approve
gives a number of hints, for example a Gerrit hook script:
 http://renier.morales-rodriguez.net/post/49144483266/configuring-gerri
 t-to-auto-submit-on-patch-ap

 Personally I'd also like it if my simrel patch sets would be submitted 
 automatically if Hudson gives a +1, but I'm not sure if that's a security
concern.

 Cheers
 /Eike

 
 http://www.esc-net.de
 http://thegordian.blogspot.com
 http://twitter.com/eikestepper



 Am 18.05.2015 um 19:24 schrieb Mickael Istria:
 On 05/18/2015 06:43 PM, David M Williams wrote:
 I don't know the answer to Sven's question ... quoted here ... does
anyone else?

  Am I right if committer of the org.eclipse.simrel.build Git repo 
  must be manually set them as code reviewer if they want to apply 
  the patch to the Git repo? I've hoped that the push is 
  automatically done if the Hudson build is successful and a fast
forward merge is possible.

 I would hope that it would be applied automatically ... but, from my 
 experience it doesn't seem to be. But, I've only done it a few 
 times, and hope a more Gerrit knowledgeable person can answer 
 authoritatively ... as well as make sure the right thing happens, if
it takes a new bug for webmasters or others to change some setting.
 Gerrit requires a manual approval from a Simrel committer to merge a 
 commit. There is no mechanism to automatically merge a review if 
 automated tests have succeeded; and since I believe the paradigm of
Gerrit and code-review is really to involve an additional human step (in
best case a 3rd-party) in the change, automating merge is probably not
something desirable.
 However, as a committer, you can apply your own patch via Gerrit UI, or
push without using a Gerrit review (and automated tests).
 https://wiki.eclipse.org/index.php?title=Simrel/Contributing_to_Simre
 l_Aggregation_Build#Pushing_your_changes

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

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

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

Re: [cross-project-issues-dev] When are Gerrit commits automatically applied?

[Konstantin Komissarchik]

What's the value in encouraging the developer to wait until verification is
done? Either, it's critical that the contribution goes in, in which case the
developer will wait anyway, or it's not critical and any failures can be
dealt with tomorrow.

- Konstantin

PS: Personally, I'd like to see gerrit/hudson style automated verification
combined with bullet-proof aggregation process that is not susceptible to
contributed repositories changing from underneath it.


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Stephan
Herrmann
Sent: Wednesday, May 20, 2015 3:23 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] When are Gerrit commits
automatically applied?

On 05/21/2015 12:11 AM, Konstantin Komissarchik wrote:
 [...] but once that
 verification has been done, what's the value of waiting for the 
 developer to click on things?

Maybe encouraging the developer to wait until s/he knows whether the job
is done or not?
:)

Disclaimer: as much as I like gerrit, for simrel contributions I still
prefer running the validation at home and then push directly ..
Call me I'm old-school, if you like.

Stephan

 -Original Message-
 From: cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
 Stephan Herrmann
 Sent: Wednesday, May 20, 2015 2:42 PM
 To: cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] When are Gerrit commits 
 automatically applied?

 I'm not sure what's the goal here?
 Enable submit-to-gerrit-and-leave -
 without awaiting the result from hudson? ;P If you wait for success, 
 what harm is done by having to do two more clicks?

 my 2c.
 Stephan

 On 05/20/2015 07:44 AM, Eike Stepper wrote:
 Hi,

 I'm not a Gerrit expert, but a quick search for gerrit auto approve
 gives a number of hints, for example a Gerrit hook script:
 http://renier.morales-rodriguez.net/post/49144483266/configuring-gerr
 i
 t-to-auto-submit-on-patch-ap

 Personally I'd also like it if my simrel patch sets would be 
 submitted automatically if Hudson gives a +1, but I'm not sure if 
 that's a security
 concern.

 Cheers
 /Eike

 
 http://www.esc-net.de
 http://thegordian.blogspot.com
 http://twitter.com/eikestepper



 Am 18.05.2015 um 19:24 schrieb Mickael Istria:
 On 05/18/2015 06:43 PM, David M Williams wrote:
 I don't know the answer to Sven's question ... quoted here ... does
 anyone else?

 Am I right if committer of the org.eclipse.simrel.build Git repo 
 must be manually set them as code reviewer if they want to apply 
 the patch to the Git repo? I've hoped that the push is 
 automatically done if the Hudson build is successful and a fast
 forward merge is possible.

 I would hope that it would be applied automatically ... but, from 
 my experience it doesn't seem to be. But, I've only done it a few 
 times, and hope a more Gerrit knowledgeable person can answer 
 authoritatively ... as well as make sure the right thing happens, 
 if
 it takes a new bug for webmasters or others to change some setting.
 Gerrit requires a manual approval from a Simrel committer to merge a 
 commit. There is no mechanism to automatically merge a review if 
 automated tests have succeeded; and since I believe the paradigm of
 Gerrit and code-review is really to involve an additional human step 
 (in best case a 3rd-party) in the change, automating merge is probably 
 not something desirable.
 However, as a committer, you can apply your own patch via Gerrit UI, 
 or
 push without using a Gerrit review (and automated tests).
 https://wiki.eclipse.org/index.php?title=Simrel/Contributing_to_Simr
 e l_Aggregation_Build#Pushing_your_changes

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

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

 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your

Re: [cross-project-issues-dev] Mars RC1 orbit build incomplete?

[Konstantin Komissarchik]

Thanks, but I am still not seeing the correct landing page for this build…

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Tuesday, May 19, 2015 11:04 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Mars RC1 orbit build incomplete?

 

 and will investigate if all else is as it should be. 

Confirmed to two different references that the modifications were just extra 
things in the wrong place, which I've deleted. 
The actual content of what is there now is as it should be. 

Thanks for letting us know. (And to webmasters, for quick reaction). 





From:David M Williams/Raleigh/IBM@IBMUS 
To:Cross project issues cross-project-issues-dev@eclipse.org, 
Date:05/19/2015 01:38 PM 
Subject:Re: [cross-project-issues-dev] Mars RC1 orbit build incomplete? 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




Who is bgamgle and why are you changing Orbit's DL area? 
-rw-r--r--+ 1 bgamblecommon173K May 13 20:39 index.xml.gz 
-rw-r--r--+ 1 bgamblecommon  2K May 13 20:39 index.html 
-rw-r--r--+ 1 bgamblecommon176K May 13 20:39 content.jar 
-rw-r--r--+ 1 bgamblecommon 81K May 13 20:39 artifacts.jar 
drwxrwsr-x+ 2 david_williams common  4K May 14 14:01 debug/ 
drwxrwsr-x+ 4 david_williams common  4K May 14 14:01 repository/ 
drwxr-sr-x+ 2 bgamblecommon  4K May 18 16:53 plugins/ 
drwxr-sr-x+ 2 bgamblecommon  4K May 18 16:53 features/ 

I have opened following bug for that issue. 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=467605 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=467605 

In the meantime, have removed that incorrect index.html and will investigate if 
all else is as it should be. 





From:Konstantin Komissarchik konstantin.komissarc...@oracle.com 
To:'Cross project issues' cross-project-issues-dev@eclipse.org, 
Date:05/19/2015 01:11 PM 
Subject:[cross-project-issues-dev] Mars RC1 orbit build incomplete? 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




The build that’s listed for Mars RC1 on orbit downloads page doesn’t have the 
usual landing page with info and download links. 
 
 http://download.eclipse.org/tools/orbit/downloads/ 
http://download.eclipse.org/tools/orbit/downloads/ 
 http://download.eclipse.org/tools/orbit/downloads/drops/S20150513182540/ 
http://download.eclipse.org/tools/orbit/downloads/drops/S20150513182540/ 
 
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 
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 
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] Mars RC1 orbit build incomplete?

[Konstantin Komissarchik]

Never mind that. Looks like caching issues. Thanks for fixing.

 

From: Konstantin Komissarchik [mailto:konstantin.komissarc...@oracle.com] 
Sent: Tuesday, May 19, 2015 11:10 AM
To: 'Cross project issues'
Subject: RE: [cross-project-issues-dev] Mars RC1 orbit build incomplete?

 

Thanks, but I am still not seeing the correct landing page for this build…

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Tuesday, May 19, 2015 11:04 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Mars RC1 orbit build incomplete?

 

 and will investigate if all else is as it should be. 

Confirmed to two different references that the modifications were just extra 
things in the wrong place, which I've deleted. 
The actual content of what is there now is as it should be. 

Thanks for letting us know. (And to webmasters, for quick reaction). 





From:David M Williams/Raleigh/IBM@IBMUS 
To:Cross project issues cross-project-issues-dev@eclipse.org, 
Date:05/19/2015 01:38 PM 
Subject:Re: [cross-project-issues-dev] Mars RC1 orbit build incomplete? 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




Who is bgamgle and why are you changing Orbit's DL area? 
-rw-r--r--+ 1 bgamblecommon173K May 13 20:39 index.xml.gz 
-rw-r--r--+ 1 bgamblecommon  2K May 13 20:39 index.html 
-rw-r--r--+ 1 bgamblecommon176K May 13 20:39 content.jar 
-rw-r--r--+ 1 bgamblecommon 81K May 13 20:39 artifacts.jar 
drwxrwsr-x+ 2 david_williams common  4K May 14 14:01 debug/ 
drwxrwsr-x+ 4 david_williams common  4K May 14 14:01 repository/ 
drwxr-sr-x+ 2 bgamblecommon  4K May 18 16:53 plugins/ 
drwxr-sr-x+ 2 bgamblecommon  4K May 18 16:53 features/ 

I have opened following bug for that issue. 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=467605 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=467605 

In the meantime, have removed that incorrect index.html and will investigate if 
all else is as it should be. 





From:Konstantin Komissarchik konstantin.komissarc...@oracle.com 
To:'Cross project issues' cross-project-issues-dev@eclipse.org, 
Date:05/19/2015 01:11 PM 
Subject:[cross-project-issues-dev] Mars RC1 orbit build incomplete? 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




The build that’s listed for Mars RC1 on orbit downloads page doesn’t have the 
usual landing page with info and download links. 
 
 http://download.eclipse.org/tools/orbit/downloads/ 
http://download.eclipse.org/tools/orbit/downloads/ 
 http://download.eclipse.org/tools/orbit/downloads/drops/S20150513182540/ 
http://download.eclipse.org/tools/orbit/downloads/drops/S20150513182540/ 
 
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 
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 
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] Unable to contribute to Mars... very frustrated

[Konstantin Komissarchik]

For years, I've had a working setup that allowed me to update Sapphire's
simrel contribution. With changes to use Gerrit, I am no longer able to
contribute. I've spent hours reading various wikis and I still cannot figure
out what keys I need to have and where I am supposed to shove them. Maybe
this stuff makes sense to someone already versed in Gerrit and SSH, but it
doesn't make sense to me. 

 

Frankly, this is a massive step in the wrong direction. Contributing to
simrel should be made easier, not more difficult. 

 

I have a couple more hours I can devote to this at the maximum. If I can't
figure out how to get back to a working configuration in that time, I am
taking Sapphire out of Mars.

 

Thanks,

 

- Konstantin

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

[cross-project-issues-dev] Unable to contribute to Mars... very frustrated

[Konstantin Komissarchik]

For years, I've had a working setup that allowed me to update Sapphire's
simrel contribution. With changes to use Gerrit, I am no longer able to
contribute. I've spent hours reading various wikis and I still cannot figure
out what keys I need to have and where I am supposed to shove them. Maybe
this stuff makes sense to someone already versed in Gerrit and SSH, but it
doesn't make sense to me. 

 

Frankly, this is a massive step in the wrong direction. Contributing to
simrel should be made easier, not more difficult. 

 

I have a couple more hours I can devote to this at the maximum. If I can't
figure out how to get back to a working configuration in that time, I am
taking Sapphire out of Mars.

 

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] Unable to contribute to Mars... very frustrated

[Konstantin Komissarchik]

I wish it did. Unfortunately, this is one of those content-free doc pages. I
can see those preference pages well enough on my own. Doesn't help in
knowing what I am supposed to do with them.

So I go to SSH2 - Key Management - Generate RSA Key

Yay! So far so good. Apply, close dialog, re-open, key is gone, what the
f**k!

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
Sent: Tuesday, May 05, 2015 12:55 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very
frustrated



On 05/05/2015 03:50 PM, Konstantin Komissarchik wrote:
 Thanks, Carl. Regarding step 1, how do I generate and store the ssh 
 key so that Eclipse will use it when communicating with Gerrit? I am on
Windows.

This may help:
http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.user/reference/r
ef-ssh2-preferences.htm?cp=65_4_1_43




 - Konstantin

 *From:*cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of 
 *Carl Anderson
 *Sent:* Tuesday, May 05, 2015 12:47 PM
 *To:* Cross project issues
 *Subject:* Re: [cross-project-issues-dev] Unable to contribute to 
 Mars... very frustrated

 Konstantin,

 I just suffered through this, too.  This is a lot more painful than it 
 should be.  I managed to narrow it down to two steps to get my 
 previous setup working:

 1) Upload your public key to 
 https://git.eclipse.org/r/#/settings/ssh-keys

 2) Change your current remote.origin.pushurl to 
 ssh://committer-id@git.eclipse.org:29418/simrel/org.eclipse.simrel.b
 uild (Right click on your org.eclipse.simrel.build git repository, 
 select properties, find remote.origin.pushurl and edit the value.)

 Then it is back to using Git as normal.

 FWIW,

 - Carl Anderson
 WTP Build guy

 Inactive hide details for Konstantin Komissarchik ---05/05/2015
 03:29:20 PM---For years, I've had a working setup that 
 alloweKonstantin Komissarchik ---05/05/2015 03:29:20 PM---For years, 
 I've had a working setup that allowed me to update Sapphire's simrel 
 contribution. With c

 From: Konstantin Komissarchik konstantin.komissarc...@oracle.com
 mailto:konstantin.komissarc...@oracle.com
 To: 'Cross project issues' cross-project-issues-dev@eclipse.org
 mailto:cross-project-issues-dev@eclipse.org
 Date: 05/05/2015 03:29 PM
 Subject: [cross-project-issues-dev] Unable to contribute to Mars... 
 very frustrated Sent by: cross-project-issues-dev-boun...@eclipse.org
 mailto:cross-project-issues-dev-boun...@eclipse.org

 --
 --




 For years, I've had a working setup that allowed me to update 
 Sapphire's simrel contribution. With changes to use Gerrit, I am no 
 longer able to contribute. I've spent hours reading various wikis and 
 I still cannot figure out what keys I need to have and where I am 
 supposed to shove them. Maybe this stuff makes sense to someone 
 already versed in Gerrit and SSH, but it doesn't make sense to me.

 Frankly, this is a massive step in the wrong direction. Contributing 
 to simrel should be made easier, not more difficult.

 I have a couple more hours I can devote to this at the maximum. If I 
 can't figure out how to get back to a working configuration in that 
 time, I am taking Sapphire out of Mars.

 Thanks,

 - Konstantin___
 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 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] Unable to contribute to Mars... very frustrated

[Konstantin Komissarchik]

Yep. Just figured out that it went directly in. Oy!

 

So what should I have done if I wanted to exercise the new verifier feature?

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael
Istria
Sent: Tuesday, May 05, 2015 1:24 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very
frustrated

 

On 05/05/2015 10:21 PM, Konstantin Komissarchik wrote:

Thanks, Doug! The save private key button was the magic step that I was
missing.

 

Now I am able to fetch the repo and push my change, but I am not done yet,
am I? I need to go somewhere to monitor and approve it now?

Nope. it's in:
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=7182
77402528603ca8c2522b5c05180e3d64f215

I'll add a note in the paragraph
https://wiki.eclipse.org/index.php?title=Simrel/Contributing_to_Simrel_Aggre
gation_Build#As_a_SimRel_committer.2C_push_directly_to_the_target_branch to
make clear that this workflow doesn't trigger a Gerrit review.

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

Re: [cross-project-issues-dev] Unable to contribute to Mars... very frustrated

[Konstantin Komissarchik]

 If you have your keys generated with openssh, they are put in the regular
~/.ssh folder, which Eclipse and EGit will use. So just generating the keys
should be enough.

 

I am on Windows and don't have any SSH tools installed, as far as I know.

 

  Did you try to use HTTPS instead ?
https://wiki.eclipse.org/Gerrit#Git_over_HTTPS

 

 Yep. Tried this URL:


https://kkomissarc...@git.eclipse.org/r/p/simrel/org.eclipse.simrel.build.gi
t

 Getting not authorized when trying to push. 

 Ok, that's not a very helpful error message.
 Is this URL the same as the one you see in
https://git.eclipse.org/r/#/admin/projects/simrel/org.eclipse.simrel.build
when selecting HTTP ?  Gerrit had an issue with some users in the past,
creating different Gerrit users for the same account.

The referenced dashboard gave me the following URL, which also yields
unauthorized.

git clone
https://kkomissarc...@git.eclipse.org/r/simrel/org.eclipse.simrel.build

- Konstantin

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael
Istria
Sent: Tuesday, May 05, 2015 1:00 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very
frustrated

 

On 05/05/2015 09:48 PM, Konstantin Komissarchik wrote:

 Have you uploaded your SSH key to Gerrit ?
https://wiki.eclipse.org/Gerrit#SSH_Keys

 

It would require having such a key in the first place. I understand the
theory of it and I've seen tools to gen key pairs, but I don't know where I
am supposed to stash the private key, for instance so that it will hookup
with the public key on Gerrit.

If you have your keys generated with openssh, they are put in the regular
~/.ssh folder, which Eclipse and EGit will use. So just generating the keys
should be enough.




 Did you try to use HTTPS instead ?
https://wiki.eclipse.org/Gerrit#Git_over_HTTPS

 

Yep. Tried this URL:

https://kkomissarc...@git.eclipse.org/r/p/simrel/org.eclipse.simrel.build.gi
t

Getting not authorized when trying to push. 

Ok, that's not a very helpful error message.
Is this URL the same as the one you see in
https://git.eclipse.org/r/#/admin/projects/simrel/org.eclipse.simrel.build
when selecting HTTP ?  Gerrit had an issue with some users in the past,
creating different Gerrit users for the same account.

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

Re: [cross-project-issues-dev] Unable to contribute to Mars... very frustrated

[Konstantin Komissarchik]

Thanks, Doug! The save private key button was the magic step that I was
missing.

 

Now I am able to fetch the repo and push my change, but I am not done yet,
am I? I need to go somewhere to monitor and approve it now?

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug
Schaefer
Sent: Tuesday, May 05, 2015 1:08 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very
frustrated

 

Yeah, the key on Windows is to make sure the SSH2 home on the General tab
points to some where useful, like C:\Users\dschaefer\.ssh, and that you
click the Save Private Key button to save it there.

 

From: Mickael Istria mist...@redhat.com
Reply-To: Cross project issues cross-project-issues-dev@eclipse.org
Date: Tuesday, May 5, 2015 at 4:00 PM
To: cross-project-issues-dev@eclipse.org
cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unable to contribute to Mars... very
frustrated

 

On 05/05/2015 09:48 PM, Konstantin Komissarchik wrote:

 Have you uploaded your SSH key to Gerrit ?
https://wiki.eclipse.org/Gerrit#SSH_Keys

 

It would require having such a key in the first place. I understand the
theory of it and I've seen tools to gen key pairs, but I don't know where I
am supposed to stash the private key, for instance so that it will hookup
with the public key on Gerrit.

If you have your keys generated with openssh, they are put in the regular
~/.ssh folder, which Eclipse and EGit will use. So just generating the keys
should be enough.




 Did you try to use HTTPS instead ?
https://wiki.eclipse.org/Gerrit#Git_over_HTTPS

 

Yep. Tried this URL:

https://kkomissarc...@git.eclipse.org/r/p/simrel/org.eclipse.simrel.build.gi
t

Getting not authorized when trying to push.

Ok, that's not a very helpful error message.
Is this URL the same as the one you see in
https://git.eclipse.org/r/#/admin/projects/simrel/org.eclipse.simrel.build
when selecting HTTP ?  Gerrit had an issue with some users in the past,
creating different Gerrit users for the same account.

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

Re: [cross-project-issues-dev] Bug 456909 - Implementing Early Startup IStartup causes org.eclipse.core.runtime.CoreException

[Konstantin Komissarchik]

I appreciate Lars's response on the bug with a pointer to the change in
question along with the rationale.

 

I do want to state that communication regarding this was lacking. Evidence:

 

1.   WTP 3.7 M6 (Mars) milestone build is affected by this issue.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=459620

2.   A number of third party plugins are similarly affected.

 

Plugin developers rely on Eclipse Platform maintaining rock-solid backwards
compatibility. As such, instances where compatibility will be broken, should
be announced at the highest volume possible and with much repetition. In
this case, the particular extension point usage pattern was apparently
deprecated in Eclipse 4.2 before being removed in 4.5. It would have been
good to add a deprecation warning to the error log starting in 4.2 in order
to ensure that the affected plugin maintainers notice that they need to take
action while there is still plenty of time to plan for this. The final
removal should have also been announced on cross-project.

 

Thanks,

 

- Konstantin

 

From: Konstantin Komissarchik [mailto:konstantin.komissarc...@oracle.com] 
Sent: Friday, April 10, 2015 2:58 PM
To: 'Cross project issues'
Subject: Bug 456909 - Implementing Early Startup IStartup causes
org.eclipse.core.runtime.CoreException

 

Could someone from the platform team comment on this issue?

 

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

 

Plugins that have an IStartup extension and worked fine on 4.4 are causing
exceptions to be logged when used on 4.5 milestones. This appears to be an
API behavior regression. The bug was filed in January and the platform team
has yet to comment on it.

 

- 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] Bug 456909 - Implementing Early Startup IStartup causes org.eclipse.core.runtime.CoreException

[Konstantin Komissarchik]

Also. The major version component on the affected platform bundles should be
incremented. 

 

From: Konstantin Komissarchik [mailto:konstantin.komissarc...@oracle.com] 
Sent: Saturday, April 11, 2015 9:31 AM
To: 'Cross project issues'
Subject: RE: Bug 456909 - Implementing Early Startup IStartup causes
org.eclipse.core.runtime.CoreException

 

I appreciate Lars's response on the bug with a pointer to the change in
question along with the rationale.

 

I do want to state that communication regarding this was lacking. Evidence:

 

1.   WTP 3.7 M6 (Mars) milestone build is affected by this issue.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=459620

2.   A number of third party plugins are similarly affected.

 

Plugin developers rely on Eclipse Platform maintaining rock-solid backwards
compatibility. As such, instances where compatibility will be broken, should
be announced at the highest volume possible and with much repetition. In
this case, the particular extension point usage pattern was apparently
deprecated in Eclipse 4.2 before being removed in 4.5. It would have been
good to add a deprecation warning to the error log starting in 4.2 in order
to ensure that the affected plugin maintainers notice that they need to take
action while there is still plenty of time to plan for this. The final
removal should have also been announced on cross-project.

 

Thanks,

 

- Konstantin

 

From: Konstantin Komissarchik [mailto:konstantin.komissarc...@oracle.com] 
Sent: Friday, April 10, 2015 2:58 PM
To: 'Cross project issues'
Subject: Bug 456909 - Implementing Early Startup IStartup causes
org.eclipse.core.runtime.CoreException

 

Could someone from the platform team comment on this issue?

 

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

 

Plugins that have an IStartup extension and worked fine on 4.4 are causing
exceptions to be logged when used on 4.5 milestones. This appears to be an
API behavior regression. The bug was filed in January and the platform team
has yet to comment on it.

 

- Konstantin

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

[cross-project-issues-dev] Bug 456909 - Implementing Early Startup IStartup causes org.eclipse.core.runtime.CoreException

[Konstantin Komissarchik]

Could someone from the platform team comment on this issue?

 

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

 

Plugins that have an IStartup extension and worked fine on 4.4 are causing
exceptions to be logged when used on 4.5 milestones. This appears to be an
API behavior regression. The bug was filed in January and the platform team
has yet to comment on it.

 

- 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] Central Checksum service going away

[Konstantin Komissarchik]

-1

This service is used by automated build systems. It cannot be retired
without severe adverse consequence. 

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
Sent: Monday, March 09, 2015 11:02 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Central Checksum service going away

Folks,

Years ago I enabled a centralized checksum service and attached it to the
downloads/mirror page, as seen here:

http://eclip.se/3Q

The system is flawed in two ways:
- artifacts that change will have invalid checksums
- on occasion, a checksum is computed too early while a file is in transit,
leading to invalid sums

Since the value provided by a central service is likely very low, and I lack
the cycles to make something more robust, I'm deprecating the service.
Please see https://bugs.eclipse.org/460490

Once retired, sums.php will return an empty response.

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

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

Re: [cross-project-issues-dev] jdt.core move to Java 7 BREE

[Konstantin Komissarchik]

What is the rationale for wanting to keep BREE levels as low as possible?
Even Java 7 enters the no further public updates phase in April of this
year. JRE 7 users in the normal update pipeline were upgraded to Java 8 in
January. Are there really users out there who _cannot_ run a newer version
of the JRE despite security and performance implications of running an old
version? I am guessing that if Mars were to require Java 8, there would be
some initial grumbling over having to upgrade, then everyone moves on in a
better and more secure configuration.

 

http://www.oracle.com/technetwork/java/javase/downloads/eol-135779.html

 

Thanks,

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ed
Willink
Sent: Wednesday, March 04, 2015 6:57 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] jdt.core move to Java 7 BREE

 

Hi

But this is important.

When osgi.utils moved from Java 5 to Java 6 that made Eclipse almost
unuseable as a Java 5 platform; not really a problem.

Now jdt.core does nearly the same thing for Eclipse as a Java 6 platform.
Are we ready to go that far? IMHO it certainly should be discussed and
announced.

Regards

Ed Willink

On 04/03/2015 14:42, Daniel Megert wrote:

Hi Ed 

Yes, this was intended. We never announce BREE changes. 

Dani 



From:Ed Willink  mailto:e...@willink.me.uk e...@willink.me.uk 
To:Cross project issues
mailto:cross-project-issues-dev@eclipse.org
cross-project-issues-dev@eclipse.org 
Date:04.03.2015 15:27 
Subject:[cross-project-issues-dev] jdt.core move to Java 7 BREE 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




Hi

Is the recent change in BREE for org.eclipse.jdt.core from Java 6 to 
Java 7 intended?

Was it announced?

Regards

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






No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5751 / Virus Database: 4299/9224 - Release Date: 03/04/15

 

___
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] [Bug 332258] Need better way to specify @NoDuplicates for list properties

[Konstantin Komissarchik]

Also c) where to report issues with the error reporter

Note that in this case, the bug has no stack traces in it, so the error
reporter is glitching.

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
Sent: Tuesday, December 16, 2014 10:43 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] [Bug 332258] Need better way to
specify @NoDuplicates for list properties

Actually, Marcel can we

a) update the name of the account to something more descriptive, like
Recommenders Error Reports

b) Improve the signature.  In addition to Your friendly error reports bot.
perhaps add a link with information and a link on how to remove the
functionality from a bugzilla project?

Thanks!



On 12/16/2014 01:39 PM, Konstantin Komissarchik wrote:
 I am seeing some spurious Bugzilla edits recorded by the
error-reports-in...@eclipse.org account this morning. Could someone
associated with this account take a look?

 Thanks,

 - Konstantin


 -Original Message-
 From: bugzilla-dae...@eclipse.org [mailto:bugzilla-dae...@eclipse.org]
 Sent: Tuesday, December 16, 2014 10:03 AM
 To: konstantin.komissarc...@oracle.com
 Subject: [Bug 332258] Need better way to specify @NoDuplicates for 
 list properties

 https://bugs.eclipse.org/bugs/show_bug.cgi?id=332258
 Product/Component: Sapphire / modeling

 --- Comment #4 from Error Reports error-reports-in...@eclipse.org --- To
date this log entry was reported 25 times.

 Your friendly error reports bot.

 --
 You are receiving this mail because:
 You are on the CC list for the bug.
 You are the assignee for the bug.

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

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

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

[cross-project-issues-dev] Missing download artifacts for Equinox Mars M4

[Konstantin Komissarchik]

It looks like Equinox Mars M4 build is missing various artifacts that should
be in the build, such as the equinox-SDK-MarsM4.zip file.

 

This is blocking some projects from being able to move to M4 and contribute
to M4.

 

http://download.eclipse.org/equinox/drops/S-MarsM4-201412102000/index.php

 

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] Observation: Frequent UI freezes when working with files

[Konstantin Komissarchik]

We have something in Sapphire that would be applicable.

 

http://git.eclipse.org/c/sapphire/org.eclipse.sapphire.git/tree/plugins/org.eclipse.sapphire.ui/src/org/eclipse/sapphire/ui/DelayedTasksExecutor.java

 

In the text change listener, we schedule a task to update the model (an 
operation that can be expensive). The executor only runs the tasks once things 
have been quiet for a certain time (no new tasks). This allows us to provide 
“immediate” on-change feedback without making the UI appear sluggish to the 
user while they are entering data.

 

Thanks,

 

- Konstantin

 

 

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

 

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 file:///\\myserver\myshare\path\to\file.c 
) and you make the beginner’s mistake of just starting to type … trying to 
validate \\m file:///\\m  and then \\my file:///\\my  and then \\mys 
file:///\\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 lars.vo...@gmail.com 
To:Cross project issues 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 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 

Re: [cross-project-issues-dev] p2 and optional not too greedy dependencies

[Konstantin Komissarchik]

Keep in mind that even if you get the scenario where EGit is installed first
working as you desire, you will still have to contend with the case where
EGit is installed after your plugins. 

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Carsten
Reckord
Sent: Tuesday, November 25, 2014 6:36 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] p2 and optional not too greedy
dependencies

On 25.11.2014 14:33, Laurent Goubet wrote:
 If I were to make that dependency optional, I'd need to make the 
 adapter factory completely independent from egit (there mustn't be any
 org.eclipse.egit.* imports in that class, lest I deal with 
 LinkageErrors of some sort (IIRC, this case is a 
 NoClassDefFoundError)). I would thus need to create a proxy which 
 sole responsibility would be to check for the presence of EGit in its 
 classpath and either delegate to the actual adapter factory or return 
 null (which in itself is also a weird behavior
 : I tell the platform that I can adapt SomeClass into SomeOther, 
 yet I still return it a null).

I would do it a bit differently. I'd keep the adapter class as-is and
determine statically, e.g. at bundle startup, if it can be used. Then I
would either register the adapter to the appropriate registries or not,
based on that outcome.

Or, if it's done via extension point, maybe the point supports enablement
criteria using org.eclipse.core.expressions. If that's the case, putting the
enablement logic into a property tester should be easy enough.

 So yes, that would be a workaround... but I'd really rather be able to 
 properly tell that my plugin _does_ depend on EGit, and tell p2 that 
 it is an important dependency of another of my plugins that should 
 be installed if all of its own requirements are met.

Agreed, that would be a nicer solution.

___
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] Equinox fix for Luna SR1 now available as a feature patch in 4.4 repository.

[Konstantin Komissarchik]

I don't think political is quite the right term, but I do believe that the
primary issues blocking more frequent or continuous releases are not
technical in nature. After all, other OSS communities that are equally large
to ours or even larger seem to manage more than three releases a year. There
are well-known techniques for addressing different levels of risk desired by
various members of the community, such as multiple streams, yet we are not
even experimenting with these.

 

I think that part of the problem is that the responsibility for defining
simrel is assigned to the Planning Council, so when an idea sprouts in the
broader community, the discussion inevitably ends with talk to your PC
representative. There, unless I am mistaken, the council operates on
consensus as opposed to majority rule, so it's easy for some corporate
interests to torpedo any changes. A related issue is that unlike a project,
where any party that contributes sufficiently can gain a full voice by
getting elected as a committer, the council membership is closed and is not
based on meritocracy. Perhaps the Planning Council  should be disbanded and
a simrel project created in its place (epp can be a sub-project).

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M
Williams
Sent: Monday, November 03, 2014 10:18 PM
To: mike.milinkov...@eclipse.org; Cross project issues
Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now
available as a feature patch in 4.4 repository.

 

Not sure what political means in this case -- just an eye-catching phrase?
-- but there are a few reasons things are done as they are ... that have
been explained so many times before ... that once more wouldn't hurt -- at
least since Mike asked. :) 

Resources and Risks: This is a patch (i.e. automatically some amount of
risk). And, not everyone needs the patch. But to make it automatically apply
to everyone's install makes everyone receive the risk. To do such a thing
requires more work up-front to prepare patches of all root features that
would be involved. And, to do it safely, would require a more testing (from
all projects) to make sure no accidental negative side effects. And, in
addition, would require more testing from all interested adopters to make
sure no accidental side effects for them. In cases like that, we usually
recommend to give a months notice. So ... by then ... we'd be almost ready
to wind down for SR2! (slight exaggeration, but the point is, it seemed
that the cases where this was blocking others, they'd prefer to have it
sooner, rather than later). Plus, I got the impression, a fair number of
projects who needed it were adopters creating products for their users, so
they can include it, if they'd like, in their eclipse product.  If not
obvious to the causal reader, this was a fix in a low level package,
org.eclipse.osgi, where risk aversion skews the cost/benefit ratio curve. 

Limits of Feature Patches: This one isn't that applicable, I do not normally
mention it in this context, but do now only due to Thomas' remark that he'd
like to see p2 leveraged (the way it was designed to)  The issue is,
the only thing p2 was designed to do was to apply feature patches. There are
many products/projects that do not use features, hence, they can not apply a
feature patch. They must come out with a new release or direct users how
to install the fix by using p2 Director. I mention this since all that extra
up front work, does not help those projects/products. And, besides that,
there are
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEWbug_status=ASSIGNE
Dbug_status=REOPENEDclassification=RTcomponent=p2list_id=10400194order=
bug_severity%2Cchangeddate%20DESC%2Cassigned_to%20DESC%2Ctarget_milestone%2C
priority%2Cpriority%2Cstatus_whiteboard%2Ctarget_milestone%2Ctarget_mileston
e%2Ccomponent%2Cvotes%20DESC%2Cbug_idproduct=Equinoxquery_based_on=query_
format=advancedshort_desc=feature%20patchshort_desc_type=allwordssubstr a
number of serious issues with feature patches, from what I can tell, which
increases risk of using wide spread feature patches. Feel free to correct
me, Thomas, if you, or another p2 committer, has fixed this limitation,
since the last time it was discussed, 3 or 4 years ago? Or, if the bug list,
is not valid? Or if I have misunderstood your remark? If you simply meant
had the ability to do continuous releases I guess I do not normally see
that as a p2 feature, but would mean this paragraph isn't relevant at all.
(In at case, see previous paragraph for continuous release issues :). 

I was quiet at first, and will (try to) remain quiet after this note --
which, doesn't mean I don't care, I just don't have time or patience to have
a long discussion on a mailing list of subtle nuances of pros and cons -- I
am definitely aware there are pros in addition to the cons I've mentioned!
--which have already been 

Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in 4.4 repository.

[Konstantin Komissarchik]

+1 to every point made here

 

The other issue that we need to recognize is that when simrel process was 
originally defined, all participating projects released on simrel schedule. 
Now, many (if not most) participating projects release more frequently. The end 
result is that the most prominent deliverables from eclipse.org are stale even 
before they are released and users have to hunt for updates to components 
outside of the well-known simrel repositories.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas 
Hallgren
Sent: Monday, November 03, 2014 11:37 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available 
as a feature patch in 4.4 repository.

 

Hi David,

 

I think it's fairly evident that the testing that was made prior to SR1 was 
insufficient and I can understand why. Projects have limited resources nowadays 
and unfortunately rigorous testing is one of the first things that gets a 
cutback. With lowered quality as a natural consequence. The way I see it, that 
problem can be attacked in one of two ways:

 

1. See to that the service releases really get tested rigorously which means 
that organizations must put up the resources needed to do so. The release train 
must be subject to integration testing.

 

2. Let the Eclipse users take the hit (like we already do now) and make sure 
that any problems that are discovered are remedied more or less immediately 
(i.e. push a new build of the release train or platform without delay). In 
essence, this would remove the need for service releases.

 

What we have now is the worst case of all. Virtually no integration testing and 
when bugs are found, no immediate new release.

 

I wasn't referring to feature patches with my remark about p2 (I'm not much 
fond of them either). I was referring to p2's ability to deliver updates in a 
safe and controlled manner.

 

- thomas

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

Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in 4.4 repository.

[Konstantin Komissarchik]

This is related to the discussion about a year or so ago about having more
frequent or even continuous updates to the composite repo. That didn't go
anywhere, unfortunately. 

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas
Hallgren
Sent: Sunday, November 02, 2014 5:02 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now
available as a feature patch in 4.4 repository.

+1

I would really like to see p2 leveraged (the way it was designed to) to make
it really easy to push fixes like this out to the community in a controlled
but swift manner.

- thomas

On 2014-11-02 11:07, Max Rydahl Andersen wrote:
 On 31 Oct 2014, at 19:56, David M Williams wrote:

 I am not sure if this bug was discussed directly on this list, or, 
 just some of its predecessors, but, we have an official fix 
 available for anyone impacted by

 Really appreciate the work for fixing this nasty subtle bug.

 But can we have a chat about why the Eclipse release train does not 
 seem to have a *good* way to release updates for this ?

 By Good I mean one that just gets available via Check For Updates 
 rather that one that does not require users to aware of having to install
a specific feature patch ?

 I think Eclipse survived this far because we haven't really had any 
 big all impacting stop ship bugs, but lately they are starting to crop
up - this issue with System properties being the worst one (that I know of).

 Can someone remind me why we can't in these cases do an update that 
 fixes this bug ? Is it technical because the release train is to 
 hardly coupled and we have feature's using exact versions and that p2
won't let you update the plugins on their own ?

 ...or is there also some political agenda on how we provide these updates
?

 In any case - I think it would be worth finding a way to update these 
 technical and political limitations to make it easier to do timely
stop-ship bug updates?

 wdyt ?

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

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

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

[cross-project-issues-dev] Features versions not incremented for Luna SR1 platform, jdt, pde, etc.

[Konstantin Komissarchik]

Hate to bring more bad news as this release already had more than its share,
but. it appears that version numbers in platform features have not been
correctly incremented for Luna SR1.

 

Luna: org.eclipse.platform_4.4.0.v20140606-1558.jar

Luna SR1 RC4: org.eclipse.platform_4.4.0.v20140911-0143.jar

Luna SR1 RC4a: org.eclipse.platform_4.4.0.v20140925-0400.jar

 

Same problem in JDT, PDE and other features part of the Eclipse project
build.

 

The update from Luna GA does seem to work regardless, so impact is in about
box confusion and  on adopters hoping to be able to reference Luna SR1 as
platform 4.4.1.

 

- 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] Orbit built for Luna SR1

[Konstantin Komissarchik]

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

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M
Williams
Sent: Tuesday, September 23, 2014 12:01 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Orbit built for Luna SR1

 

If I understand you correctly, it'd be a great usability improvement to the
page, and make a fine enhancement request, and perhaps someone would
implement it someday, or provide a contribution. 

But, for the most part, they can be inferred by their dates, and the
https://wiki.eclipse.org/Simultaneous_Release dates of the releases and
services releases. 

I say for the most part, since occasionally we have had off cycle
R-builds, at the request of a project that was doing an off-cycle release,
but I don't think we have add too many of those, surprisingly.   

I put together the following table, based on my glancing at the two sets of
dates. 

R20140525021250Luna, Luna SR1 
R20140114142710Kepler SR2 
R20130827064939Kepler SR1 
R20130517111416Kepler 
R20130118183705Juno SR2 
R20120526062928Juno, Juno SR1 

I will mention another deviation, though, and that is the R-builds, in
the big picture of things, have more to do with retention, than a particular
release. For example, I've known some, say, doing long term support of
Juno that used something from a Kepler R-build, to achieve what they
needed to. 

Put another way, while we all want to be current and in sync for the
current release, that's pretty easy, since it is always the most recent
R-build (or, most recent S-build, for milestones). 

Hope that helps, and would encourage suggestions/requests to be added to
bugzilla. 






From:Konstantin Komissarchik konstantin.komissarc...@oracle.com 
To:'Cross project issues' cross-project-issues-dev@eclipse.org, 
Date:09/23/2014 12:33 AM 
Subject:Re: [cross-project-issues-dev] Orbit built for Luna SR1 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




Thanks for the clarification. 
  
Would it be possible to list the simrel release name in the table of Orbit
downloads? 
  
 http://download.eclipse.org/tools/orbit/downloads/
http://download.eclipse.org/tools/orbit/downloads/ 
  
Thanks, 
  
- 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] On Behalf Of David M
Williams
Sent: Monday, September 22, 2014 3:17 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Orbit built for Luna SR1 
  
No, that's for Mars M2. There is not a lot of difference, but the latest
R-build is the correct one for Luna SR1: R20140525021250
http://download.eclipse.org/tools/orbit/downloads/drops/R20140525021250/
. 




From:Konstantin Komissarchik 
mailto:konstantin.komissarc...@oracle.com
konstantin.komissarc...@oracle.com 
To:'Cross project issues' 
mailto:cross-project-issues-dev@eclipse.org
cross-project-issues-dev@eclipse.org, 
Date:09/22/2014 05:30 PM 
Subject:[cross-project-issues-dev] Orbit built for Luna SR1 
Sent by: mailto:cross-project-issues-dev-boun...@eclipse.org
cross-project-issues-dev-boun...@eclipse.org 

  _  





Could someone confirm that the following Orbit build is the correct one for
Luna SR1? 
 
 http://download.eclipse.org/tools/orbit/downloads/drops/S20140917154621/
http://download.eclipse.org/tools/orbit/downloads/drops/S20140917154621/ 
 
Thanks, 
 
- Konstantin___
cross-project-issues-dev mailing list
 mailto:cross-project-issues-dev@eclipse.org
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
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] Orbit built for Luna SR1

[Konstantin Komissarchik]

Could someone confirm that the following Orbit build is the correct one for
Luna SR1?

 

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

 

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] Orbit built for Luna SR1

[Konstantin Komissarchik]

Thanks for the clarification.

 

Would it be possible to list the simrel release name in the table of Orbit
downloads?

 

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

 

Thanks,

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M
Williams
Sent: Monday, September 22, 2014 3:17 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Orbit built for Luna SR1

 

No, that's for Mars M2. There is not a lot of difference, but the latest
R-build is the correct one for Luna SR1: R20140525021250
http://download.eclipse.org/tools/orbit/downloads/drops/R20140525021250/
. 




From:Konstantin Komissarchik konstantin.komissarc...@oracle.com 
To:'Cross project issues' cross-project-issues-dev@eclipse.org, 
Date:09/22/2014 05:30 PM 
Subject:[cross-project-issues-dev] Orbit built for Luna SR1 
Sent by:cross-project-issues-dev-boun...@eclipse.org 

  _  




Could someone confirm that the following Orbit build is the correct one for
Luna SR1? 
  
 http://download.eclipse.org/tools/orbit/downloads/drops/S20140917154621/
http://download.eclipse.org/tools/orbit/downloads/drops/S20140917154621/ 
  
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
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 

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

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

[Konstantin Komissarchik]

Here is how we are calling into PDE Build. I don’t see any references to 
osgi.framework.useSystemProperties.

 

  java classname=org.eclipse.core.launcher.Main

fork=true failonerror=true maxmemory=${java.maxmemory}

classpath

  fileset dir=${bootstrap.platform}/plugins

include name=**/org.eclipse.equinox.launcher_*.jar/

  /fileset

/classpath

arg line=-clean/

arg line=-application org.eclipse.ant.core.antRunner/

arg line=-data ${build.dir}/pde/workspace/

arg line=-configuration ${build.dir}/pde/configuration/

arg line=-buildfile ${.pdeBuildDir}/scripts/build.xml/

arg value=-DtopLevelElementId=@{feature.id}/

arg value=-DarchivePrefix=eclipse/

arg value=-DbaseLocation=@{eclipse.install.dir}/

arg value=-DbuildDirectory=@{root.dir}/

arg value=-Dbuilder=${build.dir}/pde/builder/

arg value=-DcollectingFolder=collecting/

arg value=-DbuildId=@{build.id}/

arg value=-DbuildType=I/

arg value=-DbuildLabel=build/

arg value=-DROOT_RELENG_DIR=@{root.releng.dir}/

arg value=-DforceContextQualifier=@{build.id}/

arg value=-DgenerateFeatureVersionSuffix=false/

arg value=-DindividualSourceBundles=true/

arg value=-DallowBinaryCycles=true /

arg value=-DcompilerArg=${pde.build.compiler.arg}/

arg value=-DJ2SE-1.4=${java.14.system.classpath}/

arg value=-DJavaSE-1.6=${java.16.system.classpath}/

arg value=-DJavaSE-1.7=${java.17.system.classpath}/

java-args/

  /java

 

I will work on a stand-alone repro today.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
Sent: Tuesday, September 09, 2014 6:41 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Apparent Luna SR1 regression in build 
failure reporting

 

Konstantin 

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

Tom





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

  _  




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

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

Tom





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

  _  




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

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

[Konstantin Komissarchik]

I opened a separate bug, in case this is a different issue.  Assigned to 
Equinox for now. Simple repro attached.

 

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

 

Thanks,

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
Sent: Tuesday, September 09, 2014 7:23 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Apparent Luna SR1 regression in build 
failure reporting

 

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

Tom





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

  _  




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

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

Tom





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

  _  





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

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

Tom





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

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

[Konstantin Komissarchik]

We are seeing a serious regression in Luna SR1 (tested with platform RC3)
where PDE build does not report a process failure code when the build fails.
This causes any invoking build process (such as Ant) to not detect a failure
and continue.

 

Just confirmed that this works correctly if Luna is used to drive the build
instead of Luna SR1.

 

I am not sure if the regression is in the launcher or in the PDE build. 

 

Is anyone else seeing this?

 

Thanks,

 

- Konstantin

 

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

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

[Konstantin Komissarchik]

To add one more bit of info that might help.

 

When driving the build with Luna, I see An error has occurred. See the log
file in the console output. When driving the build with Luna SR1, this
message is missing.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of
Konstantin Komissarchik
Sent: Monday, September 08, 2014 10:01 AM
To: 'Cross project issues'
Subject: [cross-project-issues-dev] Apparent Luna SR1 regression in build
failure reporting

 

We are seeing a serious regression in Luna SR1 (tested with platform RC3)
where PDE build does not report a process failure code when the build fails.
This causes any invoking build process (such as Ant) to not detect a failure
and continue.

 

Just confirmed that this works correctly if Luna is used to drive the build
instead of Luna SR1.

 

I am not sure if the regression is in the launcher or in the PDE build. 

 

Is anyone else seeing this?

 

Thanks,

 

- Konstantin

 

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

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

[Konstantin Komissarchik]

Anyone? We are down to the wire here and it's looking like Luna SR1 will be
useless as a build driver unless there is a last-minute fix, since we can't
depend on it failing the build correctly.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of
Konstantin Komissarchik
Sent: Monday, September 08, 2014 10:01 AM
To: 'Cross project issues'
Subject: [cross-project-issues-dev] Apparent Luna SR1 regression in build
failure reporting

 

We are seeing a serious regression in Luna SR1 (tested with platform RC3)
where PDE build does not report a process failure code when the build fails.
This causes any invoking build process (such as Ant) to not detect a failure
and continue.

 

Just confirmed that this works correctly if Luna is used to drive the build
instead of Luna SR1.

 

I am not sure if the regression is in the launcher or in the PDE build. 

 

Is anyone else seeing this?

 

Thanks,

 

- Konstantin

 

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

[cross-project-issues-dev] Cannot launch p2 director with Luna SR1 RC2 build

[Konstantin Komissarchik]

I picked up the Luna SR1 RC2 build this morning and I am seeing the
following failure in Equinox when p2 director is called. The Eclipse IDE
starts up without any apparent issues on the same install. This issue wasn't
there in RC1 and I am seeing this on two different build systems, so I am
reasonably sure that this is not an issue on my end. 

 

 [java] An error has occurred. See the log
filejava.lang.NullPointerException

 [java] 

 [java] null.

 [java]  at
org.eclipse.osgi.internal.framework.EquinoxConfiguration.init(EquinoxConfi
guration.java:207)

 [java]  at
org.eclipse.osgi.internal.framework.EquinoxContainer.init(EquinoxContainer
.java:69)

 [java]  at org.eclipse.osgi.launch.Equinox.init(Equinox.java:31)

 [java]  at
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:
299)

 [java]  at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)

 [java]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)

 [java]  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62
)

 [java]  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:43)

 [java]  at java.lang.reflect.Method.invoke(Method.java:483)

 [java]  at
org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)

 [java]  at
org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)

 [java]  at org.eclipse.equinox.launcher.Main.run(Main.java:1465)

 [java]  at org.eclipse.equinox.launcher.Main.main(Main.java:1438)

 [java]  at org.eclipse.core.launcher.Main.main(Main.java:34)

 

Here is the launching instructions.

 

java classname=org.eclipse.core.launcher.Main fork=true
failonerror=true

  classpath

fileset dir=${bootstrap.platform}/plugins

  include name=**/org.eclipse.equinox.launcher_*.jar/

/fileset

  /classpath

  arg line=-application org.eclipse.equinox.p2.director/

  arg line=-metadataRepository ${.repositories}/

  arg line=-artifactRepository ${.repositories}/

  arg line=-destination @{dest}/

  arg line=-installIU @{extensions}/

  arg line=-vmargs/

  arg line=-Declipse.p2.data.area=@{dest}/p2/

  arg line=-Declipse.p2.unsignedPolicy=allow/

  jvmarg line=-Xmx512m/

/java

___
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] Cannot launch p2 director with Luna SR1 RC2 build

[Konstantin Komissarchik]

Thanks for the pointer, Stephan!

Any chance of an RC2a from platform/equinox to address this or should
projects roll back to RC1 platform until RC3?

Thanks,

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Stephan
Herrmann
Sent: Tuesday, September 02, 2014 9:29 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Cannot launch p2 director with Luna
SR1 RC2 build

On 09/02/2014 06:26 PM, Stephan Herrmann wrote:
 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=441377#c3

 I true blocker ...

In plain words: due to this bug Object Teams will not be able to contribute
to SR1 RC2.

Stephan


___
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] Sapphire participating in Mars release

[Konstantin Komissarchik]

Sapphire will be participating in the Mars simultaneous release, with offset
of +3.

 

Current plan is to provide release 9 for Mars.

 

https://projects.eclipse.org/projects/technology.sapphire/releases/9.0

 

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] Forum login not possible

[Konstantin Komissarchik]

Could you share the bug number? I was seeing the same issue with Chrome.
Clearing cookies helped.

 

Thanks,

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Denis Roy
Sent: Tuesday, August 12, 2014 6:25 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Forum login not possible

 

I think there's a cookie collision with the Forums.  We have a bug open for
it, we'll look into it.



On 08/12/2014 07:27 AM, Wim Jongman wrote:

Thanks for the hints guys. I am on chrome. Clearing the cookies helped. 

 

Cheers,

 

Wim

 

On Tue, Aug 12, 2014 at 11:57 AM, Mikaël Barbero mikael.barb...@gmail.com
wrote:

It happens to me from time to time. I have to remove every cookies of the
eclipse.org domain.

 

HTH.

 

Regards,

Mikaël

 

On 12 août 2014 at 11:56:02, Tom Schindl (tom.schi...@bestsolution.at)
wrote:

Hi had the same problems when using Firefox, with Chrome it worked for me. 

Tom 

On 12.08.14 11:46, Wim Jongman wrote: 
 Hi, 
 
 I cannot login to the forum already for some time. 
 
 When I click on a discussion that I receive by mail it takes me to that 
 discussion but when I press login from that page, it takes me to a login 
 screen and the returns me in the main page of the forum. 
 
 In addition, I am not logged in. Clicking again on Login just does 
 something in the background without any visual clues. 
 
 Cheers, 
 
 Wim 
 

 

___
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] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package

[Konstantin Komissarchik]

I have not seen any actual enforcement of the m4 rule in past simrel.
Largely, that's because it doesn't make much sense for projects that release
more frequently than once a year. Say the project has a release 5.2
scheduled to wrap up during m4 time frame. The next release is of unknown
length at that time (depends on actual community participation). The project
can then either (a) contribute 5.2 to Mars or (b) gamble that by the time
Mars GA rolls around, they will be on some version like 5.4 even if there is
not even a branch or a plan for that release yet. If the project opts for
option (a), we can very well end up in a situation that what ships with the
shiny new Mars release is two to three releases out of date. If the project
opts for option (b) they may end up in a situation where they have to issue
filler releases just to catch up with the declaration or miss the
declaration and contribute an earlier version.

 

Simrel process should not require projects to declare a particular release
version. Rather, the process should focus on the type of changes being
contributed at a particular date. For instance, you cannot contribute
breaking changes after mX is better than you cannot switch contribution
version after mX.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne
Beaton
Sent: Wednesday, July 30, 2014 12:14 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Wish to contribute SWTBot to Luna
aggregator, and to PDE EPP package

 

The primary intent behind a plan is to give potential contributors some
sense of how they can contribute.

I have no trouble putting you down for 2.2.1 for now with an expectation
that--should you receive contributions that warrant the creation of a new
release--you'll create a new release record (say 2.3.0) at a later date.

The actual name of your release and whether or not you create a new release
record is not nearly as important as making sure that you get proper
practice participating in the release and that your bits don't break the
aggregation. So declaring a new release before M4 isn't as important to me
as making sure that you know what bits you'll actually be contributing early
enough in the cycle to do adequate testing.

I hope that this makes sense.

Wayne

On 07/30/2014 01:04 PM, Mickael Istria wrote:

On 07/30/2014 06:47 PM, Wayne Beaton wrote:

Can I assume that you mean Mars? ;-)

Sure, you can assume that ;)




I've started assembling the list of projects/releases that will join Mars
[0]. I'll put you down for 2.2.1 for now

Thanks.




if you do decide to include a different release with Mars, then let us know
on this list (before the M4 deadline) and I'll update the record.
More generally... participating projects should create a record (if one does
not already exist) for the release that they intend to contribute in the PMI
and then inform the community via this list.
Remember that project plans need to be specified by M4. A minimal plan that
includes a description [1] of the release and a list of issues [2] (which we
can generate automatically) shouldn't be too onerous, I hope. It would be
good if you can capture a theme or two for your plan.

SWTBot doesn't really have a plan. People come and contribute what they
want, and we release when we feel it's worth it. So I'm already thinking
about how to hack this contribution process without planning a release. M4
is in December. Between December and June, there can be something like 3 or
4 releases (or 0) that cannot be planned before M4.
In the case of SWTBot, we're not much interested about the Simultaneous
Release planning, which for a small project such as SWTBot could prevent
from frequent releases if necessary. What interest us is more to be included
in Mars site and EPP package and making sure we work well with other
projects of this same Mars site.

Can the Release Train (or in that case the aggregator only) process handle
the possibility of an unexpected release after M4 ?

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

 

-- 
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
http://www.eclipse.org 
Learn about Eclipse Projects http://www.eclipse.org/projects 
 https://www.eclipsecon.org/europe2014 EclipseCon
Europe 2014

___
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