[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Thanks for the response. I did figure something out yesterday. The BPEL
plug-ins are all version 3.0, with the exception of
org.eclipse.bpel.runtimes, which is 3.2. It appears as though the nested
jar was the standard way of packaging plug-ins in 3.0 and it has changed
since then. I am fairly new to Eclipse plug-in development and was not
aware of this. I have been using 3.2.2.
I will continue to look into this and will follow up on the list when I have
more information.
Thanks.
-Jon
On 3/28/07 11:44 AM, "Michal Chmielewski" <michal.chmielewski@xxxxxxxxxx>
wrote:
> Jonathan,
>
> Interesting .... never heard of this ... but since someone did write it
> appears that there must have been some good reason for it.
>
> We can change the packaging to not create the code.jar as the plugin's
> code library ... we'd like to ideally keep the plugins themselves as
> .jar files but I reckon this is not the problem.
>
> I suppose you could pull the current code, alter it yourself and see if
> it fixes your problem.
>
> -michal
>
> Jonathan Coogan wrote:
>> Hello. I am trying to repackage portions of the Eclipse BPEL Editor within
>> an RCP application. One obstacle I am facing is the packaging of the BPEL
>> plug-ins. Most of them are bundled as JARs that contain a 2nd JAR file
>> (code.jar). I believe this is sometimes called "bundling by wrapping." The
>> problem is that I have been unable to compile or run my own plug-ins against
>> the BPEL plug-ins.
>>
>> I might be missing something, but much of the documentation I have found on
>> plug-in development indicates that this bundling scheme can be problematic.
>> Here is a passage from an RCP book I have:
>>
>> "It is technically possible to run a JAR'd plug-in that has nested JARs on
>> the classpath. Such nested JARs are automatically extracted and cached by
>> the OSGi framework. As noted earlier, this effectively duplicates the
>> amount of disk space required for the plug-in. More significantly, however,
>> the tooling (both PDE and JDT) is unable to manage classpaths that include
>> nested JARs. The net result is that while your plug-in runs, it takes more
>> space and others cannot compile against it."
>>
>> Can someone on the list provide some insight as to why the BPEL plug-ins are
>> bundled like this? Any work-arounds or suggestions for my predicament?
>>
>> Thank you.
>> -Jon
>>
>>
>>
>>
>> _______________________________________________
>> bpel-dev mailing list
>> bpel-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/bpel-dev
>>
>
