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.
o 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.
o 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]>
>>>> 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] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
