Welcome to the issue #1 of the Jakarta Newsletter. The aim of the newsletter is to try and let people know what's been going on in the jakarta projects when they have been unable to monitor all of them themselves. The editorship of the various sections and overall will probably vary which should hopefully lead to a fairly dynamic monthly newsletter.
So who's sending this to you? I'm a UK software developer working mainly with database webapps, with an interest in the development processes involved. My involvement at jakarta has been mainly as a user of various subprojects, a lurker on the general and commons-dev lists, a long time lurker and occasional conributor to Ant, and lately this Newsletter has become my pet project.
This month we have news based contributions from several projects and a plea for requirements from Avalon. I'd like to thank those who contributed and hope that you enjoy the read. If you would like to comment further on any of the highlighted discussions then please do so on the appropriate list, if you want to comment on the newsletter itself then please point your comments to firstname.lastname@example.org.
Editor: Rob Oxspring
Discussions on general have been fairly light weight this month. The main points have been in regard to issue #0 of the newsletter  and some discussion about how best to setup the scarab installation for bug reporting .
The other main "on topic" thread regarded java.sun.com's new look. Is it time for jakarta to have a facelift? can we learn lessons from sun? The answer seems to be wait for maven or forrest but generally the familiar open source rule of "your itch, you scratch it" applies . The same thread also discusses the idea of announced and arranged live chats about the various jakarta project with key developers on hand to help explain and assist.
Editor: Berin Loritsch
The Avalon team is in the process of identifying the requirements for a new version of the Avalon Framework. The changes are minimal, and focus on a tighter definition of the contract between the container and the component. The container is the code that manages all the components and how to access them. The Avalon team has identified some anti-patterns related to its use, and wants to provide a way to make it easier to use correctly.
What we want to find out from the community at large is:
1) Are you currently using Avalon in one of your projects?
2) If not, what would it take for you to consider using it on a future project?
3) If yes, what did you like best? What were your greatest challenges? If you could choose one way to improve Avalon, what would it be?
Slated for the next version of Avalon already:
1) Enhanced Meta Data. We are unifying the way we define meta data for the components. This allows the component to be used in any Avalon compliant container with zero issues. Previously you had to find out how any one container defined meta information (like version, whether the component is threadsafe or not, etc.).
2) (Tentative but likely) Standard way of extending the component lifecycle. Avalon already has a rich lifecycle management system, but sometimes you need an application specific extension. We have plans of allowing that to happen, and use any of the existing containers.
3) Enhanced tutuorials, user documentation. The new docs (when written) will focus first on how to use Avalon (the biggest complaint about our documentation). It will then present the anti-patterns that Avalon is supposed to address, and the patterns it uses to solve those issues.
Editor: Rob Oxspring
Conor MacNeill introduced some documentation about his Ant2 proposal and this lead to a discussion of how we could make ant projects more object oriented and reusable, including a look at how other systems achieve a similar result . In particular the Myrmidon Ant2 proposal featured with discussion moving onto whether templating could solve the problems being faced .
The cvs freeze for Beta3 went without a hitch [5,6] and in preparation for the release Erik Hatcher and Steve Loughran lead the way updating javadocs and manual entries for various tasks . In the aftermath of Beta3 some new version checks and diagnostic information have been discussed and added to aide users in getting the appropriate help later .
Among the task specific issues this month was a question regarding how best to add logging capabilities to elements below the task level, a number of solutions were volunteered with pros and cons to each . Lou Fox has been having some problems getting the regexreplace task to do what he wants with line endings , also the SOS and VSS tasks were treating some $ symbols a little differently to the rest of ant  . With luck the fixes should be part of Ant1.5
Finally, thanks to his contribtion in the form of the new Selector API Bruce Atherton was invited to join the team of committers .
Editor: Rob Oxspring
There were two main discussions applying to the whole of commons this month: Thanks to mass approval the new commons-user list was set up to allow users to find solutions without the intimidation of votes, commits and similar discussion . The more controversial discussion regarded the take up of maven betas for the build process in various components, can we require betas for building? can we drop ant support without a formal vote? See what you think .
Collections recieved a donation of code from avalon this month  and it was decided that some naming and layout conventions were needed [4,5]. The implementation of the primitive collections came under scrutiny as Ola Berg noticed that
Comparators came under discussion the month too: How should nulls be treated in comparators? The NullFirstComparator and NullLastComparators were proposed and implementations discussed . In collaboration with BeanUtils a BeanComparator was posted comparing the results of a method or property for order  although the class seems to be homeless at the moment. Also regarding collections was some discussion to the thread safety of StaticBucketMap  and a proposed reorganisation of util and collections .
CLI had some issues with how best to support options such as java's -D see the discussion  for full details. Plans are afoot to move into the commons proper and make a release, see the comments and action plan .
Betwixt also has plans to move to proper in preparation for a 1.0 release , but there may be some a couple of bugs to resolve first [15,16] along with some new features that Stephen Colebourne wants to add .
Elsewhere in commons there was the release for JXPath 1.0 , how the discovery package should discover its configuration  and a discussion as to the distinction between BeanUtils, Reflect and Introspect . Components new to commons were also proposed this month; Berin Loritsch introduced a component to find out how many CPUs are available on a machine and similar information , Patrick Luby is planning on separating tomcat's Daemon code into commons  and Avalon-Excalibur began the process of integrating its components into commons effort .
Editor: David Sean Taylor
The Jetspeed team has spent the month working towards the release of Jetspeed 1.4 Beta in early July. This is our first beta release, substantiating a significant improvement in quality and features. The Jetspeed 1.4 Beta release will include the following new features:
Editor: Ceki Gülcü
The month started with a question by John Armstrong  on whether log4j offered any guarantees on binary compatibility between various versions. To which Ceki replied by stating  the current policy of not removing deprecated methods until at least two release cycles are completed. This reply did not seem to satisfy John Armstrong and a long discussion ensued. A historical perspective  seemed to satisfy most people, at least the discussion petered off.
Mike McAngus started  a discussion about timezone and locale related issues in log4j date formats. James Cakalic and Mike discussed the importance of the decimal character separator. Possible performance improvements were also suggested. Mark Womack submitted code for timezone support for date elements of pattern layout. Unfortunately, the code was anonymous and we could not take into consideration. The idea seemed to catch on though.
Ceki asked for clarifications  on java buffered IO because his experience did not match the myth. Georg Lundesgaard mentioned  the character conversion buffering aspect as explained in the OutputStreamWriter javadocs.
Costin Manolache related his experience  with configuring log4j with JMX. He mentioned the web-application logging insulation problem. In response, Ceki wrote a specification  for solving the logging separation problem. This was followed by a promising discussion  on Tomcat-dev.
Mark made a proposal  for a new log4j component called "Receiver."
Editor: Otis Gospodnetic
1.2 released on June 12, 2002:
This is its first release since it migrated from Sourceforge to Jakarta. This release includes fixes for a number of bugs, improved query parsing, etc. All changes can be seen here: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-lucene/CHANGES.txt?rev=1.15
Lucene Sandbox repository has been added. The plan is to give the commit rights for that repository more freely, and allow developers to use that repository for storing outside contributions, so that we don't have to rely on mailing list archives. Also, the Sandox will, and already does, host some contributions that are still in development. Currently, a web crawler with hooks for text indexing with Lucene is being developed there: http://cvs.apache.org/viewcvs/jakarta-lucene-sandbox/contributions/webcrawler-LARM/
This project is looking for developers, so if you would like to get involved with web crawler and text indexing development, this is a good opportunity to do so.
Its well-written documentation is available in a few formats here: http://cvs.apache.org/viewcvs/jakarta-lucene-sandbox/contributions/webcrawler-LARM/doc/
Development of the next release, version 1.3, has started. Brian Goetz added preliminary support for range queries (<from date> TO <to date>), and we applied some contributed fixes that make it possible to use Lucene on read-only media, like CD-ROMs.
A list of items that we would like to work on in the future is listed in our TO-DO list: http://cvs.apache.org/viewcvs/jakarta-lucene/TODO.txt
I am in the process of applying patches/contributions that further improve the query parser by allowing Lucene API users to programmatically specify the logical operator between query terms that they want to use (AND or OR). In addition to that, a contribution burried in the list archives will advance Lucene's query support by allowing queries such as "Java app*" (find all documents containing a phrase "Java app", followed by anything). This will allow one to find documents containing either "Java application" or "Java applet" or anything else that starts with "Java app".
Editor: Thomas Mahler
OJB joined Jakarta in June!
ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that allows transparent persistence for Java Objects against relational databases.
OJB provides multiple APIs::
There has been a long discussion on using the commons-logging API for OJB. OJB currently uses its own wrapper API for logging. We came up with a proposal to extend commons-logging with features we need urgently for OJB logging .
There has also been a discussion on a proposal  that tries to define an implementation strategy for the new OJB JDO layer. Matthew Baird answered  that he will assemble a draft for a functional specification of the proposed Object Transaction Management layer. This document is almost finished and will be the base for our next implementation steps.
Editor: Daniel F. Savarese
Jakarta-Oro development has continued its trend of making small incremental additions and fixes in response to user requirements, rather than the major development initiatives that have been discussed. The most recent set of fixes and improvements were made available in a 2.0.7-dev-1 developer release on June 27th. The most pressing need for the project is the contribution of comprehensive unit tests for the core Perl regular expression classes. Without these, we will not be able to quickly press forward toward Perl 5.6 (soon 5.8) compatibility. Long term goals are to include factory class(es) for plugging in any regular expression package using the org.apache.oro.text.regex interfaces, provide a J2ME version of the package, and build more commonly used high-level text processing functionality into the package, becoming a general purpose Java text-processing toolkit rather than strictly a regular expression package.
Editor: Avik Sengupta
The POI team made two releases in June. A production release of version 1.5.1 on June 17, and a dev milestone release 1.7.0 on June 24. The dev release was notable for the inclusion of a large body of formula support. This was preceeded by some expected wrestling with the undocumented parts of the excel file format .
The dev list was animated for a while on the issue of whether poi should have a calculation engine built in. Andy summarised the discussion .
There have been many requests for a java viewer for excel files. Andy hacked up "Sucky Viewer" as a GUI component built on POI/HSSF .
Logging has been the cause of a large number of problem reports. It was therefore decided that POI would have logging disabled by default, and thus no extra libraries would be required to run POI . However, developers would have the option of enabling logging at runtime using either commons logging or log4j. This decision was further validated when there were reports of significant performance hit with logging enabled . As a result, the 1.5.1 and 1.7-dev versions have logging disabled.
The POI team is working towards a 2.0 release that adds the functionality for formula, charting and Word documents. There are many feature requests that have been asked for, but these are the top priority at the moment .
Editor: Joe Germuska
* Path-based action mapping in 1.1
* Tiles add-in to moved to core
* FormBean: Interface or Class?
* Struts and the Java Standard Tag Library (JSTL)
* New Committer: James Holmes
* Steps towards Struts 1.1b2
* Other Struts News:
* Struts News and Status page: http://jakarta.apache.org/struts/news.html
Editor: Shawn Bayern
On June 21, Jakarta Taglibs released version 1.0 of the "Standard Taglib," a compliant implementation of the JSP Standard Tag Library (JSTL), which is a new specification from the Java Community Process. The Taglibs group has also begun efforts to reorganize its web site and improve the process for responding to new submissions and ideas.
Editor: Henri Gomez
The TOMCAT 5.0 proposal was launched by Remy. The goal was to design the next generation Tomcat, using the best parts of Tomcat 3.3 and 4.x, using an improved version of coyote (2.0) code as the core, and using catalina 2.0 as the servlet container. The great thing in that proposal is that members from the 2 olds teams, 3.3 and 4.x agreed on contributing and working together putting the best they learn from 3.3/4.x. There was a proposal from the Avalon team to use Avalon as core, but it was rejected by Remy, who would prefer to have something more suitable and lighter for the TOMCAT core.
Pier then ask for a Tomcat HA (High Availability), arguing that Tomcat 4.x (he didn't speak about 3.2 or 3.3) was too unstable so it couldn't use it in his production site. There was then a lengthy discussion about stability which should be a major goal and so on. Many people (tomcat-dev) reported having no problems with Tomcat 4.0 or 3.3. Note, the thread was conducted at the same times that many of us performed extensive tests on mod_jk 1.2.0 and so tested the connector with Apache 1.3/2.0 and Tomcat 3.3/4.0.4 to detect failure in the connector (or in tomcat), and it appears that there are no major problems with both 3.3/4.0.4.
As some writers commented, the stability of a web application depends on many parts, tomcat being one of them, the real java application and remote side (SQL/enterprise applications) being also mandatory.
To summarise, I could say that all of us (tomcat developpers) want to have the stablest engine possible and the thread is open.
The major goals for Apache Tomcat 5.0 are to: