Eclipse Community Forums: Platform - User Assistance (UA)

Help

Home

Home » Eclipse Projects » Platform - User Assistance (UA) » Dropins folder not being rescanned

Show: Today's Messages :: Show Polls :: Message Navigator

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.

Report message to a moderator

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.
>

Report message to a moderator

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.
>

Report message to a moderator

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

Report message to a moderator

Re: Possible to leverage workaround? Set a unique dropins folder at startup [message #474552 is a reply to message #474551]

Fri, 19 September 2008 18:48

Morley Tooke

Messages: 19
Registered: July 2009

Junior Member

Some more followup.

Replacing bundles.info with the original file from the install package
doesn't fix the problem. Deleting all instances of the cache, and log
files where my plugin names show up doesn't work either - Eclipse loads,
but does not recognize the new plugins.

Report message to a moderator

Workaround and problem ID [message #474556 is a reply to message #474550]

Thu, 02 October 2008 19:32

Morley Tooke

Messages: 19
Registered: July 2009

Junior Member

I've got a successful workaround in place.

It appears that Eclipse logs the name of the plugin somewhere in an
internal cache. My generated plugin folder names contained a version
number and date. Each day, the date was incremented, however the version
number and plugin id (in the manifest) did not change.

Eclipse choked on the incremented folder name. There was no way to clear
the cache - so instead I was forced to uninstall and re-install Eclipse
each time.

To fix the problem, I'm simply generating the help plugins without the
appended version and date (com.company.product instead of
com.company.product_v1_20081002) and copying them into the dropins folder.
Another set of the same plugins are then jarred, and versioned, and sent
to a shared folder, where they can be picked up by the main build machine.

It's run five times in the last four days, and so far I'm five for five.

Thanks for pointing me in the right direction.

Report message to a moderator