Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
on 7/6/01 9:53 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: It would sure be nice to have a little HOWTO on what tags (like document and section) Anakia recognizes, and what they do :-). Anakia recognizes *any* tags. It is the Jakarta-Site2 module's stylesheet which is the key. Needless to say, I have now documented it: http://jakarta.apache.org/site/jakarta-site-tags.html Happy now? One more nail in this discussion's coffin. The same, of course, goes for the XSLT stylesheets, including stylebook, that are used in various projects. Yup. -jon
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Sat, Jul 07, 2001 at 05:11:04PM -0700, Pier Fumagalli wrote: Quoting Aaron Bannert [EMAIL PROTECTED]: d) jakarta-tomcat-connectors (* Pier is working on this, I've submitted Hold it... Pier is working on the new build for the WebApp Module, and the documentation related to it... I never said I'm going to take care of the documentation of all jakarta-tomcat-connectors :) :) :) Whoops, sorry. I knew that, but it slipped out. :) -aaron
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Fri, Jul 06, 2001 at 10:06:21PM -0700, Craig R. McClanahan wrote: * Docs should live in the source tree of the project that they are about. Although Henri's suggestion for jakarta-tomcat-docs is noble, what you'll find in practice is that there is very little documentation that is relevant across multiple versions of Tomcat. That remains to be seen. My gut tells me the opposite. I'm thinking connectors, classpath issues (though some details are different with Catalina, a lot are the same), web.xml docs, authentication, performance-tuning a web app... I'd love to get your input on the outline I just posted if you get around to it -- tell me which sections are definitely different between 3 and 4. The current situation with the docs on the site for 3.2 and 3.3 illustrate the problem with fragmenting two doc trees that are actually very similar. Any reorganization or new docs or error fixing will need to be propagated back to the 3.2 branch, which will be a terror to maintain. I feel the same thing could easily happen with 4.0 vs 4.1 in the near future. * The files that are checked in should only be the XML sources, *not* the generated files. This varies from what Jon set up in jakarta-site2, based on long and drawn out earlier discussions (same issues as those surrounding checking JAR files into CVS :-). +1 .xml = .java, .html = .class ./build.sh docs would generate the html directory -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
Providing Tomcat documentation in a WAR file is a little like providing a VHS tape on how to setup your VCR. It may seem really elegant to have on-the-fly style-generating documentation, and I may be alone on this, but I think that the majority of the user-oriented documentation should just be plain text. (By 'user-oriented documentation' I specifically mean build instructions and deployment configuration docs). It would be in a WAR file as HTML. The build would do the transformation and create the WAR file. Two things: 1) Users may be confused as to where the docs went if they don't see a /docs directory. Solution (one of many): have /docs/readme.txt with a pointer back to /INSTALL.txt. A quick-install guide would be pretty short... 2) Why have the docs as a web app? I'm not sure I see the benefits yet, aside from being able to have a pointer to the docs from the ROOT/index page. - r
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Sat, Jul 07, 2001 at 09:25:46AM -0700, Craig R. McClanahan wrote: Yes, we obviously need pointers in a top-level README on where the docs went. I'm willing to collaborate on these types of docs. On a slight tangent, I'd like to point out that we could use more STATUS and README documents, if only to serve the purpose of a signpost for current and new developers. *Every* CVS module that is a work-in-progress should have some sort of STATUS document, as well as a README describing what the repository contains. The first serves as a road map for any new developers who want to get into the source. The second serves as a roadmap for new builders/testers who want to know what the heck they're looking at. Also, on my list of high level desires, I forgot to include one: * All of the Tomcat documentation should be visible online at the Tomcat web site. which can (at least partially) deal with Alex's how do you set up the VCR issue :-). ( s/Alex/Aaron/ :) That will partially satisfy me, but not everyone has fully-connected high-speed internet access and graphical browsers (at least not while they're trying to get Tomcat working). I'd still like to push for plain text documentation for each of the following: 0) README and STATUS in each of a) jakarta-tomcat-4.0 b) jakarta-regexp c) jakarta-servletapi-4 d) jakarta-tomcat-connectors (* Pier is working on this, I've submitted the beginnings of a README) e) the various TC3.x repositories that I'm less familiar with 1) build instructions for each. Not extensive, just simple bootstrapping instructions, maybe even just in the README. 2) [basic] configuration instructions. Again, not extensive, but enough to get it up. Maybe a recipe that would answer questions like: a) What goes in server.xml? b) How do I start/stop TC? c) What must be already installed in order to run TC? (JDK version, etc...) Who's with me on this? I can submit an outline for each and let the people with more experience fill in the blanks. 2) Why have the docs as a web app? I'm not sure I see the benefits yet, aside from being able to have a pointer to the docs from the ROOT/index page. A couple of reasons: * Because we already do -- and it's quite convenient to be able to look at the docs once you get Tomcat started the first time. The problem today is that we are really overloading the ROOT web app, and it's not particularly well organized. I totally agree that it is convenient, but it may be harder for us to realize the difficulty in getting this beast rolling the first time from our altitude. We want every college student who has ever had any interest in Servlets/JSP running this thing on their home Linux/*BSD/WinXX (*gag*) machine, and they're only going to do that if the barrier to entry is well defined. -aaron
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
Quoting Aaron Bannert [EMAIL PROTECTED]: d) jakarta-tomcat-connectors (* Pier is working on this, I've submitted Hold it... Pier is working on the new build for the WebApp Module, and the documentation related to it... I never said I'm going to take care of the documentation of all jakarta-tomcat-connectors :) :) :) Pier
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Fri, Jul 06, 2001 at 10:06:21PM -0700, Craig R. McClanahan wrote: * Tomcat docs for a particular version should be delivered as one or more web apps (not necessarily the root webapp as is current practice). That way, the corresponding WAR files could be dropped into *any* container, or opened up and read directly from the filesystem. * At least two documentation webapps (developer-oriented and user-oriented) would seem to be appropriate. Having more than two will make it difficult to create reliable hyperlinks (since you don't have any control over the context path that someone uses to deploy). Although I find the rest of your comments on this topic both clear and refreshing, I'd like to point out a possible fallacy here: Providing Tomcat documentation in a WAR file is a little like providing a VHS tape on how to setup your VCR. It may seem really elegant to have on-the-fly style-generating documentation, and I may be alone on this, but I think that the majority of the user-oriented documentation should just be plain text. (By 'user-oriented documentation' I specifically mean build instructions and deployment configuration docs). Just my 2c, -aaron
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
Jon Stevens wrote: on 7/2/01 6:04 PM, Christopher Cain [EMAIL PROTECTED] wrote: I have no interest in Anakia, and quite frankly, as has been pointed out very astutely by Costin, I have no interest in bothering with XML for the purposes of documentation. I will produce HTML docs with my favorite editor and call it a task adequately completed. Asking anything beyond that will more than likely be more time and effort than I am prepared to invest in simple documentation. I bet you will only use a certain brand of toilet paper as well. Dunno. I let me girlfriend handle the tough decisions like that =) In short, let us please continue and decide upon how to proceed. Regardless of Jon's off-topic confusion, I would really like to know how the community would like to see any documentation which I may contribute. - Christopher That's good, cause I haven't seen you contribute anything so far, Ace. The answer is simple... ?xml version=1.0? document properties author email=[EMAIL PROTECTED]Christopher Cain/author titleCain's Documentation/title /properties body section name=Recent News p Mr. Cain actually writes a bit of documentation instead of threatening us with the idea that he might do it someday if we are lucky. /p /section /body /document :-) -jon Touche' ... that's fair. I have a small cache of docs that I never got around to submitting, partly because they are install/config docs (and the Tomcat install procedure has always been a moving target) and partly out of sheer laziness. I will bring them up to date and cast them to the dogs (tomcats?) before the next milestone. There now at least three different approaches being tossed around. As long as we come to one standardized solution, which I think is important, I'm personally pretty doc-program agnostic. If the XML solution being considered is as comparatively non-labor-intensive as the rather insightful example above, then you might indeed be lucky enough to have the gift of my documentation bestowed upon you =). My point, badly made to be sure, was simply that it would be a good idea to avoid over-engineering a doc solution. The more (most) people have to try and learn an extensive DTD or templating system, the less likely they are to bother. I have a feeling that there is an untapped wealth of docs and notes sitting around out there, written by admins and users for their own benefit in installation/configuration. The easier we make it, the more contributions we will undoubtedly receive. If a cohesive documentation system is decided upon, I would love to start contributing. I personally agree with Pier that documentation is easily as important than the product itself. I was very pleasantly surprised to see a thread seriously discussing the issue of the current catch-as-catch-can docs, and I got a little tweaked when it appeared that it would flame out without resolution. For all my criticism of you Jon, I do have to give you props on one thing. Of all the dev-list bullies I know, you are the only one who can take as much heat as you give, and do it with a smile. Plus most of the other bullies are so hopelessly overmatched in verbal exchanges that it almost isn't any fun. But you got flair, baby! =) - Christopher
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project :WAS:[TomcatDocu mentation Redactors To Hire]
on 7/3/01 11:50 AM, Christopher Cain [EMAIL PROTECTED] wrote: The more (most) people have to try and learn an extensive DTD or templating system, the less likely they are to bother. I agree. That is why I came up with Anakia. It is brain dead simple to use and runs extremely quickly. The DTD is a few simple XML tags and XHTML. I suggest that before you make any more comments, you spend some time looking at it. :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project :WAS:[TomcatDocu mentation Redactors To Hire]
Jon Stevens wrote: on 7/3/01 11:50 AM, Christopher Cain [EMAIL PROTECTED] wrote: The more (most) people have to try and learn an extensive DTD or templating system, the less likely they are to bother. I agree. That is why I came up with Anakia. It is brain dead simple to use and runs extremely quickly. The DTD is a few simple XML tags and XHTML. I suggest that before you make any more comments, you spend some time looking at it. The statement you quoted me on above was a caution in the abstract about standardizing on a complicated approach without having a few people willing to process user contributions, primarily so that we don't discourage such contributions. It was not directed at Anakia in particular, hence the or templating system. As I said, there are at least three different suggestions floating around out there, so this was simply my two cents on things to consider when deciding. I have absolutely no experience with any of the proposed products, nor have I ever pretended to. Anyway, since it sounds like Geir has graciously volunteered to help me form the Ministry of Documentation as he so cleverly coined it, the point is more or less moot now. Users can submit plain text if they like, and I certainly have no problems learning whatever the community decides upon. Everybody wins. Really, my man ... if you're going to take me to task on something, you're going to have to learn not to quote me out of context. It's so passe. For future reference, I never criticize an approach or product, especially on a dev list, without thoroughly edifying myself on the subject. (Yes, you can quote me on that. ) If you ever think that I have, then you have misunderstood me. Anyway, I had no idea that Anakia was your product. I will most certainly have a look and provide my official critique. Since your stance on JSP is dead-on accurate, and I hear that your replacement tool is actually something of an improvement, Anakia certainly deserves a look. - Christopher
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Mon, 2 Jul 2001, Rob S. wrote: 1) People don't like to write docs, and for an open-source project, I'd say that's perfectly cool so long as those same people are willing to have a read through the docs after a major update to make sure they're coherent ;) For ours especially, to author them is a pain in the arse. You should just have to worry about content, but 70% of it is cruddy HTML formatting. Would I'm not sure I understand that. There are plenty of HTML editors, and 99% of the people on this list know a bit of html. Nobody asked for good looking documentation or cool formats, the content is missing. We do need to reorganize the documentation and update it - and I agree with moving it part of a /doc webapplication ( instead of a doc directory - we can leave only the minimal README in tomcat/doc telling how to start tomcat in basic mode and look at the /doc webapp ). But I'm not sure it would be a good idea to use something else than HTML ( I actually think it would be a very bad idea at this point ). Then people will also have to worry about learning a new set of tags ( whatever dtd we use), not only about content, editors will be out of question, we'll have to spend time working on the transformation, etc. And we'll certaninly have some flame wars about what DTD to use ( docbook is the standard outside apache, stylebook is used in many apache projects - which one should we use ? Many believe the first is too complex, but some believe standards are important ). A good news - it seems AbiWord ( yet another editor ) can generate some basic docbook, and the gui is not that bad ( amazingly, it can save as palm pdb, as well as latex ! ). 2) Why don't (a lot) of people read them? I dunno... I know that personally, I have a tendency to gloss over mounds of documentation, even if My opinion - the documentation is not very well organized, I guess someone should own it and organize it as a book or as a standalone webapplication. Right now there are mostly a bunch of notes. Speaking of notes, it would be very cool if we start a new directory and colect the relevant mail from this list ( proposal, technical arguments, etc). The list is full of crap, and extracting the usefull info is quite difficult. Costin ( answering mail rather than writing the C code :-(
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
I'm not sure I understand that. There are plenty of HTML editors, and 99% of the people on this list know a bit of html. Nobody asked for good looking documentation or cool formats, the content is missing. Agreed, but using Note/Text/Whatever/Pad is what the majority of people end up using because WYSIWYG editors have a tendency to butcher the resulting HTML for the next poor sap to come along and edit it. insert years of notepad versus wysiwyg editors debate. As well, nobody's *asking* for good looking docs, but if someone's willing to put in the time and effort (e.g. myself), what else can it do other than help? ;) It's possible to have better-than-average-looking docs with a few well-chosen colours, etc. without burdening the build with images. We do need to reorganize the documentation and update it - and I agree with moving it part of a /doc webapplication ( instead of a doc directory - we can leave only the minimal README in tomcat/doc telling how to start tomcat in basic mode and look at the /doc webapp ). I fully agree with the reorganization since right now there isn't really any - aside from appdev having its own subdirectory. I'm not sure I understand the reasoning behind making the docs part of the ROOT (or /doc) web-app. I imagine to make them accessible from the default Tomcat homepage? How un/important is that? Either way, like I mentioned before - organization decision, not a doc author's =) But I'm not sure it would be a good idea to use something else than HTML ( I actually think it would be a very bad idea at this point ). Then people will also have to worry about learning a new set of tags ( whatever dtd we use), not only about content, editors will be out of question, we'll have to spend time working on the transformation, etc. Right now if you look under the Struts repository, you'll see that all of the documentation is *.xml, and I imagine the build is responsible for the transformation... I guess we'll have to talk to them to see how all of that is working out - what's the motivation? My opinion - the documentation is not very well organized, I guess someone should own it and organize it as a book or as a standalone webapplication. Right now there are mostly a bunch of notes. Yep, very much agreed. There needs to be some glue for all of the separate docs floating around, rather than combining them all into one big User's Guide. Costin ( answering mail rather than writing the C code :-( ...or writing docs! j/k of course =) So in a nutshell, here I am, raring to go on documentation. I guess I'll work on the TC4 INSTALL ??? to describe how to get the container up and running to view the docs. I'm really waiting for some guidance =) - r
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
If we can't get people to write documentation in HTML using any of the existing editors, I guess it'll be much harder to ask them to learn a XML DTD ( especially since the dtd is used only in apache, while the rest of the world is using the docbook ). And of course, force them to use notepad instead of wysiwyg ( even if docbook has some editors, they are either incomplete or too expensive ). Add to that the generation step ( where you compile the xml to see how it'll look in html ). We should try to hire some XML/XSL writers which could send us skeleton XML and XSL ?) It won't be much harder to edit XML with VI than HTML with NS/FP/DW I guess will have replies soon :)
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
At 10:09 AM -0400 7/2/01, Rob S. wrote: 1) Developers don't write them in lieu of coding. 2) Users don't read them 3...) ? http://www.c2.com/cgi-bin/wiki has a novel way of getting at the problem. Not a panacea obviously, but what is? The one at that address is perl-based; I can provide a tomcat/mod_jk/servlet based one if there's interest. -- --- For industrial age goods there were checks and credit cards. For everything else there is mybank.dom at http://virtualschool.edu/mybank Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
We should try to hire some XML/XSL writers which could send us skeleton XML and XSL ?) Look a everyother project ( almost ) in Jakarta, a quick peek will give a brief of what is doing people , and almost everybody is documenting projects in xml.., doing the processing in a mix of anakia/plain xsl.. So Jakarta is plenty of good examples ( better look at our brother TC4.0 or Struts i think they are doing his docs in plain XML/XSL) I'm +0 in xml efforts ( i'm writing my own docs in DocBook from some time ago, i'm used to nwalsh stylesheets btw ), But i share concerns expressed by Costin, so in this moment i'm totally +0 in this regards.. It won't be much harder to edit XML with VI than HTML with NS/FP/DW I guess will have replies soon :) TO write xml by hand can be a class of pain i do not recommend to anybody.., but not worse than to write html by hand.. and perhaps easiest than html.., but not with DocBook it's far bigger than the average human needs :), I think StyleBook is a subset of DocBook .., Pier can comment on this i think him was one of the StyleBook creators. Saludos , Ignacio J. Ortega
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
The Tomcat website is already generated with Anakia. It is trivial to add more .xml files to the site and there is absolutely no excuse to not just go that route. I just don't see the merits of this discussion. Go write documentation instead. -jon
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
on 7/2/01 6:04 PM, Christopher Cain [EMAIL PROTECTED] wrote: I have no interest in Anakia, and quite frankly, as has been pointed out very astutely by Costin, I have no interest in bothering with XML for the purposes of documentation. I will produce HTML docs with my favorite editor and call it a task adequately completed. Asking anything beyond that will more than likely be more time and effort than I am prepared to invest in simple documentation. I bet you will only use a certain brand of toilet paper as well. In short, let us please continue and decide upon how to proceed. Regardless of Jon's off-topic confusion, I would really like to know how the community would like to see any documentation which I may contribute. - Christopher That's good, cause I haven't seen you contribute anything so far, Ace. The answer is simple... ?xml version=1.0? document properties author email=[EMAIL PROTECTED]Christopher Cain/author titleCain's Documentation/title /properties body section name=Recent News p Mr. Cain actually writes a bit of documentation instead of threatening us with the idea that he might do it someday if we are lucky. /p /section /body /document :-) -jon
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project :WAS:[TomcatDocu mentation Redactors To Hire]
on 7/2/01 6:22 PM, Remy Maucherat [EMAIL PROTECTED] wrote: I was also wondering if it would be possible to add support for new tags. For example, tags to make it easier to write changelogs, status pages, news pages ... Remy Of course. http://jakarta.apache.org/site/jakarta-site2.html#Modification of the Website -jon
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
We've started writing some new docs in XML (catalina/docs/dev/xdocs). The HTML generation is done with XSL, but the DTD should be the same as the one used by Anakia. I noticed the xdocs directory, but I didn't see anything in there. I sent Craig an email about it a week ago, but haven't heard back from him. Am I doing something wrong? (re: CVS, not emailing Craig =) - rob web cvs weenie slifka
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
We've started writing some new docs in XML (catalina/docs/dev/xdocs). The HTML generation is done with XSL, but the DTD should be the same as the one used by Anakia. I noticed the xdocs directory, but I didn't see anything in there. I sent Craig an email about it a week ago, but haven't heard back from him. Am I doing something wrong? (re: CVS, not emailing Craig =) - rob web cvs weenie slifka It's in docs/dev/xdocs, not docs/xdocs : http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat-4.0/catalina/docs/ dev/xdocs/ Remy
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
Rob S. at [EMAIL PROTECTED] wrote: This seems to be one of the questions that comes up and never gets answered (re: docs, not Jon's behavior ;) I'm not sure what magical solution will get people to read docs. Frankly, I'd just like to get started. Anakia works for Jakarta, it works for Struts == it'll probably work for Catalina. Committers, [VOTE] on this? Personally, I don't think that Anakia is the _best_ solution ever invented, and Jon knows that I prefer XSLT to Velocity syntaxes, but so far there is no alternative option (don't even consider using StyleBook, OK? I wrote it and I deprecated it long time ago). Anakia has been proven to be a good option when it came down to the problem of building our website, and thank god that Jon made it... And so, by big +1 on using Anakia for our docs... (And if something gets out in the future which is better - I'm not implying anything here - we can decide whether to switch or not... That's the f**king good part of XML :) Pier
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project :WAS:[TomcatDocu mentation Redactors To Hire]
Rob S. at [EMAIL PROTECTED] wrote: I noticed the xdocs directory, but I didn't see anything in there. I sent Craig an email about it a week ago, but haven't heard back from him. Am I doing something wrong? (re: CVS, not emailing Craig =) Hmm... Craig didn't answer since he's on vacation until next Monday/Tuesday... (Just a FYI) Pier
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
on 7/2/01 6:45 PM, Pier P. Fumagalli [EMAIL PROTECTED] wrote: Anakia has been proven to be a good option when it came down to the problem of building our website, and thank god that Jon made it... And so, by big +1 on using Anakia for our docs... (And if something gets out in the future which is better - I'm not implying anything here - we can decide whether to switch or not... That's the f**king good part of XML :) Pier +1 on both points. Anakia isn't gods solution yet, but it does the job just fine for about 10 different Jakarta projects and like Pier says...if someone comes up with a better solution tomorrow, it is easy to switch to it. p.s. The main apache.org site will soon be generated with Anakia as well. -jon
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
Jon Stevens at [EMAIL PROTECTED] wrote: +1 on both points. Anakia isn't gods solution yet, but it does the job just fine for about 10 different Jakarta projects and like Pier says...if someone comes up with a better solution tomorrow, it is easy to switch to it. That's why I _love_ XML so much... Almost like Java... You find a better OS/VM combination, just throw away all your old stuff and move onto the new platform... As Duncan used to say: Java, portable code. XML, portable data. p.s. The main apache.org site will soon be generated with Anakia as well. That's so cool... Ok, Jon... Before you actually do it, we _need_ to find a solution for mirrors (relative links for static stuff, absolute links for CGIs and Servlets) Pier
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
GOMEZ Henri at [EMAIL PROTECTED] wrote: Good idea, We could have a tomcat-doc mailing-list, but we'll still need to commit the material. I'd rather keep the documentation together with the project. When I (don't :) write the docs, I don't want to update two CVSes, we can give access to whoever wants to write it... Pier
