Comment 1 Dani Megert 2010-03-22 06:21:55 EDT

I would only expect to see this warning (when using -debug):

!ENTRY org.eclipse.osgi 2 0 2010-03-22 11:08:52.559
!MESSAGE The following is a complete list of bundles which are not resolved,
see the prior log entry for the root cause if it exists:
!SUBENTRY 1 org.eclipse.osgi 2 0 2010-03-22 11:08:52.559
!MESSAGE Bundle org.eclipse.equinox.common_3.6.0.v20100315 [215] was not
resolved.
!SUBENTRY 2 org.eclipse.equinox.common 2 0 2010-03-22 11:08:52.559
!MESSAGE Another singleton version selected:
org.eclipse.equinox.common_3.6.0.v20100317

i.e. it should not cause errors when I have two versions of the same bundle.

Comment 2 Thomas Watson 2010-03-22 09:50:49 EDT

Does Eclipse not start for you in this case?  Eclipse starts fine and I do not see the org.eclipse.swt.SWTException: Widget is disposed error in my log.

Also, it seems like you do have debug enabled because of the beginning printouts about the configuration location etc.

Comment 3 Dani Megert 2010-03-22 09:53:52 EDT

Yes, it comes up and I use -debug.

Comment 4 Thomas Watson 2010-03-22 12:51:06 EDT

(In reply to comment #3)
> Yes, it comes up and I use -debug.

OK, so your issue is that every startup you see the exception logged because we are trying to start both versions of the bundle and one of them cannot resolve.  The framework is attempting to exactly what simpleconfigurator told it to do, which is:

1) install both versions of common
2) set the start-level of both versions to 2
3) persistently start both versions of the bundles so they are restarted every time the framework is relaunched.

When launching we increment the start-level of the framework which causes the persistently started bundles to (attempt to) start.  Since the common bundle is a singleton only one of the versions can be resolved.  When trying to start both versions of the bundle we will get a BundleException for starting one of the common bundles (again we are only doing this because simpleconfigurator told us to start both).  This causes a FrameworkEvent of type ERROR to be published.  This event is required by the OSGi specification to be fired any time we get a failure to start one of the persistently started bundles.

There is nothing the framework can do to avoid firing this event without violating the specification.  The only thing we could do is somehow decide not to log this FrameworkEvent ERROR, but I am against that because it would be a hack to log some ERRORs but not others.

I'm going to move to PDE-UI for now because I am not sure how it decides what bundles to configure into the bundles.info for p2 (it could very well be a p2 bug that is creating an invalid bundles.info).  The bottom line is I would not expect the bundles.info to ever contain two versions of a singleton bundle.

Comment 5 Dani Megert 2010-03-22 13:14:57 EDT

re comment 4: interesting read! So you're saying some bundles (mainly OSGi ones)  have to throw the error but others (e.g. 'org.eclipse.core.filebuffers') don't throw an error if two versions are present?

Comment 6 Thomas Watson 2010-03-22 13:39:04 EDT

(In reply to comment #5)
> re comment 4: interesting read! So you're saying some bundles (mainly OSGi
> ones)  have to throw the error but others (e.g. 'org.eclipse.core.filebuffers')
> don't throw an error if two versions are present?

Sorry for the confusion.  No that is not what I am saying.  I am saying that any bundles that are persistently started with eager start policy (not lazy start) are eagerly started when the framework start-level is set on launch.  These bundles will cause FrameworkEvents of type Error if they fail to start eagerly with some exception.  Bundles that use the lazy start activation policy (such as org.eclipse.core.filebuffers) will end up with some class loader errors if they fail to start lazily on first class load.  So the difference is what the activation policy is for the bundle (eager vs. lazy).

Comment 7 Thomas Watson 2010-03-22 14:41:30 EDT

Also notice that if you don't do step 4 from comment 0 to change the version then you get an even more strange bundles.info with something like this for equinox.common

org.eclipse.equinox.common,3.6.0.v20100315,file:/Users/watson/Documents/workspaces/test/bug306684/org.eclipse.equinox.common/,2,true
org.eclipse.equinox.common,3.6.0.v20100315,file:/Users/watson/Documents/workspaces/test/bug306684/org.eclipse.equinox.common_3.6.0.v20100315/,2,true

For more information see bug 306375.

Comment 8 Jeff McAffer 2010-03-29 09:48:49 EDT

I get this quite frequently with targets that have the same bundle in them twice. Really the target should eliminate duplicates. Certainly ones that have the same version and BSN.  

For cases where the version is different I suggest selecting the latest one and leaving other UNselected. People who actually want both versions can go and manually select more. The common cases IMHO is for people to want just one.

Comment 9 Darin Wright 2010-04-08 17:39:36 EDT

Needs investigation.

Comment 10 Jeff McAffer 2010-04-14 12:31:01 EDT

I just hit this in a new way in i0413

I recently updated to the latest build for both the IDE and my target. By accident I was still pointing to the M6 RCP SDK in the Helios repo as well as the RCP SDK in the I-Build repo.  The result was that a project using SWT's Display class had compile errors saying that Device.dispose() was not accessible due to access restrictions. (Device is a superclass of Display but in a different package...) This code and manifest markup has been that way for quite some time and never a problem.

In the course of investigating the problem I found the duplicate SWT jar on the classpath. Fixing the target to have only one version addressed the compile problem.

There should be some things we can do to eliminate duplicates.

For example, it is extremely unlikely that one could use two versions of the same bundle on the classpath for the same plugin.  That just should not happen.

Similarly, it is very unlikely that people want targets that have two versions of the same bundle. It is possible but for the vast majority of cases, if there are two in the same target, one of them is wrong/not needed.

If there are two versions of a bundle in the same target that are singletons, only one of them can be used.

It would help greatly if impossible cases could be eliminated and users warned about duplicates and enabled to fix them.

Comment 11 Darin Wright 2010-04-26 14:31:02 EDT

Looking at the code and testing confirms that PDE automatically removes duplicates if the BSN *and* version are the same. However, if different versions of the same bundle (same BSN) exist, they both end up in the state (and we attempt to launch both in bundles.info).

The simplest fix is probably to have the load target job choose the highest version of a bundle when mulitple versions of a singleton are present, and to allow multiple versions of bundles that are not singletons (to support multiple versions of junit, for example). (Or if the use explicitly selects one version of a bundle, we of course use that one).

Making the duplicate resolution scheme visible in the UI is probably more work (i.e. in the target platform preference page), and may not be feasible in 3.6.

Comment 12 Darin Wright 2010-05-10 14:46:43 EDT

Created attachment 167779 [details]
patch

I agree that there is an error case which would be nice to avoid/report to the user when > 1 singleton is added to the target. However, for RC1, such error reporting (in the target editor/pref page/or bundle manifests for workspace projects), feels like feature work.

Thus, to reduce risk for RC1 I've enhanced "Validate Plug-ins" on the launch tab to report when more than 1 version of singleton is present.

I will open a new enhancement request for adding more error reporting/validation in target definition/resolution.

Comment 13 Darin Wright 2010-05-10 14:47:09 EDT

please review, Curtis.

Comment 14 Jeff McAffer 2010-05-10 17:10:50 EDT

I assume that this validate is on the target somehow?

If so, can there be a "select only latest" option when there are duplicates?  It is again problematic and error prone to make users validate, remember what was a problem, hunt around to fix the ones they remember, revalidate/repeat.  The tooling knows the problem ones and we know that 80-90% of the time the right thing to do is remove the lower versioned ones...

Comment 15 Darin Wright 2010-05-10 22:22:31 EDT

(In reply to comment #14)
> I assume that this validate is on the target somehow?

No, the original bug reported by Dani was related to launching, and the fix (assistance) we have put in is when validating bundles in a launch configuration.

> If so, can there be a "select only latest" option when there are duplicates? 
> It is again problematic and error prone to make users validate, remember what
> was a problem, hunt around to fix the ones they remember, revalidate/repeat. 
> The tooling knows the problem ones and we know that 80-90% of the time the
> right thing to do is remove the lower versioned ones...

I opened bug 312321 for this, beacuse it really is feature work that should not be happening in RC1.

Comment 16 Jeff McAffer 2010-05-11 14:59:18 EDT

(In reply to comment #15)
> No, the original bug reported by Dani was related to launching, and the fix
> (assistance) we have put in is when validating bundles in a launch
> configuration.

Will the same validation happen on products?

Comment 17 Darin Wright 2010-05-11 16:38:45 EDT

(In reply to comment #16)
> Will the same validation happen on products?

This fix only validates launch configurations. Added comment to bug 312321.

Comment 18 Curtis Windatt 2010-05-11 18:10:39 EDT

Created attachment 168058 [details]
Improved Patch

Comment 19 Curtis Windatt 2010-05-11 18:13:06 EDT

Darin's fix worked fine for me, but I updated the fix to avoid creating a wrapper class just to pass a severity around.  Instead we just pass a status object.

Darin, please review and apply the updated fix.

Comment 20 Darin Wright 2010-05-12 11:29:07 EDT

+1 Applied/Fixed.

Comment 21 Darin Wright 2010-05-12 11:30:10 EDT

(fixed)

Comment 22 Dani Megert 2010-05-18 10:46:21 EDT

Verified in N20100517-2000: PDE now reports it when launching, so I guess we can mark it VERIFIED. Unfortunately inexperienced users won't notice it immediately because plug-in validation is off by default, see bug 272076.

Is it expected that when I have with same version, I get this in the console/log:

Could not start: org.eclipse.equinox.common(reference:file:/C:/eclipse/workspaces/tmp2/org.eclipse.equinox.common_3.6.0.N20100517-2000/:63). It's state is uninstalled.

The error message sounds a bit strange to me.

Test Case:
1. start with new workspace
2. import 'org.eclipse.equinox.common' as binary plug-in
3. import 'org.eclipse.equinox.common' as binary plug-in again without deleting
   the first one
4. launch target Eclipse

Comment 23 Curtis Windatt 2010-05-18 11:04:37 EDT

*** Bug 296105 has been marked as a duplicate of this bug. ***