Community
Participate
Working Groups
Created attachment 100899 [details] Logfile with the exceptions Build ID: I20080516-1333 (3.4rc1) During the initial build of my workspace after upgrading to I20080516-1333, I saw attached exception in my .log: java.lang.NullPointerException at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.checkBundleVersionsOfReexportedBundles(BaseApiAnalyzer.java:232) at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.checkApiComponentVersion(BaseApiAnalyzer.java:1257) at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.analyzeComponent(BaseApiAnalyzer.java:198) at org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.build(ApiAnalysisBuilder.java:607) [...] The interesting thing is that I'm not aware of reexporting anything. Dbl clicking on the corresponding entry in the "PDE Runtime Error Log" view threw another NPE from jface -- see attached .log: java.lang.NullPointerException at org.eclipse.ui.internal.views.log.EventDetailsDialog.updateProperties(EventDetailsDialog.java:344) at org.eclipse.ui.internal.views.log.EventDetailsDialog.createDialogArea(EventDetailsDialog.java:500) at org.eclipse.jface.dialogs.Dialog.createContents(Dialog.java:760) at org.eclipse.jface.window.Window.create(Window.java:431) at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089) at org.eclipse.ui.internal.views.log.EventDetailsDialog.create(EventDetailsDialog.java:173) at org.eclipse.ui.internal.views.log.EventDetailsDialogAction.run(EventDetailsDialogAction.java:96) at org.eclipse.ui.internal.views.log.LogView$15.doubleClick(LogView.java:512) [...]
The second NPE is a different problem that should be reported against jface.
(In reply to comment #1) > The second NPE is a different problem that should be reported against jface. Olivier could you be so kind and create the bug against jface? At this point I don't really have a clue what's jface related here and what to describe.
PS actually my feeling was that perhaps some properties were missing from the API Tooling NPE and that led to the jface NPE... there are other entries in my Error Log on which I can successfully dbl click, but on some I can't.
The first NPE is possible if the baseline doesn't contain the reexported bundle. In this case it is not possible to diagnose anything and we should ignore the reexported bundle.
(In reply to comment #2) > Olivier could you be so kind and create the bug against jface? At this point I > don't really have a clue what's jface related here and what to describe. Done. See bug 232857. There is nothing I can really describe as I have no clue what has been done to get it.
Could you please give me the baseline contents that you used to get the NPE? Thanks.
(In reply to comment #6) > Could you please give me the baseline contents that you used to get the NPE? My baseline was TM 2.0.3 from an extension location that only contained the TM downloads (RSE-SDK-2.0.3, TM-discovery-2.0.3). EMF is not part of that baseline, so you're likely right that the baseline did not contain the bundle in question. I'd just like to mention, again, that my bundles are *not* re-exporting anything.
> (In reply to comment #7) > I'd just like to mention, again, that my bundles are *not* re-exporting > anything. sure, sure :-). tm.discovery.model.edit is reexporting emf.edit :-). See the manifest.mf: org.eclipse.emf.edit;bundle-version="[2.2.0,3.0.0)";visibility:=reexport, So I do have a fix for it if I consider that I cannot do the reexport check when reexported bundles cannot be found in the baseline.
Created attachment 101114 [details] Proposed fix Case where the baseline doesn't contain all the reexported bundles. In this case we cannot check that the versions of the reexported bundles has an impact on the version of the current bundle.
Darin, Michael, please review.
Shiver me timbers! I did not notice this in the Manifest. It's the only reexport we have in all our codebase. God alone knows why the initial commiter put this ugly beast in there! Getting rid of the reexport would be a breaking change, right? My feeling is that nobody should reexport anything... or is there any guideline? Can you give advice? On a different note, given that this particular reexport uses a wide version range: My feeling is that an API change between baseline and current that's only inherited through the reexport should not trigger a version update request. Because current baseline / workspace diff _might_ have a change in reexported API, but the version range on the import does not require it. But this comment should probably go into bug 230178...
(In reply to comment #11) > I did not notice this in the Manifest. It's the only reexport we have in all > our codebase. God alone knows why the initial commiter put this ugly beast in > there! Getting rid of the reexport would be a breaking change, right? No, you cannot remove the export now. If someone has a dependency on tm.discovery.model.edit without having a dependency on emf.edit at the same time, all the types from emf.edit could not be resolved anymore. > My feeling is that nobody should reexport anything... or is there any > guideline? Can you give advice? I don't have definite answer for this. Maybe John could help here. John, what is the policy for reexporting bundles ? > On a different note, given that this particular reexport uses a wide version > range: My feeling is that an API change between baseline and current that's > only inherited through the reexport should not trigger a version update > request. Because current baseline / workspace diff _might_ have a change in > reexported API, but the version range on the import does not require it. But > this comment should probably go into bug 230178... Once your bundle reexports a bundle, all APIs of the reexported bundles are also exposed through your bundle. So you should update the major/minor version in a consistent manner regarding your reexported bundles changes.
(In reply to comment #12) > No, you cannot remove the export now. If someone has a dependency on > tm.discovery.model.edit without having a dependency on emf.edit at the same > time, all the types from emf.edit could not be resolved anymore. Sure. But we're doing a major release this time around so I think I'd rather get rid of the reexport now... still waiting for a word from John about reexports in general. > Once your bundle reexports a bundle, all APIs of the reexported bundles are > also exposed through your bundle. So you should update the major/minor version > in a consistent manner regarding your reexported bundles changes. As mentioned, I think that whether I need to update my major/minor depending on the reexported bundle should *only* depend on the version range specification in the Manifest, nothing else. See my comment on bug 230178.
There is no guideline written anywhere on re-exports that I know of. It's one of those issues that doesn't fit nicely into any of our API guideline docs. The current recommendation on the Eclipse top-level project is to never use re-exports. The only valid case I can think of for using re-export is when you split a bundle into multiple bundles. In this case for compatibility the original bundle must re-export the bundle that contains the split content. For example when we split org.eclipse.ui into multiple bundles, and later the same with org.eclipse.core.runtime, the original bundles re-exported all the pieces that were split out. Thus an existing bundle that just imports org.eclipse.ui or org.eclipse.core.runtime still has access to all the same API.
Thanks John. I filed bug 233068 to get rid of our ugly reexport.
+1 RC2
applied patch
verified
