Skip to end of metadata
Go to start of metadata



Date and Time: Every Wednesday, 12:00-1:00pm ET / 11:00-12:00pm CT / 9:00-10:00am PT

  • Video Bridge 220488, Dial 812-856-7060 to connect via phone (conference number 220488#, See PolyCom Directory for connection info)
  • Xmeeting(Mac) :
  • Ekiga(Linux) :

Mailing List:


  1. Roll Call
  2. KULRICE-8775 - Data cannot be retrieved due to an unexpected error xapool patch version increase to 1.5.0-patch4 to move cleanup errors down from ERROR to INFO to allow avoiding of producing gigs of log files in minutes due to cleanup exceptions, while still being able to monitor the other ERROR level messages in the class. Also added logging of the exception message so we can get some information as to what the exceptions that are occurring are.
  3. Rice looking at git for 2.3 development; improve ability to review & accept contributions. 2.1.x and 2.2.x will stay on svn. Any impact?
  4. Maven plugins o' the week
    1. META-INF Maven Plugin - Automatically create a self-describing .jar file. Produces a file in META-INF containing a classpath: style listing of resources (sql, xml, properties etc) contained in the jar
    2. Spring Maven Plugin - Load a Spring context that is aware of the Maven project it is running in and uses Maven to manage its dependency tree
    3. The plugins themselves are not a huge deal, but they enable some nice patterns related to things like ingesting workflow files, consuming SQL files, or any other process where it is convenient to have the exact same set of resources/software as the application itself, available for use
  5. Recurring items:
    1. JDK7 testing updates - JIRAs
      1. KULRICE-7865 - Data cannot be retrieved due to an unexpected error JDK7 version of predic8 released today (Thanks, Peter!).




xapool cleanup errors

em - last week we heard that one of the exceptions in the cleanup section was blowing up the logs with lots of gigs. turned things down from error to info and added message of the exception. light, quick change of one line of code and with Jeff's assistance we're looking at bumping up the version number if the KTI approves. So we want to bump that version number up to patch 4.

ew - seems like it's more just information for the rest of the teams that this is out there. the final version is deployed not just a snapshot?

em - it's tagged and done the same way as the last.

jc - right it's not a snapshot it's the final version.

ew - it's been tested in rice without issue?

em - correct.

ew - so our recommendation is that the rest of the group should upgrade to this version.

g - we'll set it to info if we need to see about finding something. if we do find something we'll bring it back to the group

Git and Rice

jn - jeff and/or erik please let me know if I miss anything. we're looking at making a move to Git, one big reason is that it should ease the contribution process. farooq is looking for some projects to pilot this as well since it's becoming a very popular version control system. it is different than SVN in how it works. One difference is that everyone gets their own copy of the branch, trunk, whatever they are working on without impacting the remote repository. Then when they are ready they can push it back to the repo. There are a wider variety of workflows possible. Also in the way it managers the difference it should be easier to brach and merge them back in. Opens up a lot of different things with the remote repository, with SVN when the change is made it's in the main repo, if there are problems that breaks the build and anyone that grabs the updates has a broken build as well. So if it's hosted in GitHub, they also have some social networking aspects built into it, so those that want to contribute should have an easier time doing so, you do a fork, get your copy, make your changes, put them back out there and finally generate a pull request. The team can do a code review of that pull request and then bring it back in. This should allow for easier and more contribs. There are more features, but that's the few I have right now. Being that 2.3 is kicking off, it's a good time for us to look at this. Right now we still need to figure out quite a bit, the gaps between SVN and Git, etc. So we want to also gather any concerns the projects might have and such. We don't anticipate the MVN projects and dependencies shouldn't change so those that work that way should be able to work the same. KFS with their custom build and pulling of source code might need looking at as well.

jk - for KFS we use whatever version of rice the dev has on their workstation so there's no dependencies on rice for building our jars.

ew - we should get consensus from the kuali community that this is the long term direction, the TRC would be the place to start that talk. Git is better on branching than SVN, but SVN works. However GitHub is a wonderful platform and the community involvement are the big draws for it. Social coding, community, levering contribution, etc. having an effective way to do this. if we can find ways to help with that process to get things looped back in more quickly, easier, and effectively is worth the time.

jk - we do have a kuali foundation account. i worked with farooq on that last year. KFS has a private version out there right now. We did this with KFS 4.1.1 and did some forking and pull requests. So it's there and we can play with it, it is a payed account.

jn - thanks! I think Jeff is going to move forward with our original pilot.

jc - we have some things to chat about ahead of just diving in, the tooling has some good stuff out there. we just have to figure out how to get there from here.

ew - first step, talk to the TRC (I'll do that) and get a recommendation. Rice will pilot it with any other team that wants to join in. We also need to look at what levels of security other teams might have. We wouldn't force projects to move right away. Then work with Farooq and Jeff to see how we can move our repos over there. Move the 2.3 stuff and see how we can move history over.

jn - yeah the history is part of what Jeff is going to look at.

ew - ok, just need to get the appropriate blessings

s - only question I have, is what is the scope how can the rest of the projects follow along or keep up to date.

jn - there's not much of that right now since we just started talking about it last week (in ernest). but we'll setup pages to document our process, etc.

ew - the KTI would be kept up to date as things move. would anyone else on the KTI and TRC want to join in on our efforts.

b - isn't there a TRC Git working group?

ew - oh, i'll check into that and see what they have. maybe they have the work done…oh, they haven't met quite yet (from Jessica)

Maven plugins o the week

jc - there are a couple of plugins that have been released recently. there are two listed Meta and Spring. Meta embeds meta info in the jar file automagically. Spring allow you to load spring contexts that are maven aware. The thing that's nice is that it does things in a way that's not project specific so you can just include self-contained things that don't require the full blown application to invoke the functionality.

ew - so why did we develop these?

jc - the two in use right now; student is redoing their db process and i've been working with them on that. where they're going with that is bundling the sql that defines how you get the KS database created or recreated and they are using these plugins. the other is with workflow ingestion so that these files can be ingested from the jars.

ew - i wonder if we could get someone from KS to come talk about this, the second example with workflow is interesting.

jn - yeah i could see that being useful in other areas.

jc - i've been mostly working with Andy, but I know Larry has been involved. I'll ask Larry to share with us what they are doing, I'll ping him on that.

ew - any other questions?

JDK updates

em - thanks to Corey for fixing some bugs and Peter, we currently have 0 issues that we're aware of. We are at a point that we'd like to see what the other teams have.

ew - which versions are working with it then?

em - 2.1.3 and 2.2.1 and up.

ew - has documentation been updated to say we recommend JDK7 as of x?

p - I don't think we are comfortable saying that yet since we want more input from the rest of the teams

jn - right, unless the projects test it out.

em - at the last KTI there were 1 or 2 teams that were going to start testing soon.

g - from KC we want to but haven't had time yet. we plan to start soon.

b - on KFS we're wrapping up 5.0.1 and are targeting 5.0.2 for JDK7

s - my understanding is that KS, there is still an issue, but with our latest version we're ready to run JDK7 possibly. I'll follow-up with KS and Larry as well. I'll bring up the plug-in thing for Jeff at the same time.

jh - we'l probably try in the next 3 weeks or so.

ew - cool, so it sounds like everyone at least has a plan.

other topics

ew -walk-ons?

Open KULRICE JIRAs Marked for KTI Review

key summary assignee reporter fixVersion priority created updated Received fatal alert: handshake_failure

View these issues in JIRA
  • No labels