JoomPress is a mythical synthesis of WordPress and Joomla. It combines the beauty and ease of use of WordPress's admininistration features with the robustness of Joomla's document/information management model. This ain't happening for a variety of reasons, not least because you can't whipstitch two animals together and expect the result to walk, but maybe that's better investigated another time.
An easier goal is to combine WordPress and Joomla output, because WordPress is pretty weak about content organization and Joomla's blogging ability is nonexistent. Letting the CMS tool do the CMSing and the blog tool do the blogging is appealing and practical in theory. In corporate websites it would allow a strong firewall between the people doing document management and the people writing the PR releases. Before rerigging cloudiness entirely in WordPress, I tried a JoomPress hybrid, to run a WordPress blog behind a Joomla front-end. The trial got far enough along to convince me that somebody could make it work. If others want to try, the notes are below.
In short, this process requires forcing WordPress to output an entire blog entry – with or without auxiliary content (like comment fields or sidebar elements) – into a set of variables. Then Joomla has to pick up those variables and insert them where requested in the Joomla page layout. And everything has to be cached to minimize the impact of running two content management systems simultaneously.
1. Bodging WordPress
WordPress's Template Tags (which are function calls) are all over the map as standardness goes. You can count on, roughly, the_something() to echo directly to screen and to have a counterpart get_something() which can return a variable, and that wp_otherthing() requires a string value to suppress echo and return a value instead. Except for when there is no counterpart.
And that's why this is the gnarly part. You can count on most but not all of the template tags being available to generate a blog entry as a variable. get_category(), which outputs to screen a list of the categories a post belongs to, has no exact counterpart; the closest is get_the_category(), which returns an object that has to be parsed to generate similar strings. Creating previous/next links or comments links is more convoluted, and I hadn't gotten to the point of interpreting and caching comments threads and widgets.
Widgets would have to be edited individually in order to play here.
The amount of non-recommended editing (that is, modifying files owned by the WordPress engine rather than the site owner) is minimal. I doctored the root index page to make WordPress aware of whether it was being invoked by Joomla (because the relative path to wp-blog-header.php changes to mywordpress/wp-blog-header.php as far as WordPress is concerned) , but that's all.
2. Bodging Joomla
Template files in Joomla execute within function calls so invoking WordPress from within a Joomla template will fail (because WordPress doesn't have the access to global namespace that it desperately craves). Joomla, bless its cybernetic heart, initializes global variables on launch so you can't simply run WordPress, set a variable, and then run Joomla to pick it up. Instead WordPress has to execute somewhere in the midst of Joomla's execution order. I got things working by inserting the include('mywordpress/index.php') command between triggering Joomla's onAfterRoute events and application dispatch. Again, that's about the extent of non-recommended editing.
After initializing Joomla and running WordPress there now exists a variable that has to be handled appropriately by Joomla. With the Jumi suite installed, Joomla can execute arbitrary PHP in content or module locations; use that to vacuum up the WordPress output and display it where you like.
3. Bodging WordPress and/or Joomla again
Now following links within your WordPress blog becomes interesting, because WordPress only generates absolute paths for links. It is in deep denial about the abuse it has just been subject to, so more brainwashing is called for. This is more or less where I stopped, realizing I wanted a website more than I wanted an invisibly cool, server-crushing website. But your mileage may vary.
You're in luck that WordPress and Joomla has little or no intersecting namespace in query strings. So if you're not concerned about search engine friendly (or user-friendly) URLs, output like http://example.com/index.php?option=com_content&view=article&id=97&catid=19&Itemid=14&p=23 looks unholy but works reasonably well. In which case, use WordPress's get_bloginfo('url') value as a mask to be replaced with the URL of Joomla's devising. Each will ignore the other's URL values when they execute again. I'm betting you could combine Joomla's SEF urls with WordPress's default permalinks and get by.
Insisting on a unified, clean, search engine-friendly URLs as the sum of both platforms? No idea, man. No idea.
4. Other possibilities
One of the things I didn't try, and might or might not be worth trying by somebody other than me, is to have Joomla pick up WordPress's RSS feeds instead and parse them. The upsides are pretty sweet: WordPress does it easily with a lower performance hit and can provide feeds of nearly any content you like (Front page posts, all comments, comments on a given thread…). The data is cleanly formatted and can be parsed in any way you like. The most significant downside to using RSS includes the lack of widgets and comments fields, taking a lot of the blogginess out of the blog. Joomla 1.5 has no comment fields built in and third-party mechanisms are mediocre at best. Giving WordPress as much control over that as possible means a lot.
So this is possible. Whether it's practical depends on your needs. Whether it's desirable is up to you.