Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3 Build Identifier: 20090920-1017 When using a custom target platform containing the junit4 bundle, exporting a plugin causes said plugin to be faulty: Instead of a normal bundle, the resulting jar seems to be just the zipped up project directory (with .class files residing in bin/). The .java files are in src/, and there is a .settings file. Another thing is that the qualifier part in the bundle name is not replaced by a date string. Since this is not a valid OSGi bundle, subsequent uses of the bundle fail. The export works just fine when using the "Running platform" as target platform. I observed this issue only with junit4, but it may be applicable to other bundles as well. A serious factor is that this corruption is silent, which is especially worrisome for automated builds. Using eclipse-rcp-galileo-SR1-linux-gtk Reproducible: Always Steps to Reproduce: 1. Create new minimal plug-in project 2. Add require-bundle dependency on junit4 to above bundle 3. Export plugin -> resulting file is a "good" bundle "foo_1.0.0.200910211417.jar" 4. setup a minimal custom target platform containing only the junit4 bundle (extra directory + .target file) 5. Set the created target as active target platform 6. Export plugin -> resulting file is a broken bundle "foo_1.0.0.qualifier.jar" that exhibits above mentioned faulty directory structure When using the attached test case, only steps 5 & 6 need to be executed.
Created attachment 150104 [details] Test case that exhibits the behaviour (tested on linux & windows)
It seems the underlying issue is that the bundle org.hamcrest is missing from the target platform. Adding it causes the export to produce a valid bundle. The observed issue that the bundle is silently created faultily is still unresolved. I would expect one of the following behaviours in the original case: a) Since the transitive dependencies are not used, the export succeeds, creating a valid bundle in the process. b) The export fails, and an error dialog is opened detailing which bundle is required for the export to proceed ("org.hamcrest" in this case). A faulty jar is _not_ created. This would IMHO be the preferable solution.
This is working in 3.6 and creates a valid bundle. Part of the changes for bug 203270 helped here, but even reverting those fixed lines do not reproduce the bug (you instead get an error message about being un-resolved). So there are probably two problems, the first is that we weren't using dev mode to resolve the state used for export (this would allow foo to resolve even when junit's dependencies weren't satisfied). I have not yet identified the problem that causes the faulty result. This is not specific to junit, but applies when you depend on something that does not have its requirements satisfied.
This is also caused by bug 252711 (fixed in 3.6) where an unresolved bundle is being used when we expected a resolved bundle. The side effect of the bundle being unresolved is that it ends up being treated as a binary bundle would and is just copied to the results.
Created attachment 150155 [details] patch
Darin, I plan on releasing this to 3.5.2. The fixes are already in HEAD.
+1
done
Wow, impressive response time. Thanks for the prompt fix. I suppose it should show up in the 3.5.1 M Builds next week? What would be the required effort to create a regression test for this scenario (possibly used in 3.6 as well) ?
There is already a regression test in head for bug 252711, I believe it covers the main source of the problem here which was the unresolved bundle being returned when we expected a resolved bundle.
I retested using eclipse-SDK-M20091104-0800-linux-gtk and verified that the results are good. Thanks again for getting on this so quickly!
