[09:02:44 CDT(-0500)] <Arvids> EricDalquist: I updated published schemas at https://source.jasig.org/schemas/uportal/ (UP-3192)
[09:03:21 CDT(-0500)] <Arvids> That cleared like 150 error messages in Eclipse
[09:04:08 CDT(-0500)] <EricDalquist> ah thanks, we usually only push changes there on a release but that shouldn't be a problem for now
[09:04:56 CDT(-0500)] <EricDalquist> I need to finish updating the "cutting a uP release docs" but one step will be doing a merge from https://source.jasig.org/uPortal/trunk/uportal-war/src/main/resources/xsd/ to https://source.jasig.org/schemas/uportal/
[09:04:58 CDT(-0500)] <Arvids> yeah, I thought whether should i do it or not, but figured out - since it's a bug fix, it won't hurt to publish the changes ASAP
[09:05:05 CDT(-0500)] <EricDalquist> yeah
[09:05:11 CDT(-0500)] <EricDalquist> did you do it as a merge or a copy?
[09:06:01 CDT(-0500)] <Arvids> applied diff in my workspace and commited changes
[09:06:07 CDT(-0500)] <EricDalquist> ok, sounds good
[09:06:36 CDT(-0500)] <EricDalquist> also saw the commit for the new portlet
[09:06:37 CDT(-0500)] <Arvids> and there are some more nasty XML error messages in Eclipse
[09:06:47 CDT(-0500)] <EricDalquist> I'll take a look later today or tomorrow
[09:06:51 CDT(-0500)] <EricDalquist> on which files?
[09:07:23 CDT(-0500)] <Arvids> one is flowsContext.xml
[09:08:11 CDT(-0500)] <Arvids> not sure why, but using spring-webflow-config-2.0.xsd reports errors, while spring-webflow-config-2.3.xsd does not
[09:08:42 CDT(-0500)] <Arvids> one more problematic file is cacheContext.xml
[09:08:42 CDT(-0500)] <EricDalquist> weird
[09:08:53 CDT(-0500)] <EricDalquist> well we're using webflow 2.3 so using the more recent XSD would be good
[09:09:05 CDT(-0500)] <Arvids> http://ehcache-spring-annotations.googlecode.com/svn/schema/ehcache-spring/ehcache-spring-1.2.xsd
[09:09:10 CDT(-0500)] <Arvids> this one is not available anymore
[09:09:23 CDT(-0500)] <Arvids> hence Eclipse complains at validation
[09:09:35 CDT(-0500)] <EricDalquist> oh that's my fault
[09:09:39 CDT(-0500)] <Arvids> found the same file at http://ehcache-spring-annotations.googlecode.com/svn/trunk/core/src/main/resources/com/googlecode/ehcache/annotations/ehcache-spring-1.2.xsd
[09:09:40 CDT(-0500)] <EricDalquist> I'll go publish the XSD later today
[09:09:45 CDT(-0500)] <Arvids> ahh.. ok
[09:09:47 CDT(-0500)] <EricDalquist> now that the 1.2 release is out
[09:09:58 CDT(-0500)] <EricDalquist> I work on that project with a co-worker
[09:11:24 CDT(-0500)] <EricDalquist> ok, I have to run for about 90 minutes
[09:11:58 CDT(-0500)] <Arvids> ok, one last fix: http://pastebin.com/z6dLwsHi
[09:12:39 CDT(-0500)] <EricDalquist> oh good catch
[09:13:13 CDT(-0500)] <Arvids> ok, heading home now 
[09:13:42 CDT(-0500)] <EricDalquist> have a good evening
[09:13:46 CDT(-0500)] <EricDalquist> thanks for the help 
[12:22:40 CDT(-0500)] <drewwills> my IMAP email is behaving poorly... did anyone see that Email Preview message I sent a short time ago?
[12:24:32 CDT(-0500)] <EricDalquist> yes
[12:24:42 CDT(-0500)] <b-rock_> Hi EricDalquist. I just submitted a patch https://issues.jasig.org/browse/UP-3214 that addresses circular dependencies that can sometimes be found in grouper. After reading your post the the dev list a few min ago, I put this as affecting 4.0.1 but it probably can apply to the 3.2.5 patches.
[12:25:08 CDT(-0500)] <EricDalquist> thanks good to know
[12:25:14 CDT(-0500)] <b-rock_> np
[12:42:21 CDT(-0500)] <b-rock_> Hi EricDalquist. I've got another question regarding exporting our 3.2.5-patches prod data. The fragment owners layouts were exported to the "layouts" folder and not the "fragment_layout" folder. I imported them into the 4.0.1 build, but I see that the fragment manager portlet does not list any of the fragments and the tabs don't show after logging in. Are these related?
[12:42:32 CDT(-0500)] <b-rock_> apologies for the long windedness
[12:42:55 CDT(-0500)] <EricDalquist> are all of these fragment owners correctly defined in dlm.xml in both the 3.2 code you used for exporting and the 4.0.1 instance?
[12:43:13 CDT(-0500)] <EricDalquist> the portal determines if a user is a fragment owner based on that file
[12:43:19 CDT(-0500)] <b-rock_> I think I only have them listed a the owner of the fragment but nowhere else
[12:43:30 CDT(-0500)] <EricDalquist> what do you mean?
[12:44:30 CDT(-0500)] <b-rock_> in dlm.xml I have them listed as ownerID="uocWelcome-lo" for example.
[12:44:47 CDT(-0500)] <b-rock_> am I missing another spot where they need to be listed?
[12:44:56 CDT(-0500)] <EricDalquist> that should be enough I believe
[12:45:34 CDT(-0500)] <b-rock_> yeah the fragment owners that made it into the fragment_layout folder don't have any fragments listed in the dlm.xml
[12:45:58 CDT(-0500)] <EricDalquist> are you using the dlm.xml file or are you using the DB backed fragment configuration code?
[12:46:08 CDT(-0500)] <EricDalquist> I'm not as familiar with that
[12:46:09 CDT(-0500)] <b-rock_> not sure. where can I check.
[12:46:18 CDT(-0500)] <EricDalquist> honestly I can't remember
[12:46:21 CDT(-0500)] <EricDalquist> drewwills: can you help here?
[12:46:44 CDT(-0500)] <drewwills> yeah the setting for using db-back fragments was oved... possibly to portal.properties
[12:46:48 CDT(-0500)] <b-rock_> I know we do have the dlm.xml file deployed with uPortal
[12:47:13 CDT(-0500)] <drewwills> it seems all properties were moved out of dlm.xml
[12:48:00 CDT(-0500)] <b-rock_> I didn't override this in 4.0.1 and it is set to org.jasig.portal.layout.dlm.defaultLayoutOwner=fragmentTemplate in the portal.properties
[12:48:10 CDT(-0500)] <EricDalquist> I think it is actually in the spring config in 4.0
[12:48:14 CDT(-0500)] <EricDalquist> let me look
[12:48:36 CDT(-0500)] <EricDalquist> yes in 4.0 layoutContext.xml defines the dlmConfigurationLoader bean
[12:49:08 CDT(-0500)] <EricDalquist> same thing in 3.2: https://source.jasig.org/uPortal/branches/rel-3-2-patches/uportal-impl/src/main/resources/properties/contexts/layoutContext.xml
[12:49:22 CDT(-0500)] <EricDalquist> so check your layoutContext.xml file in your 3.2 deployment
[12:49:48 CDT(-0500)] <drewwills> did you get .fragment-definition files on export?
[12:50:13 CDT(-0500)] <b-rock_> checking...
[12:51:13 CDT(-0500)] <b-rock_> I do see the structure/DLM_Tabs_and_columns.structure file but I didn't import that into the 4.0.1 build
[12:52:09 CDT(-0500)] <b-rock_> there is also the theme/DLM_XHTML.theme
[12:52:16 CDT(-0500)] <EricDalquist> that isn't what he's looking for, the first question is did your 3.2 export work correctly an export .fragment-definition files
[12:52:55 CDT(-0500)] <EricDalquist> if not something is up there and the uPortal code used to do the export doesn't know how to correctly identify which users are fragment owners
[12:52:56 CDT(-0500)] <b-rock_> I don't see any files with that extension.
[12:53:13 CDT(-0500)] <drewwills> the presence of those files would be a strong indicator that you're using the DB-backed DLM
[12:53:39 CDT(-0500)] <b-rock_> yeah. I didn't know we could use the db-backend for that so we probably arent.
[12:53:44 CDT(-0500)] <EricDalquist> so your 3.2 export, you're using the EXACT same code and config that runs the uPortal environment you're exporting from?
[12:53:58 CDT(-0500)] <drewwills> so to recap: you have some fragments listed in dlm.xml, but no corresponding fragment-layout files? or was it vice versa?
[12:53:58 CDT(-0500)] <b-rock_> yes.
[12:54:54 CDT(-0500)] <b-rock_> yes thats it. we have files in "fragment_layout" for users who are not in the dlm.xml file and files in "layout" for users who are listed in dlm.xml
[12:55:55 CDT(-0500)] <EricDalquist> are the files in fragment_layout in your export suffixed with .fragment-layout?
[12:56:54 CDT(-0500)] <b-rock_> sorry, yes they are but they are the users who are not in the dlm.xml file
[12:57:40 CDT(-0500)] <EricDalquist> are they just random users? Are they uPortal default users?
[12:57:50 CDT(-0500)] <b-rock_> they are the portal default users
[12:58:10 CDT(-0500)] <drewwills> that's surprising... is it a perfect switch? meaning, are all the users in layout/ ones that appear in dlm.xml, and are all other users in fragment_layout/?
[12:58:13 CDT(-0500)] <b-rock_> so they probably got in there from in earlier install but aren't uset
[12:58:39 CDT(-0500)] <EricDalquist> right but they should only be exported as fragment_layouts if they are listed in dlm.xml
[12:58:54 CDT(-0500)] <b-rock_> I think just the guest-lo owner for the Guests fragment is in the fragment_layouts folder
[12:58:56 CDT(-0500)] <EricDalquist> are you sure the uPortal code you're using to do the export has a correctly configured dlm.xml?
[12:59:40 CDT(-0500)] <EricDalquist> so there is only one fragment_layout file and it is guest-lo.fragment-layout?
[12:59:42 CDT(-0500)] <b-rock_> I assume it works sime we are able to get to the fragments on the front end and see the username
[13:00:16 CDT(-0500)] <b-rock_> there are also fragment_layout files for admin-lo, welcome-lo, developer-lo
[13:00:43 CDT(-0500)] <EricDalquist> ok
[13:00:51 CDT(-0500)] <EricDalquist> so the only possible way for those to appear in an export
[13:01:15 CDT(-0500)] <b-rock_> looks like the default users that ship with uportal
[13:01:21 CDT(-0500)] <EricDalquist> is for those users to be listed in the dlm.xml file in the uPortal instance wher you run "ant crn-export"
[13:01:50 CDT(-0500)] <b-rock_> gonna look there now...
[13:03:34 CDT(-0500)] <b-rock_> thats it.
[13:03:53 CDT(-0500)] <b-rock_> so I need to re-run the export with the "real" dlm.xml
[13:04:00 CDT(-0500)] <EricDalquist> yes
[13:04:14 CDT(-0500)] <b-rock_> apologies for the confusion.
[13:04:21 CDT(-0500)] <EricDalquist> you have to run the export with the EXACT same configuration you're using for the uPortal instance that you are running
[13:04:23 CDT(-0500)] <EricDalquist> so not just dlm
[13:04:30 CDT(-0500)] <EricDalquist> but group store, pags, user attributes
[13:04:43 CDT(-0500)] <EricDalquist> export touches pretty much everything in the portal
[13:05:01 CDT(-0500)] <EricDalquist> and if it can't correctly resolve information about users, layouts, portlets, etc you will get bad output
[13:05:59 CDT(-0500)] <b-rock_> ahh. thanks for the tip. I'm thinknig now that I just overworte the db connections for the 3.2.5 patches branch with the default configs. I'll make the mods and re-run the export.
[13:25:06 CDT(-0500)] <Arvids> Any comments about Translator portlet implementation?
[13:26:14 CDT(-0500)] <EricDalquist> haven't had any time to look at it yet
[13:26:19 CDT(-0500)] <EricDalquist> probably won't for a few days
[13:30:12 CDT(-0500)] <Arvids> ok, I'd be glad if someone from UI folks would review javascript code there
[13:30:54 CDT(-0500)] <Arvids> Fluid requires a lot of learning
[13:31:42 CDT(-0500)] <athena> it does
[13:31:54 CDT(-0500)] <athena> though luckily the fluid folks are also really friendly and helpful
[13:32:03 CDT(-0500)] <athena> they're over in #fluid-work, incidentally
[13:32:07 CDT(-0500)] <colinclark> We try our best
[13:33:55 CDT(-0500)] <Arvids> I believe that could help me next time
[13:35:07 CDT(-0500)] <colinclark> We're always happy to help if we can, Arvids
[13:35:22 CDT(-0500)] <colinclark> You can ping a few of us in here or lots of others in #fluid-work as athena mentioned.
[13:35:42 CDT(-0500)] <Arvids> athena, I assume you were the author or maven translator plugin, weren't you?
[13:35:46 CDT(-0500)] <athena> yes
[13:36:07 CDT(-0500)] <athena> needs some updating - a few of the last changes i made were eaten in a hard drive tragedy
[13:36:20 CDT(-0500)] <athena> also google seems inclined to stop offering that service
[13:36:43 CDT(-0500)] <EricDalquist> they still have a for-pay service
[13:36:45 CDT(-0500)] <athena> but my rework also included something that would report missing strings, which is useful regardless of whether we do auto-translation or not
[13:36:46 CDT(-0500)] <athena> yeah
[13:36:47 CDT(-0500)] <Arvids> yes, i encountered that yesterday
[13:36:52 CDT(-0500)] <EricDalquist> and I think jasig could pay for it
[13:36:57 CDT(-0500)] <EricDalquist> its REALLY cheap for our needs
[13:36:57 CDT(-0500)] <athena> seems reasonable to me
[13:37:01 CDT(-0500)] <EricDalquist> like a few dollars a year
[13:37:33 CDT(-0500)] <Arvids> yeah, when i ran it yesterday, it complained something like "too much requests received from your host"
[13:37:40 CDT(-0500)] <athena> yeah
[13:37:48 CDT(-0500)] <athena> it'll do that if you're running a whole lot of stuff
[13:37:50 CDT(-0500)] <Arvids> but it's very helpful for all those translations
[13:37:51 CDT(-0500)] <athena> complains less the next time
[13:37:54 CDT(-0500)] <athena> yeah
[13:37:57 CDT(-0500)] <athena> i'm sure the translations aren't great
[13:38:06 CDT(-0500)] <athena> but seems easier to fix the broken ones than do it all from scratch?
[13:39:08 CDT(-0500)] <Arvids> hmm... on the other hand - inserting keys with default (English) translation would help too...
[13:39:33 CDT(-0500)] <athena> well, the key name itself is now mostly the english message
[13:39:36 CDT(-0500)] <athena> so hopefully that'll help too
[13:39:57 CDT(-0500)] <athena> i'm told that w/ the eclipse resource bundle editor thing you can see all the translations for a string side by side, which also seems helpful
[13:40:17 CDT(-0500)] <Arvids> yes, i'm using it
[13:40:26 CDT(-0500)] <Arvids> but do adopters use it?
[13:40:33 CDT(-0500)] <athena> i've heard the french community uses it
[13:41:06 CDT(-0500)] <athena> you're really the first person with much internationalization expertise to be really involved in trunk dev though
[13:41:21 CDT(-0500)] <athena> sadly we've of course had a lot of language barriers that have made it harder for everyone to collaborate
[13:42:35 CDT(-0500)] <Arvids> Each large nation values its language a lot... it's not the case for such little nation as mine
[13:42:49 CDT(-0500)] <Arvids> I'm forced to know at least 3 languages here
[13:43:18 CDT(-0500)] <athena> yeah, you're much more educated than we are 
[13:44:07 CDT(-0500)] <Arvids> Heh... i could even do the basic translation for Russian language too
[13:45:35 CDT(-0500)] <Arvids> that reminds me that we have some folks on user list from russia... i'm wondering why aren't they asking for their locale provided out of the box
[13:48:10 CDT(-0500)] <athena> i'd be all for a russian translation
[13:48:21 CDT(-0500)] <athena> if you're up for QAing it all the better
[13:48:27 CDT(-0500)] <athena> think we might have foudn someone to do arabic too
[13:48:28 CDT(-0500)] <Arvids> I was just looking trhough uPortal manual and couldn't find a clue regarding i18n
[13:48:35 CDT(-0500)] <athena> errr yeah we should add some stuff
[13:48:43 CDT(-0500)] <athena> if you're interested in helping . . .
[13:49:35 CDT(-0500)] <Arvids> I'm not qualified translator, but i can try my best
[13:50:33 CDT(-0500)] <Arvids> I have some colleagues that I can ask for a help
[13:51:40 CDT(-0500)] <athena> awesome
[13:51:53 CDT(-0500)] <athena> and honestly, even just some basic fixing is way better than nothing
[13:53:26 CDT(-0500)] <Arvids> So... could you create the initial message files for Russian?
[13:53:41 CDT(-0500)] <athena> yeah, we can just use the translator plugin to do that
[13:53:52 CDT(-0500)] <Arvids> ... if google's translate service is working for you
[13:53:54 CDT(-0500)] <athena> i'll fix that thing up again to take a configurable list of languages
[13:53:57 CDT(-0500)] <athena> well . . . yes
[13:54:04 CDT(-0500)] <athena> if not i have some other ideas
[13:54:54 CDT(-0500)] <Arvids> sweet
[18:35:27 CDT(-0500)] <drewwills> arg... my eclipse wants to build uportal-war constantly... making the IDE unresponsive... are there any known setup tips for making eclipse behave reasonably here?