I'm on board with calling it uPortal 5.0.0, especially with the pending 
removal of Universality as well.

James Wennmacher - Unicon
480.558.2420

On 01/29/2015 04:02 PM, Andrew Petro wrote:
> > 1. portlets that work in uPortal 4.2
>
> I meant 4.1, of course.
>
> Sent from my phone
>
> On Jan 29, 2015, at 3:13 PM, Andrew Petro <[email protected] 
> <mailto:[email protected]>> wrote:
>
>> Getting to latest GA Spring framework would be great.
>>
>> Let’s consider calling the release that makes this upgrade uPortal 5. 
>>  The issues are subtle, but the very short version of what you wrote 
>> below is:
>>
>> 1. portlets that work in uPortal 4.2 instances today may not work in 
>> this new uPortal release without being updated, and
>> 2. portlets that take advantage of the Java 8 language features 
>> available in this uPortal release will not work in uPortal 4.2 
>> instance, and
>> 3. it more or less matters whether a portlet is targeting uPortal 4.x 
>> or this uPortal release.
>>
>> So, call it uPortal 5, and set roughly the right expectations about 
>> how much of a change we’re talking about between these releases.
>>
>> Can make this tactical move without jumping to Semantic Versioning. 
>>  Pick that up for uPortal 6.0.0 if we can’t make the transition for 
>> this release. :)
>>
>> Andrew
>>
>>
>>
>>> On Jan 29, 2015, at 2:59 PM, James Wennmacher 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> We've done some initial research on uPortal 4.2.0 supporting Java 8 
>>> (and only Java 8 so we can start to take advantage of its features) 
>>> that I wanted to communicate to the community and solicit feedback 
>>> on current research and thinking.  I will cross-post a message to 
>>> portlet-dev alerting them to this conversation but wanted to keep 
>>> the conversation in one place (this list).
>>>
>>> First, many thanks to Gary Roybal at Unicon for doing all the research.
>>>
>>> I expect the primary work of upgrading uPortal 4.2.0 to Java 8 
>>> involves updating to a version of Spring Framework that supports 
>>> Java 8.  I expect there will be minor work related to updating 
>>> documentation (altered JVM startup parameters), a few other 
>>> unforeseen issues, and eventually someone may spend time trying the 
>>> new-ish G1 garbage collector.
>>>
>>> Currently, Spring 3.2.3 and greater supports deployment on JDK 8 [1] 
>>> and Spring 4.1.x supports some Java 8 features [2].  We could 
>>> upgrade uPortal to support the latest Spring 3.2.x release (3.2.13) 
>>> and still work with Java 8.  Spring Framework 3.2.x will support 
>>> deployment on JDK 8 runtimes for applications compiled against JDK 7 
>>> (with -target 1.7) or earlier [1].  However the desired approach 
>>> IMHO is to update uPortal 4.2.0 to use the latest Spring Framework 
>>> 4.1.x release since the Spring Framework 3.2.x line is effectively 
>>> end of life at end of 2015 [3] and to benefit from Java 8 features 
>>> in uPortal codebase.  We plan to move forward with uPortal migrating 
>>> to Spring Framework 4.1.4 unless we find out that there is a 
>>> significant technical issue or investment of time for uPortal to go 
>>> to Spring Framework 4.1.4 as opposed to 3.2.13.
>>>
>>> Supporting Java 8 also means that the Spring Framework in the 
>>> portlets would also need to to be updated.  We are looking at 
>>> updating the portlets to use Spring Framework 4.1.4 also.  However:
>>>
>>>   * the portlets generally must be compiled to Java 6 to be
>>>     backwards compatible with uPortal 4.0.x [4].  This means of
>>>     course no use of Java 8 features in portlets (at least without
>>>     doing a major rev release on the portlet and documenting its
>>>     dependence on Java 8 and uPortal 4.2.0+) even though the portlet
>>>     might be using Spring Framework 4.x
>>>   * A few portlets are currently compiled to Java 5. These will need
>>>     to go to Java 6 as a target.  A quick check of the ones I have
>>>     locally suggests this impacts Bookmarks, ESupTwitter, and
>>>     SimpleContentPortlet.  There may be others.
>>>   * Though desirable due to EOL on Spring Framework 3.x in 2015,
>>>     since there is no compelling reason to have to use Spring
>>>     Framework 4.x in a portlet we may upgrade some portlets to
>>>     Spring Framework 3.2.13 if we have a problem with Spring
>>>     Framework 4.x in the portlet or it looks like it will take a lot
>>>     of time for some reason.
>>>
>>> Please let me know if you have other thoughts, opinions, 
>>> suggestions, or concerns with this plan. As a note, uPortal 4.2.0 
>>> should be able to run on Tomcat 7 or Tomcat 8 [5], but that is a 
>>> separate issue from Java 8 support and is work that can be done 
>>> later (and we'd love your help and contributions toward that!).
>>>
>>> [1] 
>>> http://spring.io/blog/2013/05/21/spring-framework-4-0-m1-3-2-3-available/
>>> [2] 
>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#_java_8_as_well_as_6_and_7
>>> [3] 
>>> http://spring.io/blog/2014/12/30/spring-framework-4-1-4-4-0-9-3-2-13-released
>>> [4] https://wiki.jasig.org/display/UPM40/Requirements
>>> [5] http://tomcat.apache.org/whichversion.html
>>>
>>> other links:
>>>
>>>   * 
>>> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
>>>
>>>   * FYI on http://openjdk.java.net/jeps/173 - Referenced from bottom
>>>     of above link. Describes several GC options referenced in
>>>     https://wiki.jasig.org/display/UPC/JVM+Configurations and
>>>     possibly used at sites are deprecated (but not removed) in Java 8.
>>>
>>> Looking forward to your thoughts.
>>>
>>> Thanks,
>>>
>>> James Wennmacher - Unicon
>>> 480.558.2420
>>>
>>> -- 
>>>
>>> You are currently subscribed [email protected]  
>>> <mailto:[email protected]>  as:[email protected]  
>>> <mailto:[email protected]>
>>> To unsubscribe, change settings or access archives, 
>>> seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>
>> -- 
>>
>> You are currently subscribed [email protected]  
>> <mailto:[email protected]>  as:[email protected]  
>> <mailto:[email protected]>
>> To unsubscribe, change settings or access archives, 
>> seehttp://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


-- 
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

Reply via email to