[01:08:42 EST(-0500)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[05:42:41 EST(-0500)] * ChanServ (ChanServ@services.) has joined ##uportal
[08:02:05 EST(-0500)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:58:30 EST(-0500)] * tsnfoo_ (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[09:04:33 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176131712.dsl.bell.ca) has joined ##uportal
[09:05:53 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined ##uportal
[09:30:45 EST(-0500)] * tsnfoo__ (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[10:18:55 EST(-0500)] * michelled (n=michelle@142.150.154.193) has joined ##uportal
[10:21:25 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:34:23 EST(-0500)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:48:04 EST(-0500)] * mrogers (n=mrogers@cabinlake.cc.umanitoba.ca) has joined ##uportal
[10:57:43 EST(-0500)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[11:07:51 EST(-0500)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:14:35 EST(-0500)] * michelled (n=team@142.150.154.193) has joined ##uportal
[11:19:26 EST(-0500)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[11:28:17 EST(-0500)] * athena7 (n=athena7@adsl-99-136-251-32.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[11:31:34 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:45:33 EST(-0500)] * tsnfoo (n=tsnfoo@140.141.213.244) has joined ##uportal
[12:07:22 EST(-0500)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[13:14:16 EST(-0500)] <EricDalquist> hrm I wonder if this is too late for 3.1 ...
[13:14:37 EST(-0500)] <athena7> ?
[13:14:40 EST(-0500)] <EricDalquist> I was just thinking that it would be very handy to separate out the base set of entity files that you must import to have a functional portal
[13:14:49 EST(-0500)] <athena7> interesting
[13:14:52 EST(-0500)] <athena7> that would be kind of useful
[13:15:02 EST(-0500)] <EricDalquist> so we would have db/entities.base/ and db/entties.default/
[13:15:09 EST(-0500)] <athena7> by the way, i filed a jira for a problem i found w/ creating portlets from the simple web proxy portlet CPD
[13:15:15 EST(-0500)] <EricDalquist> yeah saw that
[13:15:15 EST(-0500)] <athena7> i like it
[13:15:17 EST(-0500)] <EricDalquist> thanks 
[13:15:43 EST(-0500)] <EricDalquist> another thought (unrelated) I've had recently is perhaps having UP-* jira notifications go to the uportal-dev list
[13:15:52 EST(-0500)] <EricDalquist> but I figure there are probably folks that would object to that 
[13:15:58 EST(-0500)] <EricDalquist> back on the entities topic
[13:16:20 EST(-0500)] <EricDalquist> even when upgrading from an existing install there are some entity files in each release that you really have to have
[13:16:33 EST(-0500)] <holdorph> other projects tend to have a separate list, that you can subscribe to for things like subversion commits, or jira notices
[13:17:15 EST(-0500)] <athena7> yeah i was about to suggest that we could create another list if necessary
[13:17:29 EST(-0500)] <EricDalquist> there is another list
[13:17:37 EST(-0500)] <EricDalquist> jira-up@lists.ja-sig.org
[13:17:54 EST(-0500)] <EricDalquist> http://www.ja-sig.org/wiki/display/JSG/Jira+Notifications
[13:19:16 EST(-0500)] <holdorph> then maybe I didn't fully understand what you were trying to say to begin with. it wasn't so much, the sending out of notification, as much as it was more about getting people to LOOK at the notifications being sent out already
[13:19:34 EST(-0500)] <EricDalquist>
[13:19:51 EST(-0500)] <athena7> lol
[13:20:04 EST(-0500)] <athena7> sadly i suspect that would have the effect of just causing less people to keep up w/ the list
[13:20:10 EST(-0500)] <EricDalquist> yup
[13:20:23 EST(-0500)] <EricDalquist> which is why I would never actually push to do that
[13:20:35 EST(-0500)] <athena7> just the temptation, huh?
[13:20:41 EST(-0500)] <EricDalquist> yup
[13:20:49 EST(-0500)] <EricDalquist> I get reminded working on pluto
[13:21:00 EST(-0500)] <EricDalquist> the dev list there gets jira and svn notifications
[13:21:10 EST(-0500)] <EricDalquist> but that is a lot lower traffic
[13:21:25 EST(-0500)] <EricDalquist> really I'd love to be able to get RSS feeds of jira issues
[13:21:32 EST(-0500)] <athena7> it was interesting lurking in the fluid irc channel during their release
[13:21:39 EST(-0500)] <athena7> lots of real-time communication
[13:21:42 EST(-0500)] <athena7> does that not work eric?
[13:21:47 EST(-0500)] <athena7> i thought you could get rss feeds
[13:21:53 EST(-0500)] <EricDalquist> you can get rss feeds of a search
[13:22:04 EST(-0500)] <EricDalquist> but you can get an rss feed that mirros the notification scheme
[13:22:15 EST(-0500)] <EricDalquist> like I want an RSS entry for any action on any uportal issue
[13:22:20 EST(-0500)] <athena7> ah
[13:22:23 EST(-0500)] <athena7> gotcha
[13:22:25 EST(-0500)] <EricDalquist> I can get a rss feed of issue creation on uportal
[13:22:28 EST(-0500)] <EricDalquist> but nothing else
[13:22:31 EST(-0500)] <athena7> yeah that would be nice
[13:32:54 EST(-0500)] <dstn> EricDalquist: I was actually gonna file a JIRA related to what you mentioned above. I noticed that the import scripts are pretty good for checking that things match up but it doesn't really check that certain entities you really have to have are there...like the system and guest user for example
[13:35:32 EST(-0500)] * dstn off to merge 3.
[13:35:36 EST(-0500)] <dstn> 3.1*
[13:35:46 EST(-0500)] <EricDalquist>
[13:37:57 EST(-0500)] <athena7> woo
[13:38:15 EST(-0500)] <athena7> i just put our portlet admin portlet work into a fresh 3.1rc1 download
[13:38:18 EST(-0500)] <athena7> seems to still work
[14:06:46 EST(-0500)] <dstn> for the people here that use SVN do you guys use svn_load_dirs.pl for vendor drops?
[14:07:19 EST(-0500)] <EricDalquist> we're still on CVS :/
[14:07:28 EST(-0500)] <EricDalquist> but I think that is what people I've talked to use
[14:12:04 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:17:50 EST(-0500)] <dstn> so what happened to db/entities/group directory?
[14:18:06 EST(-0500)] <EricDalquist> it was replaced with group_membership
[14:18:13 EST(-0500)] <EricDalquist> the old group and membership files still work
[14:18:27 EST(-0500)] <EricDalquist> just simplified things for new deployments
[14:20:00 EST(-0500)] <dstn> ok, so group + membership = group_membership
[14:20:04 EST(-0500)] <dstn> ;-D
[14:21:09 EST(-0500)] <EricDalquist> yup
[14:21:25 EST(-0500)] <EricDalquist> we've started using them to manage local groups via source controll
[14:21:32 EST(-0500)] <athena7> yes, dstn, i use svn_load_dirs
[14:21:36 EST(-0500)] <EricDalquist> we can have a PortalAdmin.group_membership file
[14:21:45 EST(-0500)] <athena7> existing yale source control may not have used it in the past though
[14:21:56 EST(-0500)] <EricDalquist> and just have our normal weekly build process import them to update the members ofd the group
[14:26:34 EST(-0500)] <dstn> athena7: is there any documentation on "resource server" ... I'd like to know more about it
[14:26:55 EST(-0500)] <athena7> no . . . but documentation sounds like a great idea
[14:27:08 EST(-0500)] <athena7> you can gather some information from the application's front page
[14:27:17 EST(-0500)] <athena7> any particular things you'd like to hear about?
[14:28:00 EST(-0500)] <dstn> well, the basics...like what is it..beyond the obvious "it serves resources" 
[14:28:23 EST(-0500)] <dstn> I haven't actually ran it yet, I'm looking at the differences from the vendor drop to make sure I understand exactly what is being dropped
[14:28:37 EST(-0500)] <athena7> ah, gotcha
[14:28:42 EST(-0500)] <dstn> just saw this ResourceServingWebapp and went "oh what's this"
[14:28:59 EST(-0500)] <athena7> so basically it serves up static library resources - jQuery, Fluid, the famfamfam image library, etc.
[14:30:35 EST(-0500)] <athena7> it does useful things like provide a single URL that both portlets and the portal can use (thus taking advantage of caching)
[14:30:43 EST(-0500)] <athena7> gzips the css and javascript
[14:30:50 EST(-0500)] <athena7> and sets long-lived cache headers on them
[14:31:12 EST(-0500)] <athena7> also, it includes a lib you can use in your portlets - which has the filter as well as a tag library for getting the resource url
[14:32:31 EST(-0500)] <EricDalquist> the tag also has fail-safe behavior so if you use it in your portlet and the resource serving webapp isn't available it will fall back to a copy of the resource hosted by the portlet
[14:32:54 EST(-0500)] <athena7> yes
[14:33:07 EST(-0500)] <athena7> so we can make things compatible with portals not using the resource server
[14:33:50 EST(-0500)] <EricDalquist> or old versions of the resource server that doesn't include a new lib/icon/css
[14:34:28 EST(-0500)] <athena7> right
[14:35:48 EST(-0500)] <dstn> ok cool!
[14:37:32 EST(-0500)] <athena7> we've developed some new strategies that hopefully will allow a portlet to use a different version of jquery than is in the portal
[14:47:26 EST(-0500)] <EricDalquist> I hate making slides
[14:47:31 EST(-0500)] <EricDalquist> I have a few pages of outline
[14:47:35 EST(-0500)] <EricDalquist> thats easy
[14:47:47 EST(-0500)] <EricDalquist> making slides ... for whatever reason is like pulling teeth
[14:48:29 EST(-0500)] <dstn> lol
[14:48:29 EST(-0500)] <athena7> yeah, i'm not a huge fan either
[14:49:11 EST(-0500)] <dstn> so has anyone thought of renamed uportal-portlets-overlay to something like uportal-overlay since it's not really just portlets?
[14:49:38 EST(-0500)] <EricDalquist> thats a decent idea
[14:49:52 EST(-0500)] <EricDalquist> the first it could happen now is 3.2
[14:50:19 EST(-0500)] <athena7> i think it might be worth re-examining our build and deployment process in general
[14:50:31 EST(-0500)] <EricDalquist> +1
[14:50:58 EST(-0500)] <EricDalquist> yeah what we have now is what I came up with when doing the 3.0 work so it would be backwards compatable
[14:51:06 EST(-0500)] <dstn> it'd cool to see it all go to maven instead of ant + maven
[14:51:08 EST(-0500)] <EricDalquist> we can always look at where we want to go into the future
[14:51:20 EST(-0500)] <dstn> with some custom maven plugins
[14:51:24 EST(-0500)] <EricDalquist> yeah ...
[14:51:29 EST(-0500)] <dstn> for doing ear deployment and such
[14:51:31 EST(-0500)] <EricDalquist> I'm not a huge fan of custom maven plugins
[14:51:36 EST(-0500)] <dstn> lol
[14:51:37 EST(-0500)] <EricDalquist> but it is an option
[14:51:43 EST(-0500)] <dstn> ya, why not?
[14:51:55 EST(-0500)] <dstn> I've never wrote one. Just know that's the model
[14:51:58 EST(-0500)] <EricDalquist> I'm still of the opinion that maven is a great project build/reporting tool
[14:52:04 EST(-0500)] <athena7> i think we'd do well to move away from the custom ant targets
[14:52:04 EST(-0500)] <EricDalquist> and a poor scripting tool
[14:52:22 EST(-0500)] <holdorph> as much as I dislike sakai for other things. I MUCH MUCH MUCH prefer it's build process to the current uportal one
[14:52:33 EST(-0500)] <EricDalquist> do they have a lot of command line tools too?
[14:52:34 EST(-0500)] <dstn> what does sakai use?
[14:52:38 EST(-0500)] <holdorph> something about maven with the custom plugins, definitely feeling better, then ant+maven
[14:52:48 EST(-0500)] * athena7 agrees with holdorph
[14:52:54 EST(-0500)] <holdorph> they have one custom plugin to do the deployment to tomcat
[14:52:54 EST(-0500)] <EricDalquist> just building and deploying with maven isn't so bad
[14:52:58 EST(-0500)] <athena7> eric it's possible to run ant commands using the ant plugin
[14:53:08 EST(-0500)] <EricDalquist> true
[14:53:18 EST(-0500)] <athena7> part of me wonders though whether it might be useful to break up the process a little
[14:53:28 EST(-0500)] <athena7> have some maven goals that really just build the project
[14:53:42 EST(-0500)] <dstn> mvn compile?
[14:53:57 EST(-0500)] <athena7> and then start thinking about the discussions we've had about pulling in a canonical uportal war and overlaying/filtering it to create deployment-specific artifacts
[14:54:20 EST(-0500)] <athena7> which i think might require some re-organization
[14:55:27 EST(-0500)] <EricDalquist> yeah
[14:55:30 EST(-0500)] <EricDalquist> I like that idea too
[14:55:43 EST(-0500)] <EricDalquist> it still doesn't address all the command line tools we have
[14:55:53 EST(-0500)] <EricDalquist> though we can probably reduce them to just a hand ful
[14:56:22 EST(-0500)] <dstn> imagine this: mvn uPortal:dbtest
[14:56:27 EST(-0500)] <dstn> ewww ahh, cheers
[14:56:27 EST(-0500)] <EricDalquist> there will be the need for initialization of the db, crn-*, deployPortlet
[14:56:31 EST(-0500)] <athena7> right
[14:56:33 EST(-0500)] <dstn> :-D
[14:56:43 EST(-0500)] <athena7> so i think we'll need to think about how those tools should work, and where they should go
[14:57:08 EST(-0500)] <athena7> but it'd be great to sit down and think about what makes sense before the next major release
[14:57:31 EST(-0500)] <EricDalquist> yeah
[14:57:40 EST(-0500)] <EricDalquist> if we're serious about that we should start now
[14:57:47 EST(-0500)] <holdorph> <---- big fan of system installation and administration tools that don't require a build system
[14:57:55 EST(-0500)] <athena7> maybe we can talk about it at the conference some
[14:58:03 EST(-0500)] <EricDalquist> refactoring project structure and build systems is a big task
[14:58:08 EST(-0500)] <EricDalquist> holdorph: that is another requirements
[14:58:12 EST(-0500)] <EricDalquist> requirement*
[14:58:19 EST(-0500)] <EricDalquist> we have two groups of users that both have a strong view
[14:58:29 EST(-0500)] <holdorph> we really need to fix the idea that you need and+maven+source code tree to system admin functions on your production box.
[14:58:31 EST(-0500)] <EricDalquist> one says all admin work should be done via web ui tasks
[14:58:40 EST(-0500)] <EricDalquist> another says everything should be scriptable via the command line
[14:58:41 EST(-0500)] <holdorph> that's a big problem for several institutions we talk to
[14:58:57 EST(-0500)] <dstn> it could be both...
[14:59:00 EST(-0500)] <holdorph> it's why drew had to do that last DLM fragment work, matter of fact
[14:59:13 EST(-0500)] <athena7> be nice if tomcat could deploy ears
[14:59:17 EST(-0500)] <dstn> lol
[14:59:20 EST(-0500)] <EricDalquist> heh
[14:59:28 EST(-0500)] <EricDalquist> we could require jboss
[14:59:36 EST(-0500)] <athena7> well, i mean if we could just build an ear and then declare ourselves done . . .
[14:59:40 EST(-0500)] <athena7> lets not do that
[15:00:56 EST(-0500)] <EricDalquist> so perhaps splitting out packaging of some of the build tools
[15:01:05 EST(-0500)] <EricDalquist> like the ant ear deployer task
[15:01:36 EST(-0500)] <EricDalquist> you could right now put together a ant build file with that jar and deploy a .EAR to tomcat
[15:01:41 EST(-0500)] <EricDalquist> without the rest of the framework
[15:02:48 EST(-0500)] <athena7> yeah
[15:03:04 EST(-0500)] <athena7> i've sort of wondered about maybe building ears, then having a smaller tool that could deploy them
[15:03:14 EST(-0500)] <EricDalquist> that exists right now athena7
[15:03:19 EST(-0500)] <EricDalquist> its just not split out at all
[15:03:31 EST(-0500)] <athena7> but could you really just run that without having the uportal source tree downloaded?
[15:03:35 EST(-0500)] <EricDalquist> yes
[15:04:03 EST(-0500)] <EricDalquist> uportal-ear-deployer creates a little JAR that knows how to deploy EAR files to tomcat
[15:04:28 EST(-0500)] <EricDalquist> uportal-ant-tasks creates a little JAR that uses uportal-ear-deployer to make a nice ant task for deploying EAR files to tomcat
[15:04:32 EST(-0500)] <EricDalquist> if you took those two jars
[15:04:37 EST(-0500)] <EricDalquist> and created a build.xml file
[15:04:41 EST(-0500)] <EricDalquist> it would all run just fine just like that
[15:05:38 EST(-0500)] <EricDalquist> the tools that are harder to figure out are those that interact with the database
[15:05:46 EST(-0500)] <EricDalquist> dbloader could be a stand-alone module
[15:06:00 EST(-0500)] <EricDalquist> but the crn-* scripts require the uPortal code base to function
[15:06:38 EST(-0500)] <EricDalquist> deployPortletApp could also be stand-lone (right now we are just using the ant task that pluto 1.1 provides so that already is seperate)
[15:06:55 EST(-0500)] <holdorph> as they're coded now. but at the theoreticall level, it seems all they should require is the uportal .jars and the database connection information
[15:07:13 EST(-0500)] <holdorph> (the crn tasks that is)
[15:07:16 EST(-0500)] <EricDalquist> ah yeah
[15:07:21 EST(-0500)] <EricDalquist> well that is all they require right now
[15:07:29 EST(-0500)] <EricDalquist> the ant build script generates the uportal-impl jar
[15:07:41 EST(-0500)] <EricDalquist> uses the maven ant tasks to load up all the dependcies on the class path
[15:07:42 EST(-0500)] <athena7> i'll have to play with those
[15:07:50 EST(-0500)] <EricDalquist> then runs a <java> task with that classpath
[15:07:55 EST(-0500)] <EricDalquist> that could get moved out as well
[15:08:08 EST(-0500)] <EricDalquist> as long as you have a place to get your version of uportal.jar
[15:08:35 EST(-0500)] <EricDalquist> really if a school has their own local Maven repository it is very close to a stand-alone build.xml file
[15:09:06 EST(-0500)] <EricDalquist> you could pretty much take what is there, and convert the macros to just get the artifacts from the repository
[15:09:31 EST(-0500)] <EricDalquist> instead of doing a 'mvn install' on local code then getting the artifacts from the repository
[15:11:28 EST(-0500)] <EricDalquist> the 3.x build.xml is very different from 2.x in that it (should) never read files from the uPortal source tree and should be reading them off the classpath from the packaged maven artifact
[15:11:31 EST(-0500)] <awills> yeah the crn-* operations run just fine w/o the source tree (in the webapp)... you can experience it yourself with the ImportExportPortlet
[15:11:41 EST(-0500)] <EricDalquist> the only exception is the crn-* scripts reading the entities/ directory
[15:11:57 EST(-0500)] <EricDalquist> but honestly I've been thinking more about that and it doesn't make much sense to include all those entity files in uportal.jar anyways
[15:12:06 EST(-0500)] <awills> +1
[15:12:12 EST(-0500)] <EricDalquist> dstn: ran into that the other day
[15:12:18 EST(-0500)] <awills> we should talk about moving it out
[15:12:20 EST(-0500)] <EricDalquist> put the entire yale export in there
[15:12:35 EST(-0500)] <awills> ic
[15:12:36 EST(-0500)] <EricDalquist> and it took like 10 minutes to build the JAR if I remember
[15:12:42 EST(-0500)] <dstn> :-D
[15:12:50 EST(-0500)] <EricDalquist> am I remembering right dstn ?
[15:12:57 EST(-0500)] <dstn> yep
[15:13:23 EST(-0500)] <dstn> it seemed logical until it wanted to run mvn install and build 3.0.2.jar
[15:14:08 EST(-0500)] <EricDalquist> yeah
[15:17:14 EST(-0500)] <EricDalquist> http://www.ja-sig.org/issues/browse/UP-2314
[15:18:25 EST(-0500)] <EricDalquist> http://www.ja-sig.org/issues/browse/UP-2315
[15:20:26 EST(-0500)] <EricDalquist> feel free to document more of this discussion as children of UP-2314
[15:20:32 EST(-0500)] <EricDalquist> I think this would be great to address for 3.2
[15:43:48 EST(-0500)] * dstn accidentally deleted his current vendor drop
[15:43:55 EST(-0500)] <EricDalquist> oops
[15:43:57 EST(-0500)] <dstn> guess thats what I get for not paying attention
[15:44:08 EST(-0500)] <dstn> trying to do it and talk to someone at the same time
[15:44:17 EST(-0500)] <EricDalquist>
[15:45:05 EST(-0500)] <dstn> took me a min to figure out the command to copy a specific revision
[15:45:17 EST(-0500)] <dstn> svn never fails to amaze me with its syntax
[16:22:56 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined ##uportal
[17:18:44 EST(-0500)] * michelled (n=team@142.150.154.193) has left ##uportal
[17:22:53 EST(-0500)] <EricDalquist> so dstn with your current import/export experiance
[17:23:00 EST(-0500)] <EricDalquist> what do you view as 'required base entities'
[17:25:26 EST(-0500)] <bszabo> Hi Eric
[17:25:37 EST(-0500)] <EricDalquist> hi Brad
[17:26:03 EST(-0500)] <bszabo> I notice that in uP3 when the Pluto Assembler is used, the resulting web.xml files have the new lines stripped
[17:26:10 EST(-0500)] <EricDalquist> yeah 
[17:26:21 EST(-0500)] <EricDalquist> that needs to get filed as a bug against pluto
[17:26:30 EST(-0500)] <EricDalquist> I'm not sure exactly what the code is doing to cause that
[17:26:37 EST(-0500)] <EricDalquist> but it sure is a pita to read them
[17:26:37 EST(-0500)] <bszabo> ah, that's what I was wondering
[17:26:54 EST(-0500)] <bszabo> I figured you would know if that issue had been discussed at all
[17:26:57 EST(-0500)] <bszabo> yeah
[17:27:07 EST(-0500)] <EricDalquist> I haven't seen it come up on the pluto lists
[17:27:19 EST(-0500)] <EricDalquist> if you happen to be interested in digging into it I can get the patch applied to pluto
[17:28:40 EST(-0500)] <bszabo> I'd like to address it, but no promises
[17:35:33 EST(-0500)] <EricDalquist> grrr maven 2.0.10 behaves differently with wars than 2.0.9 did
[17:38:16 EST(-0500)] <athena7> eric i had a couple thoughts about the resource server project
[17:38:22 EST(-0500)] <EricDalquist> ok
[17:38:27 EST(-0500)] <athena7> 1 - should we move that configurable filter into it?
[17:38:40 EST(-0500)] <athena7> other projects might potentially want to use that i suppose
[17:38:51 EST(-0500)] <EricDalquist> the injectable ehcache filter?
[17:38:53 EST(-0500)] <athena7> yeah
[17:39:11 EST(-0500)] <EricDalquist> sounds good
[17:39:13 EST(-0500)] <athena7> ok
[17:39:18 EST(-0500)] <EricDalquist> since there is already a spring context
[17:39:30 EST(-0500)] <EricDalquist> we could create the ehcache manager more like uPortal does that way
[17:39:46 EST(-0500)] <athena7> oh, i meant into the jar for portlets to re-use
[17:39:48 EST(-0500)] <EricDalquist> and remove the JMX listener thing I added and do that in the spring context too
[17:39:51 EST(-0500)] <athena7> but we could use it in the webapp as well
[17:39:51 EST(-0500)] <EricDalquist> yeah
[17:39:56 EST(-0500)] <EricDalquist> yeah
[17:40:01 EST(-0500)] <athena7> 2 - we're setting cache headers for javascript and css, but not images
[17:40:09 EST(-0500)] <athena7> do we just want to apply that filter to all of /rs/*
[17:40:10 EST(-0500)] <athena7> ?
[17:40:19 EST(-0500)] <EricDalquist> yes
[17:40:22 EST(-0500)] <athena7> ok
[17:40:27 EST(-0500)] <athena7> i couldn't think of a reason not to
[17:40:36 EST(-0500)] <athena7> i wouldn't imagine we'd have anything in there that shouldn't be cached
[17:41:36 EST(-0500)] <EricDalquist> I don't think so
[17:41:48 EST(-0500)] <EricDalquist> I think the rule is anything under /rs/ needs to be well named enough to be cached forever
[17:42:04 EST(-0500)] <athena7> sounds great to me
[17:42:10 EST(-0500)] <athena7> i will make it so
[17:42:40 EST(-0500)] <EricDalquist>
[17:42:46 EST(-0500)] * athena7 is now riker
[17:45:40 EST(-0500)] <athena7> oh, also, i think it makes sense to remove the famfamfam icon set from uportal
[17:45:47 EST(-0500)] <athena7> since that now represents 1000 files that aren't being used
[17:45:48 EST(-0500)] <EricDalquist> yes
[17:45:50 EST(-0500)] <EricDalquist> so do I
[17:45:58 EST(-0500)] <athena7> should make the svn download less painful
[17:46:01 EST(-0500)] <EricDalquist> yup
[17:46:20 EST(-0500)] <athena7> goign to be irritating though, because that directory collected a few non-famfamfam icons
[17:46:22 EST(-0500)] <athena7> no good.
[17:46:29 EST(-0500)] <EricDalquist> hah
[17:46:30 EST(-0500)] <EricDalquist> yeah
[17:46:36 EST(-0500)] <EricDalquist> diff -r to the rescue?
[17:46:57 EST(-0500)] <athena7> yeah i'm hoping i can tell from commit times which were part of the original icon set
[17:47:24 EST(-0500)] <athena7> oddly enough there are also a pile of graphics that are missing from the list
[17:47:27 EST(-0500)] <athena7> not sure how that happened
[17:50:45 EST(-0500)] <athena7> oh, maybe my eclipse just is having issues
[17:50:47 EST(-0500)] <athena7> whatever
[18:02:19 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
General
Content
Integrations