Being a good citizen?
The choice of build tools is surprisingly contentious. I know I, personally, am not a huge maven fan. I've been given to explosive, vitriolic rants against it, actually. But now I'm forced to use it at work so I'm learning it more than I'd hoped to ever have to. 
But whatever your choice of build tool is, there's one thing I think should happen that would help out so many people. If you write some form of library to be reused by the world at large, it should get published in the maven repos. Or maybe an ivy repo(s) if there are such centralized/public beasts. Making it easy to find these artifacts will only help to drive adoption of a project.
Whether you chose maven or ant at that point (or something else...), it becomes quite simple to find and fetch dependencies. I use the ant tasks from the maven project to pull down my deps and then ant to build. It works well enough for me until I run into a library that hasn't been published to a repository somewhere. Some projects are really good about publishing their artifacts. Other projects' devs respond with simple "not my problem" responses. If I can't find a dependency in maven, I'm much more likely to try to find another library to use. So uploading an artifact may not be your problem, but it's certainly not mine. It's a good way to drive people like me to other projects, though. But maybe you don't care about that, either.
Java is dead?
There's been a lot said about closures both in favor and against the last couple of years. The debate has raged on for what feels like an eternity. But the semi-official announcement at Devoxxx recently that closures won't be making it into java7 seems to have put everyone back on their heels a bit. I, for one, am relieved at the announcement. Others are not so thrilled and have gone so far as to declare that Java is dead for their lack. Personally, every major proposal out there made my eyes bleed. There were so many gymnastics being proposed to deal with typing and generics and backward compatibility and the like that most of those proposals just made a mangle of the language. I did see one idea that I like (my thoughts on that here) but there's little chance it'll get any serious traction.
I've used closures in both my fan work and my groovy work and I've enjoyed using them. But the syntax employed is much simpler than what the main proposals had offered. As nice as closures are, inner classes have served me well enough so far with very little heartburn. Until Sun is ready to break with older versions of Java, I'm just not sure how well closures will work the current language and VM constraints.
What I was happiest too see was Mark Reinhold's jigsaw project. A small, modular, independently updatable runtime would be fantastic. I know many are upset at the lack of any major language changes being promised in java7 but I'd rather see what we have now work better. Let's not destroy the language trying to shoehorn in things that just aren't working out.
Migrating from Subversion to Mercurial
I recently moved the bot we use in freenode ##java from svn to hg. Using hg's built in conversion utilities, this process isn't bad at all. There are a number of steps to set things up, however, some of which aren't entirely as clear as they probably could be. It would appear that hg's conversion routines don't like https-based svn repos so I wrote up a quick script to help my brother move a project of his to kenai and thought I'd share it here. The heavy lifting in this script comes almost verbatim from hg convert page but hopefully this is a bit more accessible.
then
echo "usage: $0
exit
fi
if [ -z "`grep hgext.convert ~/.hgrc`" ]
then
echo Enabling the conversion extension
echo "[extensions]" >> ~/.hgrc
echo "hgext.convert=" >> ~/.hgrc
fi
URL=$1
DEST=mirror-svn
HGDEST=mirror-hg
if [ -d "${DEST}" -o -d "${HGDEST}" ]
then
echo "${DEST} or ${HGDEST} already exist. Please try working in another directory"
exit
fi
svnadmin create ${DEST}
echo '#!/bin/sh' > ${DEST}/hooks/pre-revprop-change
chmod +x ${DEST}/hooks/pre-revprop-change
svnsync init file://`pwd`/${DEST} ${URL}
svnsync sync file://`pwd`/${DEST}
mkdir ${HGDEST}
hg init ${HGDEST}
hg convert file://`pwd`/${DEST} ${HGDEST}
As you can see, it's pretty straightforward. I ended up using svnsync to get aroung the hg/https/svn problem. It also makes the conversion much faster. Once the script is done you can cd into mirror-hg and hg push it wherever you'd like. There are some options you can do during the conversion like limiting which revisions get converted and mapping usernames and the like. I've done nothing of the sort here but those shouldn't be too hard to add. And if you're really that interested in those options then you should be fully capapable of doing that yourself.
Also note, that if you don't need to use svnsync you can skip directly to the hg convert line (well, and the init right before it...) and hg will pull directly from the repository to do its conversion.
There it is. It's not fancy or earth shattering but hopefully it'll help save you some heartburn. As always, feedback is welcome.