Page Comparison

[13:47:08 CDT(-0500)] <b-rock> Greetings uPortal devs: I'm trying to initialize a database for a new 3.2.2 build of the portal and get the following error http://uportal.pastebin.com/4Vp89sVR
[13:47:45 CDT(-0500)] <b-rock> I'm not sure how to get the dbloaderrunner in the classpath for ant. I see it build out in the target folder but am not sure why ant doesn't see it.
[13:47:59 CDT(-0500)] <b-rock> does someone here know how to get it into the ant classpath?
[13:48:04 CDT(-0500)] <EricDalquist> can you pipe the full output into a file?
[13:48:13 CDT(-0500)] <EricDalquist> the build script should set that up automatically
[13:49:14 CDT(-0500)] <b-rock> sure. I'm re running it now.
[13:53:49 CDT(-0500)] <b-rock> ok. here is the full trace http://uportal.pastebin.com/5dypw3km
[13:54:25 CDT(-0500)] <EricDalquist> hrm
[13:54:29 CDT(-0500)] <EricDalquist> that all looks right
[13:54:45 CDT(-0500)] <EricDalquist> it is building the uPortal JAR which has DBLoader in it
[13:55:04 CDT(-0500)] <EricDalquist> try adding -d to the ant command
[13:55:15 CDT(-0500)] <b-rock> I'll check
[13:55:23 CDT(-0500)] <EricDalquist> I think that will show you the classpath it is using for running dbloader
[13:55:29 CDT(-0500)] <b-rock> ok
[14:02:20 CDT(-0500)] <b-rock> here is the with the -d option http://uportal.pastebin.com/dxdie5s6. Should I be running "ant initdb" instead of "ant db"? I do see the clasee in the uportal-impl/target/..impl.jar as well.
[14:03:32 CDT(-0500)] <b-rock> I have ant 1.8.1 also.
[14:10:40 CDT(-0500)] <b-rock> looks like uportal-impl-3.2.2.jar isn't on the classpath http://uportal.pastebin.com/T3JZ0GiU do you know if there is a -D option I can use to add it manually to the command?
[14:19:38 CDT(-0500)] <b-rock> haven't got it yet but am off to a meeting. Thanks for your help.
[14:37:38 CDT(-0500)] <mccordl> I may be dreaming but I thought when I had tried using uportal 3.2.2 with ant 1.8+ I had a problem and I reverted back to ant 1.7.1 and it worked. I could be totally off but I think I remember thinking perhaps that's why the uportal 3.1 manual specifies ant 1.7 and not ant 1.7+
[14:57:12 CDT(-0500)] <EricDalquist> oh
[14:57:13 CDT(-0500)] <EricDalquist> yeah
[14:57:15 CDT(-0500)] <EricDalquist> ant 1.7.1
[14:57:28 CDT(-0500)] <EricDalquist> in fact it is a bug that the build doesn't fail immediately with 1.8
[15:05:38 CDT(-0500)] <mccordl> I'll make a note of that in the manual
[15:05:49 CDT(-0500)] <EricDalquist> thanks mccordl
[15:05:55 CDT(-0500)] <mccordl> no prob
[16:16:18 CDT(-0500)] <Bananobot> I'm trying to compare the uPortal and Liferay support communities as part of an evaluation. The two IRC channels have the same number of users, counting ChanServ. :/
[16:16:30 CDT(-0500)] <EricDalquist> hah
[16:16:51 CDT(-0500)] <Bananobot> But unlike #liferay, ##uportal has a channel topic, so points go to you
[16:16:52 CDT(-0500)] <EricDalquist> do they log their channel?
[16:17:00 CDT(-0500)] <Bananobot> Probably not
[16:17:07 CDT(-0500)] <EricDalquist> well and technically JASIGLogBot isn't really a user
[16:17:16 CDT(-0500)] <EricDalquist> it just sits there and writes what we type to our wiki
[16:17:40 CDT(-0500)] <Bananobot> What's the current status of JSR-286 in uPortal?
[16:17:59 CDT(-0500)] <EricDalquist> in development with a planned GA release in late 2010 or early 2011
[16:18:25 CDT(-0500)] <Bananobot> That's good news
[16:18:46 CDT(-0500)] <EricDalquist> lots of really neat stuff in trunk right now
[16:19:00 CDT(-0500)] <EricDalquist> a nice new URL syntax (bookmarkable, logical navigation and such)
[16:19:10 CDT(-0500)] <EricDalquist> a really nice new customization UI
[16:19:19 CDT(-0500)] <EricDalquist> let me see if there is a screencast of that up yet
[16:20:09 CDT(-0500)] <EricDalquist> hrm, my person to ask just signed off for the day ... that's not helpful
[16:20:25 CDT(-0500)] <Bananobot> I did a brief accessibility evaluation of both portal systems a while ago. I did uPortal first, writing up a big list of accessibility issues I found, places where it violated Section 508, etc., obviously concluding that I didn't consider it to be a very accessible system. Then I took a look at Liferay. ...I recommended uPortal.
[16:20:37 CDT(-0500)] <EricDalquist> heh
[16:20:40 CDT(-0500)] <EricDalquist> we're working hard on it
[16:21:12 CDT(-0500)] <EricDalquist> working very closely with the Fluid project which does a lot of work with creating JavaScript components that play nice with accessibility tools
[16:21:31 CDT(-0500)] <EricDalquist> the drag & drop in uPortal for example is completely functional with just a keyboard
[16:21:46 CDT(-0500)] <EricDalquist> but there are a lot of areas to improve too
[16:21:52 CDT(-0500)] <Bananobot> I wish Section 508 would be updated to require reasonable heading navigation. That's probably the most commonly-used navigational feature for screen readers, yet it isn't mentioned anywhere in Section 508
[16:22:26 CDT(-0500)] <Bananobot> Liferay uses heading elements as if they're just to add general emphasis
[16:22:49 CDT(-0500)] <EricDalquist> heh
[16:23:16 CDT(-0500)] <EricDalquist> I don't do much work directly with the UI but I know there are a bunch of hidden navigational aids in the default uPortal UI
[16:23:33 CDT(-0500)] <awills> yes there are
[16:23:38 CDT(-0500)] <Bananobot> That's one of the reasons I'm looking forward to HTML 5. You'll be able to scope things like portlets inside <section> elements, thus eliminating the heading level stacking issues currently plaguing portals
[16:23:48 CDT(-0500)] <EricDalquist> oh yeah
[16:23:50 CDT(-0500)] <EricDalquist> that sounds handy
[16:24:20 CDT(-0500)] <EricDalquist> here are the design and wireframes for the new customization UI: https://wiki.jasig.org/display/UPC/Customize+Portal+Gallery
[16:24:28 CDT(-0500)] <EricDalquist> and https://wiki.jasig.org/display/UPC/Manage+Tabs
[16:28:04 CDT(-0500)] <EricDalquist> Bananobot: so the person who can speak to this stuff better can't be in IRC right now but via IM she said:
[16:28:04 CDT(-0500)] <EricDalquist> we actually have talked specifically about the use of heading elements and try to use them explicitly for heading navigation
[16:28:04 CDT(-0500)] <EricDalquist> and have separate CSS classes for styles
[16:28:04 CDT(-0500)] <EricDalquist> generally i believe we start portlets at <h2> so that <h1> can be the title for the whole page
[16:28:04 CDT(-0500)] <EricDalquist> also Gary Thompson (one of the main UI developers of uPortal) regularly checks uportal in screen readers
[16:28:28 CDT(-0500)] <EricDalquist> and we have things like skip links and ARIA roles included in the portal and many of the portlets and keyboard navigation features
[16:28:41 CDT(-0500)] <EricDalquist> wish she could be here so I didn't have to relay all of that
[16:29:23 CDT(-0500)] <EricDalquist> I think she'll be back in IRC tomorrow if you jump back with more questions
[16:36:44 CDT(-0500)] <Bananobot> The usual approach is to use a single h1 element, which is usually just a reiteration of the title element, and then all other headings are level 2 and beyond. There's some debate over whether this is actually the best approach for screen readers, since a flatter setup (where you have multiple h1 elements) means there's one fewer navigational action they have to do
[16:37:05 CDT(-0500)] <Bananobot> Then again, many screen reader users are used to just jumping into the first h1 and seeing what's inside that
[16:38:57 CDT(-0500)] <Bananobot> My biggest accessibility complaint with uPortal was that it deliberately hid the browser's focus rectangle, which is a major major no-no. I heard that was more of an oversight and that it was quickly fixed.
[16:40:39 CDT(-0500)] <holdorph> It's worth pointing out that at least with uPortal you could fix those things and submit a patch to uPortal. Other users could see / download the patch. And if the patch was good it would get incorporated into the main uportal code base pretty quickly
[16:41:00 CDT(-0500)] <holdorph> I've been told that getting code into liferay if you're not a liferay employee is pretty tough
[16:41:24 CDT(-0500)] <Bananobot> We're currently working with Unicon on some projects, and they seem to be regular uPortal contributors. We've already forwarded them some of my comments.
[16:41:25 CDT(-0500)] <EricDalquist> also as you go through your comparison we would be very interested in hearing your feedback on uPortal and the comparisons you come up with
[16:42:17 CDT(-0500)] <holdorph> full disclosure, i am a unicon employee, and Unicon is both a uPortal professional services provider and also a liferay partner.
[16:45:28 CDT(-0500)] <Bananobot> So far, Liferay's big selling points include JSR-286 support (which probably isn't a big deal anyway if our goal is to develop portlets that work in as many environments as possible; we'll probably be sticking with JSR-168 anyway) as well as a general perception that they are faster to adopt newer standards. uPortal seems to win in terms of accessibility and openness.
[16:46:15 CDT(-0500)] <holdorph> besides jsr 286, what other standards lead you to view liferay as faster to adop newer standards?
[16:47:41 CDT(-0500)] <Bananobot> I haven't looked into it that much. One of our partners wrote up a huge document basically concluding that uPortal has been slow to adopt emerging standards, but he's been solidly in the Liferay camp for quite some time and I'm not sure how objective his document was.
[16:48:29 CDT(-0500)] <Bananobot> I haven't worked with either uPortal or Liferay until just recently
[16:49:14 CDT(-0500)] <EricDalquist> well I have to run ... I'm in here most every weekday and look forward to chatting more Bananobot
[16:49:27 CDT(-0500)] <Bananobot> Thanks for the help
[16:49:40 CDT(-0500)] <holdorph> uportal is way behind in the adoption of jsr 286, but I don't believe it's behind in adoption of other standards
[16:50:02 CDT(-0500)] <Bananobot> WSRP 2.0 was another technology that was mentioned
[16:50:02 CDT(-0500)] <holdorph> i believe that's probably the case of taking one fact and creating a whole story around it.
[16:50:37 CDT(-0500)] <holdorph> WSRP was abandoned. That was a mostly conscious decision.
[16:51:06 CDT(-0500)] <holdorph> WSRP did not get adoption outside of uPortal and so was not worth the investment in effort, to fullfill a feature no one was using.
[16:52:19 CDT(-0500)] <holdorph> see this page http://incubator.apache.org/projects/wsrp4j.html
[16:52:27 CDT(-0500)] <holdorph> and the 2010-04-18 entry
[16:52:29 CDT(-0500)] <Bananobot> Liferay apparently supports it, so I guess that was one of the arguments in favor of Liferay
[16:52:44 CDT(-0500)] <Bananobot> Of course, I don't know if we'd ever need to use it
[16:52:54 CDT(-0500)] <holdorph> but for WSRP to be useful you have to have some other platform to use it with
[16:53:07 CDT(-0500)] <holdorph> what other platform does WSRP you'll be talking to?
[16:53:54 CDT(-0500)] <holdorph> Anyway, it is definitely a feature uPortal doesn't have. but that one is not because uPortal is slow to adopt the standard, we are consciously not spending the time on it, because no one wants to use it.
[16:55:32 CDT(-0500)] <Bananobot> I'm not aware of any plans to use WSRP. I think it was just tossed out there as a sort of "keeping the doors open" kind of concern
[16:55:58 CDT(-0500)] <Bananobot> Whether merited or not
[16:56:07 CDT(-0500)] <holdorph> it's definitely a feature difference
[16:56:20 CDT(-0500)] <holdorph> just not a reason to conclude uportal is slow to adopt standards
[16:58:10 CDT(-0500)] <Bananobot> One point in favor of uPortal was that we are aware of cases where a uPortal instance has apparently scaled to millions of users, while we aren't aware of such cases for Liferay.
[16:58:37 CDT(-0500)] <awills> that is correct... lfuller works with that system
[16:58:40 CDT(-0500)] <holdorph> uPortal is in use at Pearson Publishing with that many users
[16:58:43 CDT(-0500)] <Bananobot> We will need to scale to very heavy amounts of traffic.
[16:59:24 CDT(-0500)] <holdorph> you're aware of the pricing models for both uPortal and liferay correct?
[17:00:47 CDT(-0500)] <Bananobot> Yes
[17:01:36 CDT(-0500)] <holdorph> ok. as long as you know. I have heard from too many people who believe Liferay is free.
[17:01:42 CDT(-0500)] <Bananobot> I'm personally not a fan of freemium models, but the decision makers don't seem to see that as a concern (even though we've already been bitten by freemium models recently)
[17:02:40 CDT(-0500)] <holdorph> there's nothing about liferay that's free, as far as a production system goes.
[17:03:05 CDT(-0500)] <Bananobot> In general, I notice that directors don't seem to understand the distinctions between "open source", "open source project", and "free"
[17:03:35 CDT(-0500)] <holdorph> liferay is neither
[17:04:26 CDT(-0500)] <Bananobot> So, we've concluded that we'll be using eXo Platform. Thanks for the help.
[17:04:46 CDT(-0500)] <Bananobot>
[17:05:33 CDT(-0500)] <Bananobot> Oh hey, Wikipedia says Exo Platform supports WSRP 2.
[17:05:38 CDT(-0500)] <holdorph> exo is similar
[17:05:48 CDT(-0500)] <holdorph> in terms of not really being free/open source
[17:05:56 CDT(-0500)] <Bananobot> Exo actually hasn't been in the conversation at all
[17:06:11 CDT(-0500)] <Bananobot> But I took a look at it and it didn't seem like a compelling option
[17:06:21 CDT(-0500)] <Bananobot> So I figured I'd just keep quiet
[17:06:29 CDT(-0500)] <holdorph> exo doesn't get talked a lot about, but it's definitely an option if you're willing to spend money
[17:07:54 CDT(-0500)] <holdorph> the only truly free JSR 168 portal platforms most people talk about are: Jetspeed, JBoss portal and uPortal. exo and liferay you can see some of the source, but aren't really free or open source.
[17:08:18 CDT(-0500)] <Bananobot> Our goal is to develop portlets that we can easily distribute to as many colleges as possible, but to also have our own central portal as the sort of canonical implementations of those portlets
[17:10:40 CDT(-0500)] <athena> hey Bananobot
[17:10:51 CDT(-0500)] <athena> i hear you were asking a few questions about uportal and accessibility
[17:11:08 CDT(-0500)] <Bananobot> Yeah
[17:11:19 CDT(-0500)] <holdorph> full disclosure, athena is also a unicon employee
[17:11:21 CDT(-0500)] <Bananobot> Well, more of comments than questions
[17:11:47 CDT(-0500)] * athena is indeed
[17:12:25 CDT(-0500)] <athena> so i actually think uportal has often been early to adopt new technology - sometimes too early to be relevant, unfortunately (see mobile support)
[17:12:49 CDT(-0500)] <Bananobot> When I was evaluating uPortal and Liferay in terms of accessibility, I ended up concluding that uPortal was the better of the two, but still significantly flawed.
[17:12:59 CDT(-0500)] <athena> what issues did you see in uportal?
[17:13:24 CDT(-0500)] <athena> we've really prioritized accessibility, so i think we'd be interested in hearing about any problems you found
[17:13:30 CDT(-0500)] <Bananobot> In the build that I installed, the stylesheet dilberately hid the browser's focus rectangle. I heard that this was a recent issue and that it has since been fixed?
[17:13:41 CDT(-0500)] <athena> i know it's tested in a screen reader fairly regularly
[17:13:56 CDT(-0500)] <athena> i think it has been, but if it hasn't, that's a one-line CSS change
[17:14:30 CDT(-0500)] <athena> so it should be pretty easy to customize if you need to
[17:14:50 CDT(-0500)] <athena> as far as navigation goes, it's worth mentioning that the uportal theme includes a bunch of skip links that help access portlets, menus, etc.
[17:15:08 CDT(-0500)] <Bananobot> There was also an issue where the headings in the default portlets were using inconsistent levels. For example, one of the default portlets that shows a tabbed pane used heading level 1, which caused the rest of the page to appear as if it were inside that portlet, from a screen reader's perspective
[17:15:45 CDT(-0500)] <athena> i think we'd consider that a bug - if you remember what portlet it was, i'd be happy to file a JIRA for that
[17:15:54 CDT(-0500)] <Bananobot> Let me check
[17:15:57 CDT(-0500)] <athena> thanks!
[17:16:35 CDT(-0500)] <athena> uportal also uses aria roles and such, if you're looking for that kind of support
[17:17:15 CDT(-0500)] <Bananobot> Ah, it was the "Welcome" portlet that by default had three tabs with Lorem Ipsum text. It was the content area that contained h1 headings
[17:17:21 CDT(-0500)] <athena> ah
[17:17:27 CDT(-0500)] <athena> thanks for pointing that out - we can get that fixedf
[17:17:43 CDT(-0500)] <athena> i'm certainly hoping that real deployments of uportal don't actually use that portlet
[17:17:54 CDT(-0500)] <Bananobot> The tab labels should also be headings, but they aren't
[17:18:22 CDT(-0500)] <Bananobot> Actually, I take that back
[17:18:58 CDT(-0500)] <Bananobot> The tabs are implemented correctly
[17:19:14 CDT(-0500)] <athena> ok
[17:19:21 CDT(-0500)] <athena> thanks for letting us know about the h1 issue
[17:19:43 CDT(-0500)] <athena> i know it's kind of hard to compare portals - there's a lot of outdated information out there
[17:21:18 CDT(-0500)] <Bananobot> I get the feeling that my boss is already settled on uPortal, but he needs to go through an objective process so he can back up his decision should he be asked to justify it
[17:21:36 CDT(-0500)] <lfuller> always worth the effort.
[17:22:05 CDT(-0500)] <lfuller> on the project I am on we tend to revaluate the portals every few years or so. We haven't switched off uPortal though.
[17:22:11 CDT(-0500)] <Bananobot> I'm reading the accessibility evaluation I wrote..
[17:22:33 CDT(-0500)] <Bananobot> Ah, lightbox dialogs use span elements instead of headings
[17:22:34 CDT(-0500)] <lfuller> but Pearson is pretty intense about performance... which uPortal does better than any of the others we have thus far tried.
[17:22:44 CDT(-0500)] <lfuller> although JBoss was not too far behind in the tests we did a while back.
[17:23:01 CDT(-0500)] <Bananobot> Some default portlets require JavaScript, such as the bookmark manager
[17:23:49 CDT(-0500)] <lfuller> 508 is a pretty outdated standard... in some ways it was out of date as soon as it was released
[17:24:08 CDT(-0500)] <lfuller> but it is one of the few measuring sticks out there.
[17:24:45 CDT(-0500)] <Bananobot> Yeah, I'm not a fan of 508. I always tell people that 508 is just a starting point, and it allows the online equivalent of building a mile-long wheelchair ramp for a single flight of stairs
[17:25:04 CDT(-0500)] <lfuller>
[17:25:49 CDT(-0500)] <lfuller> Have you looked at the Fluid project?
[17:26:05 CDT(-0500)] <Bananobot> athena: The site sometimes "steals" keystrokes, so things like Ctrl+T and Ctrl+F don't work as expected. I was told that it's because you can get into a modal situation where the keystrokes are interpreted for other actions, but as a first-time user it wasn't obvious to me why my normal key combinations suddenly weren't working
[17:26:06 CDT(-0500)] <athena> which lightbox dialogs Bananobot? the things for modifying the portal layout?
[17:26:30 CDT(-0500)] <athena> Bananobot: if you're interested in filing JIRAs for stuff like that, we'd love to get it fixed
[17:27:13 CDT(-0500)] <Bananobot> I'll probably be sending in some tickets for both uPortal and Liferay.
[17:27:42 CDT(-0500)] <athena> Fluid is a neat project - very thoughtful, interesting javascript framework and components w/ a lot of accessibility support
[17:27:57 CDT(-0500)] <Bananobot> athena: Clicking on "Page Layout" is an example of the lightboxes I'm talking about
[17:28:21 CDT(-0500)] <Bananobot> athena: How well does it work when JavaScript is disabled?
[17:28:23 CDT(-0500)] <athena> gotcha
[17:28:51 CDT(-0500)] <athena> all those lightboxes are actually gone in the trunk already - we've replace all of that with a new unified content selection component
[17:29:02 CDT(-0500)] <athena> we require javascript to be enabled, basically
[17:29:04 CDT(-0500)] <Bananobot> Ah
[17:29:29 CDT(-0500)] <athena> at this point, most of the accessibility communities and standards seem to agree that it's OK to require javascript, as far as i understand it
[17:30:16 CDT(-0500)] <Bananobot> Another issue is the flexibility of the layout as the font size changes. I you disable the full-screen zooming (in Firefox, check the "Zoom text only" option in the menu) and crank up the font just a few notches, some of the text starts overlapping other parts of the page
[17:30:21 CDT(-0500)] <athena> and all the devices we're currently aiming to support offer javascript these days (desktop browsers + webkit-based mobile phone browsers)
[17:30:35 CDT(-0500)] <athena> interesting
[17:31:05 CDT(-0500)] <Bananobot> athena: Well, I disagree that it's okay to require JavaScript. I'm a big fan of progressive enhancement techniques.
[17:31:13 CDT(-0500)] <athena> i know we use text font sizes that should scale appropriately, but perhaps there is some absolute positioning that's causing that
[17:31:35 CDT(-0500)] <athena> i'm all for progressive enhancement
[17:32:05 CDT(-0500)] <athena> but i don't think we've yet heard of many real use cases that would justify building out all the functionality outside of javascript
[17:32:15 CDT(-0500)] <Bananobot> Remember that browsers aren't the only user agents visiting your site. Also, some people use NoScript (it's actually standard practice where I work, for users on Windows)
[17:32:47 CDT(-0500)] <Bananobot> It's definitely nice for a site to work without JavaScript.
[17:33:01 CDT(-0500)] <athena> yep, it definitely would be nice
[17:33:17 CDT(-0500)] <Bananobot> I can understand if you consider it not worth the effort. That's just not the way I roll.
[17:33:49 CDT(-0500)] <athena> i certainly wouldn't object to having those features - i think the issue has been more that uportal's a community-driven open-source project, so the priorities are generally set by the current adopters
[17:33:51 CDT(-0500)] <awills> it's possible to provide an additional theme, mapped to certain user agents or even users, that would contain no JavaScript at all, or alternately function 100% without JavaScript
[17:33:55 CDT(-0500)] <holdorph> which of the other portal platforms you evaluated work well without javascript enabled?
[17:34:10 CDT(-0500)] <athena> yep, awills is definitely right - uportal allows you to implement or select custom themes
[17:34:12 CDT(-0500)] <Bananobot> holdorph: None.
[17:34:21 CDT(-0500)] <athena> and older themes from uportal that didn't require javascript should still work
[17:34:42 CDT(-0500)] <awills> yes, that's true
[17:35:07 CDT(-0500)] <awills> it wasn't long ago, actually, that theme development was something you just did in the process of adopting uPortal
[17:35:34 CDT(-0500)] <lfuller> It is/was pretty common for institutions to cook up their own themes.
[17:35:37 CDT(-0500)] <awills> not so common now, since the out-of-the-box theme(s) are so improved
[17:36:03 CDT(-0500)] <lfuller> yeah... was going to say the same thing. The much older themes pretty much inspired folks to come up with their own
[17:36:20 CDT(-0500)] * holdorph remembers those days...
[17:36:21 CDT(-0500)] <Bananobot> Does uPortal have the ability to load portlet output from other portals without hosting the code locally?
[17:36:40 CDT(-0500)] <holdorph> not portlet content exactly. but other web site content
[17:36:48 CDT(-0500)] <holdorph> which could potentially be portlet content
[17:36:55 CDT(-0500)] <Bananobot> Was that supposed to be the goal of WSRP?
[17:37:20 CDT(-0500)] <awills> yes, basically... a federated portal model
[17:37:21 CDT(-0500)] <holdorph> yes. but wsrp was not widely adopted by virtually anyone.
[17:37:27 CDT(-0500)] <lfuller> with WSRP there are producers and consumers.... it just didn't take off is all (the standard I mean)
[17:37:33 CDT(-0500)] <holdorph> like the apache project I posted above.
[17:37:42 CDT(-0500)] <athena> a lot of schools achieve something similar via the uportal web proxy portlet (which is much more advanced than the liferay proxy portlet, i think)
[17:37:53 CDT(-0500)] <awills> yes, somehow WSRP came up somewhat regularly in RFP/planning stages, and never in implementation
[17:37:54 CDT(-0500)] <lfuller> Most people started using the web proxy portlets that are out there and the need for wsrp just sort of went away.
[17:37:58 CDT(-0500)] <Bananobot> holdorph: But Liferay and Exo both support WSRP 2.0, right?
[17:38:01 CDT(-0500)] <holdorph> even the apache software group, it died. if apache can't get wsrp to live.... I'm doubtful how well it's doing in the open source world in general.
[17:38:43 CDT(-0500)] <athena> i think all the open-source wsrp clients are mostly dead, which is why we haven't implemented it, IIRC
[17:38:48 CDT(-0500)] <lfuller> You might want to check to see if they both produce and consume WSRP Bananabot. Not much use if they only consume.
[17:38:58 CDT(-0500)] <holdorph> yes. If that feature is important to you, AND you can make it work well with those platforms. then you will not find an equivalent ability in uPortal
[17:39:11 CDT(-0500)] <holdorph> but I kind of doubt how much use out of WSRP you'd get in either liferay or exo
[17:39:26 CDT(-0500)] <holdorph> this comes from experience of trying to actually get wsrp up and running before.
[17:39:35 CDT(-0500)] <Bananobot> According to Wikipedia, Liferay supports WSRP 2.0 as both a producer and consumer. For Exo, I can't tell.
[17:39:53 CDT(-0500)] <athena> there are certainly some features in other portals that "exist", but don't actually work for any real use case - i wouldn't be surprised if WSRP support fell into that category
[17:40:08 CDT(-0500)] <holdorph> remember you have to pay for each server in the liferay case though.
[17:40:37 CDT(-0500)] <Bananobot> I'm only asking because this evaluation sheet specifically has a question about having the ability to embed portlets from other portals.
[17:41:14 CDT(-0500)] <holdorph> uportal users typically have taken a different approach. which it turns out works really well
[17:41:15 CDT(-0500)] <lfuller> yeah... like awills said, it frequently shows up on RFPs but never seems to get used
[17:41:31 CDT(-0500)] <holdorph> they just build actual web applications. and then proxy those applications in.
[17:41:57 CDT(-0500)] <Bananobot> Do uPortal and Liferay have similar SSO capabilities?
[17:41:57 CDT(-0500)] <lfuller> yeah... which is really pretty widespread. The web proxy approach I mean.
[17:42:36 CDT(-0500)] <athena> i don't think liferay supports shibboleth yet? (uportal does)
[17:42:46 CDT(-0500)] <holdorph> I will admit to not knowing the 'out of the box' sso options in liferay
[17:43:02 CDT(-0500)] <Bananobot> I know both support CAS.
[17:43:07 CDT(-0500)] <athena> other than that, uportal has good support for proxy-CAS authentication, which a lot of our deployers use heavily
[17:43:19 CDT(-0500)] <Bananobot> I'm not too familiar with the different SSO technologies. I know that we've been interested in Shibboleth
[17:43:36 CDT(-0500)] <athena> the last liferay release i saw didn't include proxy-CAS support, though they may have fixed that
[17:45:03 CDT(-0500)] <athena> uPortal ships with CAS out of the box, and CAS has a lot of authentication options, so it's generally possible to use anything CAS can use
[17:46:06 CDT(-0500)] <Bananobot> Is uPortal's Shibboleth support implemented through CAS?
[17:46:14 CDT(-0500)] <athena> no
[17:46:46 CDT(-0500)] <athena> there's direct support
[17:47:24 CDT(-0500)] <Bananobot> Does uPortal natively support OpenID?
[17:47:43 CDT(-0500)] <athena> i think CAS supports openid?
[17:48:38 CDT(-0500)] <holdorph> if it was important to someone the support could be added. but i don't know of anyone who's asked for it before. very few things get added to uportal, unless there's someone who's going to use them.
[17:48:53 CDT(-0500)] <holdorph> that's kind of the case with WSRP. no one was using it. so it was dropped.
[17:49:29 CDT(-0500)] <holdorph> open id and cas: https://wiki.jasig.org/display/CASUM/OpenID
[17:49:37 CDT(-0500)] <athena> we generally just use the CAS authentication options where they're available
[17:49:48 CDT(-0500)] <Bananobot> Okay
[17:49:55 CDT(-0500)] <athena> CAS is a pretty highly-regarded, secure product, so it makes a lot of sense to delegate to that
[17:50:02 CDT(-0500)] <Bananobot> I just noticed that Liferay has an option for OpenID, so I was curious
[17:50:18 CDT(-0500)] <athena> for something like shibboleth, we have direct code so that uportal can also acquire user attributes from the shibboleth service provider
[17:50:46 CDT(-0500)] <holdorph> shibboleth is a good example. that was added natively to uportal because university of chicago wanted it.
[17:50:57 CDT(-0500)] <holdorph> it didn't get added until they were going to use it though.
[17:51:47 CDT(-0500)] <athena> and then wisconsin improved on it, i believe
[17:52:30 CDT(-0500)] <holdorph> yes, it's been improved since it was added. but before chicago I believe USC was doing shibboleth, they just chose to do it outside of uPortal at the apache httpd level
[17:54:40 CDT(-0500)] <Bananobot> Well, I think I have what I need from you guys for now. Thanks. I'll still need to gather some more info about Liferay and also figure out some details about our proposed SSO setup to see if this question here is even relevant.
[17:56:04 CDT(-0500)] <Bananobot> Basically, we'll be using two different SSO systems at once: the college's own SSO which students will use to log into the system, and an additional SSO system which will be used by the portlets across all colleges.
[17:56:43 CDT(-0500)] <Bananobot> And I guess the two will hook together somehow
[17:56:50 CDT(-0500)] <Bananobot> Presumably by magic
[17:57:42 CDT(-0500)] <Bananobot> And I have to figure out whether uPortal or Liferay has better magic
[17:57:46 CDT(-0500)] <athena> well, uportal does offer some interesting authentication options for web proxy like proxy cas and delegated SAML (shibboleth), if it comes up
[17:58:37 CDT(-0500)] <awills> the model you describe sounds like a shib scenario, from what I understand
[17:58:41 CDT(-0500)] <athena> afraid i've got to run, but i'll be back tomorrow if you have specific questions
[17:58:48 CDT(-0500)] <Bananobot> athena: Thanks
[19:01:04 CDT(-0500)] <EricDalquist> hey there Bananobot, are you still around?
[19:01:11 CDT(-0500)] <Bananobot> Yeah
[19:01:19 CDT(-0500)] <EricDalquist> just read through the IRC logs
[19:01:41 CDT(-0500)] <EricDalquist> so we're using two AuthN systems at the same time with uPortal at UW-Madison
[19:02:03 CDT(-0500)] <EricDalquist> our primary users (Madison) go to my.wisc.edu and authenticate via PubCookie
[19:02:24 CDT(-0500)] <EricDalquist> about a year ago we started virtual hosting of the UW System portal: my.wisconsin.edu
[19:02:31 CDT(-0500)] <EricDalquist> users there login using Shib
[19:03:05 CDT(-0500)] <EricDalquist> implementation wise they are all logging into a single (clustered) uPortal instance that is serving both user groups
[19:03:21 CDT(-0500)] <EricDalquist> we set the skin the users see to something campus specific based on user attributes from shib
[19:04:34 CDT(-0500)] <Bananobot> Hm.. does this require custom modifications to uPortal code, or is it more modular than that?
[19:05:15 CDT(-0500)] <EricDalquist> I think our only code customization was creating a 10 line class that sets the user's skin parameter based on the user attribute and that is configured via Spring
[19:05:57 CDT(-0500)] <EricDalquist> we're in the middle of upgrading the 3.2.2 right now and when we're done with that we'll be contributing back any local modifications as patches
[19:06:26 CDT(-0500)] <EricDalquist> thats generally part of our upgrade cycle, see what we still have as a local mod and then see if we can make it not a local mod in the future somehow
[19:08:13 CDT(-0500)] <Bananobot> Unfortunately, I don't think we have the local development resources necessary to do much contribution back. I'm the only local programmer we have, and I'm also responsible for server maintenance, in-house tech support, and a column in our online publication.
[19:08:25 CDT(-0500)] <Bananobot> And, obviously, research
[19:08:53 CDT(-0500)] <EricDalquist> sounds like a lot of schools I've been in contact with over the years
[19:08:55 CDT(-0500)] <Bananobot> Which is why we're contracting with Unicon
[19:10:04 CDT(-0500)] <EricDalquist> a lot of the time even if the patch can't be applied directly attaching a 'diff -u' to a Jira ticket along with some info about the version of uPortal the diff is against is enough to get a uPortal developer to clean it up and integrate it
[19:10:15 CDT(-0500)] <Bananobot> Also, I've never done much Java programming before (and I've never done web programming in Java before), so this is a learning experience. Most of my programming experience was in PHP.
[19:10:19 CDT(-0500)] <EricDalquist> but Unicon has been good about helping places contribute back as well
[19:12:25 CDT(-0500)] <EricDalquist> well I'm off again, time to get the little one to bed. Catch you tomrorrow
[19:12:49 CDT(-0500)] <Bananobot> I have tomorrow off
[19:12:53 CDT(-0500)] <Bananobot> I'll see you later
[19:12:58 CDT(-0500)] <EricDalquist> later then
[19:13:02 CDT(-0500)] <EricDalquist> and have a good day off
[19:13:05 CDT(-0500)] <Bananobot> Thanks