Bugzilla – Full Text Bug Listing
| Summary: | Allow projects to update their own Info Centers | ||
|---|---|---|---|
| Product: | Community | Reporter: | Ben Margolis <margolis> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | adolfosbh, david_williams, denis.roy, konstantin, stephan.herrmann, stepper |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Ben Margolis
Ben (or Saul?) and I chatted via IM today, and seemed like a good idea to me. I would assume "direct access" would be an unnecessary security risk, but was wondering if there could be something like the signing queue and process, where only some people are given write access to a special "project info directory" and a cron job could check there every so often and if a jar appeared there, would copy it to the right (more restricted) place. That give some restrictions and traceability of who contributed which jars. Naive question: the info center is not a p2-enabled application that could use auto-update in order to fetch help bundles from release repositories of individual projects? Maybe that would - if at all possible - open a whole new can of worms, just thought it could help decouple the questions (a) what bundles are in the info center and (b) which versions? (In reply to comment #2) > Naive question: the info center is not a p2-enabled application that could use > auto-update in order to fetch help bundles from release repositories of > individual projects? > > Maybe that would - if at all possible - open a whole new can of worms, just > thought it could help decouple the questions (a) what bundles are in the info > center and (b) which versions? I think this is an interesting idea ... I do not know if it could be done, or not. There might be someone who would know "off the top of their head" but suspect that code is so old, no one would know enough about it right off, nor how it is set up on eclipse, to know if that is possible. It'd be best (cool even) for someone to give it a try on their own little test server, and report back their success or not, with specific recommendations. Volunteers? :) (In reply to comment #3) > It'd be best (cool even) for someone to give it a try on their own little test > server, and report back their success or not, with specific recommendations. > > Volunteers? :) +1 One thing we're probably doing wrong with help.eclipse.org is instantiate one running instance of eclipse for each version of the docs. So essentially, help.eclipse.org is nothing more than 6 eclipses running, each taking their fair share of RAM, each having the infocenter listen on different TCP ports. We bring them all together with Apache proxypass directives. As I understand it, we could simply use Jetty, on one TCP port, and host all our docs on it. If anyone can proof-of-concept this, and a system to allow committers to publish their own docs, I'd certainly supply the servers. fyi, i'm a couple of weeks away from requesting an info center for the .8 release of the EDT project. thereafter, i'd be requesting updates about as often as the webmasters would allow. so, i'd be happy to be the test case for a new process. > One thing we're probably doing wrong with help.eclipse.org is instantiate one > running instance of eclipse for each version of the docs. So essentially, > help.eclipse.org is nothing more than 6 eclipses running, each taking their > fair share of RAM, each having the infocenter listen on different TCP ports. > We bring them all together with Apache proxypass directives. > > As I understand it, we could simply use Jetty, on one TCP port, and host all > our docs on it. To cross-reference discussion in Bug 379598, serving everything across releases with a single Jetty instance might work for static docs, but it will preclude supporting any form of dynamic content... Just to throw out a thought... If we had a tool to screen scrape contents of an infocenter into purely static content, then the resources to support help.eclipse.org would be drastically lower (no eclipse instances to run) and it would be cheap to support project-level infocenters for off-cycle releases. The trick is to actually screen scrape (as opposed to re-use the doc bundles) as screen scraping captures a snapshot of dynamic content that might be present in some doc bundles. I'm not sure if this is relevant but our build/promotion generates static info center-like doc pages. You can see them on each drop here: http://www.eclipse.org/cdo/downloads > I'm not sure if this is relevant but our build/promotion generates static info
> center-like doc pages. You can see them on each drop here:
> http://www.eclipse.org/cdo/downloads
How do you produce this?
> I'm not sure if this is relevant but our build/promotion generates static info
> center-like doc pages. You can see them on each drop here:
I love it. I really do.
Thanks ;-) The doc plugins are generated locally, mostly because Buckminster would either not create new version qualifiers or new ones for each build. The first would cause the plugins not to update via p2, the latter would cause them to update even if there are no changes (our doc plugins are large and don't change often). A better (Hudson build based) solution to this problem would be appreciated. The doc plugins currently consist of javadocs, extension point docs and so called "articles". The articles are also authored as java classes with javadocs directly in the src folder of the doc plugins. The doc generator applies self-made doclets to produce the HTML with nice features, such as - Excel table rendering, http://download.eclipse.org/modeling/emf/cdo/drops/S20120605-0730/help/org.eclipse.emf.cdo.doc/html/reference/MappingStrategies.html - Rendering of real code snippets (that participate in refactorings) into something that looks like a screenshot but is copyable text, http://download.eclipse.org/modeling/emf/cdo/drops/S20120605-0730/help/org.eclipse.emf.cdo.releng.help/html/writer/examples/CreatingTransportConnections.html - Rendering of XML files, http://download.eclipse.org/modeling/emf/cdo/drops/S20120605-0730/help/org.eclipse.emf.cdo.releng.help/html/writer/examples/XmlSnippets.html The source code for that is here: http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.releng.help/src/org/eclipse/emf/cdo/releng/help/writer/examples The generator for the entire docs is here: http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.releng.doc/build.xml The Ant scripts for the specific doc plugins are generated by AssembleScripts.java. --- Then we have a fully automatic promotion service (a cron job) that picks up new Hudson builds, copies them to downloads.e.o, post-processes the new drops and finally generates a set of composite repositories and the static downloads page. As part of the post-processing we unpack the doc plugins into a ".../drops/<build-id>/help" folder and insert the breadcrumbs into the HTML files. --- I hope this was not too confusing. I'm still exhausted from the release preps :P Current process seems to Just Work. |