Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 269297

Summary:	Links in dropins directory are never rescanned
Product:	[Eclipse Project] Equinox	Reporter:	Mike Morearty <mike>
Component:	p2	Assignee:	DJ Houghton <dj.houghton>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jamesblackburn+eclipse, pascal, rtaniwa, simon_kaegi
Version:	3.4.2
Target Milestone:	3.5 M7
Hardware:	All
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:
Bug Depends on:
Bug Blocks:	299544

Description Mike Morearty

2009-03-18 18:29:41 EDT

Build ID: M20090211-1700

Steps To Reproduce:
If I add a plugin directly into the "dropins" directory, it will be picked up automatically.  But if I have a .link file in the dropins directory, and I add a plugin to the directory that it points to, the new plugin is not loaded automatically.  Even touching the .link file doesn't fix this.  Only renaming the .link file works.

1. Add a "xyz.link" file to the dropins directory, with a line like "path=.../xyz", where ".../xyz" is an absolute path to some directory on your system.  Under "xyz" there should be an "eclipse/plugins" subdir.  Add any plugin to that dir.
2. Launch Eclipse.  The plugin you added is detected automatically.
3. Exit Eclipse.  Add a *second* plugin to the xyz/eclipse/plugins directory, and launch Eclipse again.

Actual result:
The first plugin is still loaded, but the second one is not.  Even if you do "touch xyz.link", it still isn't picked up.  But if you rename xyz.link to xyzz.link, then it IS picked up.

Expected result:
I would expect that links in the dropins directory would have the same "automatically rescan" characteristics that the dropins directory itself has.  (I am not expecting some sort of infinite recursion.  It's just that .link files provide a convenient way to keep your plugins organized, but the issue described here makes it harder for me to keep my dropins in a separate directory.)

Comment 1 Mike Morearty

2009-03-18 20:44:36 EDT

Hmm -- for that matter, it's not just links.  Same is true of directories:

eclipse/
  dropins/
    mike/
      plugins/
        myplugin1.jar

If I run like this, and then I add a "myplugin2.jar" into eclipse/dropins/mike/plugins, Eclipse doesn't pick it up.

It seems to only be watching the top-level "dropins" directory for changes.

Again, I want to emphasize that I understand that it would be unacceptable to do an infinitely deep recursive scan; that is not what I am asking for.  What I'm asking for is to scan in the "sensible" places:

- the top level
- the eclipse/plugins and eclipse/features subdirs of top-level folders and links

(and by "scan", I mean not only check for new files, but also check for files that have been touched -- e.g. if a .link file was touched, then it should be re-read, because it may point to a different place.)

Comment 2 Mike Morearty

2009-03-18 20:45:35 EDT

Argh -- I wrote this:


eclipse/
  dropins/
    mike/
      plugins/
        myplugin1.jar

but I meant this:


eclipse/
  dropins/
    mike/
      eclipse/     <== I forgot this line
        plugins/
          myplugin1.jar

Comment 3 DJ Houghton

2009-03-23 10:22:53 EDT

Using the latest build, the scenario described in comment #1 and comment #2 works fine for me on Windows. Pascal, can you try this on your Mac when you get a chance?

The scenario which doesn't work for me is the updating of the installed bundles when the link file changes. (as described in comment #0)

Note that this works ok if the link file is in the /links folder but not when it is a child in the dropins. The ProfileSynchronizer#isUpToDate check is returning true and we aren't detecting the changes.

So the work-around for your specific problems would be:
- move your link file to the links/ folder
- or specify the osgi.checkConfiguration=true System property which always does a check. (expect slower startup times)

Comment 4 DJ Houghton

2009-03-27 17:24:27 EDT

I've released changes to the reconciler "is up to date" check.
Changes will be available in tonight's nightly build.
Closing.

Comment 5 DJ Houghton

2010-03-03 09:40:26 EST

*** Bug 233025 has been marked as a duplicate of this bug. ***

Comment 6 DJ Houghton

2010-08-25 16:19:50 EDT

*** Bug 288755 has been marked as a duplicate of this bug. ***