Community
Participate
Working Groups
Build Identifier: The bundles.info file is not updated when new fragment was added. Reproducible: Always Steps to Reproduce: 1. Put the feature into the dropins folder, run eclipse and everything just fine. 2. Added a new fragment which contains some classes for extending the host plugin. 3. Remove the whole folders of the feature inside the dropins folder. 4. Re-export the feature and unzipping to the dropins folder. Problem: The bundles.info was not updated to show the new fragment. Manually added the fragment inside the bundles.info resolved the problem. This proved that the fragment has no problem, but the p2 manipulator has issue under this case.
Could you please provide a test features and bundles.
Since the original project is not from me. It's a project of my friend, who asked me for some helps of his RCP project. I can't upload his project here. I made some try and found something might be related. 1. See attached org.project.test feature and plug-in. Exports the feature into into dropings/Test folder. The plug-in can be picked up correctly. See help about dialog. But I didn't see the feature be list there. Not sure if it's normal, but the plug-in works all right. 2. Create a fragment, e.g. attache org.project.test.fragment. Exports the fragment into dropings/Test/plugins as Jar file. It works all right. In the bundles.info file, there's no line org.project.test.fragment,1.0.0,dropins/Test/plugins/org.project.test.fragment_1.0.0.jar,4,false 3. Since the requirements need put a file inside the fragment, so it must be folder instead of folder. I deleted the org.project.test.fragment_1.0.0.jar and exports the fragment as folder. Copy the org.project.test.fragment_1.0.0 folder into the dropings/Test/plugins. Re-run the eclipse and found the line in the bundles.info file is still org.project.test.fragment,1.0.0,dropins/Test/plugins/org.project.test.fragment_1.0.0.jar,4,false. 4. But if the time stamp qualifier uses in the version, then the line will be updated correctly. I think this because every export creates a newer version of plug-in, which will trigger the updating of the bundles.info file. Hope this is helpful.
Created attachment 182581 [details] Test projects
Thx for the details and the test case. Your description reveals the problem. Since the version does not change, p2 does not detect that a new IU has been laid down since it solely look at bundle id and bundle version to detect changes. The solution consists in making sure a new version is published every time.
Well it's hard to say that. The jar file has been changed to a folder. It's hard to say this must be a new version. Also not every team likes the time stamp version format, which I have seen quite a few. Do you know if there's a way to force updating the bundles.info file?
Without changing the version the only way is to first delete the file, restart, unzip the new file, restart.
(In reply to comment #6) > Without changing the version the only way is to first delete the file, restart, > unzip the new file, restart. That's what I did. Steps to Reproduce: ... 3. Remove the whole folders of the feature inside the dropins folder. 4. Re-export the feature and unzipping to the dropins folder. I remove the only folder in the dropins folder. Unzip the new package and start the eclipse. It failed.
I'm not sure this is something we want to support: a change (even a bundle shape change) without a version increment. There are likely caches all over the place that will not get properly invalidated since they version did not change. Having said that, you can try to relaunch with the -clean argument.
Thanks for the reply. I understand that you don't want to support this in general. But it might be useful if we have a way to force updating the bundles.info, e.g. a command line option or so. I'll try the -clean argument and if it works, then at least there's one way to force it. (In reply to comment #8) > I'm not sure this is something we want to support: a change (even a bundle > shape change) without a version increment. There are likely caches all over > the place that will not get properly invalidated since they version did not > change. > > Having said that, you can try to relaunch with the -clean argument.
