...
[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
[17:50:08 CDT(-0500)] <athena> lol
[17:50:13 CDT(-0500)] <athena> well that's bad
[17:50:30 CDT(-0500)] <dmccallum54> oh you have no idea
[17:50:53 CDT(-0500)] <athena> lol