You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Glen Mazza <gl...@gmail.com> on 2013/07/05 03:18:05 UTC
proposed upgrades to Roller trunk...
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
Re: proposed upgrades to Roller trunk...
Posted by Dave <sn...@gmail.com>.
On Sun, Jul 28, 2013 at 5:45 PM, Glen Mazza <gl...@gmail.com> wrote:
> On 07/08/2013 08:53 AM, Dave wrote:
>
>> Overall, I think these are very good ideas. Thanks for the proposals. More
>> comments below.
>>
>> On Thu, Jul 4, 2013 at 9:18 PM, Glen Mazza <gl...@gmail.com> wrote:
>>
>> 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<h**ttp://mvnrepository.com/**
>>> artifact/org.springframework<http://mvnrepository.com/artifact/org.springframework>
>>> >)**.
>>> Hopefully we can standardize on one Spring version.
>>>
>>> My only concern here is that we might break OpenID support, which
>> relied on
>> one specific version of Spring Security if my memory serves me right.
>>
>
> That may indeed happen with a Spring upgrade, for which we'll have a JIRA
> ticket to get OpenID either fixed or replace it with another implementor of
> OpenID that can work with the Spring 3.0 series. But so long as the JPA
> and UI portions still work, I think the Spring upgrade should still occur.
> I can't see us going forward with the Spring 2.0.x, it's harder to gain
> committers when they have to work with older tools and it's too much of a
> warning sign for potential users evaluating the software, as that series
> most likely isn't patched anymore. Also, we'll need to run Spring 3.0.x
> for a few months anyway to catch all the potential incompatibilities with
> Roller code, giving us time to look at the Open ID situation.
>
+1
I think you are right on all points. OpenID support seems like a good idea,
but we've gotten no feedback about yet, positive or negative, and I do not
personally need it in Roller.
If somebody cares about OpenID support then need to speak up and/or help us
update it to work with the newer version of Spring. Hopefully, newer
versions will make it easier not harder to support OpenID.
- Dave
Re: proposed upgrades to Roller trunk...
Posted by Glen Mazza <gl...@gmail.com>.
On 07/08/2013 08:53 AM, Dave wrote:
> Overall, I think these are very good ideas. Thanks for the proposals. More
> comments below.
>
>
> On Thu, Jul 4, 2013 at 9:18 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>> 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<http://mvnrepository.com/artifact/org.springframework>).
>> Hopefully we can standardize on one Spring version.
>>
> My only concern here is that we might break OpenID support, which relied on
> one specific version of Spring Security if my memory serves me right.
>
That may indeed happen with a Spring upgrade, for which we'll have a
JIRA ticket to get OpenID either fixed or replace it with another
implementor of OpenID that can work with the Spring 3.0 series. But so
long as the JPA and UI portions still work, I think the Spring upgrade
should still occur. I can't see us going forward with the Spring 2.0.x,
it's harder to gain committers when they have to work with older tools
and it's too much of a warning sign for potential users evaluating the
software, as that series most likely isn't patched anymore. Also, we'll
need to run Spring 3.0.x for a few months anyway to catch all the
potential incompatibilities with Roller code, giving us time to look at
the Open ID situation.
>> 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<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.
>
> Roller is not Atom only and supports RSS feeds for blogs and in the planet
> aggregator, I would not like to lose those features and they cannot be
> supported with Abdera. I'd be happy to try to push a fix into ROME and see
> if we can get a release out.
>
> - Dave
>
OK, lower priority, I'll take a look at this sometime.
Glen
Re: proposed upgrades to Roller trunk...
Posted by Dave <sn...@gmail.com>.
Overall, I think these are very good ideas. Thanks for the proposals. More
comments below.
On Thu, Jul 4, 2013 at 9:18 PM, Glen Mazza <gl...@gmail.com> wrote:
> 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<http://mvnrepository.com/artifact/org.springframework>).
> Hopefully we can standardize on one Spring version.
>
My only concern here is that we might break OpenID support, which relied on
one specific version of Spring Security if my memory serves me right.
>
> 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.
>
Sounds like a very good call. I did not realize OpenJPA had grown so
stagnant and fallen behind the times.
> 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<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<http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/business/jpa/JPAPersistenceStrategy.java?revision=1498037&view=markup#l98>
Makes sense.
> 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<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.
Roller is not Atom only and supports RSS feeds for blogs and in the planet
aggregator, I would not like to lose those features and they cannot be
supported with Abdera. I'd be happy to try to push a fix into ROME and see
if we can get a release out.
- Dave
Re: proposed upgrades to Roller trunk...
Posted by Greg Huber <gr...@gmail.com>.
Changing to the lastet version of spring security, I remember there was
some changes made on the open Id stuff, see
spring-security-2.0.1-openidfix.xsd.
Maybe this change has been rolled into the latest spring release?
I remember there were some changes needed to the security.xml to get it to
work. I have a working copy that I use which uses the basic roller logic
(minus the
openidAuthenticationProcessingFilter/rollerCrowdAuthenticationService).
Cheers Greg
On 5 July 2013 02:18, Glen Mazza <gl...@gmail.com> wrote:
> 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<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<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<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<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 <https://issues.apache.org/jira/browse/ROL-1436>)
> and it outputs erroneous error messages (https://issues.apache.org/**
> jira/browse/OPENJPA-2401<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<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<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<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
>
>