uPortal IRC Logs-2012-01-19
[09:11:37 CST(-0600)] <dd> hello
[09:11:46 CST(-0600)] <EricDalquist> hi
[09:11:59 CST(-0600)] <dd> had a couple questions about fragments
[09:12:16 CST(-0600)] <dd> as it is now, i have the welcome fragment that is set for all groups
[09:12:27 CST(-0600)] <dd> i make a change and it shows up on all groups
[09:12:40 CST(-0600)] <dd> but for students i would like one extra portlet to be there
[09:12:58 CST(-0600)] <dd> but the student fragment only works for the Student tab
[09:13:04 CST(-0600)] <dd> is there a way i can do this?
[09:13:37 CST(-0600)] <EricDalquist> do you want that one portlet to only be visible to students in general?
[09:13:47 CST(-0600)] <EricDalquist> or should non-students be allowed to find/subscribe to it
[09:15:04 CST(-0600)] <dd> well, it's the e-mail preview portlet. we have a separate mail server for students
[09:15:20 CST(-0600)] <EricDalquist> ok
[09:15:21 CST(-0600)] <dd> so i created another email preview portlet with the student host set
[09:15:31 CST(-0600)] <EricDalquist> so what I would do is permission that portlet to just the Student group
[09:15:39 CST(-0600)] <EricDalquist> and then add it to the welcome fragment
[09:15:42 CST(-0600)] <dd> so basically i want to show that to student group while showing the non-student version to everyone else
[09:15:57 CST(-0600)] <EricDalquist> portlets that people don't have permission to see are silently filtered out of the layout when it is being built
[09:16:14 CST(-0600)] <dd> oh, nice. didn't know that
[09:16:28 CST(-0600)] <dd> so would i need to add welcome-lo to the student version of the portlet?
[09:16:34 CST(-0600)] <dd> so it has the ability to add it?
[09:16:37 CST(-0600)] <EricDalquist> yes
[09:16:52 CST(-0600)] <EricDalquist> in general the way we have permissions setup is that layout owners are in a special group
[09:17:01 CST(-0600)] <EricDalquist> that has permission to pretty much everything
[09:17:09 CST(-0600)] <EricDalquist> just so that when you're admining layouts you can find what you need
[09:19:06 CST(-0600)] <dd> great, thanks
[09:32:09 CST(-0600)] <dd> forgot to ask, how can i prevent users or groups of users from deleting or moving a portlet?
[09:32:15 CST(-0600)] <dd> can't seem to find documentation on it
[09:33:12 CST(-0600)] <EricDalquist> what version of uPortal?
[09:33:15 CST(-0600)] <dd> 3.2.4
[09:33:26 CST(-0600)] <EricDalquist> when you're logged in as the fragment owner
[09:33:30 CST(-0600)] <EricDalquist> there should be a customize link
[09:33:31 CST(-0600)] <EricDalquist> click that
[09:33:34 CST(-0600)] <EricDalquist> then click on the portlet title
[09:33:38 CST(-0600)] <EricDalquist> or the column header
[09:33:41 CST(-0600)] <EricDalquist> and you should get options
[09:33:47 CST(-0600)] <dd> ok
[15:04:26 CST(-0600)] <Misagh> Hi Eric, got a question on git and maven-release-plugin integration. do you have a quick minute to chat?
[15:06:14 CST(-0600)] <EricDalquist> sure
[15:07:04 CST(-0600)] <EricDalquist> uPortal trunk is setup to use the release plugin with git: https://github.com/Jasig/uPortal/blob/master/pom.xml
[15:10:03 CST(-0600)] <Misagh> Thanks. The project I am working on has a parent module (a git repository with the parent pom.xml, SCM section points to the github repository jjust like uPortal) and inside the parent folder, I have a bunch of other folders defined as submodules that point to the parent pom. So far, so good.
[15:10:31 CST(-0600)] <Misagh> The problem is, when I try to execute mvn release:prepare I get the following message from git when it tries to commit the modified poms.
[15:11:06 CST(-0600)] <Misagh> fatal: <filename> is outside repository
[15:11:21 CST(-0600)] <Misagh> This is the error message I get the build process tries to commit the modified poms
[15:11:33 CST(-0600)] <Misagh> Here's the command that it issues to the prompt:
[15:11:38 CST(-0600)] <EricDalquist> so you have 1 project in the repository
[15:11:45 CST(-0600)] <EricDalquist> which is a multi-module project
[15:11:51 CST(-0600)] <EricDalquist> and you're trying to release the entire project?
[15:12:26 CST(-0600)] <Misagh> yes
[15:12:33 CST(-0600)] <EricDalquist> weird
[15:12:38 CST(-0600)] <EricDalquist> I don't remember having any problems
[15:12:39 CST(-0600)] <Misagh> specifically, this is for CAS clearpass
[15:12:51 CST(-0600)] <Misagh> The command it executes is the following: Executing: cmd.exe /X /C "git add – pom.xml C:\Misagh\GitWorkspace\cas-clearpass\clearpass-core\pom.xml C:\Misagh\GitWorkspace\cas-clearpass\clearpass-webapp\pom.xml C:\Misagh\GitWorkspace\cas-clearpass\clearpass-integration-uportal\pom.xml"
[15:13:09 CST(-0600)] <EricDalquist> just updated the scm block
[15:13:16 CST(-0600)] <EricDalquist> link to the git repo?
[15:14:25 CST(-0600)] <Misagh> sure, let me push the local changes to the repo
[15:17:43 CST(-0600)] <Misagh> Link: https://github.com/mmoayyed/clearpass
[15:18:33 CST(-0600)] <EricDalquist> so you cloned https://github.com/mmoayyed/clearpass.git to C:\Misagh\GitWorkspace\cas-clearpass
[15:18:39 CST(-0600)] <EricDalquist> and are executing the release command from that directory
[15:18:48 CST(-0600)] <Misagh> exactly
[15:19:14 CST(-0600)] <Misagh> during the build, I do see the working directory set to c:\Misagh\GitWorkspace\cas-clearpass right before the git command is sent
[15:19:14 CST(-0600)] <EricDalquist> my only other suggestion is to make sure you're using the latest version of the release plugin
[15:19:39 CST(-0600)] <EricDalquist> what version of git are you using?
[15:19:46 CST(-0600)] <Misagh> my last commit was to actually bump the latest ver to 2.2.2, still a no go
[15:19:53 CST(-0600)] <EricDalquist> I'm on 1.7.7.4 locally
[15:20:04 CST(-0600)] <EricDalquist> and I believe this is the machine I did the last uP4 release from
[15:20:34 CST(-0600)] <Misagh> ah! I am on git version 1.7.3.1.msysgit.0
[15:20:41 CST(-0600)] <Misagh> Windows 7 pro
[15:20:56 CST(-0600)] <EricDalquist> yeah, perhaps try a newer version of git
[15:21:03 CST(-0600)] <EricDalquist> or to be snarky … something that isn't windows
[15:21:12 CST(-0600)] <Misagh> ok. thanks.
[15:21:25 CST(-0600)] <EricDalquist> since that honestly could be a difference as well
[15:21:32 CST(-0600)] <EricDalquist> I do all my work on either linux os osx
[15:21:43 CST(-0600)] <EricDalquist> os/or
[15:21:52 CST(-0600)] <Misagh> sure if the update doesnt work, I will switch to Ubuntu to see if that makes a difference
[15:32:12 CST(-0600)] <Misagh> upgraded git to 1.7.8, testing again...
[15:33:36 CST(-0600)] <Misagh> btw, I saw that you merged the changes on perf improvements into uPortal. any benchmarks?
[15:33:56 CST(-0600)] <EricDalquist> I don't have any, arvids has been doing a bunch of perf testing
[15:34:02 CST(-0600)] <EricDalquist> and those are fixes he's found
[15:36:55 CST(-0600)] <Misagh> git 1.7.8, same problem
[15:37:59 CST(-0600)] <EricDalquist> weird
[15:38:10 CST(-0600)] <Misagh> fatal: 'C:\Misagh\GitWorkspace\cas-clearpass\clearpass-core\pom.xml' is outside repository
[15:38:34 CST(-0600)] <Misagh> before switching to a different OS, I wonder if I can use git submodules to make this work?
[15:44:01 CST(-0600)] <Misagh> wow, interesting
[15:44:11 CST(-0600)] <Misagh> so, this is what happens
[15:44:24 CST(-0600)] <Misagh> I modified the pom file of one of the submodules , clearpass-core
[15:44:42 CST(-0600)] <Misagh> then, inside the parent directory, I ran git add <absolute-path-to-pom> and got the same error
[15:45:00 CST(-0600)] <Misagh> however, if I use relative paths like git add clearpass-core\pom.xml, works like a charm!
[15:46:14 CST(-0600)] <EricDalquist> that makes me think even more that it is some git/windows issue
[15:46:57 CST(-0600)] <Misagh> hmmm
[15:51:50 CST(-0600)] <Misagh> well, before I make the switch, are you aware of any particular options with the plugin that would force it to create relative paths? I doubt there's one out there, but I found a JIRA that someone has posted a patch for this exact issue
[15:52:06 CST(-0600)] <EricDalquist> I don't
[16:07:44 CST(-0600)] <Misagh> Figured out the issue
[16:08:16 CST(-0600)] <Misagh> so, the mvn scm plugin for git actually tries to parse the file path to make it relative, and it uses the startsWith() method to compare the file path against the working directory path
[16:08:34 CST(-0600)] <Misagh> the weird part is the file path starts off with "C:\", and the working directory is set to "c:\" !!
[16:09:00 CST(-0600)] <Misagh> startsWith() uses the equals(), so comparison is case sensitive!
[16:09:27 CST(-0600)] <EricDalquist> yay windows
[16:09:31 CST(-0600)] <Misagh> LOL
[16:09:42 CST(-0600)] <EricDalquist> have I mentioned my love for that OS latelty?
[16:09:44 CST(-0600)] <athena> EricDalquist: i'll create a JIRA for that pull request and merge it in
[16:09:45 CST(-0600)] <EricDalquist>
[16:09:50 CST(-0600)] <EricDalquist> thanks athena
[16:09:54 CST(-0600)] <athena> yep!
[16:09:57 CST(-0600)] <EricDalquist> glad to see new names doing pulls
[16:10:00 CST(-0600)] <athena> yeah
[16:10:01 CST(-0600)] <Misagh>
[16:10:07 CST(-0600)] <athena> and awesome to be able to manage things that way
[16:10:15 CST(-0600)] <athena> chris is a uniconer helping out with umobile dev
[16:10:23 CST(-0600)] <athena> he added some standard icons for phone/map link buttons
[16:10:24 CST(-0600)] <EricDalquist> athena: when you do the pull can you stick the jira-id in the commit message?
[16:10:28 CST(-0600)] <athena> yep!
[16:10:34 CST(-0600)] <athena> or if not i'll ask you how to do it
[16:11:08 CST(-0600)] <EricDalquist> you get a "commit message box" in the github ui
[16:11:13 CST(-0600)] <athena> ah nice
[16:11:17 CST(-0600)] <athena> git is so fabulous
[16:12:36 CST(-0600)] <EricDalquist> that it is
[16:12:45 CST(-0600)] <EricDalquist> github really helps
[16:22:59 CST(-0600)] <drewwills> I'm having a bit of trouble in 4.x trying to prevent a portlet from appearing... it's one that folks have added to personal tabs, but it doesn't work in 4.x currently... i tried removing all groups from allowed subscribers, but that didn't work for admins (due to new super-user status)... but I also tried expiring it, and i'm not sure why that didn't work either
[16:23:24 CST(-0600)] <EricDalquist> admins see everything
[16:23:40 CST(-0600)] <EricDalquist> the only way to have them not see it is to remove it from the layout
[16:23:43 CST(-0600)] <EricDalquist> or delete it
[16:24:13 CST(-0600)] <drewwills> yeah that explains what happened when i removed the groups... but I would not guess that expired portlet mechanics are permission-based
[16:24:55 CST(-0600)] <EricDalquist> yup
[16:25:00 CST(-0600)] <EricDalquist> those are simply permissions
[16:25:00 CST(-0600)] <drewwills> it doesn't seem like a permission-check situation... it just seems like you want to turn it off
[16:25:09 CST(-0600)] <EricDalquist> you can permission who can see what states
[16:28:00 CST(-0600)] <athena> admins probably have permission to see expired content
[16:28:18 CST(-0600)] <athena> and it's probably only permissions-based code that includes things in the layout
[16:28:39 CST(-0600)] <drewwills> admins essentially have: hasPermission()
[16:28:41 CST(-0600)] <athena> is there a reason not to take it out of the layout?
[16:28:45 CST(-0600)] <athena> yes, they do
[16:29:26 CST(-0600)] <drewwills> it doesn't work... it's the popular portlets portlet, and it's waiting on events in uP4
[16:29:46 CST(-0600)] <EricDalquist> why not just delete the .portlet.xml file for now
[16:29:54 CST(-0600)] <EricDalquist> and we can rename it in git until it is fixed
[16:30:08 CST(-0600)] <EricDalquist> and delete the portlet via portlet manager
[16:30:09 CST(-0600)] <athena> or remove the portlet from the layout?
[16:30:14 CST(-0600)] <EricDalquist> deleting portlets should actually work in 4
[16:30:15 CST(-0600)] <EricDalquist> that too
[16:31:26 CST(-0600)] <drewwills> i'd delete the portlet-def.xml file, but i'll have failed layout imports when I go to migrate them... or at least I'll have to set up some mid-migration-munging of the layouts
[16:32:48 CST(-0600)] <drewwills> i can do the migration then delete in the UI... or I can create a HelpfulMessage portlet and give it the same fname
[16:34:57 CST(-0600)] <EricDalquist> how many fragment layouts is this portlet in?
[17:52:12 CST(-0600)] <drewwills> this portlet is only in personal, non-fragment layouts afaik
[17:53:39 CST(-0600)] <drewwills> if you're still there... has anyone brought up how Tomcat won't stop? (seems to be a lingering, non-daemon thread somewhere) And is anyone working on a fix?
[17:53:57 CST(-0600)] <EricDalquist> in master?
[17:54:03 CST(-0600)] <EricDalquist> or in a release
[17:54:09 CST(-0600)] <EricDalquist> I know about the issue in master
[17:54:16 CST(-0600)] <EricDalquist> and i'm working on a resolution right now
[17:56:06 CST(-0600)] <drewwills> yeah the issue in master
[17:56:18 CST(-0600)] <drewwills> awesome, thanks
[17:56:27 CST(-0600)] <EricDalquist> yup, I'm drawing wonderfully close to getting the event aggregation work done
[17:56:34 CST(-0600)] <EricDalquist> and when I can merge that in the issue should get fixed
[17:56:38 CST(-0600)] <drewwills> oh that's terrific too
[17:56:39 CST(-0600)] <EricDalquist> along with a bunch of random errors you see
[17:56:53 CST(-0600)] <EricDalquist> note that this only includes one actual aggregator
[17:57:00 CST(-0600)] <EricDalquist> but the framework will be there
[17:57:19 CST(-0600)] <drewwills> does "one actual aggregator" == oracle only?
[17:57:47 CST(-0600)] <EricDalquist> no like the only thing being aggregated will be total & unique login counts
[17:57:49 CST(-0600)] <EricDalquist> it is all jpa
[17:58:16 CST(-0600)] <EricDalquist> what will be needed is either my time when we get to that point in our upgrade process or someone elses before then to write more aggregator impls
[17:58:26 CST(-0600)] <EricDalquist> to do things like aggregate tab render times, portlet render times, etc
[17:58:43 CST(-0600)] <EricDalquist> you'll need to write one to track data for your popular portlets portlet
[17:58:57 CST(-0600)] <drewwills> yep, but that's fine
[17:59:05 CST(-0600)] <drewwills> i can probably handle that
[17:59:23 CST(-0600)] <drewwills> i need to jet out... see you next week