| Automated PDE build fails to build fragment/plugin combo [message #263822] |
Mon, 26 July 2004 16:23  |
Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
Well, once again I am hoping someone can help me out here...
I have modeled a plugin/fragment wrapper around some JNI code &
libraries in exactly the way the SWT/SWT.win32 plugin/fragment works.
I created a plugin, my.plugin.wrapper, and then I created a fragment -
my.plugin.wrapper.win32. The fragment contains all of the .dll's (in
/os/win32/x86/) and the jar file (in /ws/win32/myjar.jar).
Now - if I have this plugin and fragment in my workspace, all of my
dependent plugins (requiring my.plugin.wrapper) see the API contained
within the jar file and work fine. However, if I try to run my
automated build - it fails to compile my plugins depending on
my.plugin.wrapper because it can't resolve any of the classes contained
in the jar file provided by the fragment.
NOW - if I manually copy the "/ws/win32/myjar.jar" tree from the
fragment into the plugin dir which uses it (so I now have
my.plugin.wrapper/ws/win32/myjar.jar) - all of the dependent plugins
compile. What the heck? Shouldn't this resolve through to the "ws" dir
found in the fragment? Isn't that what a fragment is for? Here is what
my manifest.mf looks like for my wrapper plugin:
Manifest-Version: 1.0
Bundle-Name: %pluginName
Bundle-Vendor: %providerName
Bundle-SymbolicName: my.plugin.wrapper; singleton=true
Bundle-Version: 0.0.2
Bundle-ClassPath: $ws$/myjar.jar
Bundle-Localization: plugin
Eclipse-AutoStart: true
Provide-Package: my.api.package.in.the.jarfile
And the manifest.mf for the fragment is:
Manifest-Version: 1.0
Bundle-Name: %fragmentName
Bundle-SymbolicName: my.plugin.wrapper.win32; singleton=true
Bundle-Version: 0.0.2
Bundle-Vendor: %providerName
Fragment-Host: my.plugin.wrapper;bundle-version="[0.0.2,1.0.0)"
Bundle-Localization: fragment
Any help would be much appreciated.
On another note - when I actually get it to compile by copying the jar
file over to the plugin, the build still utlimately fails during the
gather.bin.parts stage of the fragment with the following error:
\my.plugin.wrapper.win32\@dot not found.
Any ideas on this one?
Thanks,
Mark.
|
|
|
| Re: Automated PDE build fails to build fragment/plugin combo [message #263831 is a reply to message #263822] |
Mon, 26 July 2004 17:32  |
| Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
More information...running the build in verbose mode yields the following:
[javac] Using JDT compiler
dropping
<my_build_path>\eclipse\plugins\my.plugin.wrapper\ws\${ws}\myjar.jar
from path as it doesn't exist
dropping
<my_build_path>\eclipse\plugins\my.plugin.wrapper.win32\ws\${ws}\myjar.jar
from path as it doesn't exist
dropping <my_build_path>\eclipse\plugins\my.plugin.wrapper.win32\@dot
from path as it doesn't exist
SO - it looks like it is *trying* to do something right - but the
automated build can't resolve ${ws} across fragments, or @dot for that
matter. I'm thinking these are bugs. If I don't get a response from a
PDE guru, I guess I'll go file a bug.
Thanks,
Mark.
Mark Melvin wrote:
> Well, once again I am hoping someone can help me out here...
>
> I have modeled a plugin/fragment wrapper around some JNI code &
> libraries in exactly the way the SWT/SWT.win32 plugin/fragment works.
>
> I created a plugin, my.plugin.wrapper, and then I created a fragment -
> my.plugin.wrapper.win32. The fragment contains all of the .dll's (in
> /os/win32/x86/) and the jar file (in /ws/win32/myjar.jar).
>
> Now - if I have this plugin and fragment in my workspace, all of my
> dependent plugins (requiring my.plugin.wrapper) see the API contained
> within the jar file and work fine. However, if I try to run my
> automated build - it fails to compile my plugins depending on
> my.plugin.wrapper because it can't resolve any of the classes contained
> in the jar file provided by the fragment.
>
> NOW - if I manually copy the "/ws/win32/myjar.jar" tree from the
> fragment into the plugin dir which uses it (so I now have
> my.plugin.wrapper/ws/win32/myjar.jar) - all of the dependent plugins
> compile. What the heck? Shouldn't this resolve through to the "ws" dir
> found in the fragment? Isn't that what a fragment is for? Here is what
> my manifest.mf looks like for my wrapper plugin:
>
> Manifest-Version: 1.0
> Bundle-Name: %pluginName
> Bundle-Vendor: %providerName
> Bundle-SymbolicName: my.plugin.wrapper; singleton=true
> Bundle-Version: 0.0.2
> Bundle-ClassPath: $ws$/myjar.jar
> Bundle-Localization: plugin
> Eclipse-AutoStart: true
> Provide-Package: my.api.package.in.the.jarfile
>
> And the manifest.mf for the fragment is:
>
> Manifest-Version: 1.0
> Bundle-Name: %fragmentName
> Bundle-SymbolicName: my.plugin.wrapper.win32; singleton=true
> Bundle-Version: 0.0.2
> Bundle-Vendor: %providerName
> Fragment-Host: my.plugin.wrapper;bundle-version="[0.0.2,1.0.0)"
> Bundle-Localization: fragment
>
> Any help would be much appreciated.
>
>
> On another note - when I actually get it to compile by copying the jar
> file over to the plugin, the build still utlimately fails during the
> gather.bin.parts stage of the fragment with the following error:
>
> \my.plugin.wrapper.win32\@dot not found.
>
> Any ideas on this one?
>
> Thanks,
> Mark.
|
|
|
| Re: Automated PDE build fails to build fragment/plugin combo [message #263836 is a reply to message #263831] |
Mon, 26 July 2004 17:48 |
| Eclipse User |
|
|
|
Originally posted by: mark.melvin.dspfactory.com
Hmm... Explicitly specifying configs=win32,win32,x86, and renaming my
assemble targets appropriately has caused the resolution of the jarfile
to work (the automated build now can resolve the ${ws} alias in my
fragment classpath).
The only problem now is the "@dot" issue. The build fails in the
"gather.bin.parts" target of my fragment with:
\my.plugin.wrapper.win32\@dot not found.
Getting closer...has anyone come across this problem? I only found one
other reference to it with no responses, and no discussion in Bugzilla -
just that it was "fixed in last yesterday's build". But I think the bug
I found (Bug 66839) is a different animal altogether.
Mark.
Mark Melvin wrote:
> More information...running the build in verbose mode yields the following:
>
> [javac] Using JDT compiler
> dropping
> <my_build_path>\eclipse\plugins\my.plugin.wrapper\ws\${ws}\myjar.jar
> from path as it doesn't exist
> dropping
> <my_build_path>\eclipse\plugins\my.plugin.wrapper.win32\ws\${ws}\myjar.jar
> from path as it doesn't exist
> dropping <my_build_path>\eclipse\plugins\my.plugin.wrapper.win32\@dot
> from path as it doesn't exist
>
> SO - it looks like it is *trying* to do something right - but the
> automated build can't resolve ${ws} across fragments, or @dot for that
> matter. I'm thinking these are bugs. If I don't get a response from a
> PDE guru, I guess I'll go file a bug.
>
> Thanks,
> Mark.
>
> Mark Melvin wrote:
>
>> Well, once again I am hoping someone can help me out here...
>>
>> I have modeled a plugin/fragment wrapper around some JNI code &
>> libraries in exactly the way the SWT/SWT.win32 plugin/fragment works.
>>
>> I created a plugin, my.plugin.wrapper, and then I created a fragment -
>> my.plugin.wrapper.win32. The fragment contains all of the .dll's (in
>> /os/win32/x86/) and the jar file (in /ws/win32/myjar.jar).
>>
>> Now - if I have this plugin and fragment in my workspace, all of my
>> dependent plugins (requiring my.plugin.wrapper) see the API contained
>> within the jar file and work fine. However, if I try to run my
>> automated build - it fails to compile my plugins depending on
>> my.plugin.wrapper because it can't resolve any of the classes
>> contained in the jar file provided by the fragment.
>>
>> NOW - if I manually copy the "/ws/win32/myjar.jar" tree from the
>> fragment into the plugin dir which uses it (so I now have
>> my.plugin.wrapper/ws/win32/myjar.jar) - all of the dependent plugins
>> compile. What the heck? Shouldn't this resolve through to the "ws"
>> dir found in the fragment? Isn't that what a fragment is for? Here
>> is what my manifest.mf looks like for my wrapper plugin:
>>
>> Manifest-Version: 1.0
>> Bundle-Name: %pluginName
>> Bundle-Vendor: %providerName
>> Bundle-SymbolicName: my.plugin.wrapper; singleton=true
>> Bundle-Version: 0.0.2
>> Bundle-ClassPath: $ws$/myjar.jar
>> Bundle-Localization: plugin
>> Eclipse-AutoStart: true
>> Provide-Package: my.api.package.in.the.jarfile
>>
>> And the manifest.mf for the fragment is:
>>
>> Manifest-Version: 1.0
>> Bundle-Name: %fragmentName
>> Bundle-SymbolicName: my.plugin.wrapper.win32; singleton=true
>> Bundle-Version: 0.0.2
>> Bundle-Vendor: %providerName
>> Fragment-Host: my.plugin.wrapper;bundle-version="[0.0.2,1.0.0)"
>> Bundle-Localization: fragment
>>
>> Any help would be much appreciated.
>>
>>
>> On another note - when I actually get it to compile by copying the jar
>> file over to the plugin, the build still utlimately fails during the
>> gather.bin.parts stage of the fragment with the following error:
>>
>> \my.plugin.wrapper.win32\@dot not found.
>>
>> Any ideas on this one?
>>
>> Thanks,
>> Mark.
|
|
|
Powered by
FUDForum. Page generated in 0.03675 seconds
Home