Using weaved plugin in eclipse [message #62501] |
Sat, 04 March 2006 04:04  |
Eclipse User |
|
|
|
Originally posted by: cai.chang.gmail.com
Hi,
I added some methods to a class in a plugin that I am not allowed to
change the source using aspectJ. When used in non-eclipse environment, the
new methods in the plugin can be called without any problem by putting
both the plugin jar and aspectjrt.jar on the classpath. However, I found I
was not able to test the weaved plugin in Eclipse since there is no way to
put the aspectjrt.jar on the classpath of the plugin except changing the
dependency which I cannot do.
Is there a way to work around this or the approach I took is totally
wrong? Thanks a lot.
|
|
|
Re: Using weaved plugin in eclipse [message #62590 is a reply to message #62501] |
Mon, 06 March 2006 06:41  |
Eclipse User |
|
|
|
On Sat, 04 Mar 2006 09:04:00 +0000, Chang Cai wrote:
> I added some methods to a class in a plugin that I am not allowed to
> change the source using aspectJ. When used in non-eclipse environment, the
> new methods in the plugin can be called without any problem by putting
> both the plugin jar and aspectjrt.jar on the classpath. However, I found I
> was not able to test the weaved plugin in Eclipse since there is no way to
> put the aspectjrt.jar on the classpath of the plugin except changing the
> dependency which I cannot do.
>
> Is there a way to work around this or the approach I took is totally
> wrong? Thanks a lot.
Hi,
I don't fully understand your restrictions - so you can replace the
plug-in's jar file with a woven version of the jar file, but you can't
change the plug-in's dependencies?
Anyway, plug-in fragments might be helpful here. See for example:
http://www.awprofessional.com/articles/article.asp?p=370626& amp;seqNum=16&rl=1
to quote from that:
... a fragment appears much the same as a normal plug-in. A fragment can
specify libraries, extensions, and other files. When it is loaded by the
platform loader, a fragment is logically, but not physically, merged
into the host plug-in. The end result is exactly the same as if the
fragment's manifest were copied into the plug-in manifest, and all the
files in the fragment directory appear as if they were located in the
plug-in's install directory. Thus, a runtime library supplied by a
fragment appears on the classpath of its host plug-in.
Regards,
Matt.
|
|
|
Re: Using weaved plugin in eclipse [message #592485 is a reply to message #62501] |
Mon, 06 March 2006 06:41  |
Eclipse User |
|
|
|
On Sat, 04 Mar 2006 09:04:00 +0000, Chang Cai wrote:
> I added some methods to a class in a plugin that I am not allowed to
> change the source using aspectJ. When used in non-eclipse environment, the
> new methods in the plugin can be called without any problem by putting
> both the plugin jar and aspectjrt.jar on the classpath. However, I found I
> was not able to test the weaved plugin in Eclipse since there is no way to
> put the aspectjrt.jar on the classpath of the plugin except changing the
> dependency which I cannot do.
>
> Is there a way to work around this or the approach I took is totally
> wrong? Thanks a lot.
Hi,
I don't fully understand your restrictions - so you can replace the
plug-in's jar file with a woven version of the jar file, but you can't
change the plug-in's dependencies?
Anyway, plug-in fragments might be helpful here. See for example:
http://www.awprofessional.com/articles/article.asp?p=370626& amp;seqNum=16&rl=1
to quote from that:
... a fragment appears much the same as a normal plug-in. A fragment can
specify libraries, extensions, and other files. When it is loaded by the
platform loader, a fragment is logically, but not physically, merged
into the host plug-in. The end result is exactly the same as if the
fragment's manifest were copied into the plug-in manifest, and all the
files in the fragment directory appear as if they were located in the
plug-in's install directory. Thus, a runtime library supplied by a
fragment appears on the classpath of its host plug-in.
Regards,
Matt.
|
|
|
Powered by
FUDForum. Page generated in 0.03505 seconds