Let me prodly announce version 0.5.0 of Hades. As our project home gives you the quick overview and access to the latest binaries, sources and documentation I want to use this post to elaborate a little bit on the changes in 0.5.0 as well as the future roadmap.
Version 0.5.0 one more time simplyfies the XML required to setup Hades DAOs with Spring. The only required attribute at the dao-config element now is base-package
which aligns pretty much from the base-package
Spring users know from Spring’s context namespace. As with this namespace you can use Ant style wildcards to form package patterns to allow more flexibility. E.g. <hades:dao-config base-package="com.acme.**.dao" />
would scan all packages starting with com.acme
and ending on dao
for Hades DAO interfaces and create the appropriate instances for them.
There was a bug in 0.4 MANIFEST.MF
that trapped a few users from using Hades in an OSGi environment. 0.5.0 is fully OSGi compatible and ships with a sample application that can be dropped into a Spring-DM OSGi platform (e.g. SpringSource DM Server). The sample app gives an overview about Hades functionality and exposes a User DAO as OSGi service. Check out the sample application here.
Most users will happily use Hades in combination with Spring namespace configuration. Programatic use of Hades was always possible albeit only through a rather untyped GenericDaoFactoryBean
that implements Springs FactoryBean
interface. With 0.5.0 Hades provides a GenericDaoFactory
that provides an interface that suits needs for programatic access. Now you can create DAO instances by simply invoking GenericDaoFactory.create(em).getDao(UserDao.class);
We aligned our versioning and artifact naming OSGi conventions.
As we consider Hades to be mature, we’re going to release a version 1.0 next. Timeframe is about end of June. We will stay on JPA 1.0 for this 1.0 branch of Hades. So with the release of Hades 1.0 we will also open up a 2.0 branch that will contain features that required JPA 2.0.