Ah, if only more people knew about JDO & DataNucleus:
http://architects.dzone.com/news/non-sense-nosql-orm-frameworks
JDO, by design, supports any kind of underlying datasource. DataNucleus, the open source JDO reference implementation, already supports several NoSQL stores, including db4o, NeoDatis, Amazon S3, Google's BigTable, HBase, & MongoDB, as well as every major RDBMS around.
JDO: http://db.apache.org/jdo
DN: http://www.datanucleus.org
Friday, October 14, 2011
Thursday, October 06, 2011
Uh oh: TZ database down, in legal battles?
http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html
This is bad. We need an IETF/Oasis/etc standard for this data. I don't want to have to deal with multiple competing timezone data. It's nontrivial at best, and often very difficult, to deal with different timezones and daylight savings issues, let alone historically.
What a nightmare this could turn out to be.
This is bad. We need an IETF/Oasis/etc standard for this data. I don't want to have to deal with multiple competing timezone data. It's nontrivial at best, and often very difficult, to deal with different timezones and daylight savings issues, let alone historically.
What a nightmare this could turn out to be.
Tuesday, October 04, 2011
Why can't bundle manifests be pretty-printed?
I've had to wade through lots of OSGi bundle manifests lately, and I have to say, they are hard for an average Joe to read.
So, I entered an enhancement request for bnd to provide a directive for pretty-printing manifests. I include an example of what I'd consider pretty-yet-still-manifest-spec-compliant.
If you've suffered my fate as well, please add a +1 comment for it (until such time as github adds back voting for issues).
So, I entered an enhancement request for bnd to provide a directive for pretty-printing manifests. I include an example of what I'd consider pretty-yet-still-manifest-spec-compliant.
If you've suffered my fate as well, please add a +1 comment for it (until such time as github adds back voting for issues).
Monday, October 03, 2011
Convenient Maven POM to wrap jars for OSGi
I've been doing some OSGi work at my current gig. If you ever have a jar that isn't OSGi-ready, this is a handy-dandy little pom.xml that will use bnd (via maven-bundle-plugin) to wrap the jar, and any dependencies you want to include, in an OSGi bundle jar. Just replace theGroupId with the groupId, theArtifactId with the artifactId and theVersion with the version of the Maven artifact you want to wrap et voila.
<project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
">
<modelVersion>4.0.0</modelVersion>
<groupId>theGroupId</groupId>
<artifactId>theArtifactId.osgi-wrapped</artifactId>
<version>theVersion</version>
<packaging>bundle</packaging>
<name>${artifactId}</name>
<description>${artifactId}</description>
<dependencies>
<dependency>
<groupId>theGroupId</groupId>
<artifactId>theArtifactId</artifactId>
<version>theVersion</version>
</dependency>
<!-- TODO:
Add any other dependencies you want to embed here,
then make sure to include their artifactIds
in the space-separated list in <Embed-Dependency>
below.
-->
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.5</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Import-Package>*;resolution:=optional</Import-Package>
<_exportcontents>*</_exportcontents>
<Embed-Dependency>theArtifactId</Embed-Dependency>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>
Subscribe to:
Posts (Atom)