Jakarta's mission
I know too well the problem of over-spamming a mail list with attempts at thought provoking emails, but I also know that time is nowadays a precious commodity so I'm going to spam away and see if anyone's not drooling out of their ears by the end of all these mails. Will keep this one short. I've long maintained that Jakarta has an identity crisis (which someone pointed out is not news and has been true for many years). I've realised by looking over the website and thoughts on the future that this is not quite true. Jakarta has many identities trying to fit into the one space. We have three that I recognise, and you can see these throughout the site. 1) Umbrella of server-side Java applications, specifically web containers/frameworks. 2) Umbrella of re-useable Java components. 3) Umbrella of [EMAIL PROTECTED] More a SourceForge foundry than an ASF umbrella. Taglibs is a wonderful subproject that even merges 1+2 to make things even more of a pain, though it's not as chaotic (in the good as well as bad sense of the word) as Coommons. You can see examples of 3) in the various 'Related' links on the site in which we attempt to maintain links to the parts of our community that have become TLPs. It's a mess. I'll stop before I ramble on too much. We're the information architecture equivalent of an Escher drawing and it's very thought provoking. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cleaning up Site2
The jakarta-site2 module is horrendously old, overpowered and creaky. There's support in there for using xml/xsl->html instead of anakia, and support for printable pages. I'm not sure the use of Anakia is even justified given the limited amount that is being done. In increasing order of effort level: 1) Running ant doc_print, I can't say I'm too excited by the printable page version. I'd like to scrap it. 2) There's an XSL variant of the site generation which may be used instead of Anakia. It's not used afaik and I think it should be ditched; except that: 3) Are we really using Anakia enough to make it worth it? It seems to me that it could easily be replaced with CSS and a single Java class to kick off a simple XML/XSL conversion of each xdoc to a doc. Even that might be overkill as I suspect we could just have regexp search and replace to achieve the same goal. 4) What should the min JDK be for building the Jakarta site? Is there any reason why it can't be 1.3/1.4 (whichever one gets sane XML-wise). ie) The lib/ directory should not be needed. 5) Really contraversial: Killing dead pages. idiot.html, jars.html, ide*.html, os.html, and of course jon.html. Probably other pages too. 6) Less contraversial (as no mention of Jon or idiots): Kill vendors page? How about legal and acknowledgements? Should these be under the ASF umbrella level now and not Jakarta specific. 7) Needs moving Geir: 'Apache on the JSPA'; jspa-position.html. 8) Faqs is something I would merge in with my 'one page index' idea with cvs/svn, javadoc, jars, source, binary, issue-tracking, mailing lists, wiki. I admit I may not get it all on one page :) The challenge is how to make a 50 x 10 table look good. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta download pages Was: download pages in j.a.o.
I spent a fair while walking circles in the basement (carrying the unhappy baby) and thinking on the download pages. My first thoughts were on what they exist for. From an info-arch point of view, they are a search system in addition to the project pages themselves. The fact that the project pages link back to them is a mistake on the usability side (though does make our lives fractionally easier). My next thought is, why are there separate pages for mailing lists, source code, cvs repositories, binaries? A lot of information is repeated in attempting to provide navigation to get to the part desired. One reason for the separate pages is so that separate information may be obtained, but I believe there is a different solution to that one. So as a general direction, I think we should have a single project summary page that provides the links to all the relevant resources. This does give us a problem with how to handle the context sensitive message of how to use the resource. I think that closer.cgi has the solution there: For example: http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0.2.exe It has problems. Mainly in that it doesn't really provide much a context sensitive message. It should be mentioning signatures, keys, md5s etc. It also loses the navigation of the project it's on and dumps you into a global Apache navigation. However, I think it's the right solution architectually. A dynamic page that contains a standard message and is filled with dynamic info. So I see the same thing existing for cvs/svn (context message is how to use cvs/svn etc), mail lists (usual message about politeness etc), downloads, jars (ibiblio links?), javadocs etc. Now, circling the basement is not conducive to coherence, or correct spelling I suspect, so I'm going to ramble a bit here in vague justification. Jakarta is different to other TLP's in that it's an umbrella. One of the reasons I like the approach above is that it is playing to Jakarta's role as an umbrella. Each project will link directly to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then provides an umbrella navigation system for when people want to see all this information from a single location and not click on each sub-project. --- Baby's feed is near an end I suspect, so I need to wrap things up a bit. Direct comments on the current binindex page (with srcindex inheriting most of these flaws): 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We have 1 demo build, and I thought we did RC's rather than Milestones. I'm not sure we even need to push the nightlies at this level; the project pages themselves should be fine as anyone looking for a nightly is probably deeply involved with that project as a user. 2) I'm not sure we need to advertise the Apache blog or Jakarta news here. It's on the front page, why use up valuable space. 3) Why advertise related projects? They're in the navbar about an inch away. 4) Same complaint as Martin has. Why have the download information if we let people click right past it. The table at the top is a noble effort, but I think we need a lot more to solve the problem. 5) Agreed, Commons needs some kind of grouping to bring it together. That's it. Hopefully much food for thought. Hen On Mon, 27 Dec 2004, Martin Cooper wrote: On Tue, 28 Dec 2004, Tetsuya Kitahata wrote: Just I've tried to improve the usability of Download Pages in jakarta.a.o. (by Adding "Table Of Contents" in "Release Source Drops" section) The problem I have with this change is that it pretty much guarantees that people will completely skip reading anything about the fact that they are downloading from a mirror site, and especially the fact that they need to verify the signature of what they download. If we could put that info before the links, I would be much happier. ;-) -- Martin Cooper http://jakarta.apache.org/site/binindex.cgi http://jakarta.apache.org/site/sourceindex.cgi The migration of CVS repository (jakarta-site2) into SVN had slipped my mind -- very sorry. -- BTW: Perhaps, commons-*** lines can be separated, by creating /commons/binindex.cgi plus commons/sourceindex.cgi and by adding these lines below to .htaccess in jakarta-site2 module (migrated into SVN?). | RedirectMatch ^/site/binindex.cgi#commons-(.*) http://jakarta.apache.org/commons/binindex.cgi#$1 | RedirectMatch ^/site/sourceindex.cgi#commons-(.*) http://jakarta.apache.org/commons/sourceindex.cgi#$1 (... not sure. I am not familiar with RedirectMatch.) Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-m
Re: download pages in j.a.o.
On Tue, 28 Dec 2004, Tetsuya Kitahata wrote: Just I've tried to improve the usability of Download Pages in jakarta.a.o. (by Adding "Table Of Contents" in "Release Source Drops" section) The problem I have with this change is that it pretty much guarantees that people will completely skip reading anything about the fact that they are downloading from a mirror site, and especially the fact that they need to verify the signature of what they download. If we could put that info before the links, I would be much happier. ;-) -- Martin Cooper http://jakarta.apache.org/site/binindex.cgi http://jakarta.apache.org/site/sourceindex.cgi The migration of CVS repository (jakarta-site2) into SVN had slipped my mind -- very sorry. -- BTW: Perhaps, commons-*** lines can be separated, by creating /commons/binindex.cgi plus commons/sourceindex.cgi and by adding these lines below to .htaccess in jakarta-site2 module (migrated into SVN?). | RedirectMatch ^/site/binindex.cgi#commons-(.*) http://jakarta.apache.org/commons/binindex.cgi#$1 | RedirectMatch ^/site/sourceindex.cgi#commons-(.*) http://jakarta.apache.org/commons/sourceindex.cgi#$1 (... not sure. I am not familiar with RedirectMatch.) Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
download pages in j.a.o.
Just I've tried to improve the usability of Download Pages in jakarta.a.o. (by Adding "Table Of Contents" in "Release Source Drops" section) http://jakarta.apache.org/site/binindex.cgi http://jakarta.apache.org/site/sourceindex.cgi The migration of CVS repository (jakarta-site2) into SVN had slipped my mind -- very sorry. -- BTW: Perhaps, commons-*** lines can be separated, by creating /commons/binindex.cgi plus commons/sourceindex.cgi and by adding these lines below to .htaccess in jakarta-site2 module (migrated into SVN?). | RedirectMatch ^/site/binindex.cgi#commons-(.*) http://jakarta.apache.org/commons/binindex.cgi#$1 | RedirectMatch ^/site/sourceindex.cgi#commons-(.*) http://jakarta.apache.org/commons/sourceindex.cgi#$1 (... not sure. I am not familiar with RedirectMatch.) Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Release of Slide 2.1
-Original Message- From: James Mason <[EMAIL PROTECTED]> Date: Sun, 26 Dec 2004 16:14:07 To:Slide Developers Mailing List , Slide Users Mailing List , "Jakarta Announcements (Mailing List)" , Jakarta General List , Jakarta Project Management Committee List <[EMAIL PROTECTED]> Subject: [ANNOUNCE] Release of Slide 2.1 The Jakarta Slide community is pleased to announce the release of Slide 2.1. This is a combined bug fix and feature release. Feedback is greatly appreciated, especially in the form of bug reports. You can download Slide2.1 from: http://jakarta.apache.org/slide/download.html Release notes are at: http://cvs.apache.org/viewcvs.cgi/jakarta-slide/RELEASE-NOTES-2.1?rev=1.1.2.1 The Slide project page is: http://jakarta.apache.org/slide -James (on behalf of the Jakarta Slide community) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sent wirelessly via BlackBerry from T-Mobile. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy worries
Noel J. Bergman wrote: I share your concerns. Same here! ...there was a poll about how many active committers are around on bcel-dev. IIRC *one* responded. Other than that there are just users around waiting for patches being applied or just lurking. http://marc.theaimsgroup.com/?l=bcel-dev&m=110294999712414&w=2 The general question is what to do with such projects, and I think we should be open to creative ideas. The question is whether those projects maybe missed to nominate some more committers? ...maybe it would be worth looking into the patch queue? Not applying patches is also one way to make people go away. There has been some suggestion that they be cleaned up by migrating them to some other domain to be mothballed. The code, web site, and mailing list archives would be preserved, and could be restored at such time in the future when a community might arise. Hmm... the question is whether we really *can* mothballing them. IMHO too many projects rely on them. It's an important piece of technology. At least bugfixes need to be applied. FWICS migration costs (e.g. to asm) are fairly high. There *are* people that have patches in the queue. BCEL and BSF both seem to be in danger of having no actual Apache >>community I only know about BCEL ...but that's for sure a danger I see too! cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scarab moved
Works for me (turbine, torque). Thanks a lot! Regards Henning On Sun, 2004-12-26 at 20:28 -0500, Noel J. Bergman wrote: > Scarab has been moved from nagoya to ajax. If you were referencing the > domain as issues.apache.org, which should have been the case for the past > year, you should not see any change. If you were referencing the nagoya > hostname, you should see a redirect. > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy worries
On Sun, 2004-12-26 at 11:48 -0500, Henri Yandell wrote: > ECS is another that I'm confident is being somewhat monitored. The ECS-dev > archive looks to be dead, so need to fix that. ECS is definitely one that > I wonder if the Commons community could be supporting; guess I need to > look at the code as my only worry would be that it's too large a codebase > to try to jam in. I'm watching ECS. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
