[11:51:28 CST(-0600)] <jwennmacher> EricDalquist: I wanted to get your input on something before I make the change.
[11:51:34 CST(-0600)] <EricDalquist> ok
[11:52:13 CST(-0600)] <jwennmacher> I've completed the changes for UP-3654 bundling CalendarPortlet, along with db schema creation and data import into uPortal.
[11:52:51 CST(-0600)] <EricDalquist> awesome
[11:52:54 CST(-0600)] <EricDalquist> this is using the new plugin?
[11:53:45 CST(-0600)] <jwennmacher> The new maven lifecycles are independent of the default lifecyles (I tried to require them to spawn a dependency upon package but it wouldn't work) to insure a change to a property file is reflected in the db-init or data-import execution. We can work around this by simply adding the lifecycle goal; e.g. mvn package db-init
[11:53:48 CST(-0600)] <jwennmacher> yes
[11:54:13 CST(-0600)] <EricDalquist> sounds good
[11:55:09 CST(-0600)] <jwennmacher> I ran some quick tests. If both db-init and data-import include package as a predecessor goal, the execution time is around 4 min 33 sec to do ant initdb. If I remove the package dependencies the execution time is around 62 seconds.
[11:55:26 CST(-0600)] <EricDalquist> yeah
[11:55:34 CST(-0600)] <EricDalquist> that is probably fine
[11:55:44 CST(-0600)] <jwennmacher> Though it is a nuisance, I think we should have dbinit invoke package (twice) just for proper dependency resolution.
[11:56:00 CST(-0600)] <EricDalquist> ok
[11:57:07 CST(-0600)] <jwennmacher> OK just wanted to verify you didn't see it as a nuisance. I don't like the idea of someone pulling down a quickstart version and waiting forever to do the build if there is marginal value in adding big chunks of time.
[11:57:30 CST(-0600)] <EricDalquist> yeah, at least for now I think it is ok
[11:57:38 CST(-0600)] <EricDalquist> this will likely take a few iterations to really get tuned
[11:57:49 CST(-0600)] <EricDalquist> I'll see if I can take a look soonish at the changes
[11:57:58 CST(-0600)] <EricDalquist> this week is mostly meetings sadly 
[11:58:27 CST(-0600)] <jwennmacher> OK. For now I'm also not forcing maven.test.skip=true. It doesn't really make much difference. There's only one portlet doing tests (and the file is missing so it's throwing an error 
).
[11:58:58 CST(-0600)] <EricDalquist> ok
[11:59:19 CST(-0600)] <jwennmacher> Cool. Sad to hear about the meetings
[11:59:43 CST(-0600)] <jwennmacher> one other question. I was just starting to look at this but you may know off the top of your head.
[12:01:07 CST(-0600)] <jwennmacher> When you run the db-related ant commands the resulting vm attempts to use jgroups and execution generates error messages that are confusing unless you know what's going on. I was thinking during db operations the execution should not attempt to launch jgroups. Is there an easy way to disable that?
[12:01:29 CST(-0600)] <EricDalquist> but it should
[12:01:34 CST(-0600)] <EricDalquist> well
[12:01:35 CST(-0600)] <EricDalquist> kinda
[12:01:37 CST(-0600)] <jwennmacher> why?
[12:01:47 CST(-0600)] <EricDalquist> what if I'm doing a CLI import of data in prod
[12:01:57 CST(-0600)] <EricDalquist> I really would like my imported data to show up immediately
[12:02:02 CST(-0600)] <EricDalquist> and not when the caches expire
[12:02:33 CST(-0600)] <jwennmacher> so what is the jgroups doing? I haven't looked into what it is caching.
[12:02:47 CST(-0600)] <EricDalquist> it is the cache invalidation messaging system
[12:02:55 CST(-0600)] <EricDalquist> so we use ehcache for caching
[12:03:18 CST(-0600)] <EricDalquist> and if you look in there about 70% of the caches are configured to do invalidation based replication via jgroups