[14:26:13 CDT(-0500)] <EricDalquist> so athena
[14:26:18 CDT(-0500)] <EricDalquist> that db/code version number stuff
[14:26:23 CDT(-0500)] <athena> ah yes
[14:26:29 CDT(-0500)] <EricDalquist> I think we aggreed that I just need to manually maintain that?
[14:26:40 CDT(-0500)] <athena> managed to get it working by manually setting the version string in umobile to 4.0.6-SNAPSHOT
[14:26:45 CDT(-0500)] <athena> so yes, probably
[14:27:15 CDT(-0500)] <EricDalquist> ok
[15:44:45 CDT(-0500)] <rlewis> Help! I am having trouble getting uportal to work with MySQL. Are others able to use MySQL?
[15:45:34 CDT(-0500)] <EricDalquist> have you followed all of the steps here: https://wiki.jasig.org/display/UPM40/MySQL
[15:51:41 CDT(-0500)] <rlewis> EricDalquist: I will go thru the steps again just to make sure.
[17:27:55 CDT(-0500)] <dmccallum54> what's the typical advice for deploying JDBC drivers in uP+Tomcat 6.x so they can be used by 3rd party portlets?
[17:28:02 CDT(-0500)] <dmccallum54> shared/lib gets blown away...
[17:28:26 CDT(-0500)] <athena> typically we package the driver with the portlet itself
[17:28:29 CDT(-0500)] <dmccallum54> k
[17:28:40 CDT(-0500)] <dmccallum54> thx
[17:29:04 CDT(-0500)] <athena> but if you need to have them in shared/lib (like for JNDI configuration or something)
[17:29:14 CDT(-0500)] <athena> you could add it as a dependency to uportal-ear/pom.xml
[17:29:32 CDT(-0500)] <athena> i believe that controls what gets deployed to shared
[17:30:06 CDT(-0500)] <athena> typically though the overlay process removes hsql.jar from the in-maven portlet, then adds in whatever one is specified in the main uportal pom
[17:30:41 CDT(-0500)] <dmccallum54> dont really have any urgent need either for a shared conn pool or for JNDI
[17:31:21 CDT(-0500)] <dmccallum54> but for sanifty's sake it seems like a good idea for the portlet to be using the same sqlserver driver at the portal
[17:31:38 CDT(-0500)] <dmccallum54> even that's not actually a terribly urgent requirement, though
[17:31:48 CDT(-0500)] <athena> certainly just easier to configure and manage
[17:31:59 CDT(-0500)] <dmccallum54> so just bundling a jar with the portlet is fine
[17:32:13 CDT(-0500)] <dmccallum54> but i wasn't quite clear from reading the docs on what the predominate approach actually is
[17:32:19 CDT(-0500)] <athena> and if you use the normal mechanism, that means if someone checks out the project locally and just changes the main jdbc.* properties, those will get carried over to the portlet as expected
[17:32:32 CDT(-0500)] <athena> hmm, we probably need better documentation on that
[17:32:54 CDT(-0500)] <athena> this is the most we really have right now: https://wiki.jasig.org/display/UPM40/Working+with+Portlet+Overlays
[17:32:58 CDT(-0500)] <athena> at least a bit of an example
[17:37:48 CDT(-0500)] <dmccallum54> under that approach does the portlet binary need to be pre-processed in any way? i.e. what is the relationship between ye olde deployPortletApp ant target and this overlay mechanism?
[17:40:40 CDT(-0500)] <athena> both deployPortletApp and this overlay expect an unprocessed portlet war
[17:40:50 CDT(-0500)] <athena> where processing == plutofication
[17:41:05 CDT(-0500)] <athena> so you really shouldn't ever be pre-plutofying something, since that's portal platform and platform version specific
[17:41:10 CDT(-0500)] <dmccallum54> ah. i see the pluto plugin there at the bottom...
[17:41:22 CDT(-0500)] <athena> though there is a maven plugin available for local development shortcut cheating only
[17:41:37 CDT(-0500)] <athena> which you can use to run mvn install, plutofy, and deploy to tomcat all in one command
[17:41:47 CDT(-0500)] <athena> and i do use that sometimes for local dev, due to the laziness and such
[17:41:53 CDT(-0500)] <athena> but that shouldn't go into like production repos, etc.
[17:44:50 CDT(-0500)] <dmccallum54> so that was actually going to be my next question....
[17:45:54 CDT(-0500)] <athena> 
[17:46:09 CDT(-0500)] <athena> let me find the docs for it
[17:46:10 CDT(-0500)] <dmccallum54> what do you usually do to approximate rapid portlet dev processes in a local env, i.e. something resembling edit-build-hot-redeploy-reload-page? is it that maven-secret-sauce plugin, then?
[17:46:22 CDT(-0500)] <athena> it's still really hacky, so i wouldn't recommend sharing with someone who wasn't a dev and really familiar with maven
[17:46:35 CDT(-0500)] <athena> but basically set up a profile w/ this plugin
[17:46:43 CDT(-0500)] <athena> https://wiki.jasig.org/display/UPC/uPortal+Maven+Plugin
[17:46:54 CDT(-0500)] <athena> and then you can use the command on this page to rebuild and redeploy
[17:47:01 CDT(-0500)] <athena> no tomcat restart necessary
[17:47:05 CDT(-0500)] <athena> so that's what i'd do for back-end dev
[17:47:18 CDT(-0500)] <athena> for front-end, i'd just copy over the JSP or javascript file or whatever manually
[17:47:35 CDT(-0500)] <athena> w/ the important caveat that changes to javascript may require you to toggle aggregation off, if you're using all the resource server stuff
[17:49:08 CDT(-0500)] <athena> if you're not using the resource server stuff, you should, and docs are at https://wiki.jasig.org/display/UPC/Using+the+Resource+Server
[17:49:15 CDT(-0500)] <dmccallum54> thx much. been doing the manual UI file copying already
[17:49:28 CDT(-0500)] <athena>
[17:49:35 CDT(-0500)] <dmccallum54> but the redeploy of java changes was starting to give me the howling fantods