:-) 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
Received on Wed Jan 24 19:12:58 2007