[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Greeting,
Me and a mate encountered the same issue. In our project we needed to use the model
plugin within our own code and we couldn't reach it.
What we did is create a new plug-in 3.2 project, and copied manually sources, dependencies etc and
rebuilt the plugins. So far it does work fine.
If that can be of any use for you you can find our plugins sources there http://ta-stl.infop6.jussieu.fr/svn/pro3bpel/plugins/
and jar there http://ta-stl.infop6.jussieu.fr/svn/pro3bpel/plugins/BPLE-TA-Install/.
This is our personal svn and i'am not sure how long it'll be available tho.
Hope that help
- francois & nicolas
>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
