Transcript:
(12:11:53) damian_g: Halo, Damian Golda here 
(12:11:55) Nathan_Voxland: Not many people, but does anyone have any questions or anything they want to talk about?
(12:12:06) Nathan_Voxland: hi damian.
(12:12:47) damian_g: I’m trying to fix tests and I see that there are many cyclic dependencies between liquibase modules
(12:13:11) damian_g: for example liquibase-core use data files from other modules
(12:13:31) damian_g: LoadDataTest AFAIR
(12:14:00) damian_g: I think, that such test should be moved to other modules
(12:14:14) BryceJohnson: howdy
(12:14:20) Nathan_Voxland: yeah, I’m trying to figure out the best way to be structuring them, and transition them from an older layout
(12:15:23) damian_g: And all tests connecting to databases should be moved to lq-integration-tests
(12:15:24) Nathan_Voxland: I think LoadDataTest should exist in core to get test coverage, probably the required files for loadDataChange should be moved to liquibase-core
(12:15:42) BryceJohnson: just interested in hearing any news. we are almost done implementing liquibase into our app
(12:15:47) damian_g: Yes, thats another solution
(12:15:57) Nathan_Voxland: yes, all the database tests dhould be in integration-tests. Are there still some in core or core-jvm?
(12:16:24) Nathan_Voxland: Hi bryce, nice to see you again. good to hear you’re spreading the liquibase
(12:16:31) damian_g: yes, a lot of them but all have totally commented body
(12:17:33) Nathan_Voxland: there is a lot of that. I was hoping to move them, but the code refactorign for 2.0 has been major enough that the tests are not auto-converting well. The plan is to move them to the integration-tests module but they haven’t gotten there yet.
(12:17:46) Nathan_Voxland: lots to do :) Thanks for the help you’ve done so far, btw
(12:18:23) damian_g: welcome, my pleasure
(12:19:57) Nathan_Voxland: besides the test probablems, do you have any other thoughts or opinions on the new maven-based project layout?
(12:20:27) Nathan_Voxland: hi winther
(12:21:08) damian_g: I think, that samples (1,2 and 3) should be build before liquibase-intergation-tests
(12:21:08) BryceJohnson: winther is the dba that i work with natahn
(12:21:08) winther: hello
(12:21:37) winther: working with Bryce just lurking
(12:21:44) Nathan_Voxland: hi
(12:22:11) damian_g: now sample 1 and 2 are as JARs in core, and sample3 is not build at all
(12:22:48) Nathan_Voxland: I was wondering if it was even best to break out sample1 and sample2 as separate modules
(12:23:04) Nathan_Voxland: and have them all built before integration
(12:23:17) Nathan_Voxland: do you know if there is a maven standard for that type of thing?
(12:23:51) BryceJohnson: <-- uses ivy
(12:24:23) damian_g: we can simply put sample1,sample2 and sample3 under samples
(12:24:25) BryceJohnson: i was pleased to see the liquibase jar in the public repository
(12:26:14) Nathan_Voxland: just a general samples module? I did want to end up generating multiple sample jars to test pulling extensions from multiple locations
(12:26:23) Nathan_Voxland: liqubase is in the ivy repository? That is good
(12:26:42) BryceJohnson: ivy uses the maven public repos
(12:26:59) Nathan_Voxland: I thought about ivy on the existing ant scripts, but in the end decided it was a good chance to finally learn maven
(12:27:24) BryceJohnson: yeah true…we did ivy so to have as little impact possible with existing stuff…it works great
(12:27:26) BryceJohnson: simple
(12:27:49) damian_g: What about Continuus Integration? I’d like to see Bamboo…
(12:28:31) Nathan_Voxland: it may make the most sense to create two sample modules and put all sample extensions we want in those. And name them better than Sample1,2,3 etc.
(12:28:59) Nathan_Voxland: Then we don’t have an explosion of modules but can still test multiple jars containing extensions
(12:29:21) Nathan_Voxland: I’d like to see CI too. The only thing stopping me so far is finding somewhere to run it.
(12:29:29) damian_g: Could be. Everything is better than JARs in src/test/resources/ext
(12:29:56) BryceJohnson: bamboo…teamcity…cruisecontrol are all great
(12:30:07) Nathan_Voxland: true. I don’t like the jars there currently, they are mainly there for historical reasons so far.
(12:30:19) Nathan_Voxland: We are using teamcity here and it works well too.
(12:30:24) damian_g: Have you asked guys from ops4j.org to “rent” their Bamboo?
(12:30:47) Nathan_Voxland: Most CI apps have a “sample repository” of OS apps, but I’m not sure how well they are maintained or managed
(12:31:00) damian_g: Of course, teamcity is great. Anything could be.
(12:31:57) Nathan_Voxland: I looked at ops4j, but didn’t ask them. My guess was that they just do their projects
(12:32:14) Nathan_Voxland: There is http://opensource.bamboo.atlassian.com/
(12:32:26) Nathan_Voxland: for example
(12:32:44) Nathan_Voxland: but not sure how official it is.
(12:33:16) Nathan_Voxland: I have an old computer I was thinking I could push into service as a CI server, but I don’t have anywhere to host it with a static IP
(12:34:54) Nathan_Voxland: I do’nt thin sourceforge has a CI server available
(12:35:04) BryceJohnson: would amazon cloud computing work for something like that? i havent used that service yet though
(12:35:24) Nathan_Voxland: It would, but it would cost ~$200/mo
(12:35:39) BryceJohnson: ish
(12:36:42) Nathan_Voxland: have any of you tried creating extensions yet?
(12:37:11) Nathan_Voxland: or looked at the API in general?
(12:37:20) BryceJohnson: nope
(12:37:30) damian_g: I have a group of students, they create extension
(12:38:04) BryceJohnson: i might look at a postgres sql to liquibase sql parser
(12:38:11) damian_g: Main issue is ability to define nested elements in XML.
(12:38:13) BryceJohnson: but that’s probably above my talents
(12:39:13) BryceJohnson: .
(12:39:15) Nathan_Voxland: yeah, sorry I haven’t gotten beta3 out yet. Been overly busy at work and also am making a large refactoring to they database<->java type management interfaces
(12:40:25) Nathan_Voxland: SQL parsers are tough. From what I remember, http://code.google.com/p/garindriver/ has some SQL parsing logic in it, but just around commenting and splitting statements
(12:41:02) damian_g: They want to “publish” code and documentation. Nathan, could you give them some space at liquibase.jira.com?
(12:41:40) damian_g: Or should they use Google Code…
(12:41:53) Nathan_Voxland: for extensions? There is the extension portal at http://liquibase.jira.com/wiki/display/CONTRIB/LiquiBase+Extensions+Portal
(12:42:19) Nathan_Voxland: there is a separate “extension” project where they can use SVN, confluence, and jira as needed.
(12:42:42) damian_g: OK. that’s great
(12:43:30) Nathan_Voxland: looking at CI stuff as I’m waiting for chat messages to go through, would you guys see value if the CI server was not public, but published snapshots up to a public server?
(12:44:21) BryceJohnson: im more on the user/production side of things so right now im N/A
(12:44:32) damian_g: Mail notifications are important
(12:45:06) damian_g: Or IM messages (jabber)
(12:45:23) Nathan_Voxland: mail notifications for when someone commits something that breaks the build and/or fails tests? yes
(12:45:50) Nathan_Voxland: and seeing current test coverage etc. helps too
(12:46:06) damian_g: exactly
(12:46:54) Nathan_Voxland: I wonder if I could host jsut the reporting app on our server and have non-public remote build agents push results up…
(12:46:57) Nathan_Voxland: anyone ever try that?
(12:48:34) BryceJohnson: nope
(12:49:02) Nathan_Voxland: may be worth looking into
(12:49:49) Nathan_Voxland: more questions or comments from anyone?
(12:50:08) damian_g: maybe public visible http proxy to private CI server?
(12:51:51) Nathan_Voxland: but if there isn’t a public IP to the CI server, I dont’ think we can even proxy it
(12:52:35) Nathan_Voxland: I’ll look into the private build agents otpion. that seems the most possible
(12:54:08) Nathan_Voxland: do any of you have any more suggestions on how we could improve liquibase? What in particular would help you out the most?
(12:54:12) BryceJohnson: do you know how many people are using liquibase?
(12:55:31) BryceJohnson: i think getting things setup was a lot of by hand with creating the schema
(12:55:50) BryceJohnson: getting everything in liquibase format
(12:55:54) Nathan_Voxland: Unfortunately no. Traffic wise, there are about 500 unique visitors per day to the site
(12:56:47) BryceJohnson: it’s still a unique tool from what i can see
(12:57:04) Nathan_Voxland: it is definitly designed around hand management of the changesets. There are some tools like generateChangeLog to help, but they are mainly designed to be tools, not relied on
(12:57:05) BryceJohnson: im glad it took off…i knew when you first built it that it was a great idea
(12:57:35) BryceJohnson: Matthew Winther says:
would be cool if it would transverse all schemas in a postgres database
for the build changelog option
(12:57:36) Nathan_Voxland: thanks. There are a few similar products, but nothing as good for sure
(12:58:35) winther: exactly what i would have said
(12:58:52) damian_g: lat month we’ve performed rolling upgrade on running system using liquibase. full success, no breaks
(12:58:59) Nathan_Voxland: My current plan is to have 2.0 released mid-sept at the latest, even if it means pushign new features off to 2.1. Any thoughts on that strategy?
(12:59:11) Nathan_Voxland: glad to hear it
(12:59:12) BryceJohnson: awesome damian
(12:59:18) BryceJohnson: any migration issues to the new release?
(12:59:49) Nathan_Voxland: I don’t like to have a long time between releases, especially with a major-change like 2.0. But I don’t want to rush it either.
(13:00:03) Nathan_Voxland: The goal is to not have any migration issues for 2.0.
(13:00:13) BryceJohnson: ill have to look at the release notes
(13:01:02) Nathan_Voxland: THere is a new checksum generation method, so if it detects that you have the old checksum versions int he databasechagnelog table it will clear them out first, so there may be caess where you have runOnChange=“true” and make changes that they won’t actually run.
(13:01:11) Nathan_Voxland: I’ll have to make the release notes, then
(13:01:34) damian_g: today i’ve found that liquibase column i databasechangelog table is too small
(13:01:52) damian_g: it has 10 chars but ‘2.0-SNAPSHOT’ is longer
(13:02:05) damian_g: so maybe column should be altered
(13:02:09) Nathan_Voxland: true. I’ll have to increase that.
(13:02:52) damian_g: and it should be performed after first run of 2.0
(13:02:54) Nathan_Voxland: The trouble is that there are some databases (sybase, db2?) that have limits on the amount of data per row
(13:03:25) Nathan_Voxland: I may need to have the version logic abbreviate “snapshot” to “snap” or something
(13:03:37) damian_g: exactly
(13:03:42) Nathan_Voxland: or “-S”
(13:04:29) Nathan_Voxland: unfortuantely I have to run to a meeting now, thanks for coming everyone. I’m trying to schedule these every 2 months or so, hopefully more people come next time. Last time had more.
(13:04:44) Nathan_Voxland: perhaps too frequent? perhaps just a bad time
(13:05:17) Nathan_Voxland: make sure you send any questions or comments you have through the forum, or you can email me at nathan [at] voxland.net
(13:05:37) damian_g: time is OK (I have 7 P.M.), it’s not too frequent
(13:05:56) BryceJohnson: lunchtime :) will do
(13:06:14) BryceJohnson: good to know sept. date if we go from 1.9.4 to 2.x
(13:06:29) BryceJohnson: we will have to look at that
(13:07:50) Nathan_Voxland: if you could test out beta3 when it comes out and send me feedback, that would help too.
(13:07:57) Nathan_Voxland: thanks again for coming. I’ll try to schedule one again in october
(13:08:20) BryceJohnson: waves thanks again…great app
(13:08:41) damian_g: thanks,bye
