Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Platform - User Assistance (UA) » Eclipse 3.4 - .war deployment of a standalone help system
Eclipse 3.4 - .war deployment of a standalone help system [message #473910] Wed, 11 June 2008 21:39 Go to next message
Kitty Ohman is currently offline Kitty OhmanFriend
Messages: 2
Registered: July 2009
Junior Member
Hello,

Am hoping for advice on how to package and deploy the base eclipse help
system as a .war file and package and deploy the contents for the help
system as separate components.

We are currently working on a 3.4 infocenter implementation -- the
infocenter help system is launched from a java-based web application (not
eclipse) as a help.war file. Our preferred strategy is to package the help
contents as eclipse features/plugins in one or more separate war (or jar)
files. The infocenter is launched from the web application by sending an
http request to a Web server (Jetty) which hosts the application and help
as a part of it. (https://somehost:8283/help/index.jsp). The Jetty process
unpacks the contents of each war to a separate work location, however,
when infocenter is launched, the contents pane in empty indicating that
the content plugins are not being recognized. Following are
observations/questions:

1) If all of the features/plugins for our content are packaged in the
single help.war, the help system and contents display as expected. Our
issue is occuring when we try to separate the content features/plugins
from the base help.war. Our product is a framework into which a variety of
components can be installed -- we need the flexibility to install docs to
match the installed components.
2) It appears that the "unpack" process creates a work\<jetty work
directory>\eclipse directory (a subset of the directory structure from the
help.war)--- that contains configuration, features, plugins, and
sub-folders. A platform.xml is also created in work\<jetty work
directory>\eclipse\configuration\org.eclise.update. All of this is created
before the application itself is even started, so it appears that some
sort of loading is taking place. Is this configurable?
3) The use of a links directory was attempted -- while the help.war
contained the links directory with a link file to the location of the doc
plugin, this file was not unpacked to the subset work\<jetty work
directory>\eclipse location (a full copy of the entire help.war is also
unpacked to work\<jetty work directory>\webapps\WEB-INF). Is the links
directory the right approach here? Should it be unpacked to the subset
work directory? Because some loading takes place, is it necessary to
launch with an argument (similar to -clean) that would clear that cached
information?
4) I reviewed the suggestions in bugzilla 201666 -- question about having
all of the files at the root level of the jar -- our output produces a
feature (directory) and plugin (jar -- which puts the topic files at the
root), but then I have been jar'ing the eclipse\feature and eclipse\plugin
directories to a single jar for deployment. Is this approach correct?

One final -- and basic question -- what are the benefits of .war
deployment of the help system in general?

Thanks in advance!

Kitty
Re: Eclipse 3.4 - .war deployment of a standalone help system [message #473911 is a reply to message #473910] Thu, 12 June 2008 16:32 Go to previous messageGo to next message
Chris Goldthorpe is currently offline Chris GoldthorpeFriend
Messages: 815
Registered: July 2009
Senior Member
Let me answer the final question first. The benefit of the war file is
that you can deploy it on any Web Server and you can have more control
of how you use the security features of your favorite web server.

The help system as a war file uses the Equinox runtime to load the
plugins and it is possible to tell Equinox to load plugins from more
than one directory - unfortunately I have not had much luck finding the
documentation on how that works, maybe someone else on this news group
has more information.
Re: Eclipse 3.4 - .war deployment of a standalone help system [message #473912 is a reply to message #473911] Thu, 12 June 2008 19:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: nospam_kowalskilee.gmail.com

Just to add to what Chris said, the fact that you can deploy the war
file on any web server means that if you've already got a server machine
and running a web app server on it to run your browser-based
application, then you don't have to run an additional second web app
server to run an Eclipse-based infocenter to supply the help system for
that browser-based application.

In the past, before this war version of the Eclipse help system, some
teams would be in this scenario:
- They had some Eclipse doc plug-in for their RCP (desktop) application
- They were creating a browser-based web application
- They needed a help system for the Help buttons in that web application
- They wanted to reuse the doc plug-ins from their RCP application and
not have to recreate the TOC, index, help topics, etc.

Therefore, they wanted to be able to use an Eclipse infocenter system as
the help system hooked to the Help buttons/menu in their web
application. But to do that in the past meant that you'd have to have
two web app servers running:
- one for running their browser-based web app
- second one was the Tomcat running inside the Eclipse infocenter

Having to have two web apps running on the same machine and getting them
to talk to one another caused headaches. So being able to deploy the
Eclipse infocenter into the same web app server on which the web
application is running that needs to talk to the infocenter--that is a
glorious thing. :-)

Best regards,
Lee Anne


Chris Goldthorpe wrote:
> Let me answer the final question first. The benefit of the war file is
> that you can deploy it on any Web Server and you can have more control
> of how you use the security features of your favorite web server.
>
> The help system as a war file uses the Equinox runtime to load the
> plugins and it is possible to tell Equinox to load plugins from more
> than one directory - unfortunately I have not had much luck finding the
> documentation on how that works, maybe someone else on this news group
> has more information.
Re: Eclipse 3.4 - .war deployment of a standalone help system [message #474059 is a reply to message #473910] Fri, 13 June 2008 11:35 Go to previous message
Eclipse UserFriend
Originally posted by: eclipse.maxant.co.uk

ive written a tutorial:

http://blog.maxant.co.uk/pebble/2008/06/09/1213043100000.htm l

cheers,
ant


"Kitty Ohman" <kohman@sybase.com> schrieb im Newsbeitrag
news:cf46c1d3fc46a9191477a5265645b84a$1@www.eclipse.org...
> Hello,
>
> Am hoping for advice on how to package and deploy the base eclipse help
> system as a .war file and package and deploy the contents for the help
> system as separate components.
>
> We are currently working on a 3.4 infocenter implementation -- the
> infocenter help system is launched from a java-based web application (not
> eclipse) as a help.war file. Our preferred strategy is to package the help
> contents as eclipse features/plugins in one or more separate war (or jar)
> files. The infocenter is launched from the web application by sending an
> http request to a Web server (Jetty) which hosts the application and help
> as a part of it. (https://somehost:8283/help/index.jsp). The Jetty process
> unpacks the contents of each war to a separate work location, however,
> when infocenter is launched, the contents pane in empty indicating that
> the content plugins are not being recognized. Following are
> observations/questions:
>
> 1) If all of the features/plugins for our content are packaged in the
> single help.war, the help system and contents display as expected. Our
> issue is occuring when we try to separate the content features/plugins
> from the base help.war. Our product is a framework into which a variety of
> components can be installed -- we need the flexibility to install docs to
> match the installed components.
> 2) It appears that the "unpack" process creates a work\<jetty work
> directory>\eclipse directory (a subset of the directory structure from the
> help.war)--- that contains configuration, features, plugins, and
> sub-folders. A platform.xml is also created in work\<jetty work
> directory>\eclipse\configuration\org.eclise.update. All of this is created
> before the application itself is even started, so it appears that some
> sort of loading is taking place. Is this configurable?
> 3) The use of a links directory was attempted -- while the help.war
> contained the links directory with a link file to the location of the doc
> plugin, this file was not unpacked to the subset work\<jetty work
> directory>\eclipse location (a full copy of the entire help.war is also
> unpacked to work\<jetty work directory>\webapps\WEB-INF). Is the links
> directory the right approach here? Should it be unpacked to the subset
> work directory? Because some loading takes place, is it necessary to
> launch with an argument (similar to -clean) that would clear that cached
> information?
> 4) I reviewed the suggestions in bugzilla 201666 -- question about having
> all of the files at the root level of the jar -- our output produces a
> feature (directory) and plugin (jar -- which puts the topic files at the
> root), but then I have been jar'ing the eclipse\feature and eclipse\plugin
> directories to a single jar for deployment. Is this approach correct?
>
> One final -- and basic question -- what are the benefits of .war
> deployment of the help system in general?
>
> Thanks in advance!
>
> Kitty
>
Re: Eclipse 3.4 - .war deployment of a standalone help system [message #614435 is a reply to message #473910] Thu, 12 June 2008 16:32 Go to previous message
Chris Goldthorpe is currently offline Chris GoldthorpeFriend
Messages: 815
Registered: July 2009
Senior Member
Let me answer the final question first. The benefit of the war file is
that you can deploy it on any Web Server and you can have more control
of how you use the security features of your favorite web server.

The help system as a war file uses the Equinox runtime to load the
plugins and it is possible to tell Equinox to load plugins from more
than one directory - unfortunately I have not had much luck finding the
documentation on how that works, maybe someone else on this news group
has more information.
Re: Eclipse 3.4 - .war deployment of a standalone help system [message #614438 is a reply to message #473911] Thu, 12 June 2008 19:53 Go to previous message
Eclipse UserFriend
Originally posted by: nospam_kowalskilee.gmail.com

Just to add to what Chris said, the fact that you can deploy the war
file on any web server means that if you've already got a server machine
and running a web app server on it to run your browser-based
application, then you don't have to run an additional second web app
server to run an Eclipse-based infocenter to supply the help system for
that browser-based application.

In the past, before this war version of the Eclipse help system, some
teams would be in this scenario:
- They had some Eclipse doc plug-in for their RCP (desktop) application
- They were creating a browser-based web application
- They needed a help system for the Help buttons in that web application
- They wanted to reuse the doc plug-ins from their RCP application and
not have to recreate the TOC, index, help topics, etc.

Therefore, they wanted to be able to use an Eclipse infocenter system as
the help system hooked to the Help buttons/menu in their web
application. But to do that in the past meant that you'd have to have
two web app servers running:
- one for running their browser-based web app
- second one was the Tomcat running inside the Eclipse infocenter

Having to have two web apps running on the same machine and getting them
to talk to one another caused headaches. So being able to deploy the
Eclipse infocenter into the same web app server on which the web
application is running that needs to talk to the infocenter--that is a
glorious thing. :-)

Best regards,
Lee Anne


Chris Goldthorpe wrote:
> Let me answer the final question first. The benefit of the war file is
> that you can deploy it on any Web Server and you can have more control
> of how you use the security features of your favorite web server.
>
> The help system as a war file uses the Equinox runtime to load the
> plugins and it is possible to tell Equinox to load plugins from more
> than one directory - unfortunately I have not had much luck finding the
> documentation on how that works, maybe someone else on this news group
> has more information.
Re: Eclipse 3.4 - .war deployment of a standalone help system [message #615234 is a reply to message #473910] Fri, 13 June 2008 11:35 Go to previous message
Eclipse UserFriend
Originally posted by: eclipse.maxant.co.uk

ive written a tutorial:

http://blog.maxant.co.uk/pebble/2008/06/09/1213043100000.htm l

cheers,
ant


"Kitty Ohman" <kohman@sybase.com> schrieb im Newsbeitrag
news:cf46c1d3fc46a9191477a5265645b84a$1@www.eclipse.org...
> Hello,
>
> Am hoping for advice on how to package and deploy the base eclipse help
> system as a .war file and package and deploy the contents for the help
> system as separate components.
>
> We are currently working on a 3.4 infocenter implementation -- the
> infocenter help system is launched from a java-based web application (not
> eclipse) as a help.war file. Our preferred strategy is to package the help
> contents as eclipse features/plugins in one or more separate war (or jar)
> files. The infocenter is launched from the web application by sending an
> http request to a Web server (Jetty) which hosts the application and help
> as a part of it. (https://somehost:8283/help/index.jsp). The Jetty process
> unpacks the contents of each war to a separate work location, however,
> when infocenter is launched, the contents pane in empty indicating that
> the content plugins are not being recognized. Following are
> observations/questions:
>
> 1) If all of the features/plugins for our content are packaged in the
> single help.war, the help system and contents display as expected. Our
> issue is occuring when we try to separate the content features/plugins
> from the base help.war. Our product is a framework into which a variety of
> components can be installed -- we need the flexibility to install docs to
> match the installed components.
> 2) It appears that the "unpack" process creates a work\<jetty work
> directory>\eclipse directory (a subset of the directory structure from the
> help.war)--- that contains configuration, features, plugins, and
> sub-folders. A platform.xml is also created in work\<jetty work
> directory>\eclipse\configuration\org.eclise.update. All of this is created
> before the application itself is even started, so it appears that some
> sort of loading is taking place. Is this configurable?
> 3) The use of a links directory was attempted -- while the help.war
> contained the links directory with a link file to the location of the doc
> plugin, this file was not unpacked to the subset work\<jetty work
> directory>\eclipse location (a full copy of the entire help.war is also
> unpacked to work\<jetty work directory>\webapps\WEB-INF). Is the links
> directory the right approach here? Should it be unpacked to the subset
> work directory? Because some loading takes place, is it necessary to
> launch with an argument (similar to -clean) that would clear that cached
> information?
> 4) I reviewed the suggestions in bugzilla 201666 -- question about having
> all of the files at the root level of the jar -- our output produces a
> feature (directory) and plugin (jar -- which puts the topic files at the
> root), but then I have been jar'ing the eclipse\feature and eclipse\plugin
> directories to a single jar for deployment. Is this approach correct?
>
> One final -- and basic question -- what are the benefits of .war
> deployment of the help system in general?
>
> Thanks in advance!
>
> Kitty
>
Previous Topic:Multiple help plugin directories for workbench and standalone help
Next Topic:nesting documentation
Goto Forum:
  


Current Time: Thu Mar 28 11:58:53 GMT 2024

Powered by FUDForum. Page generated in 0.04013 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top