[Jakarta Wiki] Updated: JakartaBoardReport-March2005
Date: 2005-03-15T01:50:47 Editor: RoryWinston Wiki: Jakarta Wiki Page: JakartaBoardReport-March2005 URL: http://wiki.apache.org/jakarta/JakartaBoardReport-March2005 no comment Change Log: -- @@ -68,6 +68,8 @@ Commons Net +Commons Net 1.3.0 was released in late December. This release contained a large number of enhancements and bug fixes, but the most important change was the addition of NTP/SNTP support. Since 1.3.0, there have been more enhancements to the FTP parser (currently in CVS), with the ultimate aim of making the FTP client configuration much more flexible and comsequently being able to support different locales seamlessly. This, plus other bug fixes currently in the works, will form the basis of the 1.4 release. + Commons Transaction Cactus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Updated: JakartaBoardReport-March2005
Date: 2005-03-15T01:51:42 Editor: RoryWinston Wiki: Jakarta Wiki Page: JakartaBoardReport-March2005 URL: http://wiki.apache.org/jakarta/JakartaBoardReport-March2005 no comment Change Log: -- @@ -68,7 +68,7 @@ Commons Net -Commons Net 1.3.0 was released in late December. This release contained a large number of enhancements and bug fixes, but the most important change was the addition of NTP/SNTP support. Since 1.3.0, there have been more enhancements to the FTP parser (currently in CVS), with the ultimate aim of making the FTP client configuration much more flexible and comsequently being able to support different locales seamlessly. This, plus other bug fixes currently in the works, will form the basis of the 1.4 release. +Commons Net 1.3.0 was released in late December. This release contained a large number of enhancements and bug fixes, but the most important change was the addition of NTP/SNTP support. Since 1.3.0, there have been more enhancements to the FTP parser (currently in CVS), with the ultimate aim of making the FTP client configuration much more flexible and consequently being able to support different locales seamlessly. This, plus other bug fixes currently in the works, will form the basis of the 1.4 release. Commons Transaction - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Updated: JakartaBoardReport-March2005
Date: 2005-03-15T02:08:20 Editor: RobertBurrellDonkin Wiki: Jakarta Wiki Page: JakartaBoardReport-March2005 URL: http://wiki.apache.org/jakarta/JakartaBoardReport-March2005 no comment Change Log: -- @@ -66,6 +66,9 @@ Commons Logging +Alpha release containing improved memory recycling during hot deployment in containers without explicit support for JCL. +Pushing towards a full 1.0.5 release. + Commons Net Commons Net 1.3.0 was released in late December. This release contained a large number of enhancements and bug fixes, but the most important change was the addition of NTP/SNTP support. Since 1.3.0, there have been more enhancements to the FTP parser (currently in CVS), with the ultimate aim of making the FTP client configuration much more flexible and consequently being able to support different locales seamlessly. This, plus other bug fixes currently in the works, will form the basis of the 1.4 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Javadoc management
Interested in finding out if anyone else thinks this would be a good idea. Rather than have each subproject managing their release javadocs separately, I think it would be good if we treated the javadoc more like the releases. Located in a central location, perhaps mirrored, all versions available and perhaps with additional tools like ashkelon or multidoc to bring them together. Subprojects would still be hosting their latest cvs head javadocs internally, but they would deploy a versioned javadoc as a part of releasing, and we wouldn't end up with the issue where users cannot view the latest released javadoc due to a site rebuild etc. Javadoc seems less important for some projects, Taglibs and Tomcat leap to mind, so it may not apply for all (though seeing a tag doc in javadoc style would rock). Anyway. Looking for community interest. If there, I'd make it my 2005 Q2 task, probably along with trying to hassle on LGPL stuff again. As it's my current weapon of choice, I'd probably end up with an xml/xslt solution much like the download stuff, so feel free to point out that that wasy crap. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc management
On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Interested in finding out if anyone else thinks this would be a good idea. Rather than have each subproject managing their release javadocs separately, I think it would be good if we treated the javadoc more like the releases. Located in a central location, perhaps mirrored, all versions available and perhaps with additional tools like ashkelon or multidoc to bring them together. Sounds good to me (assuming you mean all *released* versions available). On download pages, we could have binaries, sources and javadocs, with options for javadocs being download or view online (a bit like Sun's download pages). We might not need to mirror right away - we could wait to see how much this gets used. I'm not familiar with ashkelon or multidoc. What would they bring to the party? -- Martin Cooper Subprojects would still be hosting their latest cvs head javadocs internally, but they would deploy a versioned javadoc as a part of releasing, and we wouldn't end up with the issue where users cannot view the latest released javadoc due to a site rebuild etc. Javadoc seems less important for some projects, Taglibs and Tomcat leap to mind, so it may not apply for all (though seeing a tag doc in javadoc style would rock). Anyway. Looking for community interest. If there, I'd make it my 2005 Q2 task, probably along with trying to hassle on LGPL stuff again. As it's my current weapon of choice, I'd probably end up with an xml/xslt solution much like the download stuff, so feel free to point out that that wasy crap. 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: Javadoc management
On Tue, 15 Mar 2005, Martin Cooper wrote: On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell [EMAIL PROTECTED] wrote: Interested in finding out if anyone else thinks this would be a good idea. Rather than have each subproject managing their release javadocs separately, I think it would be good if we treated the javadoc more like the releases. Located in a central location, perhaps mirrored, all versions available and perhaps with additional tools like ashkelon or multidoc to bring them together. Sounds good to me (assuming you mean all *released* versions available). On download pages, we could have binaries, sources and javadocs, with options for javadocs being download or view online (a bit like Sun's download pages). We might not need to mirror right away - we could wait to see how much this gets used. Yep. Unsure if the download page would be the best place for the view online option though. I'm not familiar with ashkelon or multidoc. What would they bring to the party? Ashkelon is an alternative to javadoc really. You load the javadoc into a database and it gives you a searchable system and a slightly more descriptive version of javadoc. I've a basic version running at: http://issues.osjava.org/ashkelon/apis.do while http://www.jdocs.com/ have a more customised version. It requires a db and a tomcat server. Multidocs is a hack of mine. It scrapes from various existing javadoc urls and builds a wrapper around them: http://www.apache.org/~bayard/multidoc/commons-multidoc/ I also had it doing src xref, test coverage etc. Low cost, but all it really adds is a nicer way for the user to find the javadoc they want. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[site] kill proposal.html page
The following page looks very dated, and I suspect utterly dead: http://jakarta.apache.org/site/proposal.html I'd like to kill it, and will do if I hear no -1's by Friday evening. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Updated: SiteInfo
Date: 2005-03-15T23:07:55 Editor: HenriYandell Wiki: Jakarta Wiki Page: SiteInfo URL: http://wiki.apache.org/jakarta/SiteInfo Split into DONE and TODO sections Change Log: -- @@ -1,5 +1,28 @@ = Plan for the future of the Jakarta site = +== TODO == + + 1. Delete content: + a. Vendor page + a. Newsletter Editor page + a. Reference library + 1. Flatten Project Guidelines and all the other 'how to' pages into a shallower structure. + 1. Removal of dead pages: + a. packageversioning* (nothing links to this) + a. versioning.html (nothing links to this) + a. idedevelopers.html (nothing links to this) + 1. Move JSPA stuff to www.apache.org. ''Geir''. + 3. [EMAIL PROTECTED] considerations. Indexing systems for javadoc, jars, downloads etc. IRC channel? Java-based reference pages? + 5. Translation sites. What to do about them. + 6. Removal of information that may be found at [http://www.apache.org/dev/], the Incubator or other ASF locations. + 7. Download improvements: + a. Update to include nightly snapshots athttp://cvs.apache.org/snapshots/ + a. Change filenames from 1.0.zip to project-1.0.zip. Do this by making the name equal the filename if no name is specified. + a. Remove Commons from Commons components? + 1. Migration of reference pages into Foundation. ''Robert'' - '''ONGOING''' + +== DONE == + 0. 2005 copyright update. - '''DONE''' 0. Cleanup of dead parts of the site. - '''DONE''' 1. Removal of Anakia build and usage of Ant/XSL as the only build system. - '''DONE''' @@ -15,15 +38,11 @@ 1. Tighter front page (tighter welcome message, new text under Products) - '''DONE''' 1. Delete content: a. Remove licence renewal and news blog from Headlines section. Rename Headlines to News. -'''DONE''' - a. Vendor page a. Acknowledgements page - Redirect to http://www.apache.org/foundation/thanks.html - a. Elsewhere news - ''Hen'' + a. Elsewhere news - '''KEEPING''' a. Our Mission -'''DONE''' - a. Newsletter Editor page - a. Reference library a. Related project table -'''DONE''' (site/java_at_apache.html) 1. Rename Graduated to Ex-Jakarta. - '''DONE''' - 1. Flatten Project Guidelines and all the other 'how to' pages into a shallower structure. 1. Removal of silly pages: a. jon.html (and images) - '''DONE''' a. love.html - '''DONE''' @@ -32,22 +51,11 @@ 1. Removal of dead pages: a. methodology.html (nothing links to this) - '''DONE''' (redirect added) a. jakarta-site-*.html (4 pages, with various links to them; however the content is bad) - '''DONE''' (rewritten) - a. packageversioning* (nothing links to this) - a. versioning.html (nothing links to this) - a. idedevelopers.html (nothing links to this) - 1. Move JSPA stuff to www.apache.org. ''Geir''. 1. Move Legal link from navbar to bottom of page. -'''DONE''' 1. Migrate to Subversion - [Site2 Conversion Instructions]. - '''DONE''' - 1. Migration of reference pages into Foundation. ''Robert'' - '''ONGOING''' - 2. Improvement of download pages. Creation of cgi pages. - ''Hen'' - [DownloadPages] + 2. Improvement of download pages. Creation of cgi pages. - ''Hen'' - [DownloadPages] - '''DONE''' a. Remove other-releases.html page. - '''DONE''' - a. Update to include nightly snapshots athttp://cvs.apache.org/snapshots/ - a. Change filenames from 1.0.zip to project-1.0.zip. Do this by making the name equal the filename if no name is specified. - a. Remove Commons from Commons components? - 3. [EMAIL PROTECTED] considerations. Indexing systems for javadoc, jars, downloads etc. IRC channel? Java-based reference pages? 4. SVN information in addition to CVS information. - '''DONE''' - 5. Translation sites. What to do about them. - 6. Removal of information that may be found at [http://www.apache.org/dev/], the Incubator or other ASF locations. - 7. Posting of board reports to the site. - '''READY TO GO LIVE''' - http://jakarta.apache.org/site/pmc/board-reports.html + 7. Posting of board reports to the site. - '''DONE''' - http://jakarta.apache.org/site/pmc/board-reports.html 8. Move 'In Memoriam' to the whoweare.html page in Feb 2005. - '''DONE''' 9. Switch google link to a form. - '''DONE''' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Updated: SiteInfo
Date: 2005-03-15T23:12:19 Editor: HenriYandell Wiki: Jakarta Wiki Page: SiteInfo URL: http://wiki.apache.org/jakarta/SiteInfo New site tasks. Change Log: -- @@ -2,17 +2,17 @@ == TODO == - 1. Delete content: + 1. Delete: a. Vendor page - a. Newsletter Editor page - a. Reference library - 1. Flatten Project Guidelines and all the other 'how to' pages into a shallower structure. - 1. Removal of dead pages: + a. Newsletter Editor page - move to wiki? kill? + a. Reference library - partly to a generic Java page and partly to a generic CVS page. a. packageversioning* (nothing links to this) a. versioning.html (nothing links to this) a. idedevelopers.html (nothing links to this) + a. proposal.html (way out of date) + a. faqs.html + 1. Flatten Project Guidelines and all the other 'how to' pages into a shallower structure. 1. Move JSPA stuff to www.apache.org. ''Geir''. - 3. [EMAIL PROTECTED] considerations. Indexing systems for javadoc, jars, downloads etc. IRC channel? Java-based reference pages? 5. Translation sites. What to do about them. 6. Removal of information that may be found at [http://www.apache.org/dev/], the Incubator or other ASF locations. 7. Download improvements: @@ -20,6 +20,10 @@ a. Change filenames from 1.0.zip to project-1.0.zip. Do this by making the name equal the filename if no name is specified. a. Remove Commons from Commons components? 1. Migration of reference pages into Foundation. ''Robert'' - '''ONGOING''' + 1. Update mail.html page. Some lists may be dead and the stated noise of each list is incorrect. + 1. Generated project info pages to replace mail, cvs/svn, jira/bugzilla/scarab, wiki parts. Would also link to the download page for said project. Could grow to cover [EMAIL PROTECTED] + 1. Javadoc index/directory. + 3. [EMAIL PROTECTED] considerations. Indexing systems for javadoc, jars, downloads etc. IRC channel? Java-based reference pages? == DONE == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Updated: SiteInfo
Date: 2005-03-15T23:13:06
Editor: HenriYandell
Wiki: Jakarta Wiki
Page: SiteInfo
URL: http://wiki.apache.org/jakarta/SiteInfo
no comment
Change Log:
--
@@ -2,6 +2,8 @@
== TODO ==
+(''Hen'' unless otherwise stated or volunteers step forward)
+
1. Delete:
a. Vendor page
a. Newsletter Editor page - move to wiki? kill?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
