[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
A final update on this topic --
This is definitely a restriction for 3rd party developers who want to code
against the BPEL plug-ins. The passage I quoted in my first email is pretty
much dead-on. Plug-ins that contain nested JARs work at runtime because the
OSGi framework extracts and caches them, but it is difficult to develop
against such plug-ins without the sources. The PDE and JDT components
cannot resolve plug-in classes that reside in a nested JAR.
I found 2 workarounds for this:
1. Include the BPEL plug-in sources in my workspace. This allows Eclipse
to resolve the classes correctly and build/export without errors.
2. Use reflection to interact with the BPEL classes. This works because it
doesn't require any compile-time dependencies on the nested classes.
I also experimented with extracting code.jar from one of the BPEL plug-ins
and adding it to my project classpath as an external library. This worked
within the Eclipse IDE but failed to export.
Perhaps it was naïve of me to think that I could develop a BPEL RCP
application at this point in time without touching any of the Eclipse BPEL
sources, but I think that is a worthy goal. It would be nice if the BPEL
plug-ins were rebundled at some point, either as simple jars or directories.
I think this would make it easier for outside developers like myself to
build on top of the great work you guys are doing.
Thanks for reading.
-Jon
On 3/28/07 1:07 PM, "Jonathan Coogan" <Jonathan.Coogan@xxxxxxxxxxxxxx>
wrote:
> 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
>>>
>>
>
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
