| Recognizing new plugins [message #514203] |
Fri, 12 February 2010 19:32  |
 Jennifer Skiendzielewski
Messages: 35
Registered: January 2010
Location: Boulder, CO |
Member |
|
|
I'm in the process of moving my products from using the Eclipse 3.1.1 help framework to version 3.5. The products are server based and accessed via web browser, so we install the help system on the server and start it when the product starts.
I've gotten everything to work (finally! Well, I haven't managed to get the system to use helpdata.xml, so I'm using the deprecated method of setting up my help TOCs. We'll see if I get back to solving that one.), but I'm looking for advice on getting the help system to recognize plugins.
Right now, we're using the brute force method that my programmer-intern figured out last summer. Basically, we add a line to \eclipse\configuration\org.eclipse.equinox.simpleconfigurato r\bundles.info
That works OK for the product. Not great, but fine. However, we add new plugins for each feature... and updating that file when you add a new feature is problematic. (I think we have a way to do it, but it's not pretty).
But there has to be a better way! I keep thinking that p2 might be some help to me-- that it might provide a cleaner way to recognize the new plugins with little work on my end. Unfortunately, I'm not a coder and I don't have time to learn all there is about p2. I've read something about the "dropins" folder and p2, but I don't know things like: what other plugins do I need to include to use that functionality? Does it even work with an infocenter running outside the eclipse platform (my intern said no, but I want to verify)?
Can anyone tell me if I'm going in the right direction? Or if there's a better solution for the help system running in InfoCenter mode?
Any help would be appreciated.
|
|
|
| Re: Recognizing new plugins [message #515875 is a reply to message #514203] |
Sun, 21 February 2010 23:55  |
Lee Anne Kowalski
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi Jennifer,
I was hoping that one of the Eclipse UA committers might have an answer
to your p2 questions and what the best methods might be.
All I have is my own anecdotal experience. In Eclipse 3.4, I tried using
the dropins directory, and was getting inconsistent results for my doc
plug-ins being recognized when I started the standalone help or
infocenter. Sometimes they would be recognized, and most often not. I
always had the -clean option on my startup command, and because the
behavior was inconsistent, I could not adequately troubleshoot to
determine the reason why it wasn't working.
So, I changed to use a config.ini file that basically cut p2 out of the
picture. Doing this gives me consistent results, and my plug-ins get
recognized (when I clear the cached directories, as in Eclipse 3.3).
The drawbacks to cutting p2 out of the picture are:
- You can't use p2 or dropins or any of the Eclipse-standard way of
updating the infocenter code plug-ins
- When you update a plug-in, you have to stop the infocenter, clear the
cached directories out of eclipse/configuration directory, and then
restart. (The only thing that's in eclipse/configuration when I start up
my infocenter is my config.ini file).
The benefits to me are that it gives me back the same methods that I was
using with the Eclipse 3.3 level code, and no need to mess around with
bundles.info.
Here's my config.ini file:
-----------------------------
Line 1: org.eclipse.update.reconcile=true
Line 2: osgi.instance.area.default=@user.home/workspace
Line 3: eclipse.buildId=M20090211-1700
Line 4: osgi.bundles=org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start
Line 5: eclipse.product=com.lak.doc.myIC
Line 6: osgi.bundles.defaultStartLevel=4
(The "Line nn" portion does not appear in the file. I include those to
point out that Line 4, the osgi.bundles line, that references
org.eclipse.equinox.common, org.eclipse.update.configurator, and
org.eclipse.core.runtime is really all on one line. It looks split
across two lines above.)
While I do not claim that this is a "better solution" than a real
p2-ized method, it has worked out for my situations.
HTH!
Lee Anne
Jennifer Skiendzielewski wrote:
> I'm in the process of moving my products from using the Eclipse 3.1.1
> help framework to version 3.5. The products are server based and
> accessed via web browser, so we install the help system on the server
> and start it when the product starts.
>
> I've gotten everything to work (finally! Well, I haven't managed to get
> the system to use helpdata.xml, so I'm using the deprecated method of
> setting up my help TOCs. We'll see if I get back to solving that one.),
> but I'm looking for advice on getting the help system to recognize plugins.
>
> Right now, we're using the brute force method that my programmer-intern
> figured out last summer. Basically, we add a line to
> \eclipse\configuration\org.eclipse.equinox.simpleconfigurato r\bundles.info
> That works OK for the product. Not great, but fine. However, we add new
> plugins for each feature... and updating that file when you add a new
> feature is problematic. (I think we have a way to do it, but it's not
> pretty).
>
> But there has to be a better way! I keep thinking that p2 might be some
> help to me-- that it might provide a cleaner way to recognize the new
> plugins with little work on my end. Unfortunately, I'm not a coder and I
> don't have time to learn all there is about p2. I've read something
> about the "dropins" folder and p2, but I don't know things like: what
> other plugins do I need to include to use that functionality? Does it
> even work with an infocenter running outside the eclipse platform (my
> intern said no, but I want to verify)?
>
> Can anyone tell me if I'm going in the right direction? Or if there's a
> better solution for the help system running in InfoCenter mode?
>
> Any help would be appreciated.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02688 seconds
] 
Search
Help
Register
Login
Home
