[10:01:45 CDT(-0500)] <Arvids> EricDalquist, you're using Eclipse 3.7, aren't you?
[10:01:51 CDT(-0500)] <EricDalquist> yes
[10:01:54 CDT(-0500)] <EricDalquist> I'm on 3.7.1
[10:02:19 CDT(-0500)] <Arvids> Don't you get errors like "Referenced file contains errors (jar:file:/home/arvids/progs/eclipse-3.7-jee/plugins/org.eclipse.wst.standard.schemas_1.0.401.v201108151912.jar!/dtds/loose.dtd)."
[10:02:37 CDT(-0500)] <Arvids> it seems that Eclipse is unable to validate DTD-specific comments
[10:03:17 CDT(-0500)] <Arvids> i'm just wondering - am i the only one facing this problem?
[10:03:23 CDT(-0500)] <EricDalquist> after your latest changes I don't see any errors
[10:03:32 CDT(-0500)] <EricDalquist> just 3893 warnings 
[10:05:13 CDT(-0500)] <Arvids> strange that i'm facing that problem if our IDE setup is about the same
[10:05:29 CDT(-0500)] <EricDalquist> hrm
[10:05:39 CDT(-0500)] <EricDalquist> I think I may have actually just turned off DTD validation
[10:05:45 CDT(-0500)] <EricDalquist> since none of uPortal'
[10:05:49 CDT(-0500)] <EricDalquist> 's DTD are published
[10:06:02 CDT(-0500)] <EricDalquist> and as we touch things we're switching them to XSD
[10:06:21 CDT(-0500)] <Arvids> ahh, that could explain the situation 
[10:44:07 CDT(-0500)] <athena> morning EricDalquist
[10:44:15 CDT(-0500)] <EricDalquist> morning athena
[10:44:17 CDT(-0500)] <athena> i'm trying to play with seeing how switching the doctype to HTML5 would affect us
[10:44:28 CDT(-0500)] <athena> the doctype for HTML5 is sort of weird - no public or system id
[10:44:46 CDT(-0500)] <athena> seems like if there's no public or system id specified, our current config leaves it out entirely
[10:44:55 CDT(-0500)] <athena> any idea where i'd look to address that?
[10:45:10 CDT(-0500)] <EricDalquist> I think the doctype is specified in the theme xsl
[10:45:40 CDT(-0500)] <EricDalquist> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resources/layout/theme/universality/universality.xsl
[10:45:46 CDT(-0500)] <EricDalquist> <xsl:output method="xml" indent="yes" media-type="text/html" doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN" doctype-system="http://www.w3.org/TR/html4/loose.dtd"/>Â Â
[10:45:50 CDT(-0500)] <athena> yeah
[10:46:01 CDT(-0500)] <EricDalquist> so what does the html5 doctype look like?
[10:46:06 CDT(-0500)] <athena> if you remove both the doctype-public and doctype-system attributes, the whole doctype gets removed
[10:46:11 CDT(-0500)] <athena> <!DOCTYPE html>
[10:46:29 CDT(-0500)] <EricDalquist> what happens if you leave them there but empty
[10:46:42 CDT(-0500)] <athena> that didn't seem to work either, though i'll try it again
[10:46:58 CDT(-0500)] <athena> i see some comments in StaxEventLexicalContentHandler about removing the doctype if no system identifier is specified
[10:47:06 CDT(-0500)] <athena> but i couldn't find anything that actually calls that code
[10:48:15 CDT(-0500)] <msk5804> Im having problems building my uportal instance. When I run initportal I get this error: Invalid bean definition with name 'PortalDb' defined in class path resource [properties/contexts/datasourceContext.xml]: Could not resolve placeholder 'environment.build.hibernate.connection.driver_class'
[10:48:45 CDT(-0500)] <msk5804> but I set it correctly in my local.properties in filters
[10:48:56 CDT(-0500)] <msk5804> any ideas?
[10:49:00 CDT(-0500)] <athena> is this uportal 4?
[10:49:04 CDT(-0500)] <msk5804> yeah
[10:49:20 CDT(-0500)] <athena> did you run a clean after setting it?
[10:49:33 CDT(-0500)] <EricDalquist> athena you might just want to try tweaking StaxEventLexicalContentHandler to handle the doctype like you want it to
[10:49:41 CDT(-0500)] <EricDalquist> that class is only used by the rendering pipeline
[10:50:11 CDT(-0500)] <athena> from what i can tell there's no logic that omits anythign if there's no system id
[10:50:31 CDT(-0500)] <athena> was wondering if maybe whatever calls it makes a decision not to call it based on the system id
[10:50:36 CDT(-0500)] <EricDalquist> yeah
[10:50:38 CDT(-0500)] <athena> i couldn't find any references to that method in the codebase
[10:50:39 CDT(-0500)] <EricDalquist> so maybe we cheat
[10:50:50 CDT(-0500)] <EricDalquist> and put in some logic so that if the systemid is HTML5
[10:50:53 CDT(-0500)] <EricDalquist> it writes out what you want
[10:51:01 CDT(-0500)] <athena> makes sense, i can try that
[10:51:03 CDT(-0500)] <EricDalquist> and then just set the systemid to html5 in the xsl
[10:51:15 CDT(-0500)] <athena> was just a little mystified as to how this code is actually getting run, or if it is
[10:51:18 CDT(-0500)] <EricDalquist> its the stax serializer making that call/don't call decision
[10:51:23 CDT(-0500)] <athena> ah gotcha
[10:51:53 CDT(-0500)] <athena> or maybe to make it more extensible we could make the system id be EMPTY
[10:52:02 CDT(-0500)] <athena> in case this crops up with something other than HTML at some point
[10:52:37 CDT(-0500)] <EricDalquist> yeah, I think we have a few options on how to fix it
[10:52:39 CDT(-0500)] <msk5804> yeah im using a groovy script that sets an overlay. In that script is runs a clean
[10:53:08 CDT(-0500)] <athena> hmm.
[10:53:34 CDT(-0500)] <athena> seems quite possible that the overlay isn't playing nicely with the filtering strategy that's in up4
[10:54:00 CDT(-0500)] <athena> this seemed like a reasonably helpful discussion of HTML5 and outdated elements: http://html5doctor.com/absent-elements-and-validation/
[10:54:11 CDT(-0500)] <athena> i think we're probably ok updating our doctype
[10:54:35 CDT(-0500)] <athena> we don't really use much of that outdated stuff, and if someone did, i think what would happen is that the page wouldn't validate, not that they'd get a stack trace
[10:55:03 CDT(-0500)] <athena> imagine we probably already have content that doesn't validate in our current doctype
[10:55:08 CDT(-0500)] <EricDalquist> sounds good
[10:55:22 CDT(-0500)] <EricDalquist> I was thinking more about my issues and I think it was from trying to use true XHTML
[10:55:42 CDT(-0500)] <EricDalquist> with which the browser fails to parse the page if there is any invalid XML
[10:55:54 CDT(-0500)] <EricDalquist> but if we can get away with just HTML5 instead of XHTML5 we should be good
[10:57:27 CDT(-0500)] <athena> yeah
[10:57:31 CDT(-0500)] <athena> i think that sounds pretty reasonable
[10:58:48 CDT(-0500)] <EricDalquist> msk5804: I'm at a bit of a loss on your issue since the default build is using that filtering correctly
[10:59:14 CDT(-0500)] <EricDalquist> just out of curiosity what versions of ant & maven are you using?
[11:16:48 CDT(-0500)] <msk5804> i am using maven 3.0.3 and ant 1.8.2
[11:49:57 CDT(-0500)] <athena> got the doctype updated to HTML5
[11:50:09 CDT(-0500)] <athena> looks like we have a few errors in the page that aren't really related to that version of HTML, but nothing too major
[11:50:14 CDT(-0500)] <athena> we're actually in pretty decent shape
[12:31:28 CDT(-0500)] <EricDalquist> athena what does the up4 mobile ui do if you have A LOT of portlets?
[12:31:35 CDT(-0500)] <EricDalquist> like 30-40
[12:31:40 CDT(-0500)] <EricDalquist> is there any grouping concept?
[12:31:58 CDT(-0500)] <athena> no
[12:32:00 CDT(-0500)] <athena> scrolls
[12:32:04 CDT(-0500)] <EricDalquist> ok
[12:32:13 CDT(-0500)] <athena> though you could of course change the theme
[12:32:18 CDT(-0500)] <EricDalquist> yup
[12:32:34 CDT(-0500)] <EricDalquist> is it just the theme or does the structure xsl flatten it all?
[12:33:27 CDT(-0500)] <athena> hmm, i actually forget offhand
[12:34:04 CDT(-0500)] <EricDalquist> no problem
[12:34:08 CDT(-0500)] <athena> might flatten it out, but it'd be easy enought o change
[12:35:28 CDT(-0500)] <EricDalquist> yeah
[13:11:50 CDT(-0500)] <athena> so do we have a set git workflow for committers yet or is that still under debate?
[13:12:44 CDT(-0500)] <EricDalquist> we don't I need to post a proposal
[13:12:52 CDT(-0500)] <athena> ok
[13:12:54 CDT(-0500)] <EricDalquist> my though is:
[13:13:06 CDT(-0500)] <athena> i have some changes queuing up, but want to make sure i wait to commit them until i know what the plan is
[13:13:10 CDT(-0500)] <EricDalquist> for any work that isn't just one little commit you should create a branch
[13:13:13 CDT(-0500)] <EricDalquist> for the specific feature
[13:13:17 CDT(-0500)] <EricDalquist> do the work there
[13:13:33 CDT(-0500)] <EricDalquist> then merge the branch back to master (and/or *-patches) when it is done
[13:14:00 CDT(-0500)] <athena> i guess i worry a bit that we won't wind up working together as closely
[13:14:01 CDT(-0500)] <EricDalquist> the you can easily collaborate on the branch if needed since others will be able to see it
[13:14:19 CDT(-0500)] <EricDalquist> well part of that rule is as much as possible branches should be short lived
[13:14:19 CDT(-0500)] <athena> how many problems have we had in the past from having new features developed on trunk?
[13:14:25 CDT(-0500)] <EricDalquist> like a week or two at most
[13:14:32 CDT(-0500)] <EricDalquist> very few
[13:14:38 CDT(-0500)] <athena> in practice though, particularly with coop dev and distractions, they're likely to be around a long time
[13:14:42 CDT(-0500)] <EricDalquist> but the goal here would be that your branch may not be functional
[13:14:51 CDT(-0500)] <EricDalquist> and that trunk/master is always functional
[13:15:06 CDT(-0500)] <athena> i know most of the new features i wind up working on take a really long time to complete
[13:15:10 CDT(-0500)] <EricDalquist> so if you're working on something but want some feedback, commiting broken code to a branch is fine
[13:15:29 CDT(-0500)] <EricDalquist> yeah, that's true, though that is still nice to have a branch for them
[13:15:40 CDT(-0500)] <EricDalquist> since we can see what is being developed and how actively, etc
[13:15:54 CDT(-0500)] <EricDalquist> instead of trying to manage lots of local new features until they are ready to commit
[13:16:30 CDT(-0500)] <athena> well, i think there's a distinction between the stuff we used to commit to trunk and the stuff that used to sit around on our boxes
[13:16:45 CDT(-0500)] <athena> like in the past, we committed a lot of half-done code and features, as long as it didn't break anything existing
[13:17:09 CDT(-0500)] <athena> i don't personally see that as a problem, and i think it's been helpful to have stuff in the trunk grow as publicly as possible, as long as it doens't break the build
[13:17:29 CDT(-0500)] <athena> but it seems like branches and git are great for the kind of thing that used to sit around on our personal machines because it wasn't done enough to commit to trunk
[13:17:40 CDT(-0500)] <EricDalquist> yeah
[13:17:51 CDT(-0500)] <EricDalquist> for that case you can branch and merge multiple times
[13:18:16 CDT(-0500)] <EricDalquist> branch for new feature X, do some dev till part done but stable, merge branch into master, repeat last 2 steps until complete
[13:18:29 CDT(-0500)] <EricDalquist> that still lets you have a place to do active development publicly
[13:18:41 CDT(-0500)] <EricDalquist> while pushing things into trunk
[13:18:53 CDT(-0500)] <athena> that sounds fair
[13:19:13 CDT(-0500)] <EricDalquist> also catching your branch up to master is easy
[13:19:13 CDT(-0500)] <athena> i guess i'm just hoping we keep pushing most stuff pretty actively into the trunk unless it's really in a state of flux
[13:19:20 CDT(-0500)] <EricDalquist> "git merge master"
[13:19:29 CDT(-0500)] <EricDalquist> I agree
[13:19:37 CDT(-0500)] <athena> we don't have a lot of resources, and a lot of the resources we do have are busy enough that they're unlikely to go play with other branches
[13:19:50 CDT(-0500)] <EricDalquist> I don't think the goal is for others to play with random dev branches
[13:20:06 CDT(-0500)] <EricDalquist> just to have them there as an easy way to collborate if needed
[13:20:21 CDT(-0500)] <EricDalquist> it also makes it even easier to track what commits are related to what feature
[13:20:55 CDT(-0500)] <athena> sounds good
[13:21:09 CDT(-0500)] <athena> so what's the plan for small changes?
[13:21:27 CDT(-0500)] <EricDalquist> I'd say just commit on master directly
[13:21:36 CDT(-0500)] <athena> ok
[13:21:56 CDT(-0500)] <EricDalquist> like when I'm updating the pom files for git, or gitignore files, no need for branching for that sort of stuff
[13:21:58 CDT(-0500)] <athena> so to project master instead of my fork?
[13:22:09 CDT(-0500)] <EricDalquist> that's up to you
[13:22:31 CDT(-0500)] <EricDalquist> the one big advantage of personal forks is that changes can be reviwed via pull request
[13:22:36 CDT(-0500)] <athena> yeah
[13:22:41 CDT(-0500)] <EricDalquist> but I'm not sure there is much value there for core committers
[13:22:55 CDT(-0500)] <EricDalquist> if we had more resources it could be a valuable rule to say that everyone works on a personal fork
[13:23:04 CDT(-0500)] <EricDalquist> and no one is allowed to accept their own pull request
[13:23:09 CDT(-0500)] <EricDalquist> then we have more code review
[13:23:16 CDT(-0500)] <EricDalquist> I don't think we have the resources for that though
[13:23:18 CDT(-0500)] <athena> right
[13:23:27 CDT(-0500)] <EricDalquist> so for those with commit access ... its up to them
[13:23:29 CDT(-0500)] <athena> i'd love to do that, but we probably just cant' really get work done then
[13:23:39 CDT(-0500)] <athena> i guess my thought is for changes like i have now, i should just commit them
[13:23:50 CDT(-0500)] <athena> simple stuff like incrementing the fluid version, adding alt attributes, etc.
[13:23:54 CDT(-0500)] <EricDalquist> yup
[13:24:04 CDT(-0500)] <EricDalquist> I'd say just commit those