Bug 329507

Comment 1 Pascal Rapicault 2010-11-05 06:46:59 EDT

Could you please provide a test features and bundles.

Comment 2 Qiangsheng Wang 2010-11-07 18:34:03 EST

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.

Comment 3 Qiangsheng Wang 2010-11-07 18:40:02 EST

Created attachment 182581 [details]
Test projects

Comment 4 Pascal Rapicault 2010-11-09 22:17:47 EST

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.

Comment 5 Qiangsheng Wang 2010-11-09 22:33:46 EST

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?

Comment 6 Pascal Rapicault 2010-11-09 22:59:52 EST

Without changing the version the only way is to first delete the file, restart, unzip the new file, restart.

Comment 7 Q.S. Wang 2010-11-10 01:34:34 EST

(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.

Comment 8 Ian Bull 2010-11-12 14:58:27 EST

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.

Comment 9 Qiangsheng Wang 2010-11-13 18:07:03 EST

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.