Eclipse Community Forums: Plugin Development Environment (PDE) » Multiple versions of library wrapper plugins

Help

Home

Home » Eclipse Projects » Plugin Development Environment (PDE) » Multiple versions of library wrapper plugins

Show: Today's Messages :: Show Polls :: Message Navigator

Multiple versions of library wrapper plugins [message #35885]

Thu, 04 December 2008 18:04

Eclipse User

Originally posted by: eclipse-news.rizzoweb.com

In our RCP application we have a number of "JAR wrapper" bundles
(created with the "Plug-in from existing JAR" project wizard).
Unfortunately, they were originally created and distributed with
qualifiers in their versions, so the versions look like
3.2.0.200809231150. When we do new builds, those plugins get built, too,
using new version numbers like 3.2.0.200812040800 and included in our
update site.

When I do an update from the previous version of our app to a new one
using a just-built update site, it correctly updates everything and
restarts. Upon restart, all of our "real" plugins load the latest
version only (according to Help > About > Plug-in Details) as expected,
but all of those JAR wrapper plugins end up showing up twice, both the
old versions and the new ones.

Can anyone explain why both versions get loaded at runtime? I've checked
and when we express dependency on them we specify the version without
the qualifier (as in 3.2.0), so I don't know what could be triggering
the load of the old versions.
Any ideas? Help debugging?

Thanks in advance,
Eric

Report message to a moderator

Re: Multiple versions of library wrapper plugins [message #35919 is a reply to message #35885]

Thu, 04 December 2008 18:07

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

But are they hurting anything? Usually the framework picks only one
when it has singleton:=true as an attribute on the symbolic name

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.platform.doc.isv/guide/workbench.htm

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Multiple versions of library wrapper plugins [message #35950 is a reply to message #35919]

Thu, 04 December 2008 20:49

Eclipse User

Originally posted by: eclipse-news.rizzoweb.com

On 12/4/2008 1:07 PM, Paul Webster wrote:
> But are they hurting anything? Usually the framework picks only one
> when it has singleton:=true as an attribute on the symbolic name

Setting singleton:=true does not seem to make any difference.
I should mention that the product is based on Eclipse 3.3, not 3.4.

Is there a way to debug what is causing the old version of the wrapper
plugin to get loaded?

Eric

Report message to a moderator

Re: Multiple versions of library wrapper plugins [message #36159 is a reply to message #35950]

Fri, 05 December 2008 17:28

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

This is a multi-part message in MIME format.
--------------030903090904010404070506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

You can turn on a lot of information about where OSGi thinks it is
loading its classes from using the osgi tracing. You can extract the
org.eclipse.osgi .options file and edit it to suit your tastes (I've
attached mine here).

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclips e.platform.doc.isv/guide/workbench.htm

--------------030903090904010404070506
Content-Type: text/plain;
name="osgi.options"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="osgi.options"

#### Debugging options for org.eclipse.osgi

# Turn on general debugging for org.eclipse.osgi
org.eclipse.osgi/debug=true
# Prints out class loading debug information
org.eclipse.osgi/debug/loader=true
# Prints out event (FrameworkEvent/BundleEvent/ServiceEvent) and listener debug information
org.eclipse.osgi/debug/events=false
# Prints out OSGi service debug information (registration/getting/ungetting etc.)
org.eclipse.osgi/debug/services=false
# Prints out bundle manifest parsing debug information
org.eclipse.osgi/debug/manifest=false
# Prints out LDAP filter debug information
org.eclipse.osgi/debug/filter=false
# Prints out security (PermissionAdmin service) debug information
org.eclipse.osgi/debug/security=false
# Prints out start level service debug information
org.eclipse.osgi/debug/startlevel=false
# Prints out package admin service debug information
org.eclipse.osgi/debug/packageadmin=true
# Prints out timing information for bundle activation
org.eclipse.osgi/debug/bundleTime=false
# Debug the loading of message bundles
org.eclipse.osgi/debug/messageBundles=false

# Eclipse adaptor options
org.eclipse.osgi/eclipseadaptor/debug = false
org.eclipse.osgi/eclipseadaptor/debug/location = false
org.eclipse.osgi/eclipseadaptor/debug/platformadmin=false
org.eclipse.osgi/eclipseadaptor/debug/platformadmin/resolver =false
org.eclipse.osgi/eclipseadaptor/converter/debug = false

### OSGi resolver options
# Turns on debugging for the resolver
org.eclipse.osgi/resolver/debug = false
# Prints out wiring information after the resolver has completed the resolve process
org.eclipse.osgi/resolver/wiring = false
# Prints out Import-Package information
org.eclipse.osgi/resolver/imports = false
# Prints out Require-Bundle information
org.eclipse.osgi/resolver/requires = false
# Prints out debug information form the "uses" clause
org.eclipse.osgi/resolver/uses = false
# Prints out cycle information
org.eclipse.osgi/resolver/cycles = false
# Prints out Eclipse-GenericRequire information
org.eclipse.osgi/resolver/generics = false

#### Profile settings
org.eclipse.osgi/profile/startup = false
org.eclipse.osgi/profile/benchmark = false
org.eclipse.osgi/profile/debug = false

# Override the default implemenation
org.eclipse.osgi/profile/impl = org.eclipse.osgi.internal.profile.DefaultProfileLogger

# Append all profile messages to the filename specified
org.eclipse.osgi/defaultprofile/logfilename =

# Output all profile log messages synchronously to the jvm console.
# By default, all log messages are cached until the log buffer is
# requested.
org.eclipse.osgi/defaultprofile/logsynchronously = false

# Specify the size of the default profile implementation log buffer.
org.eclipse.osgi/defaultprofile/buffersize = 256

#### Monitoring settings
# monitor class loading
org.eclipse.osgi/monitor/classes=true

# monitor bundle activation
org.eclipse.osgi/monitor/activation=false

# monitor resource bundle (*.properties) loading
org.eclipse.osgi/monitor/resources=false

#### Trace settings
# trace class loading - snapshot the execution stack when a class is loaded
org.eclipse.osgi/trace/classLoading=false

# trace location - file in which execution traces are written
org.eclipse.osgi/trace/filename=runtime.traces

# trace filters - Java properties file defining which classes should
# be traced (if trace/classLoading is true)
# File format:
# plugins=<comma separated list of plugins whose classes to trace>
# packages=<comma separated list of package prefixes of classes to trace>
# Note that there may be many 'plugins' and 'packages' lines in one file.
org.eclipse.osgi/trace/filters=trace.properties

# trace bundle activation - snapshot the execution stack when a bundle is activated
org.eclipse.osgi/trace/activation=false

--------------030903090904010404070506--

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Multiple versions of library wrapper plugins [message #586469 is a reply to message #35885]

Thu, 04 December 2008 18:07

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Multiple versions of library wrapper plugins [message #586486 is a reply to message #35919]

Thu, 04 December 2008 20:49

Eric Rizzo

Messages: 3070
Registered: July 2009

Senior Member

On 12/4/2008 1:07 PM, Paul Webster wrote:
> But are they hurting anything? Usually the framework picks only one
> when it has singleton:=true as an attribute on the symbolic name

Setting singleton:=true does not seem to make any difference.
I should mention that the product is based on Eclipse 3.3, not 3.4.

Is there a way to debug what is causing the old version of the wrapper
plugin to get loaded?

Eric

Report message to a moderator