Even if they're OSGi bundles I think you would still need to unpack them
if they have embedded jars.
Eugene Kuleshov wrote:
>
> In this case it is probably better to break subclipse.core plugin into
> core and two client plugins (javahl and svnkit) and only unpack the
> clients or better make them OSGi bundles, which would only take to
> change manifest file in the jar.
>
> regards,
> Eugene
>
>
> Roy Paterson wrote:
>> :-) I have done that and it works fine - but it's irritating - all
>> the other plugins I depend on work fine with the PDE in the normal way
>> without having to build them from source.
>>
>> I agree that this is obviously a limitation in the PDE since it works
>> in the runtime, but I think it's good practice at runtime to unpack
>> the plugin jar as well. I think I remember hearing that there were
>> performance issues with the Eclipse classloader loading code from
>> jars-within-jars, and this was one of the main reasons (besides
>> backwards compatibility) that they made the "unpack" option configurable.
>>
>> Regards,
>> Roy
>>
>> Eugene Kuleshov wrote:
>>> Roy,
>>>
>>> You can also checkout Subclipse projects from SVN and work with the
>>> sources.
>>>
>>> And in a mean time bug the PDE guys to fix this stupid limitation. :-)
>>>
>>> regards,
>>> Eugene
>>>
>>>
>>> Roy Paterson wrote:
>>>> I write a product called Code Collaborator that includes an Eclipse
>>>> plugin which integrates with Subclipse - see
>>>> http://www.codecollaborator.com
>>>>
>>>> In the latest code (1.1.x stream) the core plugin is delivered as a
>>>> single jar file instead of being "unpacked". This works at runtime
>>>> but at development time I have difficulty using the Eclipse PDE to
>>>> integrate my plugin with Subclipse.
>>>>
>>>> I am seeing a host of issues, all of which are solved by removing
>>>> the unpack="false" attribute in the feature.xml:
>>>>
>>>> 1) If the Subclipse core plugin is specified in the target platform
>>>> then the PDE does not put the core plugin's embedded jars on the
>>>> java classpath (Plug-in Dependencies classpath container) of a
>>>> plugin that requires it. My plugin needs some of the classes in
>>>> those jars to compile (specifically SVNUrl from
>>>> svnClientAdapter.jar). If I launch an Eclipse runtime from the PDE
>>>> with this configuration Subclipse works correctly.
>>>>
>>>> 2) If I import the Subclipse core plugin in to my workspace as a
>>>> "Binary Project" the I see the opposite effect - the PDE creates a
>>>> project and puts the embedded jars on it's classpath, but omits the
>>>> main
>>>> core jar (so the classes at the root of the plugin jar are not
>>>> found). If I launch an Eclipse runtime from the PDE with this
>>>> configuration Subclipse works correctly.
>>>>
>>>> 3) If I import the Subclipse core plugin in to my workspace as a
>>>> "Project with source folders" then the PDE resolves it correctly -
>>>> the main plugin jar and all the embedded jars are put on the
>>>> classpath and my code compiles fine. However if I launch an
>>>> Eclipse runtime from the PDE with this configuration Subclipse does
>>>> not work correctly. When I try to open the "SVN Repository
>>>> Exploring" perspective I get an error and the following log:
>>>>
>>>> !MESSAGE An error occurred while automatically activating bundle
>>>> org.tigris.subversion.subclipse.core (142).
>>>> !STACK 0
>>>> org.osgi.framework.BundleException: The activator
>>>> org.tigris.subversion.subclipse.core.SVNProviderPlugin for bundle
>>>> org.tigris.subversion.subclipse.core is invalid
>>>>
>>>> -------------
>>>>
>>>> So basically I am at an impasse - I can either make my code compile,
>>>> or make Subclipse work in the target runtime, but I need both! The
>>>> fix is to remove the unpack="false" attribute from the Subclipse
>>>> core plugin in the feature.xml. This fixes all of the issues
>>>> mentioned above.
>>>>
>>>> Please let me know how I can help make this happen.
>>>>
>>>> Thanks,
>>>> Roy Paterson
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>>> For additional commands, e-mail: dev-help@subclipse.tigris.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>> For additional commands, e-mail: dev-help@subclipse.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Wed Jan 24 19:46:34 2007