Spring, SourceForge, and Self Hosting
I recognize that SF provides a lot of free services and don't get much in return, but the value can still be less than zero for a user if they can never access the cvs repository.
[brianm@kite ~/src]$ cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/springframework login
(Logging in to anonymous@cvs.sourceforge.net)
CVS password:
cvs [login aborted]: recv() from server cvs.sf.net: Connection reset by peer
[brianm@kite ~/src]$
(Disclaimer on above snippet, I swapped sourceforge.net for its cname sf.net in order to make the preformatted example nicer on browsers -- I use the full aname to attempt checkouts.)
This is what I get at least two-thirds of the time I try access anonymous CVS on SF. Please consider Java.net, RubyForge, Apache, or Codehaus for your project hosting needs if you are going to build a real project!
Java.net has its quirks (most UI related, and incorrect docs for accessing CVS for some projects), but I have never seen its cvs servers go down. If it is a Java project you are considering putting on SF, consider Java.net.
RubyForge is running the SF software and focusing on Ruby projects. The guys running it are very active in the Ruby community, and I have yet to see a problem with the service. If you are starting a Ruby project, it is a no brainer.
Apache has somewhat more stringent requirements than SF, Java.net, or RubyForge, but they are requirements easily met by a strong project. The biggest requirement is a strong community around the project -- this ensures the project will continue, will grow, and will remain supported. Apache aims to provide strong projects long term, and the key factor there is the people working in the project -- smart, diverse groups of people and high bus numbers lead to long lived, truly useful projects with the best solutions to problems.
Codehaus is similar to Apache in that it is harder to bring a new project in, and there are definate requirements. Codehaus takes in projects that have high quality codebases, are very cutting edge, and it doesn't hurt if you know Bob the Despot or work for ThoughtWorks ;-) OTOH, two developer projects without an existing community can get hosted there if they are brilliant projects.
2 writebacks [/src] permanent link
The Object Transaction Manager is Supported in OJB 1.0!
Happy day, we decided to support the OTM in OJB 1.0. This is a really big deal as the OTM provides object space transactions, including distributed object space transactions, in non-managed environments. It makes the question "which API should I use in OJB" very easy to answer -- the OTM.
The other big benefit is real support for truly transparent persistence -- no need for makePersistent(...) calls as persistence by reachability (reference or collection) is implemented, so elements created via a simple new and added to a collection on a persistent object will be inserted automagically, as will direct references (1:1). Woot!
This was all doable under the ODMG API previously, but the PersistenceBroker API, despite being a lower level API, is just much nicer to use most of the time -- particularly for programmatic construction, and the PB style query-by-criteria and query-by-example type queries are both supported directly on the OTM.
The biggest deal is that the PB API being supported on the OTM makes implementing other query mechanisms really easy (JDO will be built on it, for example) as the PB is pretty much designed for use in building higher level API's (the current ODMG implementation is built directly on the PB, for 1.1 the ODMG layer will be moved to run on top of the OTM).
Side effect -- I have a lot of docs to write on the OTM and a very short time to do it before we release as the last couple bugs are about wrapped, and the biggest (a dedicated lock server for distributed object locks) is in as of this morning thanks to the indefatiguable Thomas Mahler.