While searching wikis for examples of async and event oriented code, we landed instead in memory lane. Colleagues in the Turbine project in the early 2000s created Codehaus because The Apache Way felt too confining. We knew we were living in the future, even as we were creating that future.
Today's meander started here: Async Code In A Nutshell
> Once upon a time, I observed event-based computing in GUIs was showing up server-side: blog 
. I also claimed there that pipeline pattern and state pattern were duals. Do I finally live in a world where these reactive event streams flow from business analysis through the network all the way through the UI?
That link to our blog is gesturing at this:
> These decoupled states waiting for asynchronous events could even be web services in a pipeline, if you accept my theory that a pipeline is just an inside-out workflow. I still think there are interesting parallels between the asynchronous event-driven processing of GUI applications and similar asynchronous event-driven processing in Service Oriented Architectures. I don't think its any coincidence that SOAs and pipelines are getting some buzz these days. Finally, I'm still interested in a workflow engine supporting ad-hoc workflows.
"Workflows" reminded me of "werkflow" which may have been an early name for drools. It was here that searching reminded me of Codehaus. wayback
> The Codehaus was formally registered on 26 February, 2003. Bob 'The Despot' McWhirter had been active in open-source for several years, with projects such as Jaxen and Drools. > > For a while, The Werken Company hosted his projects along with the projects of a handful of other developers. > > The Codehaus "brand" was created to allow for a neutral environment for non-Werken people to host their projects. Mostly, this was due to several folks thinking that Xulux was a project of The Werken Company since it was hosted on our server. > > The Codehaus helped to correct that misconception. kschrader publically announced the existance of the Codehaus a wee bit before Bob was ready for it. Oh well. > >Jason van Zyl was sharing the cost of the Werken hardware and didn't object to the formation of the Codehaus and is thus honored with the title of “The First Hausmate”. ... > Bob 'The Despot' McWhirter decided to go spend some time in Amsterdam, and the seed for the idea of the First Irregular Haus Party was planted. In October, 2003, over a dozen hausmates from across the globe assembled in Amsterdam for a weekend of brain-storming, pair programming, presentations about projects, and general socializing. It was at the Haus Party that Groovy was publically birthed.
That bit about groovy calls to mind an earlier trip down memory lane: Functions Rising blog
> I have an imaginary origin for Groovy, whether or not it actually happened this way in reality. First, I need to set the stage. I've been lurking around James Strachan and Bob McWhirter since meeting them through Jason van Zyl and Turbine and Maven. ... > Back to Groovy. I imagine that it was friction between James' interesting and useful work on Jelly and Bob's rightful distain of programming in angle brackets which spawned Groovy. Clearly there's some Jython, Python, and Ruby mixed in too as evidenced by the excellent use of closures and other functional goodness.
These threads have captured our attention for a very long time. Here they began weaving even in the earliest days of our blog: Unstarted Projects blog
- SVG Animations—blog
- Practical Internet Groupware—a book by Jon Udell who's writing originally introduced us to federated wiki.
- Werkflow, not Valves, PetriNets, Drools—state machines and data flow through graphs.
- SEDA—message oriented middleware with queues, anticipating service oriented architecture, eventually improved by kafka
- Online community development—focused on Mom's book on education reform.
Codehaus closed its doors in 2015.
Paul H reminisced in a thread on reddit reddit
The Demise of Open Source Hosting Providers Codehaus and Google Code infoq
Maven was born out of the mess that was Turbine's build. Shorthand "CJAN" gestured at CPAN. Before there was github, we used plain old mailing lists. And CVS. thread
> I have always liked having jars in CVS for ease of use, but I think that if for every project I built kept all required jars in CVS I would have 50 copies of Ant and Xerces lying around. Until something like CJAN is working I wouldn't want to remove all the jars. But I think moving in the direction of removing jars from CVS and using something like CJAN is the right way to go. > > -- > jvz.
About the same time I wrestled around with ideas for redesigning the object-relational query language. thread