Bug 314193

Comment 1 Mirko Raner 2010-05-25 01:59:05 EDT

From bug 309899, comment #19:

> One simple way doing so could be an Eclipse-PlatformFilter in MANIFEST.MF,
> similar to what we do for the WinCE / tm.rapi plugins today:
> 
> Eclipse-PlatformFilter: (& (osgi.os=win32) (osgi.arch=x86))
> 
> but negated of course since we'd want to EXCLUDE windows. The caveat of this
> approach is issues like bug 236026, but I think that p2's error reporting has
> improved in the meanwhile. Still this would be subject to testing. Also, the
> terminal.local feature description would need changing to reflect the fact that
> the feature is not available on Windows.
> 
> Another drawback is that disabling it entirely is a pity if it does work OK
> with mingw or cygwin. But that's more subject to testing.

Without having a Windows machine handy I can already say that it's very unlikely that the local terminal would work properly for Cygwin or MinGW. This would require a Cygwin/MinGW-specific Spawner and PTY implementation, similar to what was implemented for bug 248071. The native Spawner/PTY library would have to be compiled and linked specifically against the Cygwin/MinGW terminal API.

Comment 2 Mirko Raner 2010-05-25 02:37:02 EDT

Created attachment 169771 [details]
Patch to disable Local Terminal Connector on Windows

Given that interfacing with cmd.exe is difficult because Windows has no proper terminal API and that no Spawner/PTY implementation has been created for Cygwin/MinGW yet, the best for now is probably to disable this feature on Windows platforms.

The attached patch uses standard LDAP syntax for disabling the feature if osgi.os is win32. I was not able to actually test this because I don't have a Windows machine right now.

From previous experience with platform-specific features I recall that it was also necessary to add platform attributes to the site.xml of the update site, for example:

<site>
 <feature id="org.eclipse.tm.terminal.local"
  url="..."
  version="0.1.0"
  os="macosx, linux"
  ws="carbon, cocoa, gtk"
  arch="x86, x86_64"
  nl="en_US">
  <category name="...
 ...

I am not sure whether this is still necessary with the new P2 update site format or how it would be specified.

Comment 3 Martin Oberhuber 2010-05-27 06:58:38 EDT

Created attachment 170166 [details]
Patch that also disables the feature

Attached patch also disables the "win32" OS in the feature as well as the update site XML. I'm not yet fully convinced that this is the right approach, but I'm going to try how this feels with today's I-build.

Comment 4 Martin Oberhuber 2010-05-27 07:00:10 EDT

Released for I20100527. 
Marking FIXED for now, pending verification.

Comment 5 Martin Oberhuber 2010-05-27 09:44:34 EDT

Sigh... as expected, this is messy. With the changes released, our builder says:

The following error occurred while executing this line:
/opt/public/dsdp/tm/ws2/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.0.v20100428/scripts/genericTargets.xml:107: Unable to generate source (org.eclipse.tm.terminal.local.source) from binary bundle org.eclipse.tm.terminal.local_0.1.0.v201005271100.

What a nice understandable errormessage, pointing to the root cause and giving help how to fix the problem :(

Comment 6 Martin Oberhuber 2010-05-27 10:44:14 EDT

Sigh... removing the "os" property of the "plugin" included in the feature.xml was not sufficient. Source could be built with that removed, but the feature was not built on build.eclipse.org.

So, try 3... this time with feature.xml completely reverted, and the win32 speciality only exposed in site.xml and MANIFEST.MF.

Comment 7 Martin Oberhuber 2010-05-28 05:21:28 EDT

Sigh... with the feature completely reverted, and the OS limitation only in MANIFEST.MF and the site.xml, the "Local Terminal" feature is not properly hidden when installing on Windows.

Trying to select it results in a p2 error message that doesn't help understanding or fixing the problem:

Cannot complete the install because one or more required items could not be found.
  Software being installed: Local Terminal (Incubation) 0.1.0.v201005271445-41A78y8DfD-IAL88B883222 (org.eclipse.tm.terminal.local.feature.group 0.1.0.v201005271445-41A78y8DfD-IAL88B883222)
  Missing requirement: Local Terminal (Incubation) 0.1.0.v201005271445-41A78y8DfD-IAL88B883222 (org.eclipse.tm.terminal.local.feature.group 0.1.0.v201005271445-41A78y8DfD-IAL88B883222) requires 'org.eclipse.tm.terminal.local [0.1.0.v201005271100]' but it could not be found

This is essentially the same problem as I've been seeing for WinCE on Linux (documented in bug 236026). For WinCE, the issue was not that bad sine we don't provide WinCE on the Helios aggregated site. For the local terminal, which would like to see on the Helios site, this is a real problem. I'll be trying to see how the Linux Tools project, which ran into similar issues, finally solved this.

p2 is not entirely innocent in this dilemma, since a good error message should be more like "Cannot complete the install because one or more requirements could not be met. Feature "Local Terminal" includes bundle "org.eclipse.tm.terminal.local" which has constraints that cannot be met on this host."

Comment 8 Mirko Raner 2010-05-28 14:51:37 EDT

Thanks for trying all that. This seems to be way harder than it should be.

Can you point your update manager to the update site at http://eclipsemultitch.sourceforge.net on a Windows or Linux machine and check whether the feature shows up? It's a little utility plug-in to make use of Multi-Touch touch-pads on Mac laptops and it should only be installable on Mac OS. As far as I remember, I only made modifications to the site.xml to exclude non-Mac platforms. If this feature is properly hidden on Windows/Linux we can maybe use it as a guideline of how to solve our problem.

Also, could we enlist help from someone who has successfully created a platform-specific feature and who might guide us how to properly solve this? I don't know anyone off the top of my head, but I imagine there must be plenty of platform-specific Eclipse features out there by now. Any ideas?

Comment 9 Martin Oberhuber 2010-05-28 15:06:08 EDT

The Eclipsemltitch displays and installs on Windows, so that's not the solution. I have already asked Andrew Overholt from the Linuxtools project for guidance. They are in a similar situation since most of their stuff works on Linux only.

It looks like p2 is limited, as per bug 236026 comment 19, and the best that can be done at the moment is tweaking the feature such that a proper error message is printed. Unfortunately in my case, this led to not building the feature any more. I keep investigating.

Comment 10 Martin Oberhuber 2010-05-28 15:21:32 EDT

Created attachment 170418 [details]
patch (try 4) disabling feature like linuxtools does

I have installed the Linuxtools LTTng feature, and this patch sets up the terminal.local feature likewise: that is, removing the source plugin from the feature, and using a "Linux only" os setting on both plugin and feature in the feature.xml.

I'm going to run a test build with this. Although the p2 user experience is not overwhelming with this either, it is better than what we have at the moment... trying to install Linuxtools on Windows, it says:

Cannot complete the install because some dependencies are not satisfiable
  org.eclipse.linuxtools.lttng.feature.group [0.2.0.201005261305] cannot be installed in this environment because its filter is not applicable.

Comment 11 Martin Oberhuber 2010-05-29 06:31:37 EDT

I'm marking this FIXED with Mirko's original patch, since this patch resolves the main issue of showing UI elements that don't work (regardless of how the local terminal got installed).

I have opened bug 314977 to track the remaining issue of improving the error message when trying to install local terminal from Helios onto Windows. The "install from Helios" experience is less severe than the "installed something bad" experience. Also, it's not entirely our fault, and it will potentially require migrating to the new Athena builder.