Hi All, here are the next round of improvements I'd like us to consider
for Roller:
1.) Update Spring framework from 2.0.7 & 2.5.6 & 1.2 to the latest
RELEASE version (3.2.3.RELEASE apparently:
http://mvnrepository.com/artifact/org.springframework). Hopefully we
can standardize on one Spring version.
2.) Switch the default JPA framework from Apache OpenJPA (JPA 2.0) to
EclipseLink JPA (JPA 2.1). All three frameworks (including Hibernate)
are now passing JUnit tests, so we have a choice of any of the three.
Reasons:
-- This will help remove a need for one extra build--presently we have
three: Tomcat (OpenJPA), GlassFish/JavaEE (EclipseLink), and JBoss
(Hibernate). No guarantees but if we move to Tomcat/EclipseLink we may
be able to consolidate the first two. We should have EclipseLink
working anyway for GlassFish deployment (as EclipseLink is its default),
but there's no corresponding requirement for us to have OpenJPA working
on Tomcat, which doesn't have a built-in JPA framework, so we might as
well have it use EclipseLink also.
-- OpenJPA seems to have lost most of its paid committers. The project
has 624 open issues
(https://issues.apache.org/jira/browse/OPENJPA#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel),
and they've having resource difficulties in implementing JPA 2.1
(http://openjpa.208410.n2.nabble.com/OpenJPA-support-for-JPA-2-1-when-td7584157.html).
-- EclipseLink already implements JPA 2.1. It's easier to attract
committers to Roller when we use the most recent technologies.
-- As with OpenJPA, it's also very easy to activate EclipseLink logging:
http://svn.apache.org/viewvc/roller/trunk/app/src/test/resources/roller-custom.properties?revision=1499866&view=markup#l14
-- Open JPA is chatty when you build Roller
(https://issues.apache.org/jira/browse/ROL-1436) and it outputs
erroneous error messages
(https://issues.apache.org/jira/browse/OPENJPA-2401) that falsely make
people building Roller think that there's something wrong with our JPA
entity classes.
3.) Remove DB connectivity info from the persistence.xml file.
I'd like to remove line #4
(<non-jta-data-source>${datasourceName}</non-jta-data-source>) from our
persistence.xml
(http://svn.apache.org/viewvc/roller/trunk/app/src/main/resources/META-INF/persistence.xml?revision=1491090&view=markup)
and do this configuration in the roller-custom.properties file instead.
Our code already handles this:
http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/business/jpa/JPAPersistenceStrategy.java?revision=1498037&view=markup#l98
Reasons: Unlike OpenJPA, both EclipseLink and Hibernate place precedence
on the value in the persistence.xml file over whatever we configure in
emfProps in JPAPersistenceStrategy, which forces one to have to
comment-out this line when running JUnit tests with either of these two
JPA stacks. Removing DB connectivity info from persistence.xml keeps
that file workable for either direct JDBC or JNDI configuration
regardless of JPA stack. Also, putting the configuration in
roller-custom.properties (with a subsequent update in our Installation
Guide) strips away a need to have a separate JBoss build, further
helpful in build consolidation.
4.) New version of ROME-Propono with the latest ROME dependencies
(fixing problem mentioned here:
http://mail-archives.apache.org/mod_mbox/roller-dev/201306.mbox/%3C51CF6CF4.3050709%40gmail.com%3E).
This would just be a Maven POM change (I can test it out if Dave
wouldn't mind applying the patch to ROME so we can get a release out of
it). As an alternative, we can switch to Apache Abdera if-and-only-if
we have no longer a need for RSS in Roller (is Roller now Atom-only?
5.0.1 seems to indicate that...) Switching from ROME to Abdera in
Roller could end up being a lot of work though, probably not worth it
unless ROME is really dormant.
Thoughts, comments?
Thanks,
Glen
