Re: Jakarta download pages Was: download pages in j.a.o.
On 28 Dec 2004, at 20:43, Martin Cooper wrote: On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: 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. I actually think that page is horrible. Almost the entire page is filled with stuff the user doesn't care a whit about - a big list of mirror sites. The vast majority of users don't care about mirror sites, they just want to download what they want. The list of mirror sites should be stashed away in a drop-down list, as we have it now. horrible it might be but it was also horribly effective at it's job (which was to stop using download direct from apache.org). however, i think that users have got used to downloading from mirrors now so the time's probably ripe for change. I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi this would be a more workable approach. I don't see a need to have one page with all of the available downloads (with the possible exception of Commons, but I'm not sure we need that either). it's better but would require some effort. it's also quite a PITA for non-members (changes would be required to some scripts which is what stopped me last time i thought about revising the download pages). any members with good infrastructure links feel like volunteering...? i actually think that henri's idea about a single summary page for each sub-project would be a good idea containing mailing lists, a brief description, downloads and so on. would make it easy to add redirects later (as projects moved to top level). it'd make some sense in terms of making jakarta more like a portal and less like an ASF mini-me. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
Henri Yandell wrote: On Tue, 28 Dec 2004, Phil Steitz wrote: Henri Yandell wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip You can link directly now, using the anchors in the main Jakarta download pages, e.g. http://jakarta.apache.org/site/binindex.cgi#commons-math Yep. There are two poor things about this: 1) As with the new header, it means most people jump the text on keys/md5 etc. Ack. Had not thought about this. I guess that's why most do not link directly now... 2) It seems pointless from a user point of view. The bit they're interested in is very small compared to the size of the whole page they're being dumped in. Agreed in general, though grabbing multiple commons components is something that some people need to do now and then (at least I have). The struts download page is a lot nicer from a user point of view, though one criticism is that the pgp/key stuff is at the bottom of the page there and unlikely to be seen by a downloader too. It's also serving more than one file. I'd like to see each project with links to something like: http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip which would show a page that automatically does the pgp/md5 blurb, links to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles the mirror stuff. We'd use the download.cgi for both binary and source. Sounds good to me. In this case, would we rectify the old "components" j-c page to present download links to each of the commons components? Phil Hen - 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]
Re: Jakarta download pages Was: download pages in j.a.o.
I'm late to this discussion, so pardon if I'm rehashing something said earlier. It would be very advantageous to consider how the ASF Repository factors into the the download picture. I've been hoping to see some integration between the contents of dist and those of dist/java-repository. The ability of the repository download requests to be sent to the mirrors using closer.cgi or something similar would be very powerful. This url structure would be something that helped. http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip Pointing Maven at the asf repository as: http://www.apache.org/download.cgi/repository http://www.apache.org/download.cgi/repository/commons-lang/jars/commons-lang-1.4.jar would begin to use the mirrors more appropriately (if the maven client handles redirects appropriately. better yet, how about a separate virtual host just for downloads that is an implementation of the ASF Repository. http://download.apache.org/jakarta/commons/lang/jars/commons-lang-1.4.jar http://download.apache.org/struts/distributions/struts-x.x.zip http://download.apache.org/xml/xerces/jars/xerces-x.x.jar http://download.apache.org/xml/xerces/distributions/xerces-x.x.zip the download.cgi could handle all requests to the virtual host and properly redirect the user to a mirror. -mark Henri Yandell wrote: On Tue, 28 Dec 2004, Phil Steitz wrote: Henri Yandell wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip You can link directly now, using the anchors in the main Jakarta download pages, e.g. http://jakarta.apache.org/site/binindex.cgi#commons-math Yep. There are two poor things about this: 1) As with the new header, it means most people jump the text on keys/md5 etc. 2) It seems pointless from a user point of view. The bit they're interested in is very small compared to the size of the whole page they're being dumped in. The struts download page is a lot nicer from a user point of view, though one criticism is that the pgp/key stuff is at the bottom of the page there and unlikely to be seen by a downloader too. It's also serving more than one file. I'd like to see each project with links to something like: http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip which would show a page that automatically does the pgp/md5 blurb, links to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles the mirror stuff. We'd use the download.cgi for both binary and source. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: download pages in j.a.o.
Martin Cooper wrote: > 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. ;-) Makes sense. O.K. I'll do after January 10 (next year). 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: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004, Phil Steitz wrote: Henri Yandell wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip You can link directly now, using the anchors in the main Jakarta download pages, e.g. http://jakarta.apache.org/site/binindex.cgi#commons-math Yep. There are two poor things about this: 1) As with the new header, it means most people jump the text on keys/md5 etc. 2) It seems pointless from a user point of view. The bit they're interested in is very small compared to the size of the whole page they're being dumped in. The struts download page is a lot nicer from a user point of view, though one criticism is that the pgp/key stuff is at the bottom of the page there and unlikely to be seen by a downloader too. It's also serving more than one file. I'd like to see each project with links to something like: http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip which would show a page that automatically does the pgp/md5 blurb, links to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles the mirror stuff. We'd use the download.cgi for both binary and source. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
Henri Yandell wrote: On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip You can link directly now, using the anchors in the main Jakarta download pages, e.g. http://jakarta.apache.org/site/binindex.cgi#commons-math I notice that some projects use direct links like this from their project pages and some do not. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004 18:23:37 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Tue, 28 Dec 2004, Martin Cooper wrote: > > > On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell > > <[EMAIL PROTECTED]> wrote: > >> > >> 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. > > > > I'd be fine with getting rid of separate sections for these, and > > simply putting RCs in the main section, but that presupposes that we > > want to mirror RCs... > > Should RC's even be on this page? The reality is that currently we list > about 3% of all the RC's made. It would make sense for subprojects whose RCs would cause significant bandwidth consumption. However, I think the only subproject that would likely cause such volumes today is Tomcat, but they don't have RCs. (Struts used to put RCs on this page when we were in Jakarta, to take the load off the ASF servers.) So you may be right - maybe this section should go. > > I'm going to kill the Demo Build section as the only link (Velocity demo) > fails. > > >> 3) Why advertise related projects? They're in the navbar about an inch > >> away. > > > > I think the original purpose of this section was to provide links to > > projects that had moved out of Jakarta to TLPs. It would help people > > who were not yet aware that a project had "gone TLP". Now, however, > > that section seems to have a lot more in it, making it somewhat less > > meaningful. It might make sense to reinstate the original purpose, > > listing only "graduated" projects and renaming the section to reflect > > that. > > Switching to Graduated. > > I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and > XML as ones I don't think came from Jakarta. Hard to say with Gump, DB, > Web Services. I'm not sure if bits didn't exist in Jakarta. Gump originated at Jakarta, certainly. -- Martin Cooper > (at least, I'm doing this. Should be live relatively soon) > > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004, Martin Cooper wrote: On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: 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. I'd be fine with getting rid of separate sections for these, and simply putting RCs in the main section, but that presupposes that we want to mirror RCs... Should RC's even be on this page? The reality is that currently we list about 3% of all the RC's made. I'm going to kill the Demo Build section as the only link (Velocity demo) fails. 3) Why advertise related projects? They're in the navbar about an inch away. I think the original purpose of this section was to provide links to projects that had moved out of Jakarta to TLPs. It would help people who were not yet aware that a project had "gone TLP". Now, however, that section seems to have a lot more in it, making it somewhat less meaningful. It might make sense to reinstate the original purpose, listing only "graduated" projects and renaming the section to reflect that. Switching to Graduated. I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and XML as ones I don't think came from Jakarta. Hard to say with Gump, DB, Web Services. I'm not sure if bits didn't exist in Jakarta. (at least, I'm doing this. Should be live relatively soon) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004, Martin Cooper wrote: I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't have to really care about it; ie) they'd just link to: http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip or whatever. this would be a more workable approach. I don't see a need to have one page with all of the available downloads (with the possible exception of Commons, but I'm not sure we need that either). User's have different ways of wanting to find a solution. To find 'Struts Download', some may look for Struts, then Download; while others may look for Download, then Struts. That's not a justification for having a page with all available downloads, just an attempt at a justification for my index-page idea. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > 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. I actually think that page is horrible. Almost the entire page is filled with stuff the user doesn't care a whit about - a big list of mirror sites. The vast majority of users don't care about mirror sites, they just want to download what they want. The list of mirror sites should be stashed away in a drop-down list, as we have it now. I think, if we had a standard "template" for download pages, each subproject could have its own download page, something like we have for Struts: http://struts.apache.org/download.cgi this would be a more workable approach. I don't see a need to have one page with all of the available downloads (with the possible exception of Commons, but I'm not sure we need that either). > 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. I'd be fine with getting rid of separate sections for these, and simply putting RCs in the main section, but that presupposes that we want to mirror RCs... > 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. Yep. > 3) Why advertise related projects? They're in the navbar about an inch > away. I think the original purpose of this section was to provide links to projects that had moved out of Jakarta to TLPs. It would help people who were not yet aware that a project had "gone TLP". Now, however, that section seems to have a lot more in it, making it somewhat less meaningful. It might make sense to reinstate the original purpose, listing only "graduated" projects and renaming the section to reflect that. > 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. Yep. > 5) Agreed, Commons needs some kind of grouping to bring it together. I think Commons needs its own page to sort out all of the components, instead of trying to deal with a large number of artifacts of one subproject on the same page as all the other subprojects. -- Martin Cooper > That's it. Hopefully much f
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004 08:19:09 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Tue, 28 Dec 2004, Oliver Zeigermann wrote: > > > On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell > > <[EMAIL PROTECTED]> wrote: > > > >> 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 > > > > I thought a milestone is very different from an RC. A milestone is > > something even *before beta* feature freeze with only partial features > > implemented. An RC is *after* beta directly before or even identical > > to the the final release. I may be wrong, though... > > I thought so too, until I looked at the actual downloads we have under the > Milestone section. They're all RC's, and a tiny handful of the huge number > of RC's that Jakarta produces. With a night's sleep behind me, I'd like to > kill both the Demo and Milestone sections of the Jakarta index. > > Sub-projects can (and will I'm sure) still make them, we just wouldn't > bother to index them at the top level. Slide 2.1 had at least one (real) milestone in it's release cycle, but I guess it would be ok to have it accessible from Slide's pages only. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Tue, 28 Dec 2004, Oliver Zeigermann wrote: On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: 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 I thought a milestone is very different from an RC. A milestone is something even *before beta* feature freeze with only partial features implemented. An RC is *after* beta directly before or even identical to the the final release. I may be wrong, though... I thought so too, until I looked at the actual downloads we have under the Milestone section. They're all RC's, and a tiny handful of the huge number of RC's that Jakarta produces. With a night's sleep behind me, I'd like to kill both the Demo and Milestone sections of the Jakarta index. Sub-projects can (and will I'm sure) still make them, we just wouldn't bother to index them at the top level. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta download pages Was: download pages in j.a.o.
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote: > 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. The fact that Jakarta is an umbrella and then commons is an umbrella inside it was confusing me for a while and I know of many people who still are confused about that. Maybe a bit OT, but I really like the idea of Jakarta becoming an extended commons project with all larger projects going TLP. > 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 I thought a milestone is very different from an RC. A milestone is something even *before beta* feature freeze with only partial features implemented. An RC is *after* beta directly before or even identical to the the final release. I may be wrong, though... Oliver - 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]