Home » Eclipse Projects » Eclipse Platform » Resolving required plugins
| Resolving required plugins [message #144862] |
Thu, 16 October 2003 09:47  |
Eclipse User |
|
|
|
I upgraded to 3.0 M4 yesterday and imported several of my plugin projects
that work fine in 2.1.1. Following import, I ran into many compilation
errors ultimately due to the following,
"missing required Java project: 'org.eclipse.core.resources'."
I was somehow able to eliminate these dependancy errors and continue
developing. When I started Eclipse 3.0 this morning, the error are all
back again.
I never had this problem with 2.1.1. Is there something I'm doing wrong?
TIA
-Mitch
|
|
| |
| Eclipse support of reloadable plugins and OSGi... [message #145096 is a reply to message #144862] |
Thu, 16 October 2003 12:59  |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Hey all,
I read that M4 is starting to add the Equinox code that makes reloadable
plugins possible, as well as loadable plugins at runtime. A question I have
is once this is in place, do we need to run a second workbench to test our
plugins any longer? Or will Eclipse adopt a new design where by you can
automatically deploy the plugins (at runtime) right in the same IDE you are
developing with? And if so, reloading them, as well as removing them, how
will that work? Personally, I think this is a MUST HAVE. It takes too long
to start up the 2nd workbench, just to close it, make a quick change, and
rerun it again, and again... If Eclipse will truly support runtime
loadable/reloadable/unloadable plugins, then I think getting rid of the need
to run a 2nd workbench to test them is an essential piece of that pie.
Also, I see a check box (forget where) for OSGi. What level of OSGi bundles
are supported in Eclipse? Are they supported at the core level in eclipse,
or is it an adaptor plugin that maps OSGi bundles through Eclipse? In other
words, does Eclipse now implement the OSGi spec as well at its internal
levels? Will OSGi bundles also support loadable/reloadable/unloadable
capabilities?
Thanks.
|
|
| | |
| Re: Eclipse support of reloadable plugins and OSGi... [message #145379 is a reply to message #145096] |
Thu, 16 October 2003 20:20 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
The equinox code is not in the M4 drop.
What happen is the following. A partial eclipse drop is available from the
equinox website containing the new runtime.
You can unzip its content on top of M4 and you'll be able to run with it.
This brings dynamicity but because no plugin uses it, it will not do much
for you, for now!
If you have any problem relative to the new runtime, please report bugs in
Equinox / general. All other bugs should go in their regular buckets.
On another front, the current runtime has been extended with dynamic
capabilities: dynamic installation of plugin, and the crucial piece of a
dynamic registry. This is available in M4. Start using it, and give us
feedback (bugzilla: platform / core)
The equinox architecture (in two words) is OSGi as a runtime, eclipse
running on top of OSGi. The dynamic capabilities are obtained through OSGi
which is 'natively' dynamic. Please direct any question regarding this to
the equinox newsgroup.
Regarding the tooling and the ability to not start another eclipse. There
has never been any intent to do what you (Kevin) propose. As Eric correctly
indicated, this is the best way to shoot yourself in the foot. Don't you
remember VAJava, wasn't it painful that your ide was crashing when your app
was crashing?
Note that uninstalling will not happen for free, since this means collecting
classloaders, which means collecting instances. To summarize every plugin
will have to be a good citizen in getting rid of the instance of a leaving
plugin, as well as doing a perfect job of cleaning up after itself when
being shutdown (which is not the case when you look at the shutdown method
of most of plugins ;-)).
PaScaL
"Kevin" <kduffey@marketron.com> a
|
|
| | |
| Re: Resolving required plugins [message #146540 is a reply to message #145486] |
Mon, 20 October 2003 09:29 |
| Eclipse User |
|
|
|
Originally posted by: kresho.ieee.org
After using a serious portion of my patience reserve, here are the answers for the archives:
To make Eclipse not remove unresolved libraries from the build path, open Window->Preferences->Plugin development->Java Build Path Control and turn off all checkboxes. But you don't really want to do this as it should also add libraries to the build path when you add a plugin dependency in the plugin.xml (though I havent tried it)
To really solve the problem, open Window->Preferences->Plugin development->Target Platform and check all the plugins that your plugin depends on. Though, I think this setting should be on a per-project basis, not for the entire workspace. So the easiest thing to do is jusk click Select all, and forget about it.
--
Krešimir Tonkovic
Alterbox.hr doo
kresimir.tonkovic@alterbox.hr
www.alterbox.net
"Krešimir Tonkovic" <kresho@ieee.org> wrote in message news:bmo508$8vs$1@eclipse.org...
I have had the same problem with my plugin.
I added all the plugin jars to my build path to resolve compilation problems. And when I touch the plugin.xml file and save it, all plugins that are not mentioned in the <requires> tags get removed automatically. This drives me crazy! I tried adding those plugins into the plugins.xml, but eclipse keeps saying it can't resolve plugin dependencies, and still removes jars from my build path.
But this doesn't happen with all the dependencies! In particular, org.eclipse ui and org.eclipse.swt are ok, but org.eclipse.core.resources kills me! I haven't been able to find out what is different with this plugin.
Any clues?
--
Krešimir Tonkovic
Alterbox.hr doo
kresimir.tonkovic@alterbox.hr
www.alterbox.net
"Mitch Christensen" <mitch.christensen@informatixinc.com> wrote in message news:bmm7i0$ko1$1@eclipse.org...
> I upgraded to 3.0 M4 yesterday and imported several of my plugin projects
> that work fine in 2.1.1. Following import, I ran into many compilation
> errors ultimately due to the following,
>
> "missing required Java project: 'org.eclipse.core.resources'."
>
> I was somehow able to eliminate these dependancy errors and continue
> developing. When I started Eclipse 3.0 this morning, the error are all
> back again.
>
> I never had this problem with 2.1.1. Is there something I'm doing wrong?
>
> TIA
> -Mitch
>
|
|
|
| Re: Eclipse support of reloadable plugins and OSGi... [message #147825 is a reply to message #145379] |
Wed, 22 October 2003 13:57 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Hey Pascal,
I mentioned a while back I was also building a "generic" pluggable engine
similar in how eclipse works. Basically I support the idea of extension
points and extensions, reloadable plugins, etc. I was actually quite happy
to see you guys came up with a simliar idea as to what I did. That is,
anytime an extension is added to an extension point, the plugin owning that
extension point is sent an event notifying of the added extension. Same
thing if an extension is removed, the plugin owner of the extension point is
notified via an event. Unlike Eclipse and/or Equinox, my engine resolves all
plugin dependencies as plugins are loaded automatically. I don't require the
"requires" statement that eclipse does. In my engine, as each extension is
added, it looks up the extension point, if found, it figures out the plugin
owner, and then adds the dependent classloader of the extension to the
extension point plugin's classloader list, so at runtime it can delegate to
the proper dependent classloader. Actually I assign both as dependents to
one another. So far this has worked well.
As for deploying in the same IDE, you make valid points. I didn't think
about that issue where a plugin may crash the whole dang thing! However,
starting up a completely new runtime IDE each time kind of sucks. Perhaps
you guys can agree to keep the second IDE running, and somehow provide hooks
that allow you to load/unload the plugin each time you run it, as opposed to
kill the second IDE, then restart it each time. What I am after here is
turnaround time. Being able to avoid having to restart the second IDE every
time I make a change is a big time saver. On the order of up to a 1/2 hour
or more a day in an 8 hour day, if you fix/run/test quickly. 1/2 hour a day
may seem like nothing, but it is worth it to me. So maybe that can be looked
at?
"Pascal Rapicault" <pascal_rapicault@yahoo.fr> wrote in message
news:bmnck0$osf$1@eclipse.org...
> The equinox code is not in the M4 drop.
>
> What happen is the following. A partial eclipse drop is available from the
> equinox website containing the new runtime.
> You can unzip its content on top of M4 and you'll be able to run with it.
> This brings dynamicity but because no plugin uses it, it will not do much
> for you, for now!
> If you have any problem relative to the new runtime, please report bugs in
> Equinox / general. All other bugs should go in their regular buckets.
>
> On another front, the current runtime has been extended with dynamic
> capabilities: dynamic installation of plugin, and the crucial piece of a
> dynamic registry. This is available in M4. Start using it, and give us
> feedback (bugzilla: platform / core)
>
> The equinox architecture (in two words) is OSGi as a runtime, eclipse
> running on top of OSGi. The dynamic capabilities are obtained through OSGi
> which is 'natively' dynamic. Please direct any question regarding this to
> the equinox newsgroup.
>
> Regarding the tooling and the ability to not start another eclipse. There
> has never been any intent to do what you (Kevin) propose. As Eric
correctly
> indicated, this is the best way to shoot yourself in the foot. Don't you
> remember VAJava, wasn't it painful that your ide was crashing when your
app
> was crashing?
> Note that uninstalling will not happen for free, since this means
collecting
> classloaders, which means collecting instances. To summarize every plugin
> will have to be a good citizen in getting rid of the instance of a leaving
> plugin, as well as doing a perfect job of cleaning up after itself when
> being shutdown (which is not the case when you look at the shutdown method
> of most of plugins ;-)).
>
>
> PaScaL
>
>
>
>
> "Kevin" <kduffey@marketron.com> a
|
|
|
Goto Forum:
Current Time: Sat Jul 26 04:34:34 EDT 2025
Powered by FUDForum. Page generated in 0.05100 seconds |
Home