fluid-work IRC Logs-2010-05-11

fluid-work IRC Logs-2010-05-11

[02:25:07 EDT(-0400)] * joost (~joost@dfki-119.dfki.uni-kl.de) has joined #fluid-work
[08:17:52 EDT(-0400)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[08:19:50 EDT(-0400)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[08:58:20 EDT(-0400)] * kasper (~kasper@189.130.67.157) has joined #fluid-work
[09:35:56 EDT(-0400)] * colinclark (~colin@bas2-toronto09-2925239674.dsl.bell.ca) has joined #fluid-work
[10:03:26 EDT(-0400)] * clown (~clown@142.150.154.101) has joined #fluid-work
[10:33:52 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[10:40:55 EDT(-0400)] <Justin_o> kasper: i think i may have a maven script for the ui layer
[10:41:17 EDT(-0400)] <kasper> justin_o: ooooooh.... I like the sound of that!
[10:41:40 EDT(-0400)] <Justin_o> i'll e-mail it to you... please let me know if it works... you will have to make some changes to point at the proper location of the jboss server
[10:41:59 EDT(-0400)] <kasper> justin_o: cool
[10:48:17 EDT(-0400)] <Justin_o> kasper: i just sent it to you with some instructions... let me know how it goes and if you have more questions... i think if that works we should be able to make similar changes to the application layer (although i haven't looked at that pom yet)... and then possibly make a pom that sits above the application and ui layer that could itself kick off both of those builds
[10:50:14 EDT(-0400)] <kasper> justin_o: awesome justin_o. Will look at it straight away
[10:50:39 EDT(-0400)] <Justin_o> kasper: thanks
[11:05:21 EDT(-0400)] <kasper> Is there anywhere in particular I would have to place this, relative to the UI-sourcecode, justin_o?
[11:06:43 EDT(-0400)] <Justin_o> kasper: i used it at the root of the project... so where the current pom.xml file is located...this is basically the same file with some extra stuff added
[11:20:13 EDT(-0400)] <kasper> justin_o: wuhu... it ran successfully... now i got a nice new and pretty UI
[11:20:46 EDT(-0400)] <Justin_o> kasper: that's great... glad to hear it ... (smile)
[11:21:07 EDT(-0400)] <Justin_o> kasper: would you like me to take a look at the one for the application layer?
[11:21:13 EDT(-0400)] <kasper> justin_o: me too (smile) ... one step closer to a nightly build
[11:21:25 EDT(-0400)] <kasper> justin_o: yeah, that would be awesome
[11:26:28 EDT(-0400)] * athena (~athena@adsl-99-90-242-49.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[11:27:04 EDT(-0400)] * elicochran (~elicochra@dhcp-169-229-212-33.LIPS.Berkeley.EDU) has joined #fluid-work
[11:27:55 EDT(-0400)] <colinclark> Hey athena
[11:28:00 EDT(-0400)] * athena waves
[11:28:06 EDT(-0400)] <colinclark> Do you have a sec for a quick Maven question?
[11:28:52 EDT(-0400)] <athena> oh! yes
[11:28:55 EDT(-0400)] <colinclark> (smile)
[11:29:02 EDT(-0400)] <athena> i owed Justin_o a response on that, sorry!
[11:29:11 EDT(-0400)] <colinclark> No worries. He's making progress
[11:29:21 EDT(-0400)] <colinclark> Justin_o and kasper are working on builds for CollectionSpace
[11:29:34 EDT(-0400)] <athena> so uportal still doesn't actually use maven to perform deployment tasks
[11:29:37 EDT(-0400)] <athena> just generating the artifacts
[11:29:41 EDT(-0400)] <colinclark> Ah, interesting
[11:29:43 EDT(-0400)] <colinclark> Still using Ant?
[11:29:49 EDT(-0400)] <athena> yes, which i don't recommend
[11:29:52 EDT(-0400)] <colinclark> Justin_o: You managed to get deploys to JBoss working with Cargo, right?
[11:29:59 EDT(-0400)] <athena> i wrote a maven plugin for yale last year that did deployment, though
[11:30:12 EDT(-0400)] <athena> it does work, but we haven't switched uportal over to it yet
[11:30:13 EDT(-0400)] <Justin_o> colinclark: yes
[11:30:19 EDT(-0400)] <colinclark> So deploying the UI is now really easy. The issue gets interesting when we get to deploying the application WAR file.
[11:30:21 EDT(-0400)] <kasper> justin_o: csm22 in the #collectionspace channel is our app lead, in case you need some app specific assistance that i cant help you with
[11:30:32 EDT(-0400)] <colinclark> So deploying the app layer is roughly like this:
[11:30:38 EDT(-0400)] <athena> one thing i haven't been able to figure out is how to get it to selectively run on just one sub-project
[11:30:42 EDT(-0400)] <colinclark> 1. Compile and build the WAR
[11:30:46 EDT(-0400)] <kasper> colinclark: just tested out justin_o's script, worked like a charm
[11:30:49 EDT(-0400)] <colinclark> 2. Deployt it to tomcat
[11:31:04 EDT(-0400)] <colinclark> ^^ JBoss, really
[11:31:32 EDT(-0400)] <colinclark> 3. Edit a config file and deploy it to JBoss/Tomcat's lib directory
[11:31:47 EDT(-0400)] <colinclark> So #3 is a bit more complex... kasper wrote a little shell script to do this
[11:31:51 EDT(-0400)] <athena> that sounds like no fun
[11:31:56 EDT(-0400)] <colinclark> But can we automate this without code using Maven somehow?
[11:32:02 EDT(-0400)] <athena> yes, probably
[11:32:05 EDT(-0400)] <colinclark> In the simplest case, I guess we can use the Maven exec plugin
[11:32:11 EDT(-0400)] <colinclark> Any suggestions?
[11:32:12 EDT(-0400)] <athena> so one thing uportal does is to build an ear file
[11:32:26 EDT(-0400)] <athena> because we need to deploy multiple wars, as well as some jars that go to shared
[11:32:46 EDT(-0400)] <colinclark> ah, interesting
[11:33:05 EDT(-0400)] <colinclark> So the ear bundles up a bunch of wars, some jars, and perhaps some configuration?
[11:33:06 EDT(-0400)] <athena> of course, tomcat can't actually deploy ear files, so we have a custom maven plugin that can take an ear artifact and unzip it to the right spot after cleaning out the right resources
[11:33:09 EDT(-0400)] <athena> yeah
[11:33:20 EDT(-0400)] <athena> i don't have a lot of experience with them since they don't work on tomcat
[11:33:24 EDT(-0400)] <athena> but maybe they do on jboss?
[11:33:34 EDT(-0400)] <colinclark> yeah, I expect they will
[11:33:43 EDT(-0400)] <colinclark> But what's interesting is that we often do development with Tomcat
[11:33:43 EDT(-0400)] <athena> and it seems like a reasonable choice of packaging type, if you really have a bunch of resources that all go together
[11:33:48 EDT(-0400)] <colinclark> Even though final deployment is on JBoss
[11:33:52 EDT(-0400)] <colinclark> (long story there)
[11:34:03 EDT(-0400)] <athena> you could probably re-use our plugin to deploy an ear to tomcat, or at least re-use parts of it
[11:34:07 EDT(-0400)] <athena> it seems to work pretty well
[11:34:17 EDT(-0400)] <athena> there's just one thing i haven't figured out, though i suspect someone else knows the answer
[11:34:29 EDT(-0400)] <athena> right now we're still driving that maven custom plugin with ant
[11:34:46 EDT(-0400)] <athena> because i can't figure out how to execute the custom plugin from maven such that it only runs on the single desired subproject
[11:35:03 EDT(-0400)] <athena> by default it tries to run on every single project - which doesn't hurt anything, since there's nothign for it to do, but it takes forever
[11:35:25 EDT(-0400)] <athena> sakai uses a kind of similar strategy to deploy, but they actually want the plugin to run on every submodule
[11:35:39 EDT(-0400)] <athena> we don't, since our whole portal gets packaged up into one artifact
[11:36:01 EDT(-0400)] <athena> so i don't know if any of that is helpful, but i'm definitely willing to talk more about this stuff and find you guys examples if you think what uportal did might be applicable
[11:36:28 EDT(-0400)] <athena> by the way, where was the page w/ the Fluid CCLA?
[11:46:08 EDT(-0400)] <colinclark> sorry, we had a quick standup
[11:46:11 EDT(-0400)] <colinclark> catching up
[11:47:21 EDT(-0400)] <colinclark> athena: That's pretty helpful.
[11:47:35 EDT(-0400)] <athena> cool
[11:47:39 EDT(-0400)] <colinclark> I think Justin_o may have some questions as he digs into it
[11:47:44 EDT(-0400)] <colinclark> We're going to do something incremental
[11:47:45 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[11:47:53 EDT(-0400)] <athena> if you have any suggestions about the submodule issue definitely let me know
[11:47:55 EDT(-0400)] <colinclark> Step 1, get rid of any Ant scripts that do what Maven can already do
[11:48:05 EDT(-0400)] <athena> and Justin_o, seriously, if i forget to email you back, please remind me
[11:48:12 EDT(-0400)] <athena> i'm kind of disorganized right now with moving and all
[11:48:17 EDT(-0400)] <athena> that sounds like a great strategy colinclark
[11:48:17 EDT(-0400)] <colinclark> Step 2, deal with the configuration file stuff by firing off command line scripts for now, then see if there's something else we can use
[11:48:24 EDT(-0400)] <athena> that's kind of what we did with yale - start moving over what we could
[11:48:29 EDT(-0400)] <colinclark> athena: I'm amazed you're even around much, what with all the moving
[11:48:33 EDT(-0400)] <colinclark> thanks, this is really helpful
[11:48:43 EDT(-0400)] <athena> well, still working during the day (smile)
[11:48:44 EDT(-0400)] <colinclark> in part, I just wanted to make sure I wasn't insane and sending Justin_o down some crazy path
[11:48:47 EDT(-0400)] <colinclark> (tongue)
[11:48:49 EDT(-0400)] <athena> just kind of scattered in the off hours
[11:48:52 EDT(-0400)] <athena> lol no, not insane
[11:48:52 EDT(-0400)] <athena> it
[11:48:52 EDT(-0400)] <athena> 's
[11:48:53 EDT(-0400)] <athena> a
[11:48:59 EDT(-0400)] <colinclark> (smile)
[11:49:06 EDT(-0400)] <athena> it's a little hard - maven isn't exactly designed to be a deployment tool, i dont' think
[11:49:10 EDT(-0400)] <athena> but that doesn't mean it's impossible
[11:49:20 EDT(-0400)] <athena> you just can't use any of the built-in lifecycles
[11:49:35 EDT(-0400)] <athena> and we've conclusively proved that attempting to run maven through ant is the path to pain and suffering
[11:50:44 EDT(-0400)] <colinclark> (smile)
[11:50:54 EDT(-0400)] <athena> ahhhh it burns
[11:50:58 EDT(-0400)] <athena> (smile)
[11:50:58 EDT(-0400)] <colinclark> Is it equally insane to run ant through maven?
[11:51:01 EDT(-0400)] <athena> no
[11:51:10 EDT(-0400)] <athena> it is much more sane, and i think it's not a bad idea
[11:51:19 EDT(-0400)] <athena> particularly tasks like copying files and such are a great match for that
[11:51:24 EDT(-0400)] <colinclark> ok
[11:51:40 EDT(-0400)] <athena> so basically the problem we ran into is that if you do ant -> maven, it's really hard to use nice maven features like profiles
[11:51:51 EDT(-0400)] <athena> the maven ant tools project sort of helps, but it has a lot of holes
[11:51:56 EDT(-0400)] <colinclark> So, Justin_o and kasper, if we're really stuck in terms of the app-level config file, we might choose eventually to replace the shell script with some Ant so that it is cross-platform. But for now, seems like no big deal
[11:54:08 EDT(-0400)] <Justin_o> colinclark, athena: sorry, was catching up
[11:54:36 EDT(-0400)] <Justin_o> athena: don't worry about the old e-mail... i might have some new stuff to ask you though, as i go through some of these things
[11:54:50 EDT(-0400)] <athena> definitely!
[11:55:03 EDT(-0400)] <Justin_o> athena: thanks
[11:55:08 EDT(-0400)] <athena> it's all good stuff, and i'm interested to hear what you're doing, since we're also trying to move more towards maven
[11:55:20 EDT(-0400)] <kasper> colinclark: makes sense to me
[11:55:36 EDT(-0400)] <athena> and seriously, if i don't respond to you within a day or so, i've probably forgotten about it and you should feel free to remind me (smile)
[11:56:46 EDT(-0400)] <Justin_o> athena: thanks... e-mail is easy to forget about especially when we get so much
[11:56:50 EDT(-0400)] <athena> yeah
[11:56:55 EDT(-0400)] <athena> once it scrolls out of view . . .
[11:57:13 EDT(-0400)] <athena> i should probably institute some sort of folder-star-whatever strategy
[11:57:48 EDT(-0400)] <Justin_o> athena: i haven't quite figured that out either
[11:58:18 EDT(-0400)] <athena> i have recently started aggressive to-do-list-keeping though
[12:06:49 EDT(-0400)] <colinclark> athena: I am dorky, but I have an empty inbox policy, including a folder where emails go that I need to respond to
[12:06:59 EDT(-0400)] <athena> yeah, probably a good strategy
[12:07:04 EDT(-0400)] <athena> been thinking about adopting something similar
[12:07:05 EDT(-0400)] <colinclark> I'm sure there's still an old email in there from you that I need to respond to (tongue)
[12:07:09 EDT(-0400)] <athena> lol
[12:07:31 EDT(-0400)] <colinclark> So you were asking about the CCLA
[12:08:12 EDT(-0400)] <colinclark> It's on the same page... let me just dig up a link
[12:08:25 EDT(-0400)] <colinclark> athena: http://wiki.fluidproject.org/display/fluid/Fluid+Licensing
[12:08:34 EDT(-0400)] <athena> ah, thanks!
[12:08:39 EDT(-0400)] <colinclark> Iris did say that she got your CLA
[12:08:43 EDT(-0400)] <colinclark> But that we don't have one from Unicon
[12:08:47 EDT(-0400)] <colinclark> So if John Lewis is cool with it
[12:08:48 EDT(-0400)] <athena> no problem
[12:08:51 EDT(-0400)] <colinclark> thanks so much
[12:08:53 EDT(-0400)] <athena> yep, i talked to him last week
[12:08:54 EDT(-0400)] <athena> yep!
[12:34:31 EDT(-0400)] <kasper> justin_o: A question about testing
[12:34:42 EDT(-0400)] <Justin_o> kasper: sure
[12:35:01 EDT(-0400)] <kasper> justin_o: So at collectionspace, everybodys currently coding like mad, to implement as much as possible for 0.7 release
[12:35:36 EDT(-0400)] <Justin_o> kasper: okay
[12:35:40 EDT(-0400)] <kasper> justin_o: and since the three layers are not in sync it is close to impossible to keep a track of what is fully implemented, what is being implemented and what is untouched
[12:35:44 EDT(-0400)] <kasper> the question is:
[12:35:56 EDT(-0400)] <kasper> in implementation periods, how should one go about testing
[12:36:09 EDT(-0400)] <kasper> in one way it makes sense to test, as to find bugs as soon as possible
[12:36:30 EDT(-0400)] <kasper> on the other hand, it might be a wasted effort, since things can (does) change
[12:38:43 EDT(-0400)] <Justin_o> kasper: you will probably want to test as much as you can
[12:39:05 EDT(-0400)] <kasper> justin_o: ok
[12:39:16 EDT(-0400)] <Justin_o> kasper: is the daily build functional at the momeent
[12:39:59 EDT(-0400)] <kasper> more or less .. a bit out of sync i guess... The service/app is from this weekend and the UI is brand new
[12:40:16 EDT(-0400)] <kasper> justin_o: but it seems to work alright
[12:40:41 EDT(-0400)] <Justin_o> ah i see... when the daily build is pulling in up-to-date resources for all layers this type of situation will be much easier i would think...
[12:42:07 EDT(-0400)] <Justin_o> Also if the developers are up-to-date on their jiras... that is filing bugs for known issues and tasks for what they will be working on... then it should be easier to know if something is a bug that hasn't been filed and isn't something that isn't a feature that has yet to be implemented...
[12:42:29 EDT(-0400)] <Justin_o> did that make sense? not sure that it came out clear
[12:48:04 EDT(-0400)] <kasper> justin_o: yeah i think that makes sense.
[12:48:24 EDT(-0400)] <kasper> justin_o: still not quite sure how you would know what to test
[12:48:40 EDT(-0400)] <kasper> ... unless of course you look for completed tasks for v0.7 for example
[12:49:04 EDT(-0400)] <Justin_o> kasper: yes you could do that
[12:50:30 EDT(-0400)] <Justin_o> that's probably a good place to start... if you have extra time you'll probably just want to poke around and randomly test different parts to make sure that there were side effects from any of the completed tasks
[12:50:32 EDT(-0400)] <kasper> justin_o: cool, that's a good idea... Now to figure out whether the developers are actually using tasks
[12:51:12 EDT(-0400)] <Justin_o> kasper: good luck (smile)
[12:51:32 EDT(-0400)] <kasper> hehe thanks (smile)
[12:52:21 EDT(-0400)] <kasper> justin_o: btw, just had a chat with aron_ from our services team about using configuration files for the nightly build script... will link you the talk in private
[12:52:35 EDT(-0400)] <kasper> (as not to spam this channel)
[12:52:42 EDT(-0400)] <Justin_o> kasper: sure.. thanks
[12:55:41 EDT(-0400)] * EricDalquist (~apollo@adsl-99-135-74-102.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[12:55:57 EDT(-0400)] * EricDalquist (~apollo@adsl-99-135-74-102.dsl.mdsnwi.sbcglobal.net) has left #fluid-work
[12:56:17 EDT(-0400)] <kasper> justin_o: did the conversation make any sense?
[12:57:39 EDT(-0400)] <Justin_o> kasper: yep... a bit had to follow who was doing the talking, but i think i got the gist of the conversation down
[12:58:27 EDT(-0400)] <kasper> hehe yeah .. the essence was just the suggestion of having a single properties file that the scripts from all three layers uses
[12:58:33 EDT(-0400)] <Justin_o> kasper: it's interesting... so i was actually talking a bit with colin about using externals... in that case though for a pom.xml that would trigger child pom.xml files
[12:58:41 EDT(-0400)] <kasper> and since services team already has one of those, to use theirs
[12:59:21 EDT(-0400)] <Justin_o> kasper: i think the idea makes sense.. don't know enough to comment on the specifics... but it seems like a good idea not to have to keep writing the same info in several places... it would be hard to maintain in the long run
[12:59:44 EDT(-0400)] <kasper> Justin_o: yeah
[13:02:07 EDT(-0400)] <Justin_o> kasper: is the build.properties file only for their ant script or for the pom file as well?
[13:03:03 EDT(-0400)] <kasper> asking
[13:04:26 EDT(-0400)] <kasper> kasper: to my knowledge, yes, we reference properties found in services/trunk/build.properties in both our Ant buildfiles and Maven POMs. I'm certain of the former, and somewhat less sure of the latter .
[13:04:58 EDT(-0400)] <kasper> justin_o not the most convincing answer, but there you go ^ (smile)
[13:05:39 EDT(-0400)] <kasper> justin_o: by the way, that was a copy from my question in #collectionspace
[13:06:01 EDT(-0400)] <Justin_o> kasper: thanks
[13:07:31 EDT(-0400)] <Justin_o> kasper: if it ends up being that it is only useful for ant scripts, it may not be necessary to have a global build.properties file if the app and ui layers move away from ant
[13:08:12 EDT(-0400)] <kasper> justin_o: thats true
[13:11:10 EDT(-0400)] <kasper> justin_o: it's an ant file.. sorry for all the confusion
[13:16:06 EDT(-0400)] <Justin_o> kasper: okay... so it looks like pom files may also be able to reference external properties files. http://maven.apache.org/guides/getting-started/index.html#How_do_I_filter_resource_files
[13:16:13 EDT(-0400)] <Justin_o> so this may be something we will want to look at later
[13:17:14 EDT(-0400)] <Justin_o> i'm not sure if it only works with this filtering stuff or not though
[13:31:51 EDT(-0400)] <kasper> justin_o: It looks like we should be good as long as there is no ant-specific syntax in the properties file
[13:32:22 EDT(-0400)] <Justin_o> kasper: that' s good...
[13:42:13 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[14:10:06 EDT(-0400)] * jessm (~Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[14:49:26 EDT(-0400)] <jamon> jameswy: got a trim tool working i think
[14:49:54 EDT(-0400)] <jameswy> jamon: Cool! Using a different kernel?
[14:50:06 EDT(-0400)] <jamon> http://github.com/lgerbarg/hfs_trim
[14:50:15 EDT(-0400)] <jamon> it worked on an hfs image i created
[14:50:56 EDT(-0400)] <jamon> so if it doesn't compile in xcode running it from a live linux cd/usb periodically should work
[14:52:29 EDT(-0400)] <jameswy> Sweet.
[14:53:05 EDT(-0400)] <jamon> maybe a chance for me to build a sweet gui wrapper for you too (tongue)
[15:04:31 EDT(-0400)] * kasper (~kasper@201.144.87.46) has joined #fluid-work
[16:14:26 EDT(-0400)] * kasper (~kasper@189.130.67.157) has joined #fluid-work
[16:15:01 EDT(-0400)] <jamon> colinclark: got a second?
[16:15:58 EDT(-0400)] <colinclark> jamon: I'm on a call at the moment, so I have a distracted second if that is helpful. Otherwise I should be done in 45 minutes.
[16:16:14 EDT(-0400)] <jamon> k
[16:27:52 EDT(-0400)] * michelled (~michelled@142.150.154.101) has joined #fluid-work
[17:00:51 EDT(-0400)] * colinclark (~colin@142.150.154.101) has joined #fluid-work
[17:18:12 EDT(-0400)] * clown (~clown@142.150.154.101) has left #fluid-work
[17:38:38 EDT(-0400)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[21:33:23 EDT(-0400)] * yura (~yura@206-248-134-197.dsl.teksavvy.com) has joined #fluid-work