Community
Participate
Working Groups
Build Identifier: org.eclipse.babel.nls_eclipse_de 3.5.0.v20091121043401 There are several translation fragments have other fragments as their fragment host, e.g. org.eclipse.code.net.win32.x86.nl_de has org.eclipse.core.net.win32.x86 as a fragment host (which is itself a fragment). If I understand the OSGi specification correctly, a fragment must have a bundle as a fragment host. I agree that such a declaration makes sense semantically (since the translation fragment contains translations for Strings only available in the referenced fragment), but I think it is illegal from an OSGi point of view. PDE seems to see it the same way - when trying to export a feature containing such a fragment, the build runs into an error because it cannot locate the host bundle (it's probably only searching in the pool of available bundles, not the fragments). Reproducible: Always
In addition to failing to export such a feature, I can't even run a launch configuration containing such a fragment (in Eclipse Indigo).
In OSGi 4.3 the desired result (that fragments only attach when other fragments are already attached) can be achieved by having "host fragment" provide some capability and "fragment fragment" require it.
For the Indigo release, this problem of translation fragments referencing other fragments as their hosts occurs for many translations and makes the translation packages unusable for our RCP application. Is there any know workaround for Eclipse 3.7 or any work-in-progress regarding this bug?
Just as a clarification: For me, the problem occurs when I try to export the RCP product from within Eclipse 3.7.
In the current design of Babel, we check out all source files for the project from CVS repository and extract all Java properties files for translation. We don't have the information whether the plugin is a fragment or not. There is no easy and complete way to fix this. Luckily, seems like the Eclipse project is following a naming convention and use the "osgi.os" and "osgi.arch" in the plugin names in most cases. For example, the "org.eclipse.core.net.win32.x86_64" plugin is for the Fragment-Host "org.eclipse.core.net" with Eclipse-PlatformFilter: (& (osgi.os=win32) (osgi.arch=x86_64)) It may not be a fool-proof solution, but I can try to add some logics to add the Eclipse-PlatformFilter to the plugins falling into this pattern. I found one exception to the scenario so far. The Fragment-Host for "org.eclipse.compare.win32" is not "org.eclipse.compare". "org.eclipse.compare.win32" is a code plugin itself with a Eclipse-PlatformFilter: (osgi.os=win32). I have to work around this problem.
I released a fix to add "Eclipse-PlatformFilter" to fragment for fragment. Please try the language packs at: http://build.eclipse.org/technology/babel/babel_language_packs/I20110917-0400/indigo/indigo.php
*** Bug 361124 has been marked as a duplicate of this bug. ***
There are still some babel fragments that generates error when building the product. I'm listing them bellow: 1. <plugin id="org.eclipse.core.runtime.compatibility.registry.nl_de" fragment="true"/> 2. <plugin id="org.eclipse.ecf.provider.filetransfer.httpclient.ssl.nl_de" fragment="true"/> 3. <plugin id="org.eclipse.ecf.provider.filetransfer.ssl.nl_de" fragment="true"/> 4. <plugin id="org.eclipse.ecf.ssl.nl_de" fragment="true"/> 5. <plugin id="org.eclipse.jdt.compiler.apt.nl_de" fragment="true"/> 6. <plugin id="org.eclipse.jdt.compiler.tool.nl_de" fragment="true"/>
Calin, could you provide more details about the problems you see? Anyway, if it's not a fragment for fragment problem reported in this bug, you should open a separate bug report for that. Thanks!
It is the same problem with babel translations for fragments of a fragment. That's the reason I have added a comment to this bug. Unfortunately I could not reopen it. Babel translations listed above (see my previous comment) trigger the impossibility to Export the Product. I'm using Babel R 0.9.1 but I've tried also with the latest release.
Calin, we still do not have enough information to reproduce the problem. Could you please provide a step-by-step scenario for us to debug the problem? Are you aware of anything missing or anything wrong with the language packs? Are there anything different from what you expect to see?
Taking as an example the Babel translation for org.eclipse.core.runtime.compatibility.registry.nl_de . This is a fragment for the org.eclipse.core.runtime.compatibility.registry, which is again a FRAGMENT. Unfortunately the Bebel fragment for org.eclipse.core.runtime.compatibility.registry.nl_de does not have the "Eclipse-PlatformFilter" fix. Because of this I cannot export my product. Steps to reproduce: 1. Have eclipse 3.7.2 2. Have Babel language pack for German- version R 0.9.1 2.1. The same behavior exists also with the latest Babel build 3. Create one simple Application - use the Mail Template 4. Create a product for this application 5. Goto Dependencies tab and manually add in the product (if it does not exist) the fragment org.eclipse.core.runtime.compatibility.registry 6. Select your Mail.plugin and press button "Add required plugins" 7. Make sure that the org.eclipse.core.runtime.compatibility.registry.nl_de is added as a dependency 8. Goto Overview tab from your product definition and call "Eclipse product export wizard". Expected results: The export is performed correctly Actual Results: An error is thrown and the export stops. The same behavior exists for all the other listed plugins. I'll list them again bellow: 1. <plugin id="org.eclipse.core.runtime.compatibility.registry.nl_de" fragment="true"/> 2. <plugin id="org.eclipse.ecf.provider.filetransfer.httpclient.ssl.nl_de" fragment="true"/> 3. <plugin id="org.eclipse.ecf.provider.filetransfer.ssl.nl_de" fragment="true"/> 4. <plugin id="org.eclipse.ecf.ssl.nl_de" fragment="true"/> 5. <plugin id="org.eclipse.jdt.compiler.apt.nl_de" fragment="true"/> 6. <plugin id="org.eclipse.jdt.compiler.tool.nl_de" fragment="true"/> I hope that now you have enough data to reproduce the bug. Cheers, Calin
Hi, Did you managed to reproduce the behavior?
Calin, I did more investigation. First of all, those plugin fragments you listed in comment 12 are not platform dependent fragments. They cannot be fixed by adding "Eclipse-PlatformFilter". Secondly, I found that those plugin fragments do not contain any translatable files or strings besides the plugin fragment names. Will it solve your problem if we exclude these plugin fragments from the Eclipse language packs?
Hi, The solution proposed in comment 14 is excellent. Could you please tell me the babel version that will have this fix? Thanks.
Please try the latest build from: http://build.eclipse.org/technology/babel/babel_language_packs/
