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
Received on Wed Jan 24 19:42:07 2007