news.eclipse.platform.ua

[news.eclipse.platform.ua] Re: eclipse help system

cgold@xxxxxxx (Chris Goldthorpe) — Mon, 06 Oct 2008 21:34:22 GMT

I'm guessing that you have your own product based on Eclipse. There are a couple of options:

1. Remove the plugins which contribute help to Eclipse from the eclipse plugins directory. There 5 plugins all have a plugin name ending in .doc.

OR

2. Use the HELP_DATA customization. See http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/guide/ua_help_setup_preferences.htm and http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/guide/ua_help_setup_help_data.htm

Eric Rizzo wrote:

Copying this to the eclipse.platform.ua newsgroup where questions about Help usually go.

On 10/2/2008 8:23 AM, Giara wrote:
hi,
How can i manage eclipse help system to show only my own contents.
thanks
giara

[news.eclipse.platform.ua] Re: Where to include cheatsheets?

cgold@xxxxxxx (Chris Goldthorpe) — Mon, 06 Oct 2008 21:29:46 GMT

I'm not sure why it was done this way, there is no reason not to include cheatsheets in a doc plugin or create a separate plugin for them. I don't think that a fragment would be the right solution, fragments seem to be only used for localization.

Eric Rizzo wrote:

Sorry for the crosss-post, but this might be answered by either the UA, JDT, or PDE folks (or all of them).

I've noticed that JDT, Platform, and PDE all include cheatsheets. What is curious to me is that they are included in the base plugins (org.eclipse.jdt, org.eclipse.platform, org.eclipse.pde); it seems that cheatsheets really are more appropriate for the ui or doc plugins. Is there a particular reason for including them in the base plugins?

Also, are there any thoughts about the idea of putting all our cheatsheets into a fragment so they are self-contained and together?
TIA,
Eric

[news.eclipse.platform.ua] Workaround and problem ID

morley.tooke@xxxxxxx (Morley Tooke) — Thu, 02 Oct 2008 19:32:53 GMT

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.

[news.eclipse.platform.ua] Re: eclipse help system

eclipse-news@xxxxxxx (Eric Rizzo) — Thu, 02 Oct 2008 15:27:09 GMT

Copying this to the eclipse.platform.ua newsgroup where questions about Help usually go.

On 10/2/2008 8:23 AM, Giara wrote:

hi,
How can i manage eclipse help system to show only my own contents.
thanks
giara

[news.eclipse.platform.ua] Where to include cheatsheets?

eclipse-news@xxxxxxx (Eric Rizzo) — Fri, 26 Sep 2008 16:59:01 GMT

Sorry for the crosss-post, but this might be answered by either the UA, JDT, or PDE folks (or all of them).

I've noticed that JDT, Platform, and PDE all include cheatsheets. What is curious to me is that they are included in the base plugins (org.eclipse.jdt, org.eclipse.platform, org.eclipse.pde); it seems that cheatsheets really are more appropriate for the ui or doc plugins. Is there a particular reason for including them in the base plugins?

Also, are there any thoughts about the idea of putting all our cheatsheets into a fragment so they are self-contained and together?

TIA,
Eric

[news.eclipse.platform.ua] Re: Infocenter WAR file does not deploy on JBoss 4.2.1.GA - LogConfigurationExce

matt.holcomb@xxxxxxx (Matt Holcomb) — Thu, 25 Sep 2008 15:06:43 GMT

Peter, have you ever found the cause to this issue? I am having the same problems and have not had luck in resolving it so far.

[news.eclipse.platform.ua] Re: Possible to leverage workaround? Set a unique dropins folder at startup

morley.tooke@xxxxxxx (Morley Tooke) — Fri, 19 Sep 2008 18:48:42 GMT

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.

[news.eclipse.platform.ua] Re: Possible to leverage workaround? Set a unique dropins folder at startup

morley.tooke@xxxxxxx (Mosely) — Fri, 19 Sep 2008 18:23:47 GMT

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

[news.eclipse.platform.ua] Possible to leverage workaround? Set a unique dropins folder at startup

nospam_kowalskilee@xxxxxxx (Lee Anne) — Fri, 19 Sep 2008 17:51:40 GMT

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.equinox/msg04819.html using -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/

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.

[news.eclipse.platform.ua] Re: Dropins folder not being rescanned

nospam_kowalskilee@xxxxxxx (Lee Anne) — Fri, 19 Sep 2008 17:43:43 GMT

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.