Community
Participate
Working Groups
This is from a discussion in the buckminster newsgroup http://www.eclipse.org/forums/index.php?t=msg&th=198947&start=0&S=9d335ad54985c6c181ff6b9679691ce5. One of my problems was that some bundles got damaged during signing and in the end they were missing from the generated p2 site. In org.eclipse.equinox.p2.publisher.eclipse.BundlesAction there is a method getBundleDescriptions() that creates some metadata by reading the manifests of the given files (jars). In my bad cases (signed nls fragments or a signed springsource bundle with nested jars) the bundle manifest was not a valid OSGi manifest (it had an empty first line). In these cases the BundleDescription was null. The generated content.xml and artifacts.xml both do not include the bundles with a null BundleDescription. The missing IUs are mentioned in the metadata repository as requirements of other IUs and the actual (although damaged) artifact can be found in the bundles/ folder. As a user one just notices that one cannot install the final product because "there is no repository containing" the bad bundle. I think the publisher should fail if it cannot read a manifest or should at least output a warning.
Peter do you have the copy of such a bundle handy that I could use for test purpose. thx
I have tried to produce a small example but unfortunately failed (see the newsgroup thread for details as to where this happens).
Tobias could you please take a look at this and see if you can provide a patch for RC1. If not feel free to defer to 3.8. Thx
The publishers seem to be very lenient about all kinds of problems in the data sources. I agree that they should be more strict in general, but I don't know if anyone relies on the current behaviour. Therefore I would rather address this early in 3.8, allowing for time to react on valid use cases for the lenient behaviour.
Move all 3.8 bugs to Juno.
It's not clear if changing the publisher at this stage is a good idea. I'll move this out. If others feel different, please feel free to put this on Kepler.
Created attachment 224739 [details] proposed patch including test case to apply, use 'git am <patch>' test added and existing tests still passing as far as I can tell
Created attachment 224793 [details] proposed patch including test case
@Pascal: I hope you don't mind that I submit the patch. Should also be easier from an IP process point of view :-)
Patch submitted: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=ae3f93aef90e280a1711da4ac11342c011ba480d @Jan: Thank you for the contribution.
(In reply to comment #9) > @Pascal: I hope you don't mind that I submit the patch. Should also be > easier from an IP process point of view :-) Thanks for taking care of this Tobias. The IP was not really my concern. I just wanted to take the time to review the changes, but the fact you did it is even better :) Thanks for the patch Jan.
