Re: [cross-project-issues-dev] weird MPC versions causing grief

[Carsten Reckord]

> When you say "The update mechanism of MPC adds the update site of the
> newest compatible version" I wonder how exactly that happens?   I ask
> because what you describe below is exactly what would happen if the
> content metadata for http://download.eclipse.org/mpc/releases/1.7.7 is
> loaded and used during resolution, but the corresponding artifact metadata
> is not loaded and not used during the installation phase.  I know that p2
> records these things (repositories) as two separate preferences even though
> you don't see it that way in the UI; you have to dig deep to find that
> information...

Yes, this is exactly what is happening. See my other reply. I'll have a fix in 
a moment - just wondering now if we should retroactively try to fix the old 
breakage as well and add missing artifact repos to the list.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] weird MPC versions causing grief

[Carsten Reckord]

> I noticed that for the update check we only ever load the metadata
> repository [...] we now have an update site list with just a metadata repo 
> and no
> corresponding artifact repo, which would completely explain the observed
> errors.

Now I'm wondering if we should attempt to fix the update site list 
retroactively, i.e. scan for all metadata repos in the list that don't have a 
corresponding artifact repo, and add it. Theoretically, there could be cases 
where there is no 1:1 mapping between the two, but I think the common case is 
that both should exist.

Opinions?

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

Re: [cross-project-issues-dev] weird MPC versions causing grief

[Carsten Reckord]

Oh, dang! I think I found the issue...

Looking at the code for this:
> One thing that I think should be fixed regardless of the current grief is 
> that in
> the process of checking for updates, MPC potentially adds new repos to the
> list and doesn't clean them up again (as so aptly expressed in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=560062#c12). I'll open a new
> bug for this.

I noticed that for the update check we only ever load the metadata repository - 
and then leave it lying around  (and it's been like that since the dawn of 
time, or MPC 1.0 in Helios to be precise). 

That isn't harmful as long as the repo was already in the list of available 
update sites, which is the case most of the time. 

But if it wasn't (my previous example with version-specific sites, and also 
frequently the case with MPC itself, since it came from simrel and not its own 
repo), then we now have an update site list with just a metadata repo and no 
corresponding artifact repo, which would completely explain the observed errors.

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

Re: [cross-project-issues-dev] weird MPC versions causing grief

[Carsten Reckord]

Hey all,

thanks, Leif, for the reproducible steps. I did bang my head against this last 
week for a bit but couldn't reproduce the problem. Some comments below:

> I had a closer look at the issue. I found, that for the 2019-12 release the
> version of MPC that was promoted for Release and Simrel Composite was
> newer than the one in the epp-mpc.aggrcon file. That might have caused the
> problem to occur even more often. I double checked that this will be correct
> for the 2020-03 release.

We should make sure that in addition to the promoted MPC version we also keep 
the version around in the MPC release repos that ended up in the release train. 
I'll dig up that repo and promote it as well.

> session context was:(profile=epp.package.jee,
> phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
> action=).
> 
> No repository found containing: osgi.bundle,com.sun.jna,4.5.1.v20190425-
> 1842
> 
> No repository found containing:
> osgi.bundle,com.sun.jna.platform,4.5.1.v20190425-1842
> [snip]
>
> Being easy reproduceable, I doubt that this is some kind of caching problem
> here. As Ed mentioned, it does not look like a MPC problem either. 

The strange part here is:
1. The repos involved (SimRel 2019-03 and MPC 1.7.7) have both been around for 
a rather long time, so I doubt that anyone would have caching issues here 
anymore.
2. All the unresolveable artifacts come from the MPC 1.7.7 repo exclusively, 
i.e. they do exist there, but don't exist in the older simrel repo (at least 
not in that version).

To me this looks like P2 included the MPC 1.7.7 metadata repo in its planning 
stage, but then somehow ignored the MPC artifact repo completely during 
download. 

I've had a couple of similarly suspicious-looking update issues with unrelated 
installations in the past, but was never really able to reproduce them. Maybe 
this is the chance to get to the bottom of that.

> Of
> course, we could deactivate the update mechanism of MPC for RC2, which
> might reduce the number of problems, but does not solve the root problem
> and of course makes MPC updates harder for all our users that do not have
> this problem. Any opinions?

A few words about the MPC update mechanism:

First of all, while we're only talking about MPC updating itself here, that 
updater is not specifically for updating MPC. MPC is just eating its own 
dogfood here in the sense that it checks all installed Marketplace solutions 
that it knows about for updates, and if it finds any, it shows an update 
prompt. Depending on the updates found, this prompt takes the form of a general 
update prompt ("Some of your installed plug-ins have updates available."), or 
one specifically about MPC ("A new version of the Marketplace Client is 
available. ").

This update check differs a bit from what Check for Updates does in that it 
doesn't consult the repository list, but the Marketplace catalog. This means 
that for example a plug-in A might have previously had a version 1.2 published 
on the Marketplace with an update url of 
http://example.org/updates/releases/1.2, and now has updated its listing with 
the new 1.3 release and an update url of 
http://example.org/updates/releases/1.3. This would not be caught by Check for 
Updates, since the repo list would only contain the old unchanged site.

The general functionality of this update check has been around for a pretty 
long time now. What has changed a couple of releases ago (with Photon IIRC) is 
that a) we proactively trigger this update check (previously it only happened 
when you opened the "Installed Software" tab in MPC, or came across a listing 
in the search view which you already had installed) and b) we show that banner 
to make available updates more visible.

One thing that I think should be fixed regardless of the current grief is that 
in the process of checking for updates, MPC potentially adds new repos to the 
list and doesn't clean them up again (as so aptly expressed in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=560062#c12). I'll open a new bug 
for this.

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

Re: [cross-project-issues-dev] MPC 1.7.7 for 2019-06

[Carsten Reckord]

Many thanks to Mickael Istria for merging MPC's RC1 contribution in my absence. 
In the meantime, Leif was also added as a Simrel committer, so he can stand in 
for me in cases like this in the future.

Regards,

Carsten

From: cross-project-issues-dev-boun...@eclipse.org 
 On Behalf Of Leif Geiger
Sent: Wednesday, June 5, 2019 6:01 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] MPC 1.7.7 for 2019-06

Hi all,

I would like to integrate the latest MPC bugfixes (MPC version 1.7.7) into the 
2019-06 release. The corresponding epp-mpc.aggrcon was not yet merged into 
simrel.build (https://git.eclipse.org/r/#/c/143005/) and Carsten is not 
available today to do it. Could one of you do the merge for the MPC team?

Btw, what is needed to receive commit rights for simrel.build? Is it possible 
for me as MPC commiter or is it only possible for project leads?

Regards,

Leif Geiger
Product Manager & Software Engineer

--
+49 (0)69 2475666-22 | leif.gei...@yatta.de | 
www.yatta.de

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

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

Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform

[Carsten Reckord]

Hi all,


I think both issues (pool size and using the old options) should be easily 
fixable. In fact, I would have expected using the old options to have worked, 
since we did just that with our original code before bringing it into shape for 
the eclipse.org contribution - I'll check up on that.


I'm on the road today, but I have a free day tomorrow to look into it.

Carsten

--
+49 (0)69 2475666-33 | 
reck...@yatta.de | 
www.yatta.de

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Scott Lewis 

Sent: Tuesday, May 28, 2019 4:20:57 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Downstream Projects of platform to take 
note - ECF Upgrade in platform


Filetransfer providers may be disabled at start time via a system property [1].

[1] https://wiki.eclipse.org/Disabling_Apache_Httpclient45


On 5/28/2019 12:54 AM, Daniel Megert wrote:
But wouldn't that mean that (affected) clients have to change their code?

Dani



From:Scott Lewis 
To:Daniel Megert 
, Cross project 
issues 

Date:27.05.2019 23:13
Subject:[EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects 
of platform to take note - ECF Upgrade in platform
Sent by:
cross-project-issues-dev-boun...@eclipse.org




On 5/27/2019 6:52 AM, Daniel Megert wrote:
Hi Scott

I assume that shipping the older httpClient version in addition, would not 
resolve those issues and that it is something that would have to be 
changed/fixed in ECF. Correct?
I believe that the older provider (httpclient4) would resolve these issues as 
this provider has configurable timeouts...for connect and others.
It would also be helpful to enlist the support of the httpclient45 provider 
author (Carsten) via  [1] specifically around connect timeouts.   Perhaps 
something can be changed in the new provider to handle the timeouts more like 
the older provider.
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=57


Dani



From:Ed Merks 
To:
cross-project-issues-dev@eclipse.org
Date:27.05.2019 15:19
Subject:[EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects 
of platform to take note - ECF Upgrade in platform
Sent by:
cross-project-issues-dev-boun...@eclipse.org




FYI, I've run into a number of problems with the latest ECF/httpclient code.  
Mostly my own fault for how I've hacked ECF to be able to collect and submit 
cookies (so I deserve to suffer). :-P
But also other problems.  For example, the older timeout properties not being 
respected in the newer implementation, i.e., the properties from 
org.eclipse.ecf.filetransfer.IRetrieveFileTransferOptions for timeouts are not 
applied when using the new implementation where the default timeout is 120 
seconds, so that can have a bad impact if your application runs into timeouts 
and has tried to limit the overall time impact using these options.
But worse, the setup archiver application has basically stopped functioning 
with timeouts such as the following:
FAILED to load 
http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup
 ERROR: org.eclipse.oomph.util.IOExceptionWithCause: Timeout waiting for 
connection from pool: 
http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup0
 0 0

After much investigating I fear that the Apache pool implementation is perhaps 
buggy (or perhaps how ECF uses it).
ECF itself increases the pool's limit in 
org.eclipse.ecf.internal.provider.filetransfer.httpclient45.ECFHttpClientFactory.newClient()asfollows
 (so instead of 2 and 20).
builder.setMaxConnPerRoute(100);
builder.setMaxConnTotal(300);
And while these numbers seem relatively large, the setup archiver visits a 
great many resources on multiple threads (to produce the setups.zip used by the 
installer).  Only by increasing these numbers dramatically does the setup 
archiver application go back to normal functioning, completing in 19 second on 
the build server versus thrashing for 20 minutes and failing with connection 
pool timeouts.
So in the end, I'm a little concerned because p2 also uses ECF to access 
repositories and if there is a problem with the connection pool refusing to 
hand out new leases even when the client has finished 

Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release Candidate (RC1) is complete

[Carsten Reckord]

Looking at egit.aggrcon, I would guess that it is caused by this:

  http://download.eclipse.org/egit/github/staging/v5.3.0.201903061415-rc1;
 description="EGit GitHub Updates" mirrorArtifacts="false">

The mirrorArtifacts="false" will cause the EGit GitHub artifacts not to be 
included in the repo, instead triggering the composite. And I guess the local 
file: url mapping of the aggregator then causes the broken child url.

Cheers,

Carsten Reckord
Lead Software Architect & co-founder

-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org  dev-boun...@eclipse.org> On Behalf Of Carsten Reckord
> Sent: Thursday, March 7, 2019 6:49 PM
> To: Cross project issues 
> Cc: Matthias Sohn 
> Subject: Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release
> Candidate (RC1) is complete
> 
> > /home/data/httpd/download.eclipse.org/staging/2019-03/aggregate
> > <http://download.eclipse.org/staging/2019-03/aggregate>  has no
> > content.jar
> 
> That part should be fine. It's only used as an artifact repository. The 
> metadata
> repo is in /home/data/httpd/download.eclipse.org/staging/2019-03 together
> with a compositeArtifacts.jar that includes the aggregate.
> 
> However, there are two things fishy with the compositeArtifacts.jar:
> 
> 1. It contains this child, which is obviously wrong:  location='file:/home/data/httpd/download.eclipse.org/egit/github/staging/v
> 5.3.0.201903061415-rc1'/>
> This will probably cause the composite to fail loading, causing the errors you
> see.
> 
> 2. I think that composite shouldn't exist in the first place. Before build 
> 354,
> download.eclipse.org/staging/2019-03 was a plain non-composite repo. I
> guess something caused the aggregator to barf and create this strange half-
> composite with the broken child.
> 
> > msohn@build:/home/data/httpd/download.eclipse.org/staging/2019-03
> > <http://download.eclipse.org/staging/2019-03> > ls aggregate/
> > artifacts.jar  binary  features  plugins
> >
> > could this cause the problem ?
> >
> >
> > On Thu, Mar 7, 2019 at 6:25 PM Matthias Sohn  > <mailto:matthias.s...@gmail.com> > wrote:
> >
> >
> > something is wrong with the content of the staging repository.
> >
> > I installed Eclipse committer package 2019-03 M3 and could install
> > JGit/EGit 5.3.0 RC1 from
> > the original p2 repositories
> > https://download.eclipse.org/egit/staging/v5.3.0.201903061415-rc1
> >
> > https://download.eclipse.org/egit/github/staging/v5.3.0.2019030614
> > 15-rc1
> >
> >
> > but trying to update the same 2019-03 M3 installation from
> > http://download.eclipse.org/staging/2019-03/
> >
> >
> > fails with the error
> >
> >
> > An error occurred while collecting items to be installed
> >
> > session context was:(profile=epp.package.committers,
> > phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
> > action=).
> >
> > No repository found containing:
> > osgi.bundle,org.bouncycastle.bcpg,1.60.0.v20181210-2057
> >
> > No repository found containing:
> > osgi.bundle,org.bouncycastle.bcpkix,1.60.0.v20181210-2057
> >
> > No repository found containing:
> > osgi.bundle,org.bouncycastle.bcprov,1.60.0.v20181210-2057
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.cvs,1.4.900.v20190301-0040
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit.core,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit.doc,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit.gitflow,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit.gitflow.ui,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit.mylyn.ui,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.egit.ui,5.3.0.201903061415-rc1
> >
> > No repository found containing:
> > osgi.bundle,org.eclipse.epp.mpc.ui,1.7.5.v2019030

Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release Candidate (RC1) is complete

[Carsten Reckord]

> /home/data/httpd/download.eclipse.org/staging/2019-03/aggregate
>   has no
> content.jar

That part should be fine. It's only used as an artifact repository. The 
metadata repo is in /home/data/httpd/download.eclipse.org/staging/2019-03 
together with a compositeArtifacts.jar that includes the aggregate.

However, there are two things fishy with the compositeArtifacts.jar:

1. It contains this child, which is obviously wrong: 
This will probably cause the composite to fail loading, causing the errors you 
see.

2. I think that composite shouldn't exist in the first place. Before build 354, 
download.eclipse.org/staging/2019-03 was a plain non-composite repo. I guess 
something caused the aggregator to barf and create this strange half-composite 
with the broken child.

> msohn@build:/home/data/httpd/download.eclipse.org/staging/2019-03
>  > ls aggregate/
> artifacts.jar  binary  features  plugins
> 
> could this cause the problem ?
> 
> 
> On Thu, Mar 7, 2019 at 6:25 PM Matthias Sohn   > wrote:
> 
> 
>   something is wrong with the content of the staging repository.
> 
>   I installed Eclipse committer package 2019-03 M3 and could install
> JGit/EGit 5.3.0 RC1 from
>   the original p2 repositories
>   https://download.eclipse.org/egit/staging/v5.3.0.201903061415-rc1
> 
>   https://download.eclipse.org/egit/github/staging/v5.3.0.2019030614
> 15-rc1
> 
> 
>   but trying to update the same 2019-03 M3 installation from
>   http://download.eclipse.org/staging/2019-03/
> 
> 
>   fails with the error
> 
> 
>   An error occurred while collecting items to be installed
> 
>   session context was:(profile=epp.package.committers,
> phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
> action=).
> 
>   No repository found containing:
> osgi.bundle,org.bouncycastle.bcpg,1.60.0.v20181210-2057
> 
>   No repository found containing:
> osgi.bundle,org.bouncycastle.bcpkix,1.60.0.v20181210-2057
> 
>   No repository found containing:
> osgi.bundle,org.bouncycastle.bcprov,1.60.0.v20181210-2057
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.cvs,1.4.900.v20190301-0040
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit.core,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit.doc,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit.gitflow,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit.gitflow.ui,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit.mylyn.ui,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.egit.ui,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.epp.mpc.ui,1.7.5.v20190301-1516
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt,3.17.0.v20190301-0040
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.apt.core,3.6.300.v20190228-0624
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.apt.core.source,3.6.300.v20190228-0624
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.core,3.17.0.v20190227-1706
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.core.source,3.17.0.v20190227-1706
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.debug.ui,3.10.200.v20190226-0733
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.debug.ui.source,3.10.200.v20190226-0733
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.doc.isv,3.14.300.v20190301-0538
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.doc.user,3.15.200.v20190227-0848
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.launching,3.13.0.v20190222-0937
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.launching.source,3.13.0.v20190222-0937
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.ui,3.17.0.v20190228-1358
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jdt.ui.source,3.17.0.v20190228-1358
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jgit,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jgit.archive,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jgit.http.apache,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> osgi.bundle,org.eclipse.jgit.ssh.apache,5.3.0.201903061415-rc1
> 
>   No repository found containing:
> 

Re: [cross-project-issues-dev] Build problems with recent platform4.11-I-builds

[Carsten Reckord]

Hi Bernd,

> I still try to understand why the change in my target definition to use a
> different platform updates site causes this particular failure while using the
> same java, tycho and Trace Compass version. I don't see the connection.

You could use mvn -X -Dtycho.debug.resolver=true to compare the effective 
target platforms used by Tycho for the broken projects. 

However, looking at your configuration, you are using the jdt.annotations 
bundle from the running platform, i.e. Tycho, not your target platform, so I'm 
not sure if that would help...

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

Re: [cross-project-issues-dev] [orbit-dev] Heads Up: Incomplete HttpClient 4.5.6 bundle in Orbit for 2019-03M2

[Carsten Reckord]

>> Since some projects raised concerns that they are unable to react to a
>> changed packaging I propose we fix this
>> by adding the missing 4.5.6 classes which were present in 4.5.5.
>> 
>> Or we file new CQs for 4.5.7 which was released meanwhile in
>> January and directly update to this newer maintenance release.
> 
> ^ Sounds as best option to me.

Please take into account that beyond the missing packages, I think we should 
also ensure that we agree on a single httpclient version for the release train.

In the past we've had hard to reproduce issues with faulty wiring and 
classloader problems when there were multiple versions present. This can happen 
when bundles expose  types from the library in their own signatures and this 
way clients get exposed to the same types from different versions through 
different classloaders. For MPC this was the case in the past due to 
Userstorage SDK exposing httpclient API without having uses-declarations in its 
manifest. That should be fixed with https://git.eclipse.org/r/c/136312/, but I 
think other projects had similar issues.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] Heads Up: Incomplete HttpClient 4.5.6 bundle in Orbit for 2019-03M2

[Carsten Reckord]

> We, i.e. the Platform currently ship 4.5.5 and at the moment there are no
> plans to move to 4.5.6 for 2019-03. So, I don't see an issue for the projects
> listed below for 2019-03. This might change for 2019-06 though if the Platform
> decides to upgrade.

Thanks for the clarification. So now Platform and ECF (on the  bug) have 
declared that they'll stay on 4.5.5, and EGit would like to ship with 4.5.6. 

Personally, I'm fine with either. But I would very much like everyone to agree 
on a single version for 2019-03, because multiple versions in the runtime have 
led to all sorts of grief with wiring and classloader issues in the past (more 
so if the new version keeps missing some packages).
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] Heads Up: Incomplete HttpClient 4.5.6 bundle in Orbit for 2019-03M2

[Carsten Reckord]

Hi Ed,

> Firstly, I will personally not be available to accommodate any such change to
> any code and for any builds for the next four weeks, i.e., until March 11th.

Have a good vacation 

> making implicit assumptions about the
> availability of others to accommodate arbitrary decision of your own is
> generally not a good planning strategy.

Just for the sake of clarity: This was not my decision. MPC was affected by the 
breakage introduced by the new bundle, and as such, and because I contributed 
the previous version to Orbit, I offered my help to remedy the situation.

I even had the patch to add the missing packages in Gerrit already, before the 
consensus on the bug was to go the other route. In any case, MPC is fine with 
any one of the possible remediations: Staying on 4.5.5, having 4.5.6 
all-in-one, or in separate bundles.

I'll copy your feedback over to the bug for further discussion.

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

Re: [cross-project-issues-dev] [orbit-dev] Heads Up: Incomplete HttpClient 4.5.6 bundle in Orbit for 2019-03M2

[Carsten Reckord]

Hey again,

a quick update on the HttpClient situation:

We discussed on bug 
544139<https://bugs.eclipse.org/bugs/show_bug.cgi?id=544139> if we should add 
the additional packages back into the bundle as was done before, or publish 
separate bundles for them. It was decided *NOT* to change the main HttpClient 
bundle this time and instead, going forward, to publish the fluent and cache 
APIs as separate Orbit bundles. This will cause a small bit of work for some 
downstream projects (see below), but is in line with how HttpClient is 
originally distributed , and will hopefully put a stop to incomplete bundles in 
future updates.

I've filed CQs 18919 and 18920 (ATO 18921 and 18922) and will push the bundles 
to Orbit as soon as the CQs are approved. (Nobody seems to depend on the also 
missing httpmime library, so I haven't done anything about that - speak up if 
you need it)

In the meantime, I had a look at the 2019-03 repo to see who is affected.

The following projects use one of the missing libraries through Require-Bundle 
and need to react to this change:


  *   Oomph: org.eclipse.oomph.setup.sync (see bug 
544290<https://bugs.eclipse.org/bugs/show_bug.cgi?id=544290>)
  *   USS SDK: org.eclipse.userstorage, org.eclipse.userstorage.oauth (see bug 
544144<https://bugs.eclipse.org/bugs/show_bug.cgi?id=544144>)

The following projects use one of the missing libraries through Import-Package. 
They should work unchanged. For now, they'll just pick up the old HttpClient 
version, and once the new bundles are available, they should transition 
automatically:


  *   AERI: org.eclipse.epp.logging.aeri.ide
  *   MPC: org.eclipse.epp.mpc.core

Regards,
Carsten

--
Lead Software Architect & co-founder
+49 (0)69 2475666-33 | 
reck...@yatta.de<mailto:carsten%20reckord%20%3creck...@yatta.de%3e> | 
www.yatta.de<http://www.yatta.de/>

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

From: orbit-dev-boun...@eclipse.org  On Behalf 
Of Carsten Reckord
Sent: Tuesday, February 5, 2019 4:16 PM
To: Cross project issues 
Cc: Orbit Developer discussion 
Subject: [orbit-dev] Heads Up: Incomplete HttpClient 4.5.6 bundle in Orbit for 
2019-03M2

Hey everyone,

if your project consumes HttpClient from Orbit, please be aware that the new 
4.5.6 bundle does not currently include the additional packages from 
httpclient-cache, httpmime and fluent-hc. If your project requires any of these 
APIs, you might see NoClassDefFoundErrors or wiring issues.

I've opened Orbit bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=544139 to 
track the incomplete bundle.

Carsten
--
Lead Software Architect & co-founder
+49 (0)69 2475666-33 | 
reck...@yatta.de<mailto:carsten%20reckord%20%3creck...@yatta.de%3e> | 
www.yatta.de<http://www.yatta.de/>

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

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

[cross-project-issues-dev] Heads Up: Incomplete HttpClient 4.5.6 bundle in Orbit for 2019-03M2

[Carsten Reckord]

Hey everyone,

if your project consumes HttpClient from Orbit, please be aware that the new 
4.5.6 bundle does not currently include the additional packages from 
httpclient-cache, httpmime and fluent-hc. If your project requires any of these 
APIs, you might see NoClassDefFoundErrors or wiring issues.

I've opened Orbit bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=544139 to 
track the incomplete bundle.

Carsten
--
Lead Software Architect & co-founder
+49 (0)69 2475666-33 | 
reck...@yatta.de | 
www.yatta.de

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

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

Re: [cross-project-issues-dev] Eclipse IDE Simultaneous Release 2018-12 participants

[Carsten Reckord]

Hi,

Could you please update the version for the Marketplace Client? We will be 
releasing version 1.7.3 [1] for 2018-12.

Thanks,
Carsten

[1] 
https://projects.eclipse.org/projects/technology.packaging.mpc/releases/1.7.3

-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org  dev-boun...@eclipse.org> On Behalf Of Wayne Beaton
> Sent: Friday, November 30, 2018 8:25 PM
> To: Cross project issues 
> Subject: Re: [cross-project-issues-dev] Eclipse IDE Simultaneous Release
> 2018-12 participants
> 
> Thanks for the feedback.
> 
> I've created a "Eclipse IDE 2018-12
>  " page with what I figure are
> the best guesses at the release versions being contributed to the list. You'll
> notice corresponding "This release is part of Eclipse IDE 2018-12" messages
> on project and release pages (follow the links).
> 
> Please take a look.
> 
> Let me know if the version that's listed is not correct (or if something needs
> to be added or dropped). Note that if you want that version changed, we
> need to have a corresponding Release record.
> 
> If you're doing a major or minor release, then you should engage with the
> EMO as soon as possible, please, to ensure that the review gets scheduled.
> There's help in the handbook
>  ; contact
> your PMC or EMO if you're having trouble. If you're doing a new service
> release with 2018-12, then no reviews are required.
> 
> Note that whether or not you need a release record for a service release is
> really up to you. If the page lists, for example, the page lists your 2.5 
> release
> but you're really contributing a 2.5.4 release, then I leave it as a matter
> between you and your PMC to decide if you need a "2.5.4" release record.
> 
> Thanks,
> 
> Wayne
> 
> 
> On Fri, Nov 30, 2018 at 9:42 AM Lorenzo Bettini   > wrote:
> 
> 
>   Wayne, our project EMF Parsley is not in this list, though we have an
>   aggrcon file (enabled)
> 
>   Lorenzo
> 
>   On 27/11/18 19:58, Wayne Beaton wrote:
>   >
>   > Keeping the above in mind, please have a look and let me know if
> you
>   > notice that your project is not on the list, or notice that a project 
> on
>   > the list should not be there.
>   >
>   > Note that if you're planning to contribute new bits to the release,
> you
>   > should start thinking about your IP Log and Release Review
> materials soon.
>   >
>   >   * Eclipse Acceleo (modeling.acceleo)
>   >   * Eclipse Accessibility Tools Framework (technology.actf)
>   >   * Eclipse aCute (tools.acute)
>   >   * Eclipse Amalgam (modeling.amalgam)
>   >   * Eclipse ATL (modeling.mmt.atl)
>   >   * Eclipse BPEL Designer (soa.bpel)
>   >   * Eclipse BPMN 2.0 Modeler (soa.bpmn2-modeler)
>   >   * Eclipse BPMN2 (modeling.mdt.bpmn2)
>   >   * Eclipse Buildship (tools.buildship)
>   >   * Eclipse Business Intelligence and Reporting Tools (birt)
>   >   * Eclipse C/C++ Development Tools (tools.cdt)
>   >   * Eclipse CDO (modeling.emf.cdo)
>   >   * Eclipse Code Recommenders (technology.recommenders)
>   >   * Eclipse Collections (technology.collections)
>   >   * Eclipse Communication Framework (rt.ecf)
>   >   * Eclipse Corrosion (tools.corrosion)
>   >   * Eclipse Data Tools Platform (tools.datatools)
>   >   * Eclipse Dynamic Languages Toolkit (technology.dltk)
>   >   * Eclipse EclEmma (technology.eclemma)
>   >   * Eclipse Ecore Tools (modeling.ecoretools)
>   >   * Eclipse e(fx)clipse (technology.efxclipse)
>   >   * Eclipse eGerrit (technology.egerrit)
>   >   * Eclipse EMF Client (modeling.ecp)
>   >   * Eclipse EMF Compare (modeling.emfcompare)
>   >   * Eclipse EMF Diff/Merge (modeling.emf.diffmerge)
>   >   * Eclipse EMF Facet (modeling.emft.emf-facet)
>   >   * Eclipse EMF (modeling.emf.emf)
>   >   * Eclipse EMF Services (modeling.emfservices)
>   >   * Eclipse EMFStore (modeling.emfstore)
>   >   * Eclipse Equinox (eclipse.equinox)
>   >   * Eclipse Extended Editing Framework (modeling.eef)
>   >   * Eclipse Generation Factories (modeling.emf.egf)
>   >   * Eclipse Git Team Provider (technology.egit)
>   >   * Eclipse GMF Runtime (modeling.gmf-runtime)
>   >   * Eclipse Graphical Editing Framework (tools.gef)
>   >   * Eclipse Graphiti (modeling.graphiti)
>   >   * Eclipse Java Workflow Tooling (soa.jwt)
>   >   * Eclipse Jubula (technology.jubula)
>   >   * Eclipse Linux Tools (tools.linuxtools)
>   >   * Eclipse LSP4E (technology.lsp4e)
>   >   * 

[cross-project-issues-dev] AERI problems

[Carsten Reckord]

Hi all,

is anyone else seeing tons of duplicates on AERI in the last days?

I'm not sure how many of you use it actively, and how many use the automatic 
Bugzilla creation. But since yesterday, it's flooding MPC's Bugzilla with 
duplicates of the same handful of issues (which aren't "real" issues but log 
entries for network issues, and already marked as such in their respective 
original AERI problem reports). I've disabled automatic bug creation for now 
and will begin cleaning up, but was wondering if other projects are affected as 
well.

Best,
Carsten

--
+49 (0)69 2475666-33 | 
reck...@yatta.de | 
www.yatta.de
Lead Software Architect & co-founder

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

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

Re: [cross-project-issues-dev] Update to httpclient/httpcore in ECF/Platform

[Carsten Reckord]

+1 for MPC

Please note that this will also require the following two updates:

org.apache.commons.codec 1.10.0 (from 1.9.0)
org.apache.commons .logging  1.2.0 (from 1.1.1)

Carsten

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org  dev-boun...@eclipse.org> On Behalf Of Steffen Pingel
> Sent: Friday, July 13, 2018 10:49 AM
> To: Cross project issues 
> Subject: Re: [cross-project-issues-dev] Update to httpclient/httpcore in
> ECF/Platform
> 
> +1 for Mylyn
> 
> Steffen
> 
> On Fri, Jul 13, 2018 at 10:45 AM, Matthias Sohn   > wrote:
> 
> 
> 
>   On Thu, Jul 12, 2018 at 2:00 PM Mat Booth   > wrote:
> 
> 
>   Hi all,
> 
> 
>   I would to like to push for switching ECF (and therefore
> Platform) to the latest httpcomponents bundles available from orbit:
> 
>   org.apache.httpcomponents.httpclient  4.5.5
>   org.apache.httpcomponents.httpcore   4.4.9
> 
> 
>   I hope that other consumers of these bundles can also
> standardise on these latest bundles, but please make objections known if
> that is not the case.
> 
> 
> 
>   +1 for JGit
> 
> 
>   -Matthias
> 
>   ___
>   cross-project-issues-dev mailing list
>   cross-project-issues-dev@eclipse.org  d...@eclipse.org>
>   To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
>   https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> 
> 
> 
> 
> --
> 
> Steffen Pingel
> Staff Software Engineer
> http://tasktop.com
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] MPC participation in 2018-09

[Carsten Reckord]

Hi all,



MPC will participate in the 2018-09 SimRel with a 1.7.x bugfix release [1] at 
its usual +3 offset.



Thanks,

Carsten



[1] 
https://projects.eclipse.org/projects/technology.packaging.mpc/releases/1.7.0

--
+49 (0)69 2475666-33 | 
reck...@yatta.de | 
www.yatta.de
Lead Software Architect & co-founder

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] MPC not opening with space in install path - requesting respin

[Carsten Reckord]

We do now: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536583


I had this on my todo list for post-Photon regardless of this issue, but was 
holding off until this is sorted, as not to create the impression that I was 
asking for this change as part of the respin.


Best,

Carsten


--
+49 (0)69 2475666-33 | 
reck...@yatta.de | 
www.yatta.de
Lead Software Architect & co-founder


Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop


From: cross-project-issues-dev-boun...@eclipse.org 
 on behalf of Lars Vogel 

Sent: Monday, July 2, 2018 10:58:11 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] MPC not opening with space in install 
path - requesting respin

Do we have a bug to make MPC a root level feature for the EPPs? Seems like a 
good idea.

Ed Merks mailto:ed.me...@gmail.com>> schrieb am Sa., 30. 
Juni 2018, 14:18:

Mickael,

Comments below.

On 30.06.2018 13:26, Mickael Istria wrote:
Hi Ed,

Thanks for those very valuable additions to the discussion.

On Sat, Jun 30, 2018 at 11:07 AM, Ed Merks 
mailto:ed.me...@gmail.com>> wrote:
Probably the worst case would be if the user's home folder name has spaces 
"C:\Users\john doe", but I suppose that in (almost?) all cases the user could 
choose to install to a location without spaces and in all cases the user can 
update MPC from a specific URL.}
In any case, the combination of "I install to a disk location with spaces"  
(which is generally always a bad idea because something is bound not to work 
properly because it's not been tested) with "I actually use MPC" is probably 
relatively small, but who knows.

Several users were hit by this on the hours after the release and reported the 
bug. Although it does affect only a minority of users, it's still a critical 
issue IMO and we shouldn't try to minimize it in this discussion.
I'm certainly not trying to minimize or trivialize the problem.   After all, we 
don't have any actual statistics on which to base a truly informed opinion.  I 
know Oomph had problems in the past with installations with spaces in them, so 
I sympathize fully that such an issue is easily overlooked.
Maybe the conclusion will just be "we acknowledge that it's critical but didn't 
want to release the fix off-process" or maybe it'll be "let's do a respin", but 
the issue remains critical in both cases.
There's certainly a lesson to be learned when respins are generally refused 
though.  But in this case the user will need to explicitly install the update, 
as Carsten pointed out, because MPC is not a root feature amenable to updates.  
I tested to confirm that, and that does seem a far-less-than-ideal workaround.  
So from such a user's point of view its certainly a major problem, and perhaps 
major problems for many users becomes a critical problem for us...


Given we are no longer in the business of providing update releases, to me it's 
a slippery slope to me if we start respinning releases to publish multiple 
releases.  My knee jerk reaction is to vote -1 on a respin.

That's a very valid point. And I agree we shouldn't have a "respin" but...
Yes, that's why I said "knee jerk" because I realize there's always room to 
consider exceptions to the rules (which of course lead on a downward slope)...


Certainly the decision of whether we will do respins affects the decision of 
whether http://download.eclipse.org/releases/2018-09 for the September release 
can be a simple repository because there can/will never be updates versus 
whether it should be a composite to accommodate arbitrary/possible respins.

... what about publishing a respin labelled as 2018-07 ?
Indeed that's a possibility.   Though in this case, we'd probably better just 
stick to a composite with generally a single child.The Oomph Product 
Catalog has to point at something, and it would seem strange that the 2018-09 
product version actually points at a 2018-10 p2 repo.


In the end, I think there are other approaches than a respin that would help 
minimize (and in many case eliminate) the problem.

What do you think is the main point that would make a re-build of SimRel with 
newer MPC worse than adding a composite or similar things?
Given Cartsen pointed out that MCP is not a root feature, adding to the 
composite will not make Check for Updates work, so it's a moot point.   Of 
course the main point is that adding a repo to the composite would take 5 
minutes, but if you factor in all the overhead for all the people involved in 
producing the packages, testing them, and making them available to the public, 
it's hard to calculate the number of person hours involved.
Is this a process issue, or a technical pain point?
Well both.  One process issue is the exception process and the other technical 
issue 

[cross-project-issues-dev] Bugzilla broken?

[Carsten Reckord]

Hey all,

anyone else get an Internal Server Error when trying to comment in Bugzilla? 

I can't seem to comment on 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=530834. I already tried logging 
out and back in and deleting cookies.

Regards,
Carsten
-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de
Lead Software Architect & co-founder

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] MPC not opening with space in install path - requesting respin

[Carsten Reckord]

Ed,

as always thanks for your valuable feedback. Comments inline:

> Probably the worst case would be if the user's home folder name has spaces
> "C:\Users\john doe", but I suppose that in (almost?) all cases the user could 
> choose
> to install to a location without spaces and in all cases the user can update 
> MPC from
> a specific  URL.

The problem is with communicating that fact and the correct remedy to users 
encountering the problem. In that moment, all that they see is that the IDE 
isn't working properly and they don't know what to do about it. That doesn't 
make a very good impression and shines on the IDE as a whole, especially since 
MPC is a core aspect of the IDE's plug-in ecosystem.

> Given we are no longer in the business of providing update releases, to me 
> it's a slippery
> slope to me if we start respinning releases to publish multiple releases.  My 
> knee jerk
> reaction is to vote -1 on a respin.

I appreciate that concern and would like nothing more than to avoid a respin. 
But given the somewhat special situation MPC is in (see below) and the 
impression this makes on affected users, I still think it would be the best way 
to go.

> In any case, the combination of "I install to a disk location with spaces"  
> (which is generally
> always a bad idea because something is bound not to work properly because 
> it's not been
> tested) with "I actually use MPC" is probably relatively small, but who  
> knows.

That's the factor I discussed at length yesterday with the folks at the 
Foundation managing the Marketplace server and associated channels. It's really 
hard to estimate how many users encounter this issue, but given that there was 
quite some traffic on the bug and on Twitter (see Mickael's comment), it's 
certainly of  interest.

I can speak for the MPC usage though, both as project maintainer and from our 
own Marketplace entries. It's the strongest channel we have for third-party 
plug-ins and sees tons of daily use. So I'm pretty certain that most users with 
a space in their path will also be MPC users.

> Note that another possible solution to this problem for users who create 
> their installations
> with the Eclipse Installer is to add the URL the MPC fix to the Oomph Product 
> Catalog for all
> Photon Product Versions.  I tested this for installing the Committers  Photon 
> Product Version.
> ...
>  If we do add a URL, it should probably be specifically 
> http://download.eclipse.org/mpc/releases/1.7.1 right?  I tested that as well,

Thanks for testing this. I think adding the update to the Oomph catalog would 
be a great thing to do regardless of the respin discussion. If that's an option 
for you, then http://download.eclipse.org/mpc/releases/1.7.1 would indeed be 
the repository to use.

> Along a similar line of thinking,  
> http://download.eclipse.org/releases/photon is a composite
> and  http://download.eclipse.org/mpc/releases/1.7.1 could be added to that 
> composite.  
> This would make check for updates work (I assume) and it would ensure that 
> the existing 
> Oomph Product Catalog would directly install the latest version of MPC during 
> the initial  
> installation process.

Unfortunately no. This will work for initial installations from the repository 
(e.g. with the Oomph installer) and for upgrades from earlier distributions. It 
won't work for existing Photon release users though, including those who will 
download the packages later on.

This is due to how MPC is included in the EPP packages. It isn't shipped as a 
root feature, but contained in the EPP package feature. That precludes it from 
"Check for Updates" unfortunately, since that only checks for new versions of 
root features.

> Certainly the decision of whether we will do respins affects the decision of 
> whether
>  http://download.eclipse.org/releases/2018-09 for the September release can 
> be a simple
> repository because there can/will never be updates versus whether it should 
> be a
> composite to accommodate arbitrary/possible respins.

Another important factor in that decision would be how easy it is for projects 
to push out updates in between releases.

I intend to ask the EPP project to change the way they ship MPC for the 2018-09 
release, i.e. make it a proper root feature like (most) everything else, so MPC 
can push out its own updates just like other projects. I'd have been quite 
happy if I could roll out this fix with a simple "Check for updates".

So I would expect that in a similar situation, the 2018-09 release actually 
wouldn't need a composite and/or respin.

Best regards,
Carsten
 
-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de
 
Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change 

[cross-project-issues-dev] MPC not opening with space in install path - requesting respin

[Carsten Reckord]

Hi everyone,

Unfortunately I have to inform you that the Marketplace Client project will 
have to ask for a SimRel respin because of bug 536385 [1].

Due to this bug, the Marketplace Client in the Photon release fails to open for 
users that have their Eclipse installed into a path that contains spaces - or 
more accurately, whose configuration area path contains spaces.

This includes users who
- rename their Eclipse directory to something like "Eclipse Photon"
- install Eclipse under a path that has spaces, e.g. "/Users/john/My 
Projects/eclipse"
- use the "-configuration" option to set the config area to something with 
spaces in it

It does not include installations to read-only locations with spaces, e.g. 
"C:\Program Files\eclipse", because in that case, Eclipse will use a writeable 
overlay directory in $HOME/.eclipse without spaces. Overall, it's hard to 
estimate the percentage of our users affected by this, but there is some 
traffic on the bug and on several duplicates.

I've already published an MPC update with a fix to our release update site at 
http://download.eclipse.org/mpc/photon and users confirmed that it fixed the 
issue.

I'm asking for this respin, because this is obviously a very bad user 
experience for those affected, and MPC is an essential part of Eclipse's 
plug-in ecosystem. And secondly, with the way the packages are built, I can't 
push out an MPC update that would get picked up by "Check for updates", so 
users don't have any easy recourse to get the fix and I can't think of a 
"milder" solution to roll out this fix effectively.

Best regards,

Carsten


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

--
+49 (0)69 2475666-33 | 
reck...@yatta.de | 
www.yatta.de
Lead Software Architect & co-founder

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Heads up: multiple HttpClient versions in simrel

[Carsten Reckord]

> org.eclipse.jgit.http.apache is an optional bundle which is not used by EGit.
> It's used in JGit by org.eclipse.jgit.lfs.server (supports implementation of 
> a git
> lfs server)
> and org.eclipse.jgit.pgm (jgit command line client).

Yes, but it's in the simrel repository and it pulls in the second HttpClient 
version. 

Since that version has a higher qualifier than the one bundled with ECF, it 
gets pulled in by installing anything that has a dependency on HttpClient with 
a version range. So it also ends up in all the packages (while the other 
version is brought in, because the ECF feature contains the exact version).
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Heads up: multiple HttpClient versions in simrel

[Carsten Reckord]

> I'm not sure yet if this is the cause of my bug in MPC, but in the past, these
> kind of version mixups have always been problematic.

I've tested the MPC bug without the duplicate HttpClient versions by installing 
MPC into an Eclipse SDK, and the error is gone. So I guess I can confirm that 
it's caused by wiring issues due to the duplicate version. I'm not sure what 
those wiring issues are yet; "diag" in the OSGi console thinks that everything 
is fine, and I can't see any weird wiring going on...
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Heads up: multiple HttpClient versions in simrel

[Carsten Reckord]

Hey everybody,

while diagnosing a problem with reporting install errors in the Marketplace 
Client (https://bugs.eclipse.org/bugs/show_bug.cgi?id=535821), I noticed that 
since RC3 we have two versions of HttpClient 4.5.2 in the Simrel repository.

I'm not sure yet if this is the cause of my bug in MPC, but in the past, these 
kind of version mixups have always been problematic.

I've dug around a bit (for details, see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535821), and the two versions are 
contributed by the Platform 
(org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925) and by JGit 
(org.apache.httpcomponents.httpclient_4.5.2.v20180410-1551 - this one is new in 
RC3). The newer HttpClient version was introduced in Orbit I20180417184143 to 
make it safely co-exist with commons.logging 1.2 and commons.codec 1.10, 
neither of which are currently found in the Simrel repository.

While the version contributed by JGit is the current one from the Orbit Photon 
repository, I think at this point the easiest and safest thing to do would be 
for JGit to go back to the old version to get a consistent state of the Simrel 
repo again. The alternative would be to update ECF with the new version, respin 
the platform, and get the Mylyn SDK to use the new version as well.

What do you think?

Kind regards,
Carsten Reckord

--
+49 (0)69 2475666-33 | 
reck...@yatta.de<mailto:carsten%20reckord%20%3creck...@yatta.de%3e> | 
www.yatta.de<http://www.yatta.de/>
Lead Software Architect & co-founder

Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt 
a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

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

[Carsten Reckord]

Hi all,

MPC will participate in Photon with MPC 1.7.0 [1] at its usual +3 offset.

Thanks,
Carsten

[1] 
https://projects.eclipse.org/projects/technology.packaging.mpc/releases/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] Oxygen.1a is broken when installed on top of the BETA Patch feature

[Carsten Reckord]

Hi Stephan,

we still have the P-builds in our internal mirror staging area:

drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161024-0950
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161024-2040
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161220-0520
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161220-0605
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161220-0630
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161220-0720
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161220-0825
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20161221-0730
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170118-0315
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170118-0910
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170131-0635
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170208-0120
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170310-0700
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170315-0540
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170316-0420
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170519-0945
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170523-
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170526-0330
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170602-0810
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170602-1020
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170609-0640
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170618-0400
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170627-0135
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170726-1055
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170731-0440
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170731-0540
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170826-0400
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170831-0455
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170905-0025
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170911-2315
drwxrwxr-x+4 eclipse-mirror eclipse-mirror 4096 Oct 13 03:39 P20170919-1155

Let me know which one(s) you need and I can make them available again. Same 
goes for the P-build download drops.

Best,
Carsten Reckord

-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de

Yatta Solutions GmbH · Mainzer Landstraße 50 · 60325 Frankfurt a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Stephan Herrmann
> Sent: Saturday, October 14, 2017 2:34 PM
> To: cross-project-issues-dev@eclipse.org
> Subject: Re: [cross-project-issues-dev] Oxygen.1a is broken when installed
> on top of the BETA Patch feature
> 
> Interesting idea, let's hope we still have the bits to perform the necessary
> experiments,
> see https://dev.eclipse.org/mhonarc/lists/platform-releng-
> dev/msg28664.html
> 
> Stephan
> 
> On 14.10.2017 02:08, David Williams wrote:
> > I have not looked at this in detail, but one solution would be to produce a
> new "Beta Java-9 patch" even though it is no longer
> > needed with Oxygen.1.
> >
> > Its purpose would be to simply make sure the latest JDT was installed
> (instead of the patched parts of JDT).
> >
> > The idea is that if someone has the beta patch installed already, then
> "check for updates" would effectively pull in Oxygen 1a.
> >
> >
> >
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > 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] Oxygen.1 and JDK9

[Carsten Reckord]

> We looked at what you suggest, but found that it might be confusing for
> users since the entry says 'Installed'.

It says "Installed" instead of "Update" because it was decided to focus on the 
"Install" flow on the main list tab, and move actions for installed items to 
the "Installed" tab. The "Installed" button will take you there and show the 
available operations.

I agree that that can be confusing. Would you mind opening a bug about that?

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

Re: [cross-project-issues-dev] Oxygen.1 and JDK9

[Carsten Reckord]

Hey all,

> I would use the second way which is described in more detail. If you use the
> first way, make sure that you select "Update my installation...".

This looks like another issue with the update-but-not-quite-update scenario of 
the Java 9 entry. It isn't supposed to jump back from the feature selection 
page to the main list like that. I'll look into getting this fixed with the MPC 
Oxygen.1a update. 

Until then, might I suggest instructing your users to directly use the 
Marketplace Client to find and install the Java 9 entry instead of using 
drag? I know it's not quite as user-friendly to have to look up the entry 
again elsewhere, but you won't have to go through the ""One solution selected", 
deselect, re-select dance...
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] MPC would like to contribute a fix to Oxygen.1a - RE: Upcoming Oxygen 1.a release

[Carsten Reckord]

I've pushed https://git.eclipse.org/r/#/c/105870/. If there aren't any 
objections, I'm going to merge it to Oxygen.1a_JDK9.

> MPC would like to contribute a fix for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=525201 to the Oxygen.1a
> release. This isn't strictly a contribution for Java 9 support, but it 
> currently
> blocks the Eclipse SDK product from being able to install the Java 9 and 
> JUnit 5
> Marketplace entries [1][2]  (This only affects the SDK - EPP packages can
> install the Java 9/JUnit 5 entries fine).
> 
> It would be great to get this update into the Oxygen.1a release. However it's
> not a critical fix since the circumstances under which the issue surfaces are
> rare and it works for the EPP packages. So a decision not to include it in the
> Java 9 release would be okay for me as well.

-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de

Yatta Solutions GmbH · Mainzer Landstraße 50 · 60325 Frankfurt a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] MPC would like to contribute a fix to Oxygen.1a - RE: Upcoming Oxygen 1.a release

[Carsten Reckord]

Hi all,

MPC would like to contribute a fix for 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=525201 to the Oxygen.1a release. 
This isn't strictly a contribution for Java 9 support, but it currently blocks 
the Eclipse SDK product from being able to install the Java 9 and JUnit 5 
Marketplace entries [1][2]  (This only affects the SDK - EPP packages can 
install the Java 9/JUnit 5 entries fine).

It would be great to get this update into the Oxygen.1a release. However it's 
not a critical fix since the circumstances under which the issue surfaces are 
rare and it works for the EPP packages. So a decision not to include it in the 
Java 9 release would be okay for me as well.

Best,
Carsten

-
[1] https://marketplace.eclipse.org/content/java-9-support-oxygen
[2] https://marketplace.eclipse.org/content/junit-5-support-oxygen

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Mélanie Bats
> Sent: Wednesday, September 13, 2017 3:16 PM
> To: cross-project-issues-dev@eclipse.org
> Subject: [cross-project-issues-dev] Upcoming Oxygen 1.a release
> 
> Hi,
> 
> As decided during the last planning council meeting, the dates for the
> Oxygen 1.a release are:
> 
> * Oxygen JDT Official JDK9 release on Thursday, September 21
> * Oxygen.1a Platform RC1   on Friday, September 22
> * Oxygen.1a RC1on Friday, September 29
> * Oxygen.1a Platform RC2   on Friday, September 29
> * Oxygen.1a RC2on Friday, October 6
> * Oxygen.1aon Wednesday, October 11
> 
> The purpose of the Oxygen 1.a release is to provide support for Java 9
> and JUnit 5.
> Consequently, only changes needed for Java 9 or JUnit 5 can participate
> to this release. Projects are encouraged to declare their intent to
> participate to this special release by replying to this thread.
> 
> This release will appear in the SimRel repository and be offered to
> users for upgrade as a normal release.
> 
> Best regards,
> --
> Mélanie Bats
> Eclipse Modeling Consultant
> +33 5 34  57 16 29
> @melaniebats
> 
> *Obeo*
> 25 Boulevard Victor Hugo - Colomiers - France
> http://www.obeo.fr
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
+49 (0)69 2475666-33 | reck...@yatta.de | www.yatta.de

Yatta Solutions GmbH · Mainzer Landstraße 50 · 60325 Frankfurt a.M. (Germany)
Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director 
Johannes Jacop
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Transparent P2 mirrors (Was: Why (not) a "Final Daze" in SimRel?)

[Carsten Reckord]

> > B) Now imagine a transparent mirroring solution where step 1 immediately
> redirects us to a suitable mirror, and P2 cooperates:
> >
> > 1. Request http://download.eclipse.org/foo/updates/latest/p2.index
> > a. Receive HTTP 307 to
> http://mirror.example.org/foo/updates/latest/p2.index
> > b. Update P2 repo object so further repository loading uses the
> redirected URL
> > c. Follow redirect and get
> http://mirror.example.org/foo/updates/latest/p2.index
> > 2. Get http://mirror.example.org/foo/updates/latest/compositeContent.jar
> > 3. Read child URL "../../drops/1.2.3", resolve it to
> http://mirror.example.org/foo/drops/1.2.3
> >
> 
> Hi Carsten,
> 
> That would certainly make things more efficient from our side: given a
> p2 repo, provide a mirror location for all the artifacts.
> 
> Not sure what needs to happen in p2 for that to work, however.

I'll open a bug and try to find out :) 

>From what I remember of the P2 repo loading internas, it shouldn't be too 
>difficult. The bug[1] referenced by Mykola might be an organizational blocker 
>though.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=507657
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Transparent P2 mirrors (Was: Why (not) a "Final Daze" in SimRel?)

[Carsten Reckord]

> I must echo something that Ed touched on:
> 
> >> * Doesn't the Foundation plan to enable a transparent mirroring
> >> system very soon that would make all this p2.mirrorsUrl useless?
> > No!!!  With mirror URLs, the mirrors are directly accessed with no
> > further access to download.eclipse.org.  With transparent mirroring,
> > the download server remains a bottleneck because it must be consulted
> > in order to redirect "transparently" to some other site.
> 
> Agreed -- transparent mirroring is nice for zip files and such, where a
> short URL can be convenient. But for p2 repos which are accessed by
> machines, NO  :)  Let the client gather bits from the local source
> directly.

This goes wy off-topic from the original discussion, but:

Depending on how the transparent mirroring works, I could actually see it help 
a lot for P2 repos as well - at least with a little support from P2.

A) The situation right now is, for some fictional composite release update site 
on eclipse.org, and a very simplified P2 install:

1. Get http://download.eclipse.org/foo/updates/latest/p2.index
2. Get http://download.eclipse.org/foo/updates/latest/compositeContent.jar
3. Read child URL "../../drops/1.2.3", resolve it to 
http://download.eclipse.org/foo/drops/1.2.3
4. Get http://download.eclipse.org/foo/drops/1.2.3/p2.index
5. Get http://download.eclipse.org/foo/drops/1.2.3/content.jar
6. Resolve the P2 install plan
7. Get http://download.eclipse.org/foo/drops/1.2.3/artifacts.jar
8. Read p2.mirrorsUrl from artifacts.jar
9. Get mirror list from p2.mirrorsUrl (e.g. 
http://www.eclipse.org/downloads/download.php?file=/foo/drops/1.2.3=xml)
10. Select a mirror from the list and download individual artifacts from the 
mirror

While step 10 is typically the one that transfers the most actual bits over the 
pipes, that's actually six requests with non-trivial content that hit 
eclipse.org before we ever reach the mirror. In my experience, this already 
adds up to some significant delay if download.eclipse.org has a slow day or 
your pipe to it is thin in general. 

Also, having to mess with the artifacts.xml, e.g. to provide this repository 
completely from your own mirror, is quite messy. And having your Eclipse still 
contact download.eclipse.org due to the p2.mirrorsUrl when you've put up a 
mirror e.g. on a local server can be quite a surprise.

B) Now imagine a transparent mirroring solution where step 1 immediately 
redirects us to a suitable mirror, and P2 cooperates:

1. Request http://download.eclipse.org/foo/updates/latest/p2.index
a. Receive HTTP 307 to http://mirror.example.org/foo/updates/latest/p2.index 
b. Update P2 repo object so further repository loading uses the redirected URL
c. Follow redirect and get 
http://mirror.example.org/foo/updates/latest/p2.index 
2. Get http://mirror.example.org/foo/updates/latest/compositeContent.jar
3. Read child URL "../../drops/1.2.3", resolve it to 
http://mirror.example.org/foo/drops/1.2.3
...

That's a single request to eclipse.org (maybe two or three if there is no 
p2.index and P2 has to guess) and we're off to a faster mirror. And all that 
without messing with p2.mirrorsUrl. Also, it's much closer to how HTTP 
redirects are handled on the web and feels a lot more natural, to me at least.

Right now, this doesn't work because P2 transparently fetches the redirected 
content for each request, one at a time, but does not interpret it as a 
location change for the whole repo (which means you still get the first 
sequence of requests, just with a redirect after each step). I never quite 
understood the rationale behind this behavior. Was this a concious decision, 
and for what use-case? Or is it just coincidentally the ECF transport's 
redirect handling "just doing its job"?

WDYT?
Carsten
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] gdk_test_simulate_button

[Carsten Reckord]

Doug,

We had the same issue in MPC. This should be resolved in RC3, see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=517273

Best regards,
Carsten

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer
> Sent: Friday, May 26, 2017 12:36 AM
> To: Cross project issues <cross-project-issues-dev@eclipse.org>
> Subject: [cross-project-issues-dev] gdk_test_simulate_button
> 
> Hey gang,
> 
> I'm getting crashes on certain machines when running tests against Oxygen.
> This has been reported before, and it seems to have some relation to the
> GTK webkit library. Do we have documented somewhere how to properly set up
> a Linux machine to run Oxygen, or at least run tests so they don't crash?
> 
> Thanks!
> Doug
> 
> For reference, the crash:
> 
> 18:18:58 #
> 18:18:58 # A fatal error has been detected by the Java Runtime
> Environment:
> 18:18:58 #
> 18:18:58 #  SIGSEGV (0xb) at pc=0x7f48ad594a40, pid=19297,
> tid=0x7f48d0e6f700
> 18:18:58 #
> 18:18:58 # JRE version: Java(TM) SE Runtime Environment (8.0_111-b14)
> (build 1.8.0_111-b14)
> 18:18:58 # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed
> mode linux-amd64 compressed oops)
> 18:18:58 # Problematic frame:
> 18:18:58 # C  [libgdk-3.so.0+0x45a40]  gdk_test_simulate_button+0x0
> 18:18:58 #


-- 
Yatta Solutions GmbH
- Carsten Reckord -

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

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

Geschäftsführung:
  Johannes Jacop

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

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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 update problem status

[Carsten Reckord]

Hi Marcel,

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

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

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

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

Best,
Carsten

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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 update problem status

[Carsten Reckord]

Hi all,

I have tested the respin candidate with MPC, and it looks good. I've tested 3 
scenarios, using the JavaEE EPP package:

1. Neon.2 with Docker Tools and Oomph installed, updated to Neon.3a
-> works, and the offending HttpClient is not installed

2. Direct install of Neon.3a with Docker Tools and Oomph
-> works, and the offending HttpClient is not installed

3. Neon.3 with Docker Tools and Oomph installed, updated to Neon.3a
-> this still contains the broken HttpClient (as mentioned before). However, at 
least in my tests, it looks like it was only wired to bundles requiring only 
the package subset actually present in the bundle, and there were no wiring 
issues through package exports that I could see. Specifically, both USS and MPC 
were wired to the 4.3.6 version, so that potential conflict was resolved 
properly.

After the initial update, I ran each resulting Neon.3a instance a couple of 
times with -clean and/or -initialize to see if that changed the wiring somehow, 
but didn't run into problems.

Best,
Carsten

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Frederic Gurr
> Sent: Thursday, May 4, 2017 1:18 AM
> To: Cross project issues 
> Subject: Re: [cross-project-issues-dev] [eclipse.org-planning-council]
> Neon.3 update problem status
> 
> Hi Ed,
> 
> The corresponding EPP repository can be found here:
> 
> https://hudson.eclipse.org/packaging/job/neon.epp-tycho-
> build/599/artifact/org.eclipse.epp.packages/archive/repository/
> 
> Regards,
> 
> Fred
> 
> On 28.04.2017 10:25, Ed Merks wrote:
> > Fred,
> >
> > If someone would let me know when there is a corresponding EPP
> > repository available, I can do some further testing.   With regard to
> > your specific question, if the p2.inf can specify an exact bundle
> > version to remove that's probably a good idea.   And by exact I mean
> > that it would only remove the known-to-be-broken versions of these
> > bundles that no one should ever have used and no one should ever use in
> > the future.  Those broken versions have never been in a "released"
> > repository, except for Neon.3.  It should not remove newer versions of
> > the fixed bundles, even though those might cause the same wiring
> > problems.  That being said, I think a main contributing factor to the
> > wiring problem is the constraints that were added to exclude higher
> > versions.   I know for example that oomph and userstorage work fine with
> > the latest versions of these bundles but it was constrained not to use
> > to exclude the broken versions for Oomph 1.1.
> >
> > I hope that everyone who added such constraints will be sure to remove
> > them for Oxygen M7.  Oomph's 1.8 contribution to Oxygen will use and
> > contribute the latest versions of those bundles...
> >
> >
> > On 27.04.2017 22:14, Frederic Gurr wrote:
> >> Open questions:
> >> - Do we need to use the uninstall command in p2.inf to remove old Http*
> >> bundles for users that already upgraded to Neon.3 and have a broken
> >> setup at the moment? How would that affect 3rd party plugins that might
> >> bring their own HttpClient version (Martin's question)?
> >
> > ___
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-coun...@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> > IMPORTANT: Membership in this list is generated by processes internal to
> > the Eclipse Foundation.  To be permanently removed from this list, you
> > must contact e...@eclipse.org to request removal.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Carsten Reckord]

And I spoke too soon - I didn't take the bundle containments of the feature 
into account. So we now have:

> > B. Respin with the old version of httpclient: Needs a Neon.3 Orbit
> Service Release containing only the 4.3.6 version of httpclient. Needs a
> respin of Linux Tools to downgrade the version But the other depending
> projects will not be updated and so the MPC will still not work for end
> user after the update.
> 
> MPC would work fine with this, as would the Userstorage SDK. I was under
> the impression that Linux Tools couldn't do this because the security
> update they applied required the new httpclient version.

Still working fine.

> > C. Respin with the two versions of httpclient: Needs a Neon.3 Orbit
> Service Release containing the old 4.3.6 version and the fixed 4.5.2
> version of httpclient. In theory the two httpclient bundles should be able
> to work side-by-side but we've seen a lot of wiring issues in Oxygen due
> to the mix.
> 
> Judging by the issues in Oxygen, this will likely break MPC.
> [...]

Still the case.

> > D. Respin with only the new fixed version of httpclient: Needs a Neon.3
> Orbit Service Release containing only the 4.5.2 version of httpclient.
> Needs a respin of all the depending projects (Marketplace?) to update
> their ranges to the new 4.5.2 version minimum and force the update.
> 
> MPC wouldn't need a respin for this, but Userstorage will.

Actually MPC would need a respin as well to remove the 4.3.6 httpclient from 
its feature.

Also, a respin of Userstorage would require a respin of Oomph, because the 
Userstorage bundles are contained in the org.eclipse.oomph.setup.core feature.

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

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Carsten Reckord]

Hi,

> There seem to have been no notes/minutes taken during the meeting:
> 
>   https://wiki.eclipse.org/Planning_Council/April_05_2017
> 

Sorry, I didn't see these minutes until now, only Melanie's mail on the list. 
But there seems to be a misconception with the proposed solutions wrt MPC:

> B. Respin with the old version of httpclient: Needs a Neon.3 Orbit Service 
> Release containing only the 4.3.6 version of httpclient. Needs a respin of 
> Linux Tools to downgrade the version But the other depending projects will 
> not be updated and so the MPC will still not work for end user after the 
> update.

MPC would work fine with this, as would the Userstorage SDK. I was under the 
impression that Linux Tools couldn't do this because the security update they 
applied required the new httpclient version.

> C. Respin with the two versions of httpclient: Needs a Neon.3 Orbit Service 
> Release containing the old 4.3.6 version and the fixed 4.5.2 version of 
> httpclient. In theory the two httpclient bundles should be able to work 
> side-by-side but we've seen a lot of wiring issues in Oxygen due to the mix.

Judging by the issues in Oxygen, this will likely break MPC. 

MPC itself is fine with either version, and isn't affected by the broken 
httpclient version either (it gets all of its httpclient dependencies through 
package imports, so it won't get wired against the broken bundle).

However, MPC is exposed to httpclient directly through its own dependency and 
indirectly through Userstorage API. And since the Userstorage SDK, in an 
attempt to avoid the broken httpclient, restricts its version to [4.3,4.4) in 
Neon, we'll likely get wiring conflicts, which might or might not be solved by 
Thomas's Oxygen fix.

> D. Respin with only the new fixed version of httpclient: Needs a Neon.3 Orbit 
> Service Release containing only the 4.5.2 version of httpclient. Needs a 
> respin of all the depending projects (Marketplace?) to update their ranges to 
> the new 4.5.2 version minimum and force the update.

MPC wouldn't need a respin for this, but Userstorage will.

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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Carsten Reckord]

> Also, I'd like to add that SimRel seems to be missing integration tests
> covering basic user stories. At this point, it might be more fruitful to
> invest in automated tests for SimRel than to brainstorm about best
> processes.

+1 as mentioned earlier and less eloquently:

> But as far as checks against the finished packages go, how about an 
> integration test suite that simrel projects can contribute their own test 
> bundles to and that runs against the finished packages? Relying solely on 
> manual labor in the form of the great work of our package maintainers (and 
> hopefully testers in all the participating projects) seems a bit 
> anachronistic. I would expect a rather simple test to be that all bundles in 
> all packages can actually start (maybe with an exception list for a few 
> special cases). And projects could add smoke tests to check that their basic 
> functionality works, thus detecting cross-project integration issues with 
> otherwise unrelated release train projects automatically.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Carsten Reckord]

> I think there is also another thing to consider. IMHO projects should stop
> hard-pinning specific 3rd party versions in the feature.xml - at least in
> the feature they submit into the common repo. This triggers p2 to install
> multiple versions into packages. 

Speaking from the perspective of one of the projects that currently do this, 
I'm all in favor of changing that. 

I think what would be needed would be a clear best practice for making sure that

1. a version that my project can work with is contributed to the simrel repo 
(and to my project's repo as well)
2. the bundles don't show up in "Install New Software..."

Before I added the orbit bundle to my feature, I tried around quite a bit, and
- widening the version in the feature via p2.inf will result in the bundle no 
longer included in my repository by default
- including the bundle in the repository explicitly via the category.xml 
results in it being visible in the UI
- not including the bundle in a category in category.xml will put it into a 
synthetic "Default" category

So looking around at others with this problem, just including the bundle in the 
feature.xml seemed the way to go at the time.

FWIW, in Oxygen, MPC will remove the Orbit HttpClient bundles from its feature, 
include them in the repository explicitly, and use some XML processing to hide 
them. However, that seemed overly complicated to achieve something I expect to 
be a common case...

> We also have projects that update
> dependencies at different paces. This is concerning from a security
> perspective. Should we consider something more drastic like target
> platform filtering when building the packages?

Well, you'd have to filter (or test) the repository aggregation build actually. 
In this case, the offending bundles didn't make it into any of the packages as 
far as I can see.

But as far as checks against the finished packages go, how about an integration 
test suite that simrel projects can contribute their own test bundles to and 
that runs against the finished packages? Relying solely on manual labor in the 
form of the great work of our package maintainers (and hopefully testers in all 
the participating projects) seems a bit anachronistic. I would expect a rather 
simple test to be that all bundles in all packages can actually start (maybe 
with an exception list for a few special cases). And projects could add smoke 
tests to check that their basic functionality works, thus detecting 
cross-project integration issues with otherwise unrelated release train 
projects automatically.

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

Re: [cross-project-issues-dev] UI tests on HIPP - segfaults and browser support

[Carsten Reckord]

> Hi Carsten,
> 
> I suppose that libwebkitgtk.so is not installed or otherwise not working
> on your HIPP.
> 
> Eclipse would usually prefer webkitgtk over xulrunner automatically if
> it’s available.
> By enforcing webkitgtk, you enforced a non-working configuration.
> 
> Perhaps at least temporarily you should consider running on GTK2, by
> setting the SWT_GTK3 environment variable to 0:
> https://www.eclipse.org/swt/faq.php#gtkstartup
> 
> Since you probably don’t have shell access to you HIPP, you may have to
> file a Bugzilla asking Webmaster’s help to add a working version of
> libwebkitgtk.so to your HIPP.
> 
> Thanks,
> Martin

Duh, it's always the obvious stuff that one tends to miss :P Thank you. Bug 
filed :=)
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] UI tests on HIPP - segfaults and browser support

[Carsten Reckord]

> > 2. I recently switched my target platform to Oxygen, and now my UI tests
> > always segfault somewhere down the line:
> >
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  SIGSEGV (0xb) at pc=0x7f19ea78b510, pid=10922,
> > > tid=0x7f1b077af700
> > > #
> > > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build
> > > 1.8.0_102-b14)
> > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode
> > > linux-amd64 compressed oops)
> > > # Problematic frame:
> > > # C  [libgdk-3.so.0+0x38510]  gdk_test_simulate_button+0x0
> >
> > It looks like this happens the first time SWTBot "clicks" on a Link
> widget.
> > But I don't have the faintest idea what to do about it.
> 
> Can you share full stacktrace ? I haven't seen this one so a bit more
> details is needed.

Oh, I forgot to link to the trace. Here it is: 
https://hudson.eclipse.org/mpc/job/epp-mpc-ci/ws/org.eclipse.epp.mpc.tests/hs_err_pid10922.log
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] UI tests on HIPP - segfaults and browser support

[Carsten Reckord]

Hi everybody,

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

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

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

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

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

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

/cheers
Carsten

-- 
Yatta Solutions GmbH
- Carsten Reckord -

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

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

Geschäftsführung:
  Johannes Jacop

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

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

Re: [cross-project-issues-dev] Problem with Git HTTP Authentication in Neon.1

[Carsten Reckord]

While I was writing this, David also opened bug 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=502937 in parallel, suggesting 
another way to do a minimal update.

> -Original Message-
> From: technology-pmc-boun...@eclipse.org [mailto:technology-pmc-
> boun...@eclipse.org] On Behalf Of Carsten Reckord
> Sent: Friday, September 30, 2016 8:08 PM
> To: Cross project issues <cross-project-issues-dev@eclipse.org>;
> technology-...@eclipse.org
> Cc: mpc-...@eclipse.org
> Subject: [technology-pmc] Problem with Git HTTP Authentication in Neon.1
> 
> Everybody,
> 
> Unfortunately, we have found an issue in Neon.1 that breaks EGit's HTTP
> Basic Auth support. If users try to check out a repository via HTTP that
> requires authentication, they will get a wrong password dialog from
> Eclipse UI instead of EGit's own, and even if they enter the correct
> credentials here, the operation will ultimately fail.
> 
> The problem was introduced by MPC's version in Neon.1, which tried to work
> around problems caused by EGit's replacement of the global
> java.net.Authenticator. Details can be found on bug
> http://eclip.se/501000. A new version of MPC that disables the problematic
> behavior is available[1], but the question is how to proceed in rolling
> out this fix.
> 
> I see several options on how to proceed and would like to ask for your
> opinion:
> 
> 1) Just communicate the issue and provide instructions for the user to fix
> it
> 
> Instructions would be to install the MPC update manually, either from the
> update site via "Install New Software...", or via MPC itself. We could
> probably use the Error Reporter to inform users of the fix.
> 
> This is definitively the easiest to do. But given the impression this bug
> might make on users, the question is if it is enough.
> 
> 2) Ask for a full respin / Neon.1a release
> 
> This is clearly on the other end of the spectrum as the most heavyweight
> solution, but would ensure that all future downloads have the fix and all
> existing installations get it via automatic updates.
> 
> 3) Provide the fix as an addition to the Neon simrel composite
> 
> This would be sort of a middle-ground that has come up in the discussion
> on http://eclip.se/501000. Instead of doing a full respin, we could add a
> minimal repository with the fix to the Neon simrel composite. This would
> make the fix available as an automated update to existing users, and Ed
> would make sure that installations via the Eclipse Installer would include
> the fix from the start. This would just leave the package archive
> downloads, which would only receive the fix with their next automatic
> update.
> 
> Due to the impact on the user community and the impression we make here, I
> think this is severe enough to warrant option 2, but I'd really like to
> hear your opinions. I'm sorry that I didn't catch this in time for the
> release and for any extra work it causes now.
> 
> Yours,
> Carsten
> 
> [1] http://download.eclipse.org/mpc/releases/1.5.1a

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Problem with Git HTTP Authentication in Neon.1

[Carsten Reckord]

Everybody,

Unfortunately, we have found an issue in Neon.1 that breaks EGit's HTTP Basic 
Auth support. If users try to check out a repository via HTTP that requires 
authentication, they will get a wrong password dialog from Eclipse UI instead 
of EGit's own, and even if they enter the correct credentials here, the 
operation will ultimately fail. 

The problem was introduced by MPC's version in Neon.1, which tried to work 
around problems caused by EGit's replacement of the global 
java.net.Authenticator. Details can be found on bug http://eclip.se/501000. A 
new version of MPC that disables the problematic behavior is available[1], but 
the question is how to proceed in rolling out this fix. 

I see several options on how to proceed and would like to ask for your opinion:

1) Just communicate the issue and provide instructions for the user to fix it

Instructions would be to install the MPC update manually, either from the 
update site via "Install New Software...", or via MPC itself. We could probably 
use the Error Reporter to inform users of the fix.

This is definitively the easiest to do. But given the impression this bug might 
make on users, the question is if it is enough.

2) Ask for a full respin / Neon.1a release

This is clearly on the other end of the spectrum as the most heavyweight 
solution, but would ensure that all future downloads have the fix and all 
existing installations get it via automatic updates.

3) Provide the fix as an addition to the Neon simrel composite

This would be sort of a middle-ground that has come up in the discussion on 
http://eclip.se/501000. Instead of doing a full respin, we could add a minimal 
repository with the fix to the Neon simrel composite. This would make the fix 
available as an automated update to existing users, and Ed would make sure that 
installations via the Eclipse Installer would include the fix from the start. 
This would just leave the package archive downloads, which would only receive 
the fix with their next automatic update.

Due to the impact on the user community and the impression we make here, I 
think this is severe enough to warrant option 2, but I'd really like to hear 
your opinions. I'm sorry that I didn't catch this in time for the release and 
for any extra work it causes now.

Yours,
Carsten

[1] http://download.eclipse.org/mpc/releases/1.5.1a
-- 
Yatta Solutions GmbH
- Carsten Reckord -

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

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

Geschäftsführung:
  Johannes Jacop

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

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

Re: [cross-project-issues-dev] Oomph b3 agregator

[Carsten Reckord]

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

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

This currently blocks validation of all simrel contributions through Gerrit. 

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

Best,
Carsten


> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Ed Merks
> Sent: Wednesday, September 14, 2016 6:00 PM
> To: cross-project-issues-dev@eclipse.org
> Subject: Re: [cross-project-issues-dev] Oomph b3 agregator
> 
> Eike is unavailable at the moment. I believe
> http://download.eclipse.org/oomph/drops/release/1.5.0 was contributed to
> the aggregation today, but I'm personally not sure how to check this
> simrel thing.  Sorry.  I think the promotion script automatically deleted
> all the milestone repos when it promoted this release build, so the simrel
> contribution better be pointing at 1.5.0...
> 
> 
> 
> On 14.09.2016 16:35, LE FEVRE FRANCOIS wrote:
> 
> 
>   Dear all
> 
>   We are encountering some problems due to the unavailability of Oomph
> p2 [1]
> 
>   The p2 milestone seems to empty [2]
> 
> 
> 
>   Could you confirm what is the version linked to the simrel
> aggregator on Neon?
> 
>   Is it now this one [3]
> 
> 
> 
>   Thanks
> 
> 
> 
>   Quentin & Francois
> 
> 
> 
>   [1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=501428
> 
>   [2] http://download.eclipse.org/oomph/drops/milestone/S20160831-
> 044539-1.5.0-M1
> 
>   [3]: http://download.eclipse.org/oomph/drops/release/1.5.0/?d
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   ___
>   cross-project-issues-dev mailing list
>   cross-project-issues-dev@eclipse.org  d...@eclipse.org>
>   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] MPC participation in Oxygen

[Carsten Reckord]

Unfortunately, MPC will stay disabled for Oxygen M1, because we depend on USS 
(Eclipse User Storage), currently a part of Oomph, which is not yet enabled.

I don't believe anyone in the release train depends on MPC, so I hope this 
doesn't cause any problems.

Carsten

> -Original Message-
> From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-
> issues-dev-boun...@eclipse.org] On Behalf Of Carsten Reckord
> Sent: Wednesday, August 10, 2016 6:35 PM
> To: Cross project issues <cross-project-issues-dev@eclipse.org>
> Subject: [cross-project-issues-dev] MPC participation in Oxygen
> 
> Hi all,
> 
> MPC will participate in Oxygen with MPC 1.6.0 [1] at its usual +3 offset.
> 
> Thanks,
> Carsten
> 
> [1]
> https://projects.eclipse.org/projects/technology.packaging.mpc/releases/1.
> 6.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
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] org.eclipse.userstorage?

[Carsten Reckord]

Hi Doug,

the USS plugins come from http://download.eclipse.org/oomph/uss/updates/latest.

See 
http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/plain/org.eclipse.epp.mpc-target/staging.target
 for details.

Best,
Carsten

On July 7, 2016 8:17:02 PM CEST, Doug Schaefer <dschae...@blackberry.com> wrote:
>Hey gang,
>
>I’m cleaning up my commercial product build so that it doesn’t build
>off of the simrel repo. I can’t seem to find what project repo
>contributes the org.eclipse.userstorage plug-in that the MarketPlace
>core plug-in depends on. Any ideas?
>
>Thanks,
>Doug.
>
>
>
>
>___
>cross-project-issues-dev mailing list
>cross-project-issues-dev@eclipse.org
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Sent from my Android phone. Please excuse my brevity.
--
Yatta Solutions GmbH
- Carsten Reckord -

t +49 (0)69 2475666-33
f +49 (0)69 2475668-0
e reck...@yatta.de

Anschrift Office Kassel
Universitätsplatz 12
34127 Kassel

Anschrift Office Frankfurt a.M.
Mainzer Landstraße 50
60325 Frankfurt a.M.

Sitz, Handelsregister:
Sitz der Gesellschaft: Kassel
Amtsgericht Kassel, HRB 14720
USt-IdNr DE263191529

Geschäftsführung:
Johannes Jacop
Dr. Christian Schneider

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

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

[cross-project-issues-dev] MPC participation in Neon release

[Carsten Reckord]

Hi,

MPC will be participating in the Neon simultaneous release with
offset +3.

The release record is at 
https://projects.eclipse.org/projects/technology.packaging.mpc/releases/1.5.0


Regards,
Carsten

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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.eclipse.org/c broken?

[Carsten Reckord]

Hi everybody,

I'm currently getting strange effects when browsing the gitweb page at
http://git.eclipse.org/c/

The page links at the bottom seem to be completely broken. E.g. the (2)
link is for me

http://git.eclipse.org/c/%20SomeCustomInjectedHeader:injected_by_wvs/org.eclipse.cdt.old.git/diff/old2/cdt-home/developer/featurespec/2.0/contentassist.html/bpmn2-modeler/org.eclipse.bpmn2-modeler.git/cbi/org.eclipse.cbi.maven.plugins.git/babel/server.git/bpel/org.eclipse.bpel.git/dash/org.eclipse.dash.repositories.git/cdt/org.eclipse.cdt.git/cdt/org.eclipse.launchbar.git/?ofs=50

which results in a 404. The correct link would be
http://git.eclipse.org/c/?ofs=50 i believe. Not sure where the stuff in
between comes from...

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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 Reporting Tool Improvement

[Carsten Reckord]

For cutting off the stack frames at Display.readAndDispatch() there's
already https://bugs.eclipse.org/bugs/show_bug.cgi?id=451359.

On 06.05.2015 13:54, Ed Merks wrote:
 Marcel,
 
 The error reporting tool is extremely cool and very useful!
 
 One aspect that could likely be improved significantly is the computation of 
 the 
 blamed projects.  In particular I'm having to triage many reports such as 
 this 
 one:
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f9b544e4b0a38aecd742e2/details
 
 No doubt that's because Oomph is on the stack:
 
 
 
 I would like to suggest that the blame logic should consider that 
 Display.readAndDispatch processes events of arbitrary origin.  As such, 
 nothing 
 below that point in the stack is likely contributing to any problem above 
 that 
 point in the stack.
 
 Given that Oomph often starts a background dialog to perform tasks on 
 startup, 
 every possible problem that happens elsewhere in the IDE ends up in Oomph's 
 triage bucket,  so the list I must triage is large to the point where I'm not 
 sure it can ever be managed:
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/?projects=oomphkinds=NORMALkinds=FREEZEcategories=UNCONFIRMEDpage=1size=100sort=createdOn,desc
 
 The duplicates are a bit annoying too, but you have some nice support for 
 that 
 already:
 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/5522970ce4b026254ee014bf/similar
 
 Kudos for creating this great technology!
 
 Cheers,
 Ed
 
 
 
 
 
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

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

Re: [cross-project-issues-dev] Error Reporting Tool Improvement

[Carsten Reckord]

Maybe I worded mine badly, but I was after pretty much the same as Ed ;P

(maybe with the addition that I would take the cut-off trace as a base
for all subsequent analysis - blame, duplicate detection, ...)

On 06.05.2015 14:56, Marcel Bruch wrote:
 Thanks for the feedback Ed. I understand your critique with the current blame 
 logic. Unfortunately cutting off / ignoring frames below Display.runAsync or 
 Display.runDeferred can have the opposite effect (missing the project that 
 scheduled the ui runnable). I remember stacktraces that contained the 
 necessary information below these frames. I’ll have to investigate further to 
 find out how often we will be wrong with one or the other approach.
 
 Carsten’s feature request is different from your request. While I’m (ATM) not 
 convinced cutting off frames from a trace wont remove necessary information 
 (some times), I can imaging to produce reasonable results by improving the 
 blame function as you suggested. I created bug 466576 [1] to track your 
 request specifically. I’ll post updates to this bug.
 
 Thanks,
 Marcel
 
 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576
 
 
 On 06 May 2015, at 14:00, Carsten Reckord reck...@yatta.de wrote:

 For cutting off the stack frames at Display.readAndDispatch() there's
 already https://bugs.eclipse.org/bugs/show_bug.cgi?id=451359.

 On 06.05.2015 13:54, Ed Merks wrote:
 Marcel,

 The error reporting tool is extremely cool and very useful!

 One aspect that could likely be improved significantly is the computation 
 of the 
 blamed projects.  In particular I'm having to triage many reports such as 
 this 
 one:

 https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f9b544e4b0a38aecd742e2/details

 No doubt that's because Oomph is on the stack:



 I would like to suggest that the blame logic should consider that 
 Display.readAndDispatch processes events of arbitrary origin.  As such, 
 nothing 
 below that point in the stack is likely contributing to any problem above 
 that 
 point in the stack.

 Given that Oomph often starts a background dialog to perform tasks on 
 startup, 
 every possible problem that happens elsewhere in the IDE ends up in Oomph's 
 triage bucket,  so the list I must triage is large to the point where I'm 
 not 
 sure it can ever be managed:

 https://dev.eclipse.org/recommenders/committers/confess/#/problems/?projects=oomphkinds=NORMALkinds=FREEZEcategories=UNCONFIRMEDpage=1size=100sort=createdOn,desc

 The duplicates are a bit annoying too, but you have some nice support for 
 that 
 already:

 https://dev.eclipse.org/recommenders/committers/confess/#/problems/5522970ce4b026254ee014bf/similar

 Kudos for creating this great technology!

 Cheers,
 Ed








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


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

-- 
Yatta Solutions GmbH
- Carsten Reckord -

  t  +49 (0)69 2475666-33
  f  +49 (0)69 2475668-0
  e  reck...@yatta.de

Anschrift Office Kassel
  Universitätsplatz 12
  34127 Kassel

Anschrift Office Frankfurt a.M.
  Mainzer Landstraße 50
  60325 Frankfurt a.M.

Sitz, Handelsregister:
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

Geschäftsführung:
  Johannes Jacop
  Dr. Christian Schneider

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

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

Re: [cross-project-issues-dev] How to merge (subsets of) 2 git repos into 1, preserving history ?

[Carsten Reckord]

You might have some luck with subtree merging:
http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging

But every time I've had to use that, it had me pulling my hair for days
on end...

Doing a subtree merge without squashing should give you a merge commit
with the two separate histories as its ancestors.

I don't remember exactly, but I think showing historic state of a
specific file across the merge commit afterwards is a bit messy (due to
the changed file path)...

On 09.04.2015 11:14, Oberhuber, Martin wrote:
 Hi all,
 
 Sorry for the wide distribution, but I'm sure somebody has done this before 
 and any pointer would be very helpful.
 The TCF/Terminals restructuring which I mentioned earlier has passed its 
 review so we want to proceed now:
 
 
 1.   Create a new git repo under /gitroot/tm/org.eclipse.tm.terminal.git
 
 2.   Fill it with the following subtrees from 2 other git repos, 
 including all history in those subtrees respectively:
 
 a.   http://git.eclipse.org/c/tm/org.eclipse.tm.git/tree/terminal
 
 b.  http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/tree/terminals
 
 I have already reached out to webmaster who could provide the new git repo, 
 but now we're wondering how to merge/import the 2 git histories.
 
 Please put any hints/advice on the restructuring bug:
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=462230
 
 Many thanks in advance !
 Martin
 --
 Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
 direct +43.662.457915.85  fax +43.662.457915.6
 
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

-- 
Yatta Solutions GmbH
- Carsten Reckord -

  t  +49 69 2475666-33
  f  +49 69 2475668-0
  e  reck...@yatta.de

Office Kassel
  Universitätsplatz 12
  34127 Kassel

Office Frankfurt a.M.
  Mainzer Landstraße 50
  60325 Frankfurt a.M.

Seat, Trade Register:
  Registered seat: Kassel
  Amtsgericht Kassel, HRB 14720
  VAT-ID DE263191529

Management:
  Johannes Jacop
  Dr. Christian Schneider

Contact:
  t  +49 (0)69 2475666-0
  f  +49 (0)69 2475668-0
  e  i...@yatta.de

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

Re: [cross-project-issues-dev] Dates, review documentation, etc. for Mars

[Carsten Reckord]

On 09.02.2015 19:30, Wayne Beaton wrote:
 You do not generally need a CQ for a library that you use indirectly as a 
 result 
 of pulling in the bits from another Eclipse project that uses the library 
 directly. You only require a CQ for libraries that your project code uses 
 directly. Clever reflection tricks constitute direct use.

I have a question about this.

I'm trying to sort out what to do about our (MPC's) slightly convoluted
dependencies to Apache HttpComponents Client and Core. MPC consumes those in
two ways: indirectly via P2 and directly via package imports.

Historically, we haven't pulled in a specific version or included the
library in our download bits/repository, but rely on the platform to provide
a version. I think that's somewhat bad form and plan to change it for Mars
accordingly (piggyback CQs are coming up).

In the meantime, Platform has changed its shipped version between Luna SR1
and SR2. So while nothing has changed in MPC's dependency, it'll technically
run with the new version in SR2. Does this mean I should

a) do nothing for Luna SR2
b) file a piggyback CQ for the new Apache HttpComponents versions
c) dto and request our CQ for the old version to be marked obsolete?

Best regards,
Carsten
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] MPC for Mars M5 issue with Linux/GTK3

[Carsten Reckord]

Hi everybody,

Please note that due to an unforeseen structural change in SWT for GTK3, the
MPC contribution to Mars M5 doesn't work properly with GTK3.

When using Mars M5 with Linux GTK3, you will notice that the Recent,
Popular and Installed tabs in the Marketplace Client remain empty.
Search and News should work as expected, so MPC is still usable.

As a workaround for a full MPC experience, you can switch to GTK2 by setting
the SWT_GTK3 environment variable before starting Eclipse:

$ export SWT_GTK3=0
$ ./eclipse

Since a possible workaround for Linux would have broken Windows and Mac due
to another bug, and because it warrants more careful testing to avoid
unintended side-effects, we decided to go with the GTK3 breakage for M5.

The MPC issue is tracked in [1]. The underlying SWT issue is tracked in [2]
and has been fixed as of yesterday evening. So has the Windows/Mac bug
preventing a workaround, tracked in [3]. I'll publish a fixed MPC build in
the next days, so all should run smoothly for M6 again.

Best,
Carsten

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=458846
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=458844
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=148082
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] MPC participation in Mars

[Carsten Reckord]

Wayne was already so nice to mark us as participating. But let me follow
that up with the formal announcement:

The Marketplace Client project (MPC) intends to participate in Mars with an
1.4.0 release.

For this release, we are looking to further improve the user experience and
make the marketplace an even more attractive place to offer your plug-ins.
I'll follow up with more details on the mpc-dev list.

Our release record is at
https://projects.eclipse.org/projects/technology.packaging.mpc/releases/1.4
and the offset will be +3.

Thanks,
Carsten
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] p2 and optional not too greedy dependencies

[Carsten Reckord]

There might be a better, p2-based solution, but I think you can move the
problem from installation time to runtime:

1. Make the dependency from o.e.e.c.egit to EGit optional and non-greedy, so
o.e.e.c.egit doesn't pull in EGit
2. Always include o.e.e.c.egit in your install
3. At runtime, check in o.e.e.c.egit if EGit is present and o.e.e.c.egit can
do its thing. Otherwise just ignore it.

On 25.11.2014 10:47, Laurent Goubet wrote:
 Hi all,
 
 I'd like the help of p2 experts on a little issue...
 
 This question is for emf compare, in namespace org.eclipse.emf.compare. 
 For the sake of brevity, I'll abbreviate this namespace as o.e.e.c 
 everywhere.
 
 We have a number of plugins that get installed through a feature, among 
 which is plugin 'o.e.e.c.ide'. We support comparisons for specific files 
 (namely, files representing EMF models) either 'with each other' or 
 'with a repository version'. This repository can be git, svn, cvs... 
 through either EGit, Subversive, Team's CVS support... Our base 
 implementation is generic and only uses the eclipse Team APIs... but in 
 order to support some of the repository providers' quirks, we are forced 
 to depend on them to use their specific APIs. We have done so in 
 isolated plugins, separated in support for xxx features that the user 
 needs to install manually.
 
 For example, if the user uses EGit and wishes to compare his models 
 through that provider, he needs to install the EGit support feature, 
 which contains a single bundle, o.e.e.c.egit. But this feature is not so 
 obvious and the generic support will behave strangely as long as it is 
 not installed. What I'd like is for this bundle to be installed 
 automatically with EMF Compare if EGit is already installed in the 
 environment, but not force the installation of EGit if it is not. I am 
 not sure whether optional dependencies can get me there.
 
 case 1 : o.e.e.c.ide has an optional, non-greedy dependency towards 
 o.e.e.c.egit, which has a non-optional dependency on egit.
 case 2 : o.e.e.c.ide has an optional, greedy dependency towards 
 o.e.e.c.egit, which has a non-optional dependency on egit.
 
 In case 1, I believe that o.e.e.c.egit will never be installed 
 automatically, even if its dependency, EGit, is present in the environment?
 In case 2, however, my understanding is that o.e.e.c.egit will always 
 be installed as long as EGit is accessible i.e. even if it is not 
 installed, if it is reachable through the registered repository URIs, p2 
 will install it along?
 
 Note that currently, o.e.e.c.ide does not even depend on o.e.e.c.egit : 
 the dependency is not needed, we just think that p2 will need it somehow 
 if we want this automatic installation to happen one way or another.
 
 In other words, what we'd like is : if the user selects the feature 
 EGit support for EMF Compare in p2, then EGit will be installed along. 
 After all, we need it and in this particular case, the user has asked 
 for it. But if he does not select that feature, we'd like the support 
 bundle, o.e.e.c.egit, to still be installed if and only if EGit already 
 is (or has been selected for install)... Greedy, but not too much :p. Is 
 that possible through p2.inf or anything?
 
 Regards,
 
 Laurent Goubet
 Obeo
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe from 
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Provider and feature names

[Carsten Reckord]

On 18.11.2014 09:24, Tom Schindl wrote:
 BTW even if the sorting would be better the
 next thing I could talk about is searching.

I agree. Actually, EGit is exactly the contribution that I always have
trouble finding in the simrel repository. Because I always search by project
name and only remember that that doesn't work for EGit after scratching my
head at the empty search result for a few seconds...

So another -1 for dropping the short project name (at least until search
includes matches in description text and maybe even feature id).

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Marketplace Client bug in Luna

[Carsten Reckord]

Everybody,

Congratulations to everyone involved for another very smooth release. But
it's release day, so there has to be some kind of hickup, right? Well, happy
to oblige... :(

I'd like to notify you about a bug in the shipped MPC release for Luna:

Due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=437844, the Market and
Category select boxes have no effect in the released version (beyond logging
an exception in the error log). The bug is fixed, but was found too late to
make it into the release unfortunately (and was obviously not a stop-ship
kind of issue).

The fix is available on the MPC update site[1] and announced on the MPC
website[2].


[1] http://download.eclipse.org/mpc/luna
[2] http://www.eclipse.org/mpc
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Update site content cannot be displayed in IE11

[Carsten Reckord]

Your site index also doesn't load in Chrome 35.0.1916.114 m. I get

 Uncaught TypeError: undefined is not a function (index):14

I don't know if there is a recommended format, but my 2 cents are:

From a release engineer's point of view, I'd rather generate the index.html
statically as part of the build than rely on runtime javascript.

From a user's point of view, I find the information what to do with the site
- i.e. install instructions like on the emf site you linked to - much more
useful than the content listing (although having that can be neat at times,
too).


Best,
Carsten

On 22.05.2014 11:23, Igor Vinnykov wrote:
 Hello,
 
  
 
 One of our users reported the problem that the auto-generated update site
 http://download.eclipse.org/technology/subversive/1.1/update-site/ cannot be
 opened in IE11. I see that when this URL is opened in IE11 the page is
 blank. When it's opened in FF then I can see everything like before -
 plug-ins and their versions. It seems that the script that generates page
 content on-fly isn't compatible with latest IE.
 
  
 
 At the same time updates sites of other projects look differently -
 http://download.eclipse.org/modeling/emf/emf/updates/releases/
 
  
 
 The questions are:
 
 1. How should we generate update sites to get content that can be displayed
 on all modern browsers?
 
 2. Which update site format is up-to-date?
 
  
 
 Any recommendations will be appreciated.
 
  
 
 Best regards,
 
 Igor Vinnykov
 
 Subversive Team
 
  
 
  
 
 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

-- 
Yatta Solutions GmbH
- Carsten Reckord -

  t  +49 (0)561 5743277-33
  f  +49 (0)561 5743277-8833
  e  reck...@yatta.de

Anschrift Office Kassel
  Ludwig-Erhard-Straße 12
  34131 Kassel

Anschrift Office Frankfurt a.M.
  Mainzer Landstraße 50
  60325 Frankfurt a.M.

Sitz, Handelsregister:
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

Geschäftsführung:
  Johannes Jacop
  Dr. Christian Schneider

Kontakt Geschäftsstelle:
  t  +49 (0)561 5743277-0
  f  +49 (0)561 5743277-88
  e  i...@yatta.de

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

[cross-project-issues-dev] New public API in MPC

[Carsten Reckord]

Hi all,

Just a small heads-up: The MPC project now has an official public API as
part of its 1.3.0 Luna contribution. I missed cc'ing this list in my
original announcement, so please see the mail below for details.

This shouldn't really affect the release train in any way.

I also don't expect any issues for other MPC consumers, because the existing
internal API has been kept as stable as possible. There are a couple of
small changes to the internal service implementations that should be trivial
to adapt to, in case anybody was using those directly. Please comment on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=432803 if you see any problems.

Best,
Carsten

 Original Message 
Subject: [mpc-dev] MPC gets a public API
Date: Wed, 16 Apr 2014 20:02:40 +0200
From: Carsten Reckord reck...@yatta.de
Reply-To: Communication between MPC committers mpc-...@eclipse.org
To: Communication between MPC committers mpc-...@eclipse.org

Hi all,

I wanted to let everybody know that as part of our 1.3.0 release for Luna,
MPC now has a proper public API. The inofficial internal API has been pretty
stable for a number of releases now, so it seemed only logical to make it
public.

All relevant services to query the Marketplace REST API are now available in
org.eclipse.epp.mpc.core in the org.eclipse.epp.mpc.core.service package.

The core data model used by the services has been extracted to interfaces in
the org.eclipse.epp.mpc.core.model package. This required some small changes
to the old internal model classes and some overloading of method signatures
in the internal DefaultMarketplaceService implementation to use the new
public data model.

I expect most client code to be unaffected by this. If you are using the
internal service definitions, you will see some deprecations, but migrating
to the official API should be trivial and straight-forward.

The Marketplace Wizard has also got a bit of public API now, Allowing to
launch the wizards with more control over its initial state.

Please use https://bugs.eclipse.org/bugs/show_bug.cgi?id=432803 to comment
on the new API or raise new bugs if you have additional use cases that are
not currently covered.


Best,
Carsten

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

Re: [cross-project-issues-dev] Kepler SR2: Advice on feature-rename migration paths needed

[Carsten Reckord]

Hi,

This problem looks like it's not caused by the migration of your
sub-features and you'll probably get a different result with e.g. an Eclipse
Classic with Code Recommenders 1.x installed and attempting the update there.

Rather, it's not possible to replace the old o.e.r.rcp.feature with
something else, because it is required by the EPP DSL Feature upstream. The
reported conflict is then probably a result of P2 trying to keep the old
feature and installing the new one, too.

In the end, your migration feature idea is probably still best, if you want
users to be able to update - assuming that the offending EPP feature doesn't
get updated for Kepler SR2.

On 10.01.2014 15:58, Andreas Sewe wrote:
 Oddly enough, the installer is still aware that, despite the name
 change, it is really performing an update of o.e.r.rcp.feature but
 with the included features things go wrong:
 
 Your original request has been modified.
   Code Recommenders Developer Tools is already installed, so an update 
 will be performed instead.
 Cannot complete the install because of a conflicting dependency.
   Software being installed: Code Recommenders Developer Tools 
 2.0.5.v20140110-1444 (org.eclipse.recommenders.rcp.feature.feature.group 
 2.0.5.v20140110-1444)
   Software currently installed: Eclipse DSL Tools 2.0.1.20130919-0803 
 (epp.package.dsl 2.0.1.20130919-0803)
   Only one of the following can be installed at once: 
 Code Recommenders: Intelligent Code Completion Runtime 
 2.0.5.v20140107-1248 (org.eclipse.recommenders.completion.rcp 
 2.0.5.v20140107-1248)
 Code Recommenders: Intelligent Completion Runtime 
 1.0.5.v20130822-0858-b90 (org.eclipse.recommenders.completion.rcp 
 1.0.5.v20130822-0858-b90)
   Cannot satisfy dependency:
 From: Eclipse DSL Tools 2.0.1.20130919-0803 (epp.package.dsl 
 2.0.1.20130919-0803)
 To: org.eclipse.epp.package.dsl.feature.feature.group 
 [2.0.1.20130919-0803]
   Cannot satisfy dependency:
 From: EPP DSL Feature 2.0.1.20130919-0803 
 (org.eclipse.epp.package.dsl.feature.feature.group 2.0.1.20130919-0803)
 To: org.eclipse.recommenders.feature.rcp.feature.group 0.0.0
   Cannot satisfy dependency:
 From: Code Recommenders: Intelligent Completion 1.0.5.v20130822-0858-b90 
 (org.eclipse.recommenders.feature.completion.rcp.intellig.feature.group 
 1.0.5.v20130822-0858-b90)
 To: org.eclipse.recommenders.completion.rcp [1.0.5.v20130822-0858-b90]
   Cannot satisfy dependency:
 From: Code Recommenders Developer Tools 1.0.5.v20130822-0858-b90 
 (org.eclipse.recommenders.feature.rcp.feature.group 1.0.5.v20130822-0858-b90)
 To: 
 org.eclipse.recommenders.feature.completion.rcp.intellig.feature.group 
 [1.0.5.v20130822-0858-b90]
   Cannot satisfy dependency:
 From: Code Recommenders Developer Tools 2.0.5.v20140110-1444 
 (org.eclipse.recommenders.rcp.feature.feature.group 2.0.5.v20140110-1444)
 To: org.eclipse.recommenders.completion.rcp [2.0.5.v20140107-1248]

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

Re: [cross-project-issues-dev] Patch application is broken in Kepler SR1

[Carsten Reckord]

Konstantin,

We are doing something similar with patches in our product. I just did a few
quick tests and everything seems to work as expected for me with Kepler SR1
RC3. With a feature installed in a different version than targeted by our
patch - both higher or lower - the patch is rejected.

On 17.09.2013 19:36, Konstantin Komissarchik wrote:
 In Juno and prior, if a patch doesn't apply, there would be an error in p2
 ui and user can deselect the patch. In Kepler, the patch is installed,
 despite the fact that it is for a version of the feature that doesn't exist
 in the target.

We had a similar problem in the past, but that was way back when (I think
Indigo). It was caused by the P2 publisher not creating the proper version
bounds for the patch feature in the repository metadata.

Given that you are only hit now, this is probably not the problem, but it
doesn't hurt to check. Make sure that the patchScope version range in your
content.jar/content.xml has the expected value, e.g.:

patchScope
  scope
requires size='1'
  required namespace='org.eclipse.equinox.p2.iu'
name='org.eclipse.uml2.feature.group'
range='[4.1.0.v20130610-0712,4.1.0.v20130610-0712]'/
/requires
  /scope
/patchScope

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=350088 for the
long-standing bug on this.

 Is this related to the p2 problem solving abilities added in Kepler? If so,
 is there a way to turn that off? Any other ideas on how to get patches
 working properly in Kepler?

If remediation gets involved, you should see a page in the wizard that
outlines the changes to your installation (e.g. I got that when trying to
apply a Kepler patch to an older feature from Juno, suggesting an update of
the patched feature for the patch to apply).

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

Re: [cross-project-issues-dev] Patch application is broken in Kepler SR1

[Carsten Reckord]

On 17.09.2013 20:59, Konstantin Komissarchik wrote:
 Since the issue is still not fixed in p2 (seriously!?), what did you do for
 a workaround in your patches?

Since I needed a fix quickly at that time, I patched our Buckminster-based
toolchain using the fix I attached to that bug.

I kind of lost track on the bug afterwards, sorry for that.


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

Re: [cross-project-issues-dev] Status and outlook for Luna M1

[Carsten Reckord]

Make that 26, I've enabled MPC now. Sorry to be this late to the party.

On 21.08.2013 20:53, David M Williams wrote:
 We are currently down to 27 (from yesterday's 50) projects that have not 
 enabled their contribution. (List below) Unfortunately many of those (like 
 DTP) are depended on by many others so I remind you low level projects 
 you are holding up others!

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

Re: [cross-project-issues-dev] Preferences (topic was touched in Eclipse smells kind of dead thread)

[Carsten Reckord]

On 15.07.2013 22:08, Pascal Rapicault wrote:
 Unfortunately I don't think that the JDT approach is workable for all
 preferences, and asking the user for the scope where he wants to store a
 particular preference is going to result in complex UI that will confuse
 users.

How about a global change user configuration switch? Flick the switch to
enter user configuration mode and any configurations you make anywhere
will end up in the user scope. To avoid confusion/accidental changes, this
mode could be indicated with some big notification banner in the workspace
(and the preference editor).

Add a reset to user configuration option to sync other workspaces by
overriding/clearing local workspace-scope preferences and voila (or maybe do
that automatically based on e.g. timestamping of the user preference store).

On 16.07.2013 09:54, Campo, Christian wrote:
 Sharing prefs between workspaces sounds good. The suggested solution
 still sounds a little bit too complicated (for my taste of course). If I
 open a workspace, why cant I not directly reference an existing workspace
 and copy the preferences from there ? (why the extra export step) And for
 completeness wouldnt it be call if all my Eclipse installations share the
 same list of know workspace locations :-) so that I dont have to add them
 again when I unpack a new Eclipse IDE.

I don't think any solution based on copying preferences between workspaces
is a good one. It gets very confusing very fast when multiple (2)
workspaces get involved and you wish to keep them all in sync on some common
settings that could change at any time in anyone of them.


One problem with either approach is that I often encountered the case where
not everything was copyable/syncable with the available methods (i.e.
preference im/export and workspace layout copying). I often ended up
fiddling with stuff manually that didn't get across. One particular area
OTOH is position of view trims as well as position and filtering of toolbar
items. But of course those problems would just be worth individual bug
reports and have no impact on a solution strategy for the general syncing
problem.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] FW: [Doug on the Eclipse CDT] New comment on Eclipse smells kind of dead???.

[Carsten Reckord]

 I wonder if we might consider some kind of user survey option

I really like the idea of a survey - at least a lot more than that of a
usage data collector. And I think it is actually more suited for the
questions asked here than an ongoing data collection.

I'd give it some time - say two weeks to a month after first launch of the
installation (or workspace, not sure at what level this might make the most
sense without being too obtrusive). Then pop up a dialog _once_, asking to
take part in the survey and optionally including a snapshot of the relevant
settings.

The idea is that the user's typical setup including all configuration
options that are interesting for us in the scope of this discussion will
have mostly stabilized by then and a single snapshot would be enough to get
comparable value as an ongoing data collection.

 A user survey is better than nothing, but we are definitely going to get far
 fewer survey responses than opt-ins for automated usage data collection,
 which makes the answers less valuable.

I think if you ask nicely for participation _once_, you'll get at least as
many participants for the survey as you'd get for the data collection, if
not more because it's less big-brother-ish.

And if it optionally includes a snapshot of the preference data, it'd be of
at least comparable value (my bet would still be it's of more value).
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler is GO!

[Carsten Reckord]

On 26.06.2013 16:34, Tom Schindl wrote:
 In the end I think we need to investigate why some ecf stuff is missing
 from time to time

Digging around a bit, this is what I found out:

- The repository contains the filetransfer.httpclient4 bundles exclusively
now, whereas earlier RCs also contained the filetransfer.httpclient bundles

- ECF itself didn't contribute the filetransfer.httpclient(4) bundles in
their aggregator build at all

- It seems like it used to be pulled in by org.eclipse.equinox.p2.sdk and
org.eclipse.equinox.p2.core

- P2 have switched to httpclient4 in the meantime, so the old bundles aren't
included anymore...

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

Re: [cross-project-issues-dev] Missing Kepler downloads for DTP and MPC

[Carsten Reckord]

For MPC, this was probably my mistake, sorry.

I failed to prepare those archives beforehand and I have absolutely no idea
how to get access to the download area to get a zip archive up there (or,
for that matter, how to create a dedicated MPC 1.2 release update site at
http://download.eclipse.org/mpc/kepler/).

There's mention that I could request shell access through the My Foundation
portal, but I can't see any such function in the portal...

I've already mailed Ian, but haven't reached him so far since he's currently
on vacation.

On 26.06.2013 21:50, Konstantin Komissarchik wrote:
 It would be very helpful to see an ETA from DTP and MPC for publishing
 Kepler bits.
 
  
 
 Thanks,
 
  
 
 - Konstantin

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

Re: [cross-project-issues-dev] Missing Kepler downloads for DTP and MPC

[Carsten Reckord]

Thank you, Steffen!

On 26.06.2013 23:13, Steffen Pingel wrote:
 Hi,
 
 thanks for raising this Konstantin. I created an MPC repository with the
 1.2.0 Kepler build at http://download.eclipse.org/mpc/releases/1.2.0/. I'll
 follow up on the MPC mailing list with more details so we can improve
 coordination for future releases.
 
 Steffen
 
 
 On Wed, Jun 26, 2013 at 11:00 PM, Konstantin Komissarchik 
 konstantin.komissarc...@oracle.com wrote:
 
 See if you are able to connect to the downloads server using your committer
 credentials. Try this in an SFTP client. I use FileZilla on Windows.

 Host: build.eclipse.org
 Protocol: SFTP/SSH

 MPC downloads are going to be at /home/data/httpd/
 download.eclipse.org/mpc
 path once you connect to the server.

 Thanks,

 -Konstantin

 PS: I see that Benjamin Muskalla and Steffen Pingel are also listed as MPC
 committers. Perhaps they have more details on MPC process for publishing
 artifacts.



 -Original Message-
 From: cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Carsten
 Reckord
 Sent: Wednesday, June 26, 2013 1:40 PM
 To: Cross project issues
 Subject: Re: [cross-project-issues-dev] Missing Kepler downloads for DTP
 and
 MPC

 For MPC, this was probably my mistake, sorry.

 I failed to prepare those archives beforehand and I have absolutely no idea
 how to get access to the download area to get a zip archive up there (or,
 for that matter, how to create a dedicated MPC 1.2 release update site at
 http://download.eclipse.org/mpc/kepler/).

 There's mention that I could request shell access through the My Foundation
 portal, but I can't see any such function in the portal...

 I've already mailed Ian, but haven't reached him so far since he's
 currently
 on vacation.

 On 26.06.2013 21:50, Konstantin Komissarchik wrote:
 It would be very helpful to see an ETA from DTP and MPC for publishing
 Kepler bits.



 Thanks,



 - Konstantin

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

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

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

-- 
Carsten Reckord
  t  +49 561 5743277-33
  f  +49 561 5743277-8833
  e  reck...@yatta.de

Yatta Solutions GmbH
  Sitz der Gesellschaft: Kassel
  Amtsgericht Kassel, HRB 14720
  USt-IdNr DE263191529

Geschäftsführung:
  Johannes Jacop,
  Dr. Christian Schneider

Adresse:
  Ludwig-Erhard-Straße 12
  34131 Kassel

Kontakt:
  t  +49 561 5743277-0
  f  +49 561 5743277-88
  e  i...@yatta.de

Bankverbindung:
  Kasseler Bank eG
  BLZ 520 900 00
  Kto-Nr 158 305

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

Re: [cross-project-issues-dev] Missing Kepler downloads for DTP and MPC

[Carsten Reckord]

The download pages are updated now with the MPC 1.2.0 release bits for Kepler.

On 26.06.2013 23:13, Steffen Pingel wrote:
 Hi,
 
 thanks for raising this Konstantin. I created an MPC repository with the
 1.2.0 Kepler build at http://download.eclipse.org/mpc/releases/1.2.0/. I'll
 follow up on the MPC mailing list with more details so we can improve
 coordination for future releases.
 
 Steffen
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] RC2 build already on its way?

[Carsten Reckord]

Hi all,

Am I too late to get a change into the the RC2 +3 build already? I was under
the impression I still had until 5pm CET but I see the build already running
on Hudson?

I have held off for the discussion on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=409019, but would still like
to make the change in MPC to disable remediation.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] RC2 build already on its way?

[Carsten Reckord]

David M Williams david_willi...@us.ibm.com wrote:

The build runs continuously (when ever someone makes a change to
their 
b3aggrcon file). So, yes, you do have until 5 PM today to contribute. 

Thanks, and done. Sorry for the noise. I got confused by the 
kepler.epp-package-build job that was running at the time and the earlier 
lockForPromotion. That sounded so final ;)
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Heads up - new MPC version

[Carsten Reckord]

Hi everybody,

I'm the new committer on the Marketplace Client project and I'm looking
forward to working on it and with all of you for at least Kepler and the
following service releases. This is my first ride on the release train and
I've only just jumped on, so please be patient with me ;)

My first order of business is to let you know that MPC will update its
contribution to Kepler M6 from 1.1.1 to 1.2.0.


For MPC 1.2, a couple of bugs have been fixed, but the more important
changes are regarding user experience:

- It should be clearer now, that you can select more than one solution at a
time (bug 337774)
- Install counts and star ratings are shown (bug 323259)

And last but not least
- A News tab has been added that will show the latest and greatest from
eclipse.org (or your 3rd-party marketplace) (bug 401721).


No public API was changed (what little there is). The internal API contains
one breaking change in org.eclipse.epp.mpc.core that might hit 3rd-party
extenders: a method has been added to the class
org.eclipse.epp.internal.mpc.core.service.MarketplaceService for the new
News REST API.


I'm sorry for the late notification, but since no other project on the train
seems to have code dependencies on the MPC bits I hope that it won't be a
problem. I'll update the aggregation files and project plan later today.


Best regards,
Carsten

-- 
Carsten Reckord
  t  +49 561 5743277-33
  f  +49 561 5743277-8833
  e  reck...@yatta.de

Yatta Solutions GmbH
  Registered seat: Kassel
  Amtsgericht Kassel, HRB 14720
  VAT-ID DE263191529

Management:
  Johannes Jacop,
  Dr. Christian Schneider

Address:
  Ludwig-Erhard-Straße 12
  34131 Kassel
  Germany

Contact:
  t  +49 561 5743277-0
  f  +49 561 5743277-88
  e  i...@yatta.de
  w  www.yatta.de

Bank account:
  Kasseler Bank eG
  IBAN DE89 5209   1583 05
  BIC GENODE51KS1

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