I defer to the committers, but I think that sounds reasonable for 4.2.0. The uPortal Steering Committee would like to have a community call in April or May to give folks more info on what’s in this release.
We will have to see how best to have the conversation about what would be in 5.0, particularly around the Javascript-based front end. I am hopeful that the various folks exploring new and innovative front ends can have a meeting of the minds and end up collaborating on an exciting new direction for uPortal. While some of this can be accomplished on-list (e.g., I know we will be sharing more of our work in the near future), I suspect there will be some conference calls and in-person meetings in the future. The June conference presents an exciting opportunity for further collaboration on this. JimH On Mar 10, 2015, at 2:41 PM, James Wennmacher <[email protected]<mailto:[email protected]>> wrote: Updating everyone on where things are at with Java 8 in uPortal. Many thanks to Gary Roybal for a lot of excellent work. * uPortal was updated to use Spring Framework 3.2.9 (https://github.com/Jasig/uPortal/pull/524). This gives uPortal the ability to run on Java 8 in master. A number of us are running uPortal on Java 8 locally and I encourage you to do that as well. * It does not give us Java 8 features. For that we will need Spring Framework 4.x. * There is a PR present https://github.com/Jasig/uPortal/pull/525 which does take uPortal to Spring Framework 4.0.5 which does provide Java 8 bytecode support in uPortal. * There are 2 deprecated classes copied from Spring Framework 3.x into uPortal code because they were removed from Spring Framework 4.x. Ideally we need to refactor uPortal to not need these classes, preferably before processing the PR. * https://wiki.jasig.org/display/UPC/uPortal+-+Java+8+Upgrade documents the information found related to the current issues and pending work, including a change made in Spring Framework past 3.2.9 and 4.0.5 that breaks uPortal and prevents us from going to a newer version of Spring Framework in uPortal. * There are a few portlets that have pending Pull Requests to upgrade them to newer versions of Spring Framework. However at this point we probably don't need to upgrade portlets to have them run on Java 8. We may find that not to be true for a few portlets but the quickstart configuration seems to work as is. Proposal * I suggest we cut a release of uPortal 4.2.0 using the Spring Framework 3.2.9 that is in place. This version can run on Java 7 or Java 8. I would like to hold off for at least a few weeks to give time to process the portlet spring framework version upgrades to include in the 4.2.0 release and anything else people really want in a 4.2.0 release. * Over time we continue to work on the issues of uPortal using Spring Framework 4.0 and use that as the one of the basis for a uPortal 5.0 release, requiring Java 8 at that time. There are also some interesting changes for Respondr proposed for a Javascript-based front end (different than the UW Madison approach) that alters how the page is constructed and rendered that is more modern in approach. More will be communicated later about this after we get a bit further down the road and insure it works, but if it works as we think it will it would also serve as a foundation piece for a uPortal 5.0 release. Please provide any thoughts and feedback on this suggestion. Thanks, James Wennmacher - Unicon 480.558.2420 On 02/03/2015 12:58 PM, James Wennmacher wrote: Passing along an email I saw related to spring framework upgrades in uPortal/portlets to make sure we spread the information far and wide and get any feedback accordingly ... https://github.com/spring-projects/spring-framework/wiki/Migrating-from-earlier-versions-of-the-spring-framework Still working through stuff, but one thing that might help (from the above link): Enforced minimum dependency versions As of Spring Framework 4.1, several optional dependencies are required to be within the supported range: in particular, EhCache 2.5+, Quartz 2.1.4+, Jackson 2.1+, and ROME 1.5+ (see below for details about 4.x dependency declarations in the Spring Framework 4.0 section). Older versions have still been tolerated in the Spring Framework 4.0.x line for a smoother upgrade path; as of 4.1, the intended minimum versions are being enforced. Most importantly, don't use Quartz 1.8.x anymore; upgrade to Quartz 2.1.4+ instead! Note that as of Spring Framework 4.1.4, Apache HttpComponents HttpClient needs to be 4.3+ across the framework. The previous partial tolerance of old HttpClient versions had to be dropped in order to fix several configuration issues when running against 4.3+. I'm also seeing a need to update Hibernate (I'm trying 3.6.10.Final). That may also require adding/updating a bunch of other dependencies as well (Javassist, slf4j, etc). James Wennmacher - Unicon 480.558.2420 On 01/29/2015 05:07 PM, James Wennmacher wrote: Upon reflection I think this is very reasonable. What I took from this is: * Bump the portlet's major version # (my interpretation) * Change all portlets we upgrade Spring on to build to Java 7, document accordingly I like that and I can live with it. Anyone running Java 6 is probably not updating their portlets, and they certainly have an easy upgrade path by just switching to Java 7 without changing any other part of their infrastructure. Works for me (and is very desirable). James Wennmacher - Unicon 480.558.2420 On 01/29/2015 04:05 PM, Drew Wills wrote: James et al., On Jan 29, 2015, at 1:59 PM, James Wennmacher <[email protected]><mailto:[email protected]> wrote: the portlets generally must be compiled to Java 6 to be backwards compatible with uPortal 4.0.x [4]. They have to be compiled to Java 6 to be compatible with uP 4.0 _on Java 6_. IIRC, running uP 4.0 on Java 7 is supported as well, so you could actually run a Java 7 portlet on uP 4.0 if you like. And as we advance the platform to newer versions of Java, I should think the portlets are free to follow suit as soon as the opportunity permits. This who want updates to their Java 6 portlets running in their Java 6 JVM can still have them — they just need to obtain a new patch release on the line they’re already on. We won’t shift required JVM version in a patch release. drew -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
