Community
Participate
Working Groups
We should consider using Eclipse PlatformFilter headers [1] to prevent problems with RAP installed into the IDE (bug 276000). The current solution of adding a fake dependency to "A.PDE.Target.Platform", as suggested in bug 276000, has the disadvantage to prevent adding dependencies to our feature, which in turn blocks bug 338528. I suggest that we define a new windowing system, e.g. osgi.ws=rap. The affected RAP bundles whould declare a platform filter in their bundle manifest and thus they would never be activated on the desktop anymore. The RAP target platform would have to define this new osgi.ws property. We already did some experiments and found that this approach works well. Compared to p2-based solutions (such as bug 306709, comment 10+), this it would eliminate our problems entirely and reliably. I think that the concept of platform filters is a good fit because RAP can be thought of as a windowing system of its own. [1] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html
Created attachment 190285 [details] Version 1 The provided patch defines platform filter (osgi.ws=rap) for RAP bundles which can case conflicts when they are installed into a desktop application. I used following criteria to identify conflicting bundles: * conflicting extension points * conflicting export packages
Created attachment 190878 [details] Version 2 I reviewed the patch with Holger and we decided to remove the PlatformFilters from: * org.eclipse.equinox.registry: is no more included into RAP-target * org.eclipse.rap.rwt.q07: is fragment and can't run without its host which defines the PlatformFilters
All relevant runtime bundles now have the platform filter (osgi.ws=rap) set in their MANIFEST.MF. From now on, the Equinox parameter -ws (or the system property osgi.ws) *must* be set to "rap" in order to run a RAP application. If this setting is missing, the windowing system will be derived from the runtime environment (i.e. the operating system) and the RAP runtime bundles will not start. When running RAP from the Eclipse IDE, the launcher sets the -ws parameter to ${target.ws} by default. Therefore, the "Windowing System" should be set to "rap" in the target platform. We will add documentation (bug 338834) and tooling support (bug 338817, bug 338818) to assist with this new requirement. Hopefully this will resolve all our "RAP in the IDE" problems... Changes are in CVS HEAD.
You also may want to ensure what happens in the deployment scenario. eg. building a war and deploying it into Tomcat. This will be a major break between older versions as you need to prepare the right environment in your web.xml / config.ini / wherever.
>You also may want to ensure what happens in the deployment scenario. A good point Benny. There are plans to extend the WAR Products tooling to support the RAP's windowing system. The WARs generated for RAP will include into their web.xml the "-ws rap" program argument.
(In reply to comment #4) Filed bug 339676 against War Products. web.xml in war build and demo feature have been adapted.
Has anyone tested this with PDE Build and products using the Equinox Jetty HttpService including the native launcher? Those builds require the WD set to the one required by the launcher which would be GTK, Win32, etc.
OK, as I suspected, this change breaks PDE RAP product builds in two ways. 1. If I specify "rap" as WS in the target platform the native launcher and the launcher fragment jar are missing. 2. If I export the product for multiple platforms I get an exception/error: --- Processing inclusion from feature org.eclipse.gyrex.features.dependencies.admin: Bundle org.eclipse.rap.jface_1.4.0.qualifier failed to resolve.:" --- The bundle fails to resolve because I'm exporting my server for the win32 platform using the win32 launcher. Is there any chance this change can be rolled back? I do understand the importance of the "RAP in IDE" issue but this change is very drastic. I also think it's just another workaround for a flaw in p2. Isn't it possible to generate this platform requirement into the p2 metadata of each bundle but not into the bundle manifest?
Hi Gunnar, first of all, I'm sorry for the bad timing. We should have announced this change earlier before M6. We thought about it for a long time and talked to different people and simply did not expect real problems. So if nothing helps, we'll may have to roll back. However, I don't see the windowing system as a workaround, for me it feels like the natural solution to the problem, which is that SWT/desktop and RWT/server bundles cannot co-exist, just like code for different windowing systems could not coexist. RWT is just another implementation of SWT, so you can't put both into the same platform. Regarding PDE build, we use a headless PDE build to build RAP, including a demo application, without problems. But using a launcher to start a RAP server was something we never considered. If I understand it correctly, this includes mixing RWT and SWT in the same running platform, doesn't it? Wouldn't it be better to start the server as a process of it's own, with its own bundle pool?
(In reply to comment #9) > Regarding PDE build, we use a headless PDE build to build RAP, including a demo > application, without problems. But using a launcher to start a RAP server was > something we never considered. If I understand it correctly, this includes > mixing RWT and SWT in the same running platform, doesn't it? Actually, SWT is not involved. The issue is that the eclipse.exe (even if launched without splash screen) still depends on the window system. I doubt that the Equinox team can rework the launcher packaging to provide a headless launcher for each os/arch combination that will work without a ws.
On the other hand, if it's just me (a significant small minority) that you guys should not roll back. Did the RAP in IDE issue occurred again recently? I thought it was fixed with the target platform dependency hack?
Well, that's an unexpected problem. I'm not sure how many users might be affected. If it's everyone using the "Embedded Jetty in Equinox", then we have a problem and should probably roll back this change for M6. However, this is only about the clickable eclipse.exe, it's still possible to start equinox headless without the fragment. Maybe we can find some solution that allows to use a native launcher but let it pass the rap ws to the started Equinox instance? I still believe that the restriction we introduce with the rap ws makes sense. I seem to remember that Ekke reported a RAP in the IDE again recently. Ekke, can you confirm this? We also tried a p2-based approach (bug 306709), but that's not trivial, not ready for production because of missing declarative support (bug 312937) and would it break the simultaneous build (bug 313873). Meanwhile, I'd prefer a solution at OSGi level, not p2 level, because this would also address the problem at runtime - where it actually happens. Just like dependencies are resolved by p2 but also checked by OSGi, such conflicts should be checked by OSGi - with platform filters, they can be prevented at runtime AND deployment time. Even if the RAP runtime is installed into a dropins folder, platform filters will take effect.
Runtime enforcements are a good thing. I'm just not sure that the osgi.ws property is the right thing. Technically, RAP is not the window system on the server but on the browser (like GWT). So a server can run multiple (RAP, GWT & SWT control ui [1]). [1] We do have a customization that installs an SWT tray icon when the server is started in order to allow easy/convenient lifecycle control.
Interesting. Just goes to show that you never know all the uses. I looked at this idea when it was first discussed and thought it was ok but now in light of comment 8, I am broken for Toast as well. (Not that Toast is a critical system but it is the example in the Equinox book so presumably some number of people who read the book will be doing the same thing). That is, building/deploying RAP in Jetty on Equinox is not IMHO a fringe case. Having said that, figuring some way to have ws=rap AND get the executable/launcher fragments feels like the right path. Unfortunately, I don't see that happening in the short term. There are likely all manner of implicit assumptions that the executable/launcher WS is the same as the SWT WS and that the WS matters for executable/launcher build and packaging. Summary: I think we were too late with this change and it should be rolled back. Changing the importance to major to reflect the impact. (unless you want to open a new bug about this)
Thanks for your insights on this, Jeff and Gunnar. I have rolled back the changes for now to avoid breaking clients with M6. Still hoping that we'll find a solution soon as this problem also prevents us from improving our build. I leave this bug open as enhancement request.
fwiw, I raised this topic in the Equinox call yesterday. There was general agreement that it sucks that your approach did not work. The problem is more general and around producing headless products. We suspect that executables etc all work fine with no gui but the build/packaging and delivery workflows are making assumptions. We'd like to address this but it is unlikely to happen for Indigo. I opened a bug in Equinox to drive that approach and marked it as blocking this bug.
(In reply to comment #16) > I opened a bug in Equinox to drive that approach and marked it as > blocking this bug. Looks like you accidentally removed it. Re-added reference to bug 340066.
D'oh! Thanks.
Thank you Jeff for opening bug 340066. Will be great if we can discuss this issue at EclipseCon. (In reply to comment #16) > fwiw, I raised this topic in the Equinox call yesterday. There was general > agreement that it sucks that your approach did not work. The problem is more > general and around producing headless products. We suspect that executables > etc all work fine with no gui but the build/packaging and delivery workflows > are making assumptions. We'd like to address this but it is unlikely to happen > for Indigo. I opened a bug in Equinox to drive that approach and marked it as > blocking this bug.
(In reply to comment #12) > ... > > I seem to remember that Ekke reported a RAP in the IDE again recently. Ekke, > can you confirm this? > sorry for late answer - stepped just today through bugzillas... yes, after many months without RAP in the IDE it happened again, so I was happy that you found a way to prevent this but of course if this breaks other kind of builds it's no solution at the moment the only workaround for me is, after installing / updating to check the plugins folder and manually remove the rap plugins
Thanks for following up on this! Still looking forward to make this happen, even if after Indigo!
We finally have a working solution to prevent RAP from being installed into the IDE, based on p2 expressions (bug 385512). The platform filters approach is not needed anymore.
