Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] MPC not opening with space in install path - requesting respin

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 | reckord@xxxxxxxx | 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


Back to the top