Overview
| Excerpt |
|---|
uPortal 2.6 is seriously old. Consider adopting or upgrading to a modern uPortal release instead. uPortal 2.6 is the first version to require JDK 1.5, other features include DLM as the default layout manager, Drag and Drop user preferences option and a DIV & CSS centric skin. |
| Note | ||
|---|---|---|
| ||
uPortal 2.6 is seriously old. Consider adopting or upgrading to a modern uPortal release instead. |
Requirements
uPortal 2.6 requires JDK 1.5 or later. It may run under JDK 1.6 but support for JDK 1.6 is not a primary goal of the uPortal 2.6.0 initial release (instead focusing on getting JDK 1.5 support right.)
Release Notes
Hangups – Changes in 2.6 that might trip you up
- PersonDirs.xml is no longer parsed or honored by default. Use of PersonDirs.xml, which no longer ships as a file with uPortal as of 2.6, can be easily restored via configuration in personDirectory.xml.
- DLM is now the default layout manager. If you were relying on something else to be the default, you'll need to either migrate to using DLM (recommended and preferred) or be sure to point 2.6.1 at existing or otherwise suitable configuration instructing it to use the non-DLM layout management scheme you're looking to use. (DLM was one of the available layout management schemes in 2.5
- ALM is deprecated and will be removed from availability in a near future release*
2.6-export.1 - Detailed Release notes
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
2.6.1 - Detailed Release notes
Fixes in 2.6.1
- The initportal and deployPortletApp Ant targets function correctly without an internet connection.
- ALM cyclical reference handling.
...
- Statistics are only logged instead of logged and written to System.out
- Unsafe HTML elements are now filtered by the CSynFeed channel.
2.6.0 - Detailed Release notes
Enhancements in 2.6.0 not present in any 2.5.x release
...
There was a presentation about uPortal 2.6 at the March 2005 Developers' meeting in LA.
Release goals
What are we looking for from a uPortal 2.6 release? What could we achieve in uPortal 2.6 that would make deployers very interested in redeploying on a uPortal 2.6?
The following outlines some goals we might adopt for this release. What will actually be accomplished will be driven by interest in doing this work.
Stability, Stability, Stability
One important continuing issue in the uPortal 2.x codebase is stability in terms of bugfixes and memory leaks. Rutgers has applied significant resources to tracking down memory leaks and related bugs.
Skinning
Jason Shao of Rutgers has posted thoughts and a proposed process for imporving the skinnability and potentially the default look and feel of uPortal, to better use technologies like divs and css. This effort will likely have deliverables in the 2.6 timeframe.
Layout Management
Among the most cxciting contributions to 2.5 is SunGard SCT's DLM alternative layout management from their Luminis product, which is based upon uPortal.
Looking towards the 2.6 timeframe, we may see synergies between the alternative layout managers. Another place for improvement here is in enabling programmatic creation of layout fragments. Sources for layout information may extend beyond databases and XML files to enable such things as a runtime interrogation of a CMS for generating layout portions presenting appropriate managed content.
Nested tabs
As more content becomes available, we may need more screen real estate upon which to present it. Nested tabs and even more tree-like skins for uPortal may be the way to achieve this. Nested tabs have already been implemented by schools such as Virginia Tech. Even more schools may be able to take advantage of this approach if uPortal includes transforms/skins out of the box demonstrating more advanced presentations than the current tab-column approach.
WSRP Consumption
As more compelling WSRP producers come online, our WSRP consumer may need to become more sophisticated than what we currently use. We currently used a hacked version of the WSRP4j proxyportlet.
Sakai integration work
There will be opportunities to take advantage of Sakai to make uPortal a better portal for universities.
Historical issues
When we imported our Bugzilla instance into our modern issue tracking system, JIRA, we imported a number of issues that are still applicable. We should review these and determine which, if any, should be scheduled to be addressed on the uP 2.6 timeframe.
Issues that slipped the 2.5 release
Some issues will slip the 2.5 release. For some issues, this is because they weren't actually important enough to be addressed. For others, we've just run out of time on good ideas and they should be scheduled for the 2.6 timeframe.
product maturity
Beyond stability, there are ways in which uPortal can become a more mature product. This includes administrative tools. To what extent is smoothing administration something upon which we wish to focus for uPortal 2.6?
Groups and permissions
uP 3 will be looking to use the uP 2 groups and permissions functionality. This will be an opportunity for both products to take advantage of a spun out groups and permissions API – as well as to make this API available for other projects.
Also, Kieth Stacks of SunGard SCT will be working on a "finer grained permissions" effort which we can expect to have deliverables on the 2.6 timeframe.
Other ideas
What other local enhancements have you made to your uPortal instance that can be fruitfully shared back with the community? What enhancements are you looking to make locally that we can collaboratively develop?
Most importantly, what can we accomplish in this release that will make it a release that you'll be eager to redeploy your local uPortal instance upon?