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]
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]
License issue
Hi, I have a question containing different licenses. As far as I understand, we are not allowed to ship JARs (for dependency) that are under LGPL. What would be with BSD License? Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: License issue
-Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Hi, I have a question containing different licenses. As far as I understand, we are not allowed to ship JARs (for dependency) that are under LGPL. What would be with BSD License? BSD dependencies are fine. Simply make sure you are following the license and include any necessary notices or copyright messages in your NOTICE file. jaaron - 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 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: Cleaning up Site2
On Tue, 28 Dec 2004 00:35:08 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: 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. Fine with me. I had no idea it was there. ;-) 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. I would be +0 for just using Ant's xslt (a.k.a. style) to kick off a simple XSLT conversion along with a CSS stylesheet. (I would be +1 if I was more practised in the use of these myself.) This is how we generate the Struts documentation, and it's worked well for us. Also, I suspect that using XSLT instead of Anakia would open up the possibility of more contributors, and using CSS would allow for some folks to come up with a much snazzier site much more easily. 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. I'd say just require JDK 1.4 and a recent version of Ant, and you're all done. The lib directory can go. 5) Really contraversial: Killing dead pages. idiot.html, jars.html, ide*.html, os.html, and of course jon.html. Probably other pages too. No opinion on this one. 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. If there's stuff that makes sense to move to the main ASF site, then we should do that. Other stuff, like perhaps the vendors page, might make more sense on the wiki. I'd be leery of moving too much out, though, since I suspect a lot of people don't think to look outside the Jakarta site for help. 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. The FAQs page is pretty big all by itself. Not sure how you're going to manage incorporating that into a 'one page index', but I'll look forward to seeing what you come up with. ;-) -- Martin Cooper 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.
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 food for thought. Hen On Mon, 27 Dec 2004, Martin Cooper wrote:
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: Cleaning up Site2
I'll go ahead and start making changes/cleanup in a steady manner now that I've had a sanity check from Martin. While meritocracy is great, I'm very aware that meritocracy on Jakarta things could like despotism for me. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy worries
I'm not a fan of the mothballing concept as I understand its proposed implementation, but I agree that some process for officially relegating a project to maintenance mode may be necessary. In some sense, projects like oro and regexp have been victims of their own success. Both moved into Jakarta at a relatively feature complete stage and as a result there has been little demand for making enhancements or following through on suggested enhancements to the respective code bases. Given the widespread use of the software and its inclusion in commercial products like WebLogic and WebSphere, I think Jakarta's shepherding of these projects has done a lot of good. At some point, the Java standards process obviates the need for some software. java.util.regex has been influenced by, reinvented, and even borrowed features from at least oro, if not also regexp. Even with J2SE 5, we have seen the addition of a MatchResult interface that is very much like what has long been in oro. My first encounter with it was when it broke the JDK 1.5 Gump build because of class name aliasing. As more programmers migrate to J2SE 1.4 and 5, I really don't see any demand growing for oro and regexp. There are many things that could be done to continue development of the projects, but is there really a demand? I don't see it. As far as what to do, I don't think the projects need separate foo-dev and foo-user mailing lists. But it may be an unnecessary imposition on infrastructure to merge them into just [EMAIL PROTECTED] Here's a spontaneous and ill-thought suggestion. As a first step we could have a Legacy Products or Dormant Products section between Products and Related on the Jakarta pages. We could list dormant projects under that category. Then we can solicit volunteers from the PMC to be committers for each project to ensure that each has at least three. Volunteering means you agree to review and adddress patches and bug reports, vote on releases, etc., but not necessarily undertake new development initiatives (unless you want to). I volunteer to play that role for regexp and I'm pretty sure Vadim wouldn't have a problem doing so for oro. That gives us two committers for each and we'd need a third. From Noel's comments, it sounds like rounding up a quorum for BSF should be doable as well. If activity on a dormant project increases to the point the PMC volunteers are no longer needed to maintain 3 active committers, then the project can move back to the Products section. Otherwise, it stays in a dormant maintenance mode. At some point, if it can be established that a dormant project isn't being used, then I'm okay with the mothballing concept as I understand it. I just think there's a transition state. First we need to ensure oversight (3 PMC members monitoring the project) and then give the projects a shot at revival. Anyway, that's just a spontaneous suggestion I haven't thought through. With respect to oro and regexp specifically, one of the following might help even though I don't really expect them to reawaken: 1. merge oro-dev,regexp-dev,regexp-user,oro-user into just regexp@ 2. or move them into commons 3. or actually merge the code bases into one and work on a new API (I don't see this happening because it's a pointless exercise when there's no demand) Moving into commons is probably the best thing for oro because its io, util, and text packages have the potential to be incorporated into other commons components or be reinvented into something more text processing oriented and less regex oriented. That's just not going to happen given the status quo. Anyway, after the move to Subversion, moving into commons will be really easy (although we'll need a URL redirect and the build process will have to switch to maven). daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy worries
On Tue, 28 Dec 2004, Daniel F. Savarese wrote: suggested enhancements to the respective code bases. Given the widespread use of the software and its inclusion in commercial products like WebLogic and WebSphere, I think Jakarta's shepherding of these projects has done a lot of good. Yep, supporting stable yet inactive projects is definitely worth doing. While Alexandria and Watchdog are not believed to have any active users anymore, ORO and Regexp are likely to have active users for a long time. I'm +1 to changing the projects list on the site to represent some subprojects as dormant/dead and others as stable/inactive. As more programmers migrate to J2SE 1.4 and 5, I really don't see any demand growing for oro and regexp. There are many things that could be done to continue development of the projects, but is there really a demand? I don't see it. The only vague interest I have for a new ORO would be if it supported the Perl 6 changes to regexp. I imagine it'll be a while before Sun match these. As far as what to do, I don't think the projects need separate foo-dev and foo-user mailing lists. But it may be an unnecessary imposition on infrastructure to merge them into just [EMAIL PROTECTED] Here's a spontaneous and ill-thought suggestion. As a first step we could have a Legacy Products or Dormant Products section between Products and Related on the Jakarta pages. We could list dormant Oops, I +1'd too early :) projects under that category. Then we can solicit volunteers from the PMC to be committers for each project to ensure that each has at least three. Volunteering means you agree to review and adddress patches and bug reports, vote on releases, etc., but not necessarily undertake new development initiatives (unless you want to). I volunteer to play that role for regexp and I'm pretty sure Vadim wouldn't have a problem doing so for oro. That gives us two committers for each and we'd need a third. From Noel's comments, it An important point of a dormant project would be that the 3 PMC volunteers are specified somewhere; preferably on that projects site. Technically we have 3 PMC members on every subproject, but the reality is that often their interest level does not match the fact they have CVS access. First we need to ensure oversight (3 PMC members monitoring the project) and then give the projects a shot at revival. Anyway, that's just a spontaneous suggestion I haven't thought through. I like it. What do we do if we can't find the volunteers? With respect to oro and regexp specifically, one of the following might help even though I don't really expect them to reawaken: 1. merge oro-dev,regexp-dev,regexp-user,oro-user into just regexp@ Very tempting to start by moving the two oro lists over to the two regexp lists. While oro is the fuller codebase, regexp has the better name. 2. or move them into commons No rush I think, but long term a useful idea. My interest in oro/regexp is such that I've been able to easily see that Vadim and yourself were maintaining sufficient oversight on the two regexp projects. The worry would be if the two of you vanished/idled/got bored. 3. or actually merge the code bases into one and work on a new API (I don't see this happening because it's a pointless exercise when there's no demand) Yeah, pointless. 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: Dormancy worries
Henri Yandell wrote: On Tue, 28 Dec 2004, Daniel F. Savarese wrote: snip/ Then we can solicit volunteers from the PMC to be committers for each project to ensure that each has at least three. Volunteering means you agree to review and adddress patches and bug reports, vote on releases, etc., but not necessarily undertake new development initiatives (unless you want to). I volunteer to play that role for regexp and I'm pretty sure Vadim wouldn't have a problem doing so for oro. Count me in. snip/ With respect to oro and regexp specifically, one of the following might help even though I don't really expect them to reawaken: 1. merge oro-dev,regexp-dev,regexp-user,oro-user into just regexp@ Very tempting to start by moving the two oro lists over to the two regexp lists. While oro is the fuller codebase, regexp has the better name. If that will not happen, I'm ok to subscribing to oro-dev. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy worries
Henri Yandell wrote: JServ, Watchdog and Alexandria are both dormant as far as I know. The mailing list for Alexandria needs to be closed down, so I'll take care of making that happen. Depends how you define dormant. There is _very_ occasional use of Watchdog when we do a Tomcat 4 release. This is itself a pretty rare event but I can see there being at least one further Tomcat 4 release. I don't see Tomact 4's use of Watchdog being a sufficient driver for further commits to the Watchdog codebase. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dormancy worries
Henri Yandell wrote: JServ, Watchdog and Alexandria are both dormant as far as I know. The mailing list for Alexandria needs to be closed down, so I'll take care of making that happen. Depends how you define dormant. There is _very_ occasional use of Watchdog when we do a Tomcat 4 release. This is itself a pretty rare event but I can see there being at least one further Tomcat 4 release. I don't see Tomact 4's use of Watchdog being a sufficient driver for further commits to the Watchdog codebase. Mark - 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.
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: Cleaning up Site2
Henri Yandell wrote: I'll go ahead and start making changes/cleanup in a steady manner now that I've had a sanity check from Martin. While meritocracy is great, I'm very aware that meritocracy on Jakarta things could like despotism for me. Hen +1 on Henri being a temporary despot. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mess in jakarta.apache.org/
Worringly, this is just the flotsam lying around at the top level :) What on this list cannot be rm -r'd? There's usually one or two important ones in the pile of junk, so I'll be relatively careful. BUGS/ Copy of a CVS/. Odd. bcel.org/ Old copy of BCEL site. broken/ A maven repo by the looks of it. builds/ Old build system. Seems somewhat empty and broken. How long to maintain? buildsite.sh Something to do with TAC. Dead way to build site. cjan/ Dead java-repo for pre-cursor to Maven. commons-mavenized/ Old test Commons site. cvsweb/ Broken symlink. gump/ Entire site, though htaccess is redirecting. How long to maintain this? index-new.html Dead copy of index.html jakarta-gnats.tar.gz Dead bug tracking system. jjar/ Dead java-repo for pre-cursor to Maven. jmeter201/ Copy of JMeter site. Bizarrely seems to be kept up to date. log4j/ Entire site, though htaccess is redirecting. How long to maintain this? main.template Old dead file. ojb/ A simple redirect. How long to maintain this? oldsite.tar.gz Dead old file. pluto/ Entire site, though htaccess is redirecting. How long to maintain this? phoenix/ Broken symlink. resources A struts file. Odd. struts/ Entire site. Redirecting so not viewable. How long to maintain this? tac.jar Something to do with TAC. Dead way to build site. tomcat-4.0/ Bizarre. An installation of Tomcat 4. tomcat-old/ Old copy of Tomcat site. turbine.old/ Old copy of Turbine site. userGuide A struts file. Odd. 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, 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]
