| Exporting "Deployable plugin with AspectJ support" yields plugin with aspects missing [message #68687] |
Thu, 30 November 2006 08:24  |
Eclipse User |
|
|
|
I am having a major problem generating a "Deployable Plug-in with
AspectJ support":
I have an eclipse plugin project (it also has the "AspectJ nature") that
contains about 10 aspects, i.e. .aj files. The project also has a lib
directory which contains about 12 .jar files that are used by my
application. Into 3 of these 12 .jar files aspects are woven by the
above aspects (these .jar files are therefore also listed on the AspectJ
inpath tab).
Everything compiles fine and I can start and execute the plugin using an
eclipse runtime workbench, which also works perfectly.
Now I want to bundle things up into some easy deployable form. So I
choose File => Export... => Deployable Plug-in with AspectJ support.
I select the plugin, enter the name of an archive file (say:
myplugin.zip) and hit "Finish".
Obviously at this point the files in the project are not simply packed
up into the target .zip file, but an entire rebuild takes place first.
At the end the .zip file is generated and - as I checked - contains all
files (including the .jar files in the lib directory).
But when I then take that generated .zip and unpack it into the target
system's eclipse directory and then start eclipse and execute the plugin
I get runtime errors like:
---------------------
java.lang.NoSuchMethodError: myPlugin/MyClass.markChanged()V
at
myPlugin/observability.ObservableAspect.ajc$interMethodDispa tch1$myPlugin_observability_ObservableAspect$myPlugin_MyClas s$markChanged(ObservableAspect.aj)
at
myPlugin.observability.ObservableAspect.ajc$afterReturning$m yPlugin_observability_ObservableAspect$2$4511a4b8(Observable Aspect.aj:76)
at ...
---------------------
markChanged() is one of these methods that should have been woven into
the 3 mentioned jars in lib. So, apparently, these methods are now
lacking and have NOT been woven into the .jar files by that last build
triggered by the export.
What am I missing or doing wrong here? Any ideas? Workarounds?
Michael
Ps.: This is on eclipse 3.2.1 and with the latest AJDT 1.4.1.
|
|
|
|
| Re: Exporting "Deployable plugin with AspectJ support" yields plugin with aspects missing [message #68826 is a reply to message #68724] |
Thu, 07 December 2006 06:39  |
| Eclipse User |
|
|
|
Originally posted by: spyoung.uk.ibm.com
The JARs in to which you are weaving are only the source and are not
modified; the new classes (i.e. the woven versions) are output either to
your Eclipse project's bin directory (look on the filesystem, rather
than in Eclipse) or to your project's outjar, if you have one specified.
It is from one of these locations that the runtime workbench picks up
the woven code.
I've added some comments/advice/suggestions to your bug 166765 which
relates to this issue.
Cheers,
Steve
Michael Moser wrote:
> I just did an "experiment" and the result left me stunned:
>
> I rebuilt things and ran the plugin in the runtime workbench. As I
> wrote, here everything works fine. While that workbench was executing I
> copied the 3 .jar files that are supposed to contain the weaved-in
> aspect code out into a temp. directory. So, at this moment the aspects
> should have been correctly woven into the .jar files - at least that's
> what I had thougth. From that temp. directory I copied them into the
> .zip file that the previous export had generated (thereby overwriting
> the .jars that were originally packed into the .zip).
>
> That modified .zip I then transferred to the target system's eclipse
> directory, unpacked it and started eclipse and with it my plugin. To my
> surprise I get the same errors re. missing methods. So, the aspects
> aren't really woven into the .jar's at all and now I'm really puzzled!
> When and how are these aspects woven into the code before the runtime
> workbench executes? And where does the aspect code come from, because
> obviously it is in the executing code, but has NOT been in the .jar
> files from which it was loaded!?!
>
> And how would I weave AspectJ code into .jar files, i.e. actually modify
> those jars?
>
> Michael
>
>
>
>
>
|
|
|
| Re: Exporting "Deployable plugin with AspectJ support" yields plugin with aspects missing [message #68902 is a reply to message #68826] |
Mon, 11 December 2006 08:01 |
| Eclipse User |
|
|
|
Hi Steve,
sorry I didn't react earlier - I first had to finish and deliver a
report that was due last Friday.
Thanks for your explanation! That the woven classes are NOT in the .jar
but are actually duplicated to the output and "shaddowing" the original
classes finally explained everything to me, like why "catching" those
..jar's didn't change anything. etc.
Building on that I was finally able to come up with a scheme that now
allows me to build a plugin automatically (more details in the mentioned
bugzilla entry).
Cheers and thanks again!
Michael
"Steve Young" <spyoung@uk.ibm.com> wrote in message
news:el8uhs$j35$1@utils.eclipse.org...
> The JARs in to which you are weaving are only the source and are not
> modified; the new classes (i.e. the woven versions) are output either
> to your Eclipse project's bin directory (look on the filesystem,
> rather than in Eclipse) or to your project's outjar, if you have one
> specified. It is from one of these locations that the runtime
> workbench picks up the woven code.
>
> I've added some comments/advice/suggestions to your bug 166765 which
> relates to this issue.
>
>
> Cheers,
>
> Steve
|
|
|
| Re: Exporting "Deployable plugin with AspectJ support" yields plugin with aspects missing [message #595484 is a reply to message #68687] |
Thu, 30 November 2006 08:43 |
| Eclipse User |
|
|
|
I just did an "experiment" and the result left me stunned:
I rebuilt things and ran the plugin in the runtime workbench. As I
wrote, here everything works fine. While that workbench was executing I
copied the 3 .jar files that are supposed to contain the weaved-in
aspect code out into a temp. directory. So, at this moment the aspects
should have been correctly woven into the .jar files - at least that's
what I had thougth. From that temp. directory I copied them into the
..zip file that the previous export had generated (thereby overwriting
the .jars that were originally packed into the .zip).
That modified .zip I then transferred to the target system's eclipse
directory, unpacked it and started eclipse and with it my plugin. To my
surprise I get the same errors re. missing methods. So, the aspects
aren't really woven into the .jar's at all and now I'm really puzzled!
When and how are these aspects woven into the code before the runtime
workbench executes? And where does the aspect code come from, because
obviously it is in the executing code, but has NOT been in the .jar
files from which it was loaded!?!
And how would I weave AspectJ code into .jar files, i.e. actually modify
those jars?
Michael
|
|
|
| Re: Exporting "Deployable plugin with AspectJ support" yields plugin with aspects missing [message #595523 is a reply to message #68724] |
Thu, 07 December 2006 06:39 |
| Eclipse User |
|
|
|
The JARs in to which you are weaving are only the source and are not
modified; the new classes (i.e. the woven versions) are output either to
your Eclipse project's bin directory (look on the filesystem, rather
than in Eclipse) or to your project's outjar, if you have one specified.
It is from one of these locations that the runtime workbench picks up
the woven code.
I've added some comments/advice/suggestions to your bug 166765 which
relates to this issue.
Cheers,
Steve
Michael Moser wrote:
> I just did an "experiment" and the result left me stunned:
>
> I rebuilt things and ran the plugin in the runtime workbench. As I
> wrote, here everything works fine. While that workbench was executing I
> copied the 3 .jar files that are supposed to contain the weaved-in
> aspect code out into a temp. directory. So, at this moment the aspects
> should have been correctly woven into the .jar files - at least that's
> what I had thougth. From that temp. directory I copied them into the
> .zip file that the previous export had generated (thereby overwriting
> the .jars that were originally packed into the .zip).
>
> That modified .zip I then transferred to the target system's eclipse
> directory, unpacked it and started eclipse and with it my plugin. To my
> surprise I get the same errors re. missing methods. So, the aspects
> aren't really woven into the .jar's at all and now I'm really puzzled!
> When and how are these aspects woven into the code before the runtime
> workbench executes? And where does the aspect code come from, because
> obviously it is in the executing code, but has NOT been in the .jar
> files from which it was loaded!?!
>
> And how would I weave AspectJ code into .jar files, i.e. actually modify
> those jars?
>
> Michael
>
>
>
>
>
|
|
|
| Re: Exporting "Deployable plugin with AspectJ support" yields plugin with aspects missing [message #595565 is a reply to message #68826] |
Mon, 11 December 2006 08:01 |
| Eclipse User |
|
|
|
Hi Steve,
sorry I didn't react earlier - I first had to finish and deliver a
report that was due last Friday.
Thanks for your explanation! That the woven classes are NOT in the .jar
but are actually duplicated to the output and "shaddowing" the original
classes finally explained everything to me, like why "catching" those
..jar's didn't change anything. etc.
Building on that I was finally able to come up with a scheme that now
allows me to build a plugin automatically (more details in the mentioned
bugzilla entry).
Cheers and thanks again!
Michael
"Steve Young" <spyoung@uk.ibm.com> wrote in message
news:el8uhs$j35$1@utils.eclipse.org...
> The JARs in to which you are weaving are only the source and are not
> modified; the new classes (i.e. the woven versions) are output either
> to your Eclipse project's bin directory (look on the filesystem,
> rather than in Eclipse) or to your project's outjar, if you have one
> specified. It is from one of these locations that the runtime
> workbench picks up the woven code.
>
> I've added some comments/advice/suggestions to your bug 166765 which
> relates to this issue.
>
>
> Cheers,
>
> Steve
|
|
|
Powered by
FUDForum. Page generated in 0.04146 seconds
Home