Overview
The uPortal community is very interested in having people easily contribute to the uPortal project. One way of encouraging this is to identify appropriately sized projects that new contributors can bite off. This also requires that mentors be identified for the projects. This page serves as a clearing house for this information This project list can also serve as input for a Google Summer of Code application.
If you have an idea for a project and are prepared to mentor a developer on it, add the project and your name to the list.
If you are interested in taking on one of these projects or are a potential student developer with the Google Summer of Code, please contact the appropriate mentor(s).
If you have an idea for a project that you would like to be a developer on and need a mentor for, or could be a mentor but not at this time, please add it to the list on the Project Brainstorming page.
Skills and Technologies Required
The following skills and technologies are used in Jasig and uPortal projects. A developer who chooses to work on the ideas listed on this page would be required to use many of these skills and technologies.
- Java
- Spring (dependency injection)
- Spring MVC (both Portlet and Web application)
- Spring WebFlow
- JPA
- Hibernate
- XML Parsing
- XSL
- Javascript (including, but not limited to JQuery)
|
Mentors
By placing your name on the list below, you are indicating that are willing and able to act as a Jasig mentor. This is with the understanding that there will be periods during the year when you will be unable to mentor due to other commitments.
|
|
Existing Portlets
These are possible changes to existing portlets.
Announcements Portlet as it is now, could use a few enhancements
- Enhancements
- Remotely pulled announcements to populate a topic such as RSS with permissions needing to be set, or custom RSS that includes permissions from another AnnPLT instance running in another portal.
- The emergency topic should also be updated to pull from a central campus emergency RSS feed instead of relying on manual input.
- Adding Fluid Infusion components such as the Pager, etc.
(medium) Bookmarks Portlet AJAXification (mentor: Eric Dalquist, Jen Bourey)
The Bookmarks Portlet has been included with uPortal since 3.0 and includes a dynamic interface that uses 100% custom JavaScript and no real AJAX callback support.
- Enhancements
- Moving to jQuery for dynamic user interface
- Adding AJAX callbacks for adding, updating and removing bookmarks as well as navigating and arranging the bookmarks tree hierarchy.
(medium) JSR-168 IMAP/POP multi-server portlet (mentor: Jen Bourey)
While the Duke tabbed mail portlet has provided Jasig with a first pass at a multi-server, configurable IMAP/POP portlet, the portlet has not been submitted for incubation and may not address the needs of all institutions. It would be nice to have a more stable, mature version. A well-planned, generalizable portlet built from community specifications would be an attractive portlet to bundle with uPortal.
Content/Document Management JSR 170 (Java Content Repository) Portlets (mentor: CrisH)
The points might be one, two, or more portlets, additionally, some of this work is already begun as an ASU student project. I do think that even if there is one portlet that does everything, the ability to configure that portlet to only do "some" things would be valuable, e.g., only display some content from a JCR.
- (medium) Read only file browser given a certain configurable node starting point
- (easy) Ability to edit text and/or html documents in the repository
- (easy) Ability to display text, html or image documents in repository
- (medium) Tagging content in a jcr
- (medium) Searching content in a jcr (including searching content, or metadata like tags)
- (medium) Tag clouds in general for all tags, or tag clouds given a configured subset of tags
Google Gadget Portlet (mentor: Jen Bourey)
I know there was talk about this in the past, but I'm not sure where it ended up.
- (easy) Gadget Portlet - Produce a portlet which will run in a standard portlet container (targeting uPortal as the reference platform) that would serve as a Google Gadget container.
- (easy) ability to for an admin to publish a specific google gadgets inside of a portlet
- (easy) ability for a user to subscribe to any google gadget they want
Open Social Container Support
The OpenSocial specification parallels the Portlet specifications in many ways, while adding on many social networking and relationship based components. uPortal's Higher-Education focus exposes some possible synergies related to supporting OpenSocial style interactions for extension and collaboration. This might look like:
- Gadget hosting support (see above)
- OpenSocial services backed by Portal/Portlet APIs (possibly leveraging an existing implementation like Apache Shindig, or a hybrid like Sling)
- Support for white/blacklisting services from public/external sites, and exporting hosted services (OpenSocial or portlets) for hosting in remote OpenSocial containers
- (hard) User Manager Portlet - An administrative portlet developed using Spring WebFlow 2 that allows administrators to add, modify, and delete local portal users including password management. It could also tie into a newer version of the UP_PERSON_DIR table to allow for administration of local user attributes as well. Additional optional parts include: An end-user targeted flow for users to change their passwords. The portlet could use the Fluid pager component for navigating the users in the system. The portlet could tie into the permissions APIs to allow for delegated administration of users within specific groups.
- (medium) User admin portlet (for managing local portal users)
- (medium) LDAP admin portlet (for browsing adding/creating/deleting users in LDAP)
- (medium) Self registration portlet (both for local portal user, ldap users)
- (easy) Change password, possibly related to the previous point, maybe separate
- (hard) Portlet Manager for publishing portlets (unicon is already well down this road, but what might unicon not be able to get to)
- (hard) Deploy a new portlet UI, possibly tie-in to portlet manager, possibly a separate portlet
- (medium) DLM fragment creator (right now you can only create or delete dlm fragments by editing an xml file)
- (hard) DLM audience, PAGs, Person Directory editor portlets (right now this done by editing configuration files in text editors outside of the portal)
- (medium) Monitoring portlets (probably multiple here, some showing different stats collection results, some showing jmx info/controls, e.g., number of currently active sessions, ehcache info/controls)
New uPortal Services Portlets
These are kind of like the Admin Portlets but with a more end-user-non-admin focus.
- (very hard) uPortal Search Framework - Develop a search framework that would allow for searching within the portal environment. Implementation should include an index of published content & descriptions (e.g. keywords, titles, descriptions) as well as the ability for portlets to participate in the indexing. One example might be a webproxy or RSS portlet supporting an optional interface that would allow them to return an index of the information retrieved by the portlet, which could then be returned as part of search results. Or an addressbook portlet might export an interface to local and remote directories. Other functionality which should be investigated is the ability of this search service to plug into a broader search framework, e.g. acting as a data source for something like a Google Search Appliance.
Third Party Portlets (Incorporate from somewhere else?) (mentor: CrisH)
Work to try to get technology developed elsewhere to run seemlessly and possibly ship with uPortal, by listing these things I do not mean to imply I know they exist, I just expect they already do and it would probably be better to use them if they exist, then to create our own versions. The effort of each of the following is marked as easy assuming the work is only to package already existing portlet code up for use in uPortal, it assumes minimal to no code changes. This may or may not be a realistic assumption, depending on the third party code that is used.
- (easy) forums
- (easy) blog (display and/or author)
- (easy) wiki
- (easy) flickr portlet
- (easy) nearly any existing social networking site portlet
Framework
The following ideas are not necessarily portlet oriented, but more framework oriented. They might involve creating or modifying portlets, but the original ideas seemed more apart from Portlets when the idea was first documented.
- (hard) Support for CONFIG Portlet mode
- (hard) Support for EDIT_DEFAULTS Portlet mode
- (hard) Support for PREVIEW Portlet mode
- (very hard) Asynchronous portlet rendering - Modify the uPortal rendering process to support asynchronously rendering portlets, probably using AJAX to perform composition and aggregation of portlet content at the browser level, instead of using the current rendering buffer approach. The asynchronous rendering functionality should gracefully degrade to support browsers and rendering devices that do not support javascript, using techniques such as progressive enhancement.
WSRP Support
WSRP is a cross-platform (Java and .Net primarily) standard for exposing and sharing portlet-type content through webservices. Implementations can both produce and consume WSRP markup, allowing their services & content to be distributed across multiple sites, servers, and services. This could include:
- (hard) Implement a WSRP Consumer Portlet to display remote content in the portal
- (very hard) Implement a WSRP Producer to support exposing portal content to external consumers
- (very hard) WSRP and WS-* Security implementations to bridge authentication between sessions