I am looking forward to hitting JavaPolis in Belgium next week. I am going to be talking about Groovy with James Strachan.
It looks like a great event, especially as I get to hang out with Cedric Beust, Howard Lewis Ship, Rod Johnson, Patrick Linskey, Vincent Massol, Mike Cannon-Brookes, BEA / Beehive guys, and many more friends!
The beer in Belgium is always great too. I love getting a special glass for each ‘brand’ of beer. So much more refined ;)
Bob the Despot of Codehaus has a new venture called OpenXource.
He is a great position to come to the business world and discuss open source strategy, and help build community (which is the #1 element of open source IMO).
He has started some interesting topics called Crossings
E.g.
What Should You Release as Opensource?
Anti-Pattern: Everyone is a Maintenance Coder
It is interesting to see the growing interest from the corporate world. I hope to be working with Bob on many of these issues!
The Rumsfeld quote below was in response to a question regarding the Army combatant who had asked Rumsfeld the previous day about why he needs to dig up scrap iron to outfit his Hummer.
“I don’t know what the facts are but somebody’s certainly going to sit down with him and find out what he knows that they may not know, and make sure he knows what they know that he may not know, and that’s a good thing. I think it’s a very constructive exchange,” Rumsfeld said of the questioner.
Huh?
Casting SPELs in Lisp is a really cool, fun ‘comic book’ which walks you through the LISP language and environment.
Why is it the LISPers that get so creative in this way? They get the Little Lisper (and Schemer), and cartoons. Only the Squeak guys seem to come close in bizarreness!
After reading something like this cartoon, you WANT to jump in and write some code.
After reading arguments in some of the ‘other’ communities out there….. ;)
A lot of people in the community have been bugging Sun that they need to shake off the “Java == the language” view, and think more about the platform.
Tim Bray definitely saw this, and he pulled together a summit between top dynamic languages folk, and the main Sun Java players.
As soon as I heard about the summit I was really excited. When smart people get together good things happen. And it sounds like they did. Hey, there was even talk of adding an opcode here and there if it really made sense!
On Tuesday a summit was held at Sun, “with a few of our internal Java leaders, and on the dynamic-languages side, Larry Wall and Dan Sugalski (Perl and Parrot), Guido van Rossum, Samuele Pedroni and Sean McGrath (Python), and James Strachan (Groovy)”.
There were a couple of action items to report back on this or that, but the take-aways were pretty clear. For my money, the important thing about the meeting was bridge-building; the dynamic-language guys now know who to shout at in Javaland, and the Java guys know who in dynamic-language land to pester about what works and what doesn
The AspectWerkz team has really been hitting the keyboard hard :)
They recently announced the AspectWerkz 2 architecture, which is a full Aspect Container. Along with that came AWBench which benchmarks various AOP implementations (and it shows how far along AspectWerkz has come on the performance side).
Then, today, they announced AW Proxy which gives you the best of both worlds of traditional proxies, and AOP advice.
Resources
AspectWerkz 2.0: Extensible Aspect Container
AspectWerkz 2.0: Plain Java AOP, Java 5 Annotations, and EJB 3 Transactions
Poor Pat asked Mark Roth of Sun to not jump in a take peoples syntax.
The problem is that once JSP (via JSTL) says “${foo} will resolve to X”. Other frameworks don’t get a look in. Pat was worried that #{..} would be eaten up yet and OGNL uses that for maps and such!
Matt Raible was on the chat session with Mark Roth and asked these questions:
I asked the following question as part of the chat:
Is there any chance that web frameworks (like WebWork) could override the default settings for the EL? So ${myForm} can look in areas other than page/request/session/application scope – i.e. WebWorks’s ValueStack?
It looks like this *is* going to be a part of JSP 2.1 – from Mark Roth:
JSP 2.1 is not only concerned about supporting Faces. We also want to support other frameworks. the new unified EL 2.1 API supports the concept of a pluggable VariableResolver (similar to the one that Faces has) which allows you to plug in your own logic for how variables like ${myForm} are resolved. So yes, this will be supported.
Imagine that? Pluggable Resolvers? Now we can live nicely together.
Note to Self: Write a nasty revolver which does weird things with ${} and get it somewhere to confuse people on projects:
Why does ${foo} print out SO YOU WANTED SOME FOO DID YAH! instead of the value?
The Apache DB group voted on a new JDO proposal. The new proposal spells out a place for some serious JDO work to happen.
It has been brought together with leaders in the Apache, other open source, and JDO worlds:
There are six initial subprojects envisioned:
I witnessed a lot of good talk at ApacheCon, and I am happy to hear that it is coming to fruition. With these fine blokes behind it, I am hopeful for a top notch JDO implementation with an Apache brand.
Someone already asked “Doesn’t OJB support JDO?” to which Brian McCallister replied:
OJB supports a JDO interface via a plugin to the JDO 1.0.X reference implementation (which is SCSL, non-commercial variant) so is basically useless right now. This same RI is part of the initial codebase for this project, so the OJB JDO 1.0.X interface can actually become useful =)
Yeah, I know it is a point release, but I am glad that Maven 1.0.2 is released as 1.0.1 wasn’t grabbing dependencies for me (which is fixed by “Fail on 403 response to dependency download (and also anything > = 400) Fixes MAVEN-1502.”).
The Apache Maven team is pleased to announce the release of Maven 1.0.2.
http://maven.apache.org/start/download.html
This release contains further bugfixes since the Maven 1.0 release. In addition, all of the latest stable plugin releases are included, which include both bugfixes and some new features.
We recommend that all users upgrade to this release, in particular those using pre-1.0 betas or release candidates.
Maven is a project management and project comprehension tool. Maven is based
on the concept of a project object model: builds, documentation creation, site
publication, and distribution publication are all controlled from the project
object model. Maven also provides tools to create source metrics, change logs
based directly on source repository, and source cross-references.To see a list of changes to Maven, please refer to the Changes Report, or the brief summary below:
- [MAVEN-1428] – “Response content length not known”
- [MAVEN-1501] – maven seems not to evaluate .properties of parent pom
- [MAVEN-1502] – Build doesn’t fail when dependency can’t be downloaded due to wrong permissions
- [MAVEN-1507] – Fails on IBM 1.3 JDK
- [MAVEN-1511] – Jar override does not work when trying to override to SNAPSHOT
- [MAVEN-1518] – Wrong behaviour for non existing overwritten dependency
Please note that each plugin has its own changes report – please refer to the plugins site to see the plugin you are interested in.
We hope you enjoy using Maven! If you have any questions, please consult:
- the FAQ: http://maven.apache.org/faq.html
- the maven-user mailing list: http://maven.apache.org/mail-lists.html
For news and information, see:
- Maven Blogs: http://www.mavenblogs.com/
- The Apache Maven Team
Rather than always having my tests go to a database, I have my DAOs all mocked up.
For most of my tests, I want to use this mock layer (much faster). For some cases I want to use the full layer (e.g. to test the real DAOs, or for integration tests).
I wired up my BaseTestCase to handle both cases in a simple class, which ties into the Spring Dependency post from yesterday:
package foo.test;
import org.springframework.test.AbstractDependencyInjectionSpringContextTests;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public abstract class BaseTestCase extends AbstractDependencyInjectionSpringContextTests {
private static String[] realPaths = { "classpath:applicationContext*.xml" };
private static String[] mockPaths = { "classpath:test-applicationContext.xml", "classpath:applicationContext-webwork.xml" };
protected Log log = LogFactory.getLog(this.getClass().getName());
/**
* Override method to choose which layer to use
*
* Default to using the mock layer
*/
protected boolean useMockLayer() {
return true;
}
protected String[] getConfigLocations() {
return useMockLayer() ? mockPaths : realPaths;
}
}
Now, I just place my mocks in the test-applicationContext.xml:
<bean id=”userDAO” class=”foo.dao.MockUserDAO”/>
If I want a test to use the full layer I simply override:
protected boolean useMockLayer() {
return false;
}
My posts, status updates, link blog, and anything else I do on the web is here:
I am honoured to be working with my long time friend and collaborator Ben Galbraith on helping to set the direction of the industry.