Home » Eclipse Projects » Platform - User Assistance (UA) » Dropins folder not being rescanned
Dropins folder not being rescanned [message #474548] |
Fri, 19 September 2008 13:30 |
Morley Tooke Messages: 19 Registered: July 2009 |
Junior Member |
|
|
Hello all,
I've got a similar problem to the below issue.
The background:
I've got an automated DITA build that generates Eclipse plugin
documentation every night at 4am (while I'm at home watching
infomercials). The generated plugins work great when I place them in the
dropins folder - so I know that my plugins are ok. The automated build
starts by killing the infocenter process. Then, the DITA build runs and
eventually the output plugins are copied to the dropins folder (which is
initially cleaned out by deleting the previous night's plugins). Then,
when the build completes, the infocenter is launched again using the
-clean option.
Here's the problem:
On a brand new eclipse install, this process works perfectly. I show up
the next day at work and the infocenter is alive, and contains my built
plugins. The next day after that, the infocenter is alive, but does not
contain my plugins - despite the fact that the DITA build was successful
and the new plugins are in the dropins folder.
So the problem it seems, is that the dropins folder does not get rescanned
every time the infocenter restarts, or for that matter, every time Eclipse
starts. I'm wondering if the names of my plugins are cached somewhere, so
that the new plugins are creating collisions when they are added? Debug
doesn't tell me anythihng.
Also note that the -clean option doesn't seem to work any more. The only
remedy is to delete the Eclipse installation, and re-install every single
day.
Thanks for your help.
|
|
|
Re: Dropins folder not being rescanned [message #474549 is a reply to message #474548] |
Fri, 19 September 2008 17:43 |
Eclipse User |
|
|
|
Originally posted by: nospam_kowalskilee.gmail.com
Hi Mosely,
When you refresh your plug-ins, do you update the manifest info and
version number in the MANIFEST.MF file?
About -clean: I've been seeing other postings on some of the other
newsgroups (e.g., eclipse.technology.equinox) where other people are
having troubles using dropins and -clean doesn't help them. I don't know
the answer about whether -clean behavior has changed in 3.4.
Based on one of the threads on eclipse.technology.equinox where someone
mentioned the bundles.info file, I did locate the following file:
eclipse/configuration/org.eclipse.equinox.simpleconfigurator /bundles.info
That file contains a listing of plug-ins/bundles, including the ones in
my dropins directory. It has clearly cached the list of bundles.
You might try looking for more info about the bundles.info file to learn
more. I will say that I've seen some Bugzilla bugs related to "bundle
pool" that seem to be related to this behavior.
Hope this helps,
Lee Anne
Mosely wrote:
>
> Hello all,
>
> I've got a similar problem to the below issue.
>
> The background:
>
> I've got an automated DITA build that generates Eclipse plugin
> documentation every night at 4am (while I'm at home watching
> infomercials). The generated plugins work great when I place them in the
> dropins folder - so I know that my plugins are ok. The automated build
> starts by killing the infocenter process. Then, the DITA build runs and
> eventually the output plugins are copied to the dropins folder (which is
> initially cleaned out by deleting the previous night's plugins). Then,
> when the build completes, the infocenter is launched again using the
> -clean option.
>
> Here's the problem:
>
> On a brand new eclipse install, this process works perfectly. I show up
> the next day at work and the infocenter is alive, and contains my built
> plugins. The next day after that, the infocenter is alive, but does not
> contain my plugins - despite the fact that the DITA build was successful
> and the new plugins are in the dropins folder.
> So the problem it seems, is that the dropins folder does not get
> rescanned every time the infocenter restarts, or for that matter, every
> time Eclipse starts. I'm wondering if the names of my plugins are cached
> somewhere, so that the new plugins are creating collisions when they are
> added? Debug doesn't tell me anythihng.
>
> Also note that the -clean option doesn't seem to work any more. The only
> remedy is to delete the Eclipse installation, and re-install every
> single day.
>
> Thanks for your help.
>
|
|
|
Possible to leverage workaround? Set a unique dropins folder at startup [message #474550 is a reply to message #474548] |
Fri, 19 September 2008 17:51 |
Eclipse User |
|
|
|
Originally posted by: nospam_kowalskilee.gmail.com
Hi Mosely,
I don't know if this would help you work around the issue.
I found this posting in eclipse.technology.equinox about a parameter
that lets you specify a second 'watched' directory:
http://dev.eclipse.org/newslists/news.eclipse.technology.equ inox/msg04819.html
using
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/<your_path_to_shared_dropins_folder >
ekke's blog is at:
http://ekkes-corner.blogspot.com/2008/06/eclipse-ganymede-p2 -shared.html
I haven't thought far enough to see how you could make use of it with
your automated process and the fact that some things seem to get cached
and not cleared.
Sincerely,
Lee Anne
Mosely wrote:
>
> Hello all,
>
> I've got a similar problem to the below issue.
>
> The background:
>
> I've got an automated DITA build that generates Eclipse plugin
> documentation every night at 4am (while I'm at home watching
> infomercials). The generated plugins work great when I place them in the
> dropins folder - so I know that my plugins are ok. The automated build
> starts by killing the infocenter process. Then, the DITA build runs and
> eventually the output plugins are copied to the dropins folder (which is
> initially cleaned out by deleting the previous night's plugins). Then,
> when the build completes, the infocenter is launched again using the
> -clean option.
>
> Here's the problem:
>
> On a brand new eclipse install, this process works perfectly. I show up
> the next day at work and the infocenter is alive, and contains my built
> plugins. The next day after that, the infocenter is alive, but does not
> contain my plugins - despite the fact that the DITA build was successful
> and the new plugins are in the dropins folder.
> So the problem it seems, is that the dropins folder does not get
> rescanned every time the infocenter restarts, or for that matter, every
> time Eclipse starts. I'm wondering if the names of my plugins are cached
> somewhere, so that the new plugins are creating collisions when they are
> added? Debug doesn't tell me anythihng.
>
> Also note that the -clean option doesn't seem to work any more. The only
> remedy is to delete the Eclipse installation, and re-install every
> single day.
>
> Thanks for your help.
>
|
|
|
Re: Possible to leverage workaround? Set a unique dropins folder at startup [message #474551 is a reply to message #474550] |
Fri, 19 September 2008 18:23 |
Morley Tooke Messages: 19 Registered: July 2009 |
Junior Member |
|
|
Thanks - that's an interesting workaround - I'll take a look at it and see
if I can make it work.
Regarding your earlier questions, no, I'm not updating the version numbers
in manifest.mf. My plugin folder names are timestamped, but the name and
version in the manifest stays the same - since the plugin versions are
staying constant. I'm not using features, or inserting plugins alongside
existing plugins. The purpose of this infocenter(IC) is to allow all of
the writers to view their content in a daily-generated, central IC.
re: Bundles.info, yes, I've just now done a "search in files" for my
plugin names and they appear in two places within the Eclipse
configuration directory. You used to be able to kill that directory to
force a clean reboot - however, now you can't.
Deleting Bundles.info causes Eclipse to fail on load. Deleting my plugin
entries out of Bundles.info allows Eclipse to load, but does not reload my
new plugins. Perhaps there is a parity bit somewhere, or something that
alerts it to a possible new configuration?
Thanks for your help. I'll try messing around with the configuration files
a little bit more.
Mosely
|
|
| | |
Re: Dropins folder not being rescanned [message #619895 is a reply to message #474548] |
Fri, 19 September 2008 17:43 |
Eclipse User |
|
|
|
Originally posted by: nospam_kowalskilee.gmail.com
Hi Mosely,
When you refresh your plug-ins, do you update the manifest info and
version number in the MANIFEST.MF file?
About -clean: I've been seeing other postings on some of the other
newsgroups (e.g., eclipse.technology.equinox) where other people are
having troubles using dropins and -clean doesn't help them. I don't know
the answer about whether -clean behavior has changed in 3.4.
Based on one of the threads on eclipse.technology.equinox where someone
mentioned the bundles.info file, I did locate the following file:
eclipse/configuration/org.eclipse.equinox.simpleconfigurator /bundles.info
That file contains a listing of plug-ins/bundles, including the ones in
my dropins directory. It has clearly cached the list of bundles.
You might try looking for more info about the bundles.info file to learn
more. I will say that I've seen some Bugzilla bugs related to "bundle
pool" that seem to be related to this behavior.
Hope this helps,
Lee Anne
Mosely wrote:
>
> Hello all,
>
> I've got a similar problem to the below issue.
>
> The background:
>
> I've got an automated DITA build that generates Eclipse plugin
> documentation every night at 4am (while I'm at home watching
> infomercials). The generated plugins work great when I place them in the
> dropins folder - so I know that my plugins are ok. The automated build
> starts by killing the infocenter process. Then, the DITA build runs and
> eventually the output plugins are copied to the dropins folder (which is
> initially cleaned out by deleting the previous night's plugins). Then,
> when the build completes, the infocenter is launched again using the
> -clean option.
>
> Here's the problem:
>
> On a brand new eclipse install, this process works perfectly. I show up
> the next day at work and the infocenter is alive, and contains my built
> plugins. The next day after that, the infocenter is alive, but does not
> contain my plugins - despite the fact that the DITA build was successful
> and the new plugins are in the dropins folder.
> So the problem it seems, is that the dropins folder does not get
> rescanned every time the infocenter restarts, or for that matter, every
> time Eclipse starts. I'm wondering if the names of my plugins are cached
> somewhere, so that the new plugins are creating collisions when they are
> added? Debug doesn't tell me anythihng.
>
> Also note that the -clean option doesn't seem to work any more. The only
> remedy is to delete the Eclipse installation, and re-install every
> single day.
>
> Thanks for your help.
>
|
|
|
Possible to leverage workaround? Set a unique dropins folder at startup [message #619896 is a reply to message #474548] |
Fri, 19 September 2008 17:51 |
Eclipse User |
|
|
|
Originally posted by: nospam_kowalskilee.gmail.com
Hi Mosely,
I don't know if this would help you work around the issue.
I found this posting in eclipse.technology.equinox about a parameter
that lets you specify a second 'watched' directory:
http://dev.eclipse.org/newslists/news.eclipse.technology.equ inox/msg04819.html
using
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/<your_path_to_shared_dropins_folder >
ekke's blog is at:
http://ekkes-corner.blogspot.com/2008/06/eclipse-ganymede-p2 -shared.html
I haven't thought far enough to see how you could make use of it with
your automated process and the fact that some things seem to get cached
and not cleared.
Sincerely,
Lee Anne
Mosely wrote:
>
> Hello all,
>
> I've got a similar problem to the below issue.
>
> The background:
>
> I've got an automated DITA build that generates Eclipse plugin
> documentation every night at 4am (while I'm at home watching
> infomercials). The generated plugins work great when I place them in the
> dropins folder - so I know that my plugins are ok. The automated build
> starts by killing the infocenter process. Then, the DITA build runs and
> eventually the output plugins are copied to the dropins folder (which is
> initially cleaned out by deleting the previous night's plugins). Then,
> when the build completes, the infocenter is launched again using the
> -clean option.
>
> Here's the problem:
>
> On a brand new eclipse install, this process works perfectly. I show up
> the next day at work and the infocenter is alive, and contains my built
> plugins. The next day after that, the infocenter is alive, but does not
> contain my plugins - despite the fact that the DITA build was successful
> and the new plugins are in the dropins folder.
> So the problem it seems, is that the dropins folder does not get
> rescanned every time the infocenter restarts, or for that matter, every
> time Eclipse starts. I'm wondering if the names of my plugins are cached
> somewhere, so that the new plugins are creating collisions when they are
> added? Debug doesn't tell me anythihng.
>
> Also note that the -clean option doesn't seem to work any more. The only
> remedy is to delete the Eclipse installation, and re-install every
> single day.
>
> Thanks for your help.
>
|
|
|
Re: Possible to leverage workaround? Set a unique dropins folder at startup [message #619897 is a reply to message #474550] |
Fri, 19 September 2008 18:23 |
Morley Tooke Messages: 19 Registered: July 2009 |
Junior Member |
|
|
Thanks - that's an interesting workaround - I'll take a look at it and see
if I can make it work.
Regarding your earlier questions, no, I'm not updating the version numbers
in manifest.mf. My plugin folder names are timestamped, but the name and
version in the manifest stays the same - since the plugin versions are
staying constant. I'm not using features, or inserting plugins alongside
existing plugins. The purpose of this infocenter(IC) is to allow all of
the writers to view their content in a daily-generated, central IC.
re: Bundles.info, yes, I've just now done a "search in files" for my
plugin names and they appear in two places within the Eclipse
configuration directory. You used to be able to kill that directory to
force a clean reboot - however, now you can't.
Deleting Bundles.info causes Eclipse to fail on load. Deleting my plugin
entries out of Bundles.info allows Eclipse to load, but does not reload my
new plugins. Perhaps there is a parity bit somewhere, or something that
alerts it to a possible new configuration?
Thanks for your help. I'll try messing around with the configuration files
a little bit more.
Mosely
|
|
| | |
Goto Forum:
Current Time: Wed Sep 25 17:12:48 GMT 2024
Powered by FUDForum. Page generated in 0.04412 seconds
|