uPortal IRC Logs-2010-12-06

Owned by Apereo Infrastructure
Last updated: Dec 06, 2010Version comment
5 min read

[10:12:30 CST(-0600)] <awills> EricDalquist did you see comments from Denny Denny?
[10:13:04 CST(-0600)] <EricDalquist> I did, I also got a question about the default mvn build not working in trunk
[10:13:28 CST(-0600)] <EricDalquist> does the new filtering stuff require extra setup to make the maven build work?
[10:14:45 CST(-0600)] <awills> it seems that if you maven filters, the filters file must exist... thus the issue with bamboo we addressed on Friday... is that what you mean? or something else?
[10:15:59 CST(-0600)] <athena>  (*Unless you're building directly from Maven, without Ant.  In that case you'll need a tiny adjustment, as I discovered with the help of Bamboo.)
[10:16:17 CST(-0600)] <athena> from looking at the code, it looks like it has to do with the dot that the ant task appends to the environment name if it's set
[10:16:44 CST(-0600)] <athena> awills i'm also having problems even getting the ant build to run
[10:16:55 CST(-0600)] <awills> i was just refering to the -Dfilters.file=... that we added to bamboo
[10:16:58 CST(-0600)] <EricDalquist> can we have the filters file simply setup by default?
[10:17:09 CST(-0600)] <awills> sure, i believe we can
[10:17:13 CST(-0600)] <EricDalquist> note I've had no time to actually look at the code or changes :/
[10:17:28 CST(-0600)] <athena> maybe we can just tell everyone to rename their current file to be "build.local.properties" and use that as the default rather than a blank env name?
[10:17:44 CST(-0600)] <awills> Denny Denny's comment makes me think there are platform differences to how this works
[10:17:58 CST(-0600)] <athena> dunno, but ant's not working at all for me on os x
[10:18:02 CST(-0600)] <awills> and that may be what athena's seeing
[10:18:52 CST(-0600)] <awills> probably the default value for <filters.file> should point to something that exists
[10:19:34 CST(-0600)] <awills> and also we should add these -Djasig.ignore things
[10:20:18 CST(-0600)] <awills> which is what I was going to ask about... are there known issues with passing blank arguments to mvn from ant?
[10:22:12 CST(-0600)] <EricDalquist> yes
[10:22:14 CST(-0600)] <EricDalquist> you can't do that
[10:22:25 CST(-0600)] <awills> then that's the issue
[10:22:26 CST(-0600)] <EricDalquist> which is why all those jasig.ignore parameters are there
[10:22:54 CST(-0600)] <awills> yeah, never got up to speed on that... works on windows i guess
[10:22:57 CST(-0600)] <athena> i think i can get this stuff fixed this morning if you'd like
[10:23:00 CST(-0600)] <awills> i can put them in
[10:23:40 CST(-0600)] <athena> do you have time right now?
[10:24:43 CST(-0600)] <awills> i could make it if necessary, but would actually appreciate it if you would... you'll be more certain to catch the platform differences anyway
[10:25:04 CST(-0600)] <athena> sure, i'll take care of it now - have some things i need to do in trunk this morning, so it's likely more urgent for me
[10:25:09 CST(-0600)] <awills> though I'd like to continue to support buil.properties, as the patch does now
[10:25:33 CST(-0600)] <athena> to do that we'd need to think of a way to support it in both maven and ant
[10:26:09 CST(-0600)] <awills> afaik, the only issues are (1) -Djasig.ignore and (2) it would be nicer not to have to say >mvn -Dfileters.file=xyz install
[10:27:03 CST(-0600)] <athena> it looks like right now you'd have to say ant -Dfilters.file=local and mvn -Dfilters.file=local. (trailing dot) - is that right?
[10:27:24 CST(-0600)] <awills> well ant -Denv works for 'local'
[10:27:48 CST(-0600)] <awills> or you can say ant -Dfilters.file=foo.propoerties
[10:27:53 CST(-0600)] <athena> ah
[10:28:02 CST(-0600)] <athena> right, the environment name, not the filters file
[10:28:41 CST(-0600)] <awills> but right now you don't have to specify an -Denv to ant... it just uses build.properties
[10:28:47 CST(-0600)] <athena> right
[10:28:54 CST(-0600)] <athena> but if i wanted to specify an environment?
[10:29:09 CST(-0600)] <awills> to ant? then you use -Denv
[10:29:17 CST(-0600)] <athena> and to maven?
[10:29:26 CST(-0600)] <awills> right now -Denvironment.name
[10:29:32 CST(-0600)] <awills> then it works the same
[10:29:32 CST(-0600)] <athena> k
[10:31:16 CST(-0600)] <athena> ok
[10:31:27 CST(-0600)] <athena> think we should think about making those variable names the same in the future
[10:32:16 CST(-0600)] <awills> yeah that makes sense
[10:32:40 CST(-0600)] <EricDalquist> well it would be good to make them the same before the first release that includes this feature (smile)
[10:32:55 CST(-0600)] <athena> yeah
[10:33:08 CST(-0600)] <athena> even better to switch to all-maven, but that involves a lot more time
[10:33:27 CST(-0600)] <awills> would you want to make them both environment.name? i'm not sure if there's a risk of oddness from the fact that ant already uses things like env.M2_HOME
[10:33:59 CST(-0600)] <awills> i don't encounter any issues, but i suppose there might be some lurking
[10:34:03 CST(-0600)] <athena> i don't really care what the variable name is - i think it would just be more straightforward to have it be the same for both maven and ant tasks
[10:34:28 CST(-0600)] <awills> sure
[10:37:26 CST(-0600)] <athena> ok, committed the fix
[10:42:38 CST(-0600)] <awills> excellent
[10:53:19 CST(-0600)] <athena> back shortly
[12:20:14 CST(-0600)] <EricDalquist> wishing for a JSP -> spring i18n tool
[12:20:19 CST(-0600)] <EricDalquist> anyone know of one?
[12:20:30 CST(-0600)] <athena> what kind of thing are you thinking of?
[12:20:41 CST(-0600)] <EricDalquist> I'd love to be able to feed a JSP in
[12:20:50 CST(-0600)] <EricDalquist> and get a properties file and modified JSP out
[12:20:55 CST(-0600)] <athena> oh
[12:20:57 CST(-0600)] <athena> that would be awesome
[12:21:02 CST(-0600)] <athena> i do not know of one though (sad)
[12:21:08 CST(-0600)] <EricDalquist> where all the string looking things are replaced with spring:message
[12:21:18 CST(-0600)] <EricDalquist> would be really neat
[14:21:49 CST(-0600)] <EricDalquist> weird ... wrong-number phone call from a +7 country code
[14:37:22 CST(-0600)] <athena> sounds like an expensive wrong number
[14:37:31 CST(-0600)] <EricDalquist> yeah, glad I'm not paying for it
[14:37:48 CST(-0600)] <athena> i bet (smile)
[15:13:10 CST(-0600)] <EricDalquist> ARG, fluid's use of !important can be a little annoying (sad)
[15:13:39 CST(-0600)] <colinclark> EricDalquist: It is annoying, and it's something we're going to fix
[15:13:45 CST(-0600)] <EricDalquist> yay! (smile)
[15:13:54 CST(-0600)] <colinclark> Unfortunately not for the upcoming 1.3 release, but definitely for the next one
[15:14:05 CST(-0600)] <colinclark> We were really heavy-handed with !important
[15:14:11 CST(-0600)] <colinclark> total drag
[15:14:30 CST(-0600)] <EricDalquist> yeah, I think portal environments are especially sensitive to it
[15:14:38 CST(-0600)] <EricDalquist> so many different concerns on one page :/
[15:23:38 CST(-0600)] <athena> ugh
[15:24:06 CST(-0600)] <athena> turns out the group service's method to return the root group for an entity type just returns a group that's hard-coded in portal.properties
[15:24:31 CST(-0600)] <EricDalquist> yup
[15:25:04 CST(-0600)] <athena> do we still have code to make those root groups magically have the right id?
[15:25:16 CST(-0600)] <EricDalquist> yes
[15:25:17 CST(-0600)] <EricDalquist> somewhere
[15:25:27 CST(-0600)] <athena> ok, that's good at least then
[15:25:44 CST(-0600)] <EricDalquist> I think it exists in a .crn script
[15:29:16 CST(-0600)] <athena> gotcha
[15:29:29 CST(-0600)] <athena> this code for the entity selector really needs to be rewritten as a fluid component
[15:29:39 CST(-0600)] <athena> no time to do it right now really, but it'd be a lot more stable that way