Hi Nathan,
Would the TRY-M2 branch happen to be a proof-of-concept branch that the migration to M2 would be taking place in? If so, I would love to contribute to this effort as all of my projects are being built with M2 these days. Let me know if you would like some help in this arena as I have some time to contribute.
Thanks!
-Ryan
The try-m2 branch was some very very old code. I deleted the branch so it is not confusing. I am also still not convinced that we need to convert our build process from Ant to Maven. We don’t really have any dependencies that it would help track, and the ant script is already done and working. The try-m2 branch was created by someone that was going to try to convince me otherwise, but they never made it very far in the conversion.
Currently the only active branches are trunk for 2.0 and /branches/1.9 for ongoing maintenance of 1.9.
Nathan
I has some issues using the current ant scripts because they seemed to depend on IntelliJ and the folder structure did not seem to fit when running ant. When done correctly Maven is a great build tool, I find it much easier compared to Ant. All recent projects I did used (or now use) Maven because the ease it brings to building the software. Another plus is IDEs supporting Maven (like NetBeans).
Thanks for the info, Nathan and as always the speedy response. Just to play devil’s advocate, in reaction to your statement in regards to the lack of project dependencies in LB I’m seeing many jars in the project that appear to be dependencies that really could be removed from SVN should a Maven2 migration take place. Below is the list of jars I’ve found that would no longer need to be a part of every checkout of LB. Arguably, since developers working on the Liquibase project are not making changes to these 3rd-party libs, they really don’t belong in SVN as they need not be versioned. They are already released versions of libs that currently must be checked out w/ the project which means if you checkout trunk and a branch, you then have a copy of all of these dependencies in both of the working copies vs having the classpath reference the one copy of each dependency from a local repo. I’m not writing this to sell you on the idea but merely to give you more information to aid in your ultimate decision.
In regards to the ANT build file, I too have had some minimal troubles with this which I was able to remedy fairly quickly. However, I’m still not getting the requirement of having a JDK 1.5 installed as the build will fail even with a 1.6 set with a language level of 1.5. As all the maven-based projects I work on set the compiler source and target levels to 1.5, having a 1.6 JDK still works out just fine.
In response to chris, I would have to agree that using Maven removes the need for checking in IDE specific project files as well. Using the Eclipse project files, I noticed that there was a hard-coded path to a grails directory pointing at C:\somethingOrOther. This certainly does not work out on systems that a) do not have the resource installed to the mentioned path b) on *nix-based systems.
On an unrelated note, I’m getting many test failures when running the test target… I’m not sure if this has to do w/ the current 2.0 migration status or a problem with my project setup as I have yet to investigate… I just thought I should mention it while I was on the topic of building LB. 
Keep up the great work, Nathan! I know that everyone involved in the Liquibase Community really appreciates the LB project and your committment to supporting the community!
Best Regards,
-Ryan
/core/lib:
324,238 cglib-nodep-2.1_3.jar
62,696 easymock-2.2.jar
15,887 easymockclassextension-2.2.jar
112,249 junit-4.1.jar
/core/lib-compile:
18,665 ant-ikvmc.0.5.jar
428,218 emma.jar
38,232 emma_ant.jar
/core/lib-sources:
75,704 junit-4.1-src.jar
/core-jvm/lib:
324,238 cglib-nodep-2.1_3.jar
62,696 easymock-2.2.jar
15,887 easymockclassextension-2.2.jar
112,249 junit-4.1.jar
/core-jvm/lib-compile:
1,034,049 ant-1.6.5.jar
175,426 commons-collections-2.1.1.jar
38,015 commons-logging-1.0.4.jar
26,202 commons-logging-api-1.0.4.jar
313,898 dom4j-1.6.1.jar
52,847 ejb3-persistence-3.3.1.jar
280,196 hibernate-annotations-3.3.1.jar
66,426 hibernate-commons-annotations-3.3.1.jar
2,274,768 hibernate3-3.2.6.jar
57,993 jsdk-2.4.jar
960,232 maven-ant-tasks-2.0.7.jar
2,694,014 spring-2.0.6.jar
11,236 spring-aspects-2.0.6.jar
104,178 spring-mock-2.0.6.jar
/core-jvm/lib-jdbc/cache-2007.1:
1,961,463 CacheDB-2007.1.jar
/core-jvm/lib-jdbc/db2-9:
2,011,601 db2jcc.jar
1,015 db2jcc_license_cu.jar
/core-jvm/lib-jdbc/derby-10.3
2,338,649 derby-10.3.1.4.jar
/core-jvm/lib-jdbc/firebird-2
648,080 jaybird-full-2.1.1.jar
/core-jvm/lib-jdbc/h2-1.0:
1,065,550 h2-2007-07-12.jar
/core-jvm\lib-jdbc/hsqldb-1.8:
643,806 hsqldb-1.8.0.7.jar
/core-jvm/lib-jdbc/informix-11.50:
723,241 ifxjdbc-3.50.JC3.jar
/core-jvm/lib-jdbc/jtds-1.2:
285,638 jtds-1.2.jar
/core-jvm/lib-jdbc/maxdb-7.6:
489,216 sapdbc-7_6_00_30_5567.jar
/core-jvm/lib-jdbc/mssql-2005-1.0:
231,949 sqljdbc-2005-1.0.jar
/core-jvm/lib-jdbc/mysql-5.0.4:
495,944 mysql-connector-java-5.0.4-bin.jar
/core-jvm/lib-jdbc/oracle-10.2:
1,536,554 ojdbc14-10.2.0.1.0.jar
/core-jvm/lib-jdbc/postgres-8.2:
427,780 postgresql-8.2-505.jdbc3.jar
/core-jvm/lib-jdbc/sqlite-3.5.8:
58,448 sqlite.jar
/core-jvm/lib-jdbc/sybase-15:
456,674 jconn3-6.0.jar
136,076 jTDS3-6.0.jar
/core-jvm/lib-test:
1,822 liquibase-sample1.jar
1,337 liquibase-sample2.jar
/maven/lib:
1,438,405 maven-core-2.0.7-uber.jar
By the way my 2 cents:
In SVN there are Eclipse files (.project and .classpath) in core directory but they are broken - points to non-existient jars.
In core-jvm directory there is no Eclipse files, but they should (or core should compile sources from core-jvm).
Also I suggest to move samples from core-jvm to separate project.
Even if you don’t want to use maven, you should consider to use standard maven directory layout - it’s familiar for many users.
And please move unpacked ide-src.zip to another repo (or branch) - it’s another 11MB to download.
Also there is a problem with subversion access - I cannot update CORE/trunk/core - subversion requests username/password (TortoiseSVN 1.6.3) and when cancelled there is error:
OPTIONS of 'http://liquibase.jira.com/svn': authorization failed: Could not authenticate to server: rejected Basic challenge (http://liquibase.jira.com)
It’s strange because update on CORE/trunk/core-jvm works fine…
I do know that the eclipse setup is broken currently. I just committed a fix for the eclipse setup, although I’m not quite sure what to do about the maven project setup. It is complaining about not finding the maven libraries. I did install M2Eclipse, but I’m not sure what else I have to do.
You are right that we should minimize the required download from SVN. I removed the ide-src.zip file to help.
I’ll take a look at why core-jvm is asking for authenticaiton. It shouldn’t. I didn’t do anything different creating it. If you do a svn update does it come down? Maybe there was a weird network hiccup.
The reason we have the 1.5 requirement in ant is to ensure that when using ant to do a build (really only done at release time) you are actually using a 1.5 compiler. You can set 1.6 to use 1.5 bytecode, but it won’t catch usage of 1.6-only APIs. You should be able to use the internal eclipse compiler to do most liquibase development and it will compile with a 1.6 compiler just fine.
The grails project reference should be gone as well now too.
There are a bunch of tests failing currently in trunk for 2.0. It isn’t necessarily a problem with your install, is just under construction code 
My biggest concern with maven is keeping the bar to entry for compiling liquibase and submitting patches as low as possible. At least to me, Ant seems more straightforward and common. I’m open to convincing that maven is going to make it easier.
Nathan
What I find most attractive to Maven is how you define what the build result must be instead of defining the build process. Ant files are just a Makefile in XML in which you need to define the build order, the target dependencies, the compile command, the jar command, the test commands etc. With Maven you just need to tell the result must be and JAR file and what the dependencies are. This is slightly simplified but should given an idea how easy it is.
offtopic:
Currently I know two IDE’s which support Maven; Eclipse and NetBeans. Eclipse uses the M2Eclipse plugin which plugs into Eclipses build mechanism and provides a different CLASSPATH to Eclipse based on the task executed. I had the impression the CLASSPATH presented by M2Eclipse was not always the CLASSPATH you expected (and was different to the mvn cmdline tool) which caused some projects not to run. Also, the M2Eclipse plugin tries to do project references in eclipse to other projects in a module pom file but this messes up the CLASSPATH even more. It feels like M2Eclipse is just another Maven implementation which does not the same as you would expect form the ‘real’ maven.
NetBeans just uses the cmdline mvn (which is bundled btw) to execute the various build steps. At first this seems somewhat cheap and ‘oh, they did take the easy solution’ but after two days I had almost no complaints at all.
Chris
Originally posted by: chris
What I find most attractive to Maven is how you define what the build result must be instead of defining the build process. Ant files are just a Makefile in XML in which you need to define the build order, the target dependencies, the compile command, the jar command, the test commands etc. With Maven you just need to tell the result must be and JAR file and what the dependencies are. This is slightly simplified but should given an idea how easy it is.
I have to agree with you on this, Chris. IMO, the build lifecycle[1] common to all standard projects is one of the things that Maven2 just got right. Not needing to explicitly tell ANT what directory to delete when doing a “clean”, not having to tell ANT how to construct your classpath from your dependencies, not having to include dependencies in your project source tree, not having to tell ANT how to compile your Classes and Test Classes and into what directory, etc. are all reasons I am a HUGE fan of the Maven2 build lifecycle. Typically, you need to create/modify build.xml files for each and every project and I find that they can get mighty complex fairly quickly in multi-project builds.
Another plus is the “convention over configuration” ideology that Maven2 adopts that Chris hit on in his earlier post. When a developer is aware that a project is being built with Maven2, they come to expect the project to be laid out in a standard, familiar way making it unneccessary for them to try and figure out, through a build.xml file where certain things live and how they relate to each other and what their purpose may be. This usually is fairly straight-forward (at least on the projects I’ve worked on). I could sing many praises of a Maven2 build so if there are other more specific concerns you may I have, I would be more than happy to discuss them.
[1]http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference
Originally posted by: chris
offtopic: Currently I know two IDE's which support Maven; Eclipse and NetBeans. Eclipse uses the M2Eclipse plugin which plugs into Eclipses build mechanism and provides a different CLASSPATH to Eclipse based on the task executed. I had the impression the CLASSPATH presented by M2Eclipse was not always the CLASSPATH you expected (and was different to the mvn cmdline tool) which caused some projects not to run. Also, the M2Eclipse plugin tries to do project references in eclipse to other projects in a module pom file but this messes up the CLASSPATH even more. It feels like M2Eclipse is just another Maven implementation which does not the same as you would expect form the 'real' maven.NetBeans just uses the cmdline mvn (which is bundled btw) to execute the various build steps. At first this seems somewhat cheap and ‘oh, they did take the easy solution’ but after two days I had almost no complaints at all.
Chris, I too have had some issues with Eclipse and the M2Eclipse plugin but it always came down to configuration of the M2Eclipse plugin… For example, the resolving artifacts from the workspace issue you mentioned is resolved by unchecking the “Resolve Artifacts From Workspace” checkbox in the Run Configuration. In terms of Classpath issues I have found the M2Eclipse Embedded maven not to work as expected so I now configure the Run Config to use my Maven installation… I actually prefer this as it means that all of my builds, whether from the cmd line, IntelliJ IDEA, or in Eclipse are all performed using the same install of Maven.
Nathan:
I have attached a demo multi-module Maven project consisting of a domain model and an uber-jar that depends on that model. When you run mvn verify you will end up with 3 jars… 1 for the model, 1 for the uber-jar, and one that IS the uber-jar which also contains the model. Please take a look and compare what it would take to do the same in ANT. I have a feeling you will agree that it is MUCH easier to get going and building using this project than it would be to have a non-standard layout that you need to familiarize yourself with and figure out what target to run, etc. Okay… that’s enough from me for the moment. I hope this makes my case 
Originally posted by: NathanHave you considered getting a Bamboo instance for automated Continuous Integration?
There are a bunch of tests failing currently in trunk for 2.0. It isn't necessarily a problem with your install, is just under construction code :)
Originally posted by: rynam0
Have you considered getting a Bamboo instance for automated Continuous Integration?
I would like to get one going, but I do not have a publicly available server that would work for it. The website is hosted on a shared godaddy server and the issue tracker is on the hosted version of jira. They do not appear to support a hosted bamboo server from atlassian.
Does anyone know of a (preferably freely-available) continuous integration server service?
Nathan
You do make good points about simplifying builds by describing what you want vs. telling ant everything.
Like I said, my sticking with ant is primarily that i know it. I also like the control that it gives me to do whatever I want in the build process, even if it doesn’t follow a standard setup or lifecycle. It would be nice to cut down the 600+ line ant script, however. Also things like sonar would be nice to have.
I’ll take a look at the multi-module example and what it would take to convert over the codebase when I get back from vacation (next weekend). I’m not promising anything because because my main goal is to get 2.0 out by the end of august, but during the conversion to 2.0 would be a good time to do it.
Nathan
Sounds good, Nathan. Hope you’re enjoying your week off. As I too was off this week, I took some of my spare time and mocked up what the current build might look like in a multi-module maven project. It currently only deals with core, core-jvm, and the maven plugin. It also creates the distribution archives in the liquibase-dist module. As I was uncertain what the intention of the samples was at this point (two classes get compiled and jarred yet all other java sources are left as source), I have left these out of the current example. Also, I have not delved into the core-clr module at this point.
There is one prerequisite that maven version 2.1.0-M1 or greater must be used to build it. (I’m currently on 2.2.0)
To run the example simply import to your favorite IDE and run a clean verify. This will build all of the modules in the example and produce the distribution archives. Since tests are failing you may have to run ‘mvn -DskipTests=true clean verify’ as by default failing tests will fail the build.
Hope you enjoy the example.
-Ryan
Ok, so the zip is too large to attach to the forum… I’ve created a JIRA for you to get the example from as a workaround to the forum’s attachment size limitation. http://liquibase.jira.com/browse/CORE-430
Thanks, I’ll take a look. The sample jars shouldn’t need to be build on every build, they are there to show how to create extensions and are used in the integration tests to make sure the extension system works correctly.
The core-clr module isn’t something that needs to be built with maven, it will probaly be build with msbuild or similar. We would need maven to run ikvmc to create the liquibase-core.dll library, however, for the core-clr project to use.
Nathan
If I am allowed to chirp in here… 
@Ryan: Nice work with the maven example.
@Nathan: You could always still use the maven-ant-tasks plugin if there is something that you REALLY need to do in an Ant script. The other reason that I would like to throw my weight behind using maven is that you can EASILY create (and keep up to date) an OSGi’fied version of liquibase by keeping the manifest creation up to date inside of the maven POM. This is all very much simplified by using the maven-bundle-plugin. I, for one, would love to have out-of-the-box OSGi bundles of liquibase.
Regarding the CI. It would be really AWESOME to have access to a Bamboo instance with the Jiraversions plugin installed. That way you can automatically pass(pull) version numbers for the project from Jira and pass them into the POM. You do know that Atlassian grants you a free opensource license if you are using their products for Open Source development, right?
Or you could look at using an Amazon EC2 server and host bamboo there? Just thoughts.
—Jaco
The osgi option was one thing I was thinking would be nice about maven too. Makes it harder to back-port osgi support to 1.9 though
There are lots of free options for CI software, the trouble is having a publicly-available server to host it. Amazon would be a couple hundred $US a month from what I can tell, even a godaddy virtual private server would run ~$30/month which is $30/month more than I have to spend :)
I’ll keep looking into CI options, though. It is something I would like to get going.
Nathan
Ok, I made the leap and converted svn to use maven. The template you sent, rynam0, was a huge help, thanks a lot.
My final rational was that it was a good excuse for me to learn maven better :)
I did convert the intellij and eclipse projects to be maven projects as well.
Just to let you know, though, I may hit you guys up for questions on maven usage as I go along. Also, if you see ways we can and/or should improve our configuration be sure to let me know.
Nathan
Very cool, Nathan! I just checked out the trunk and was able to import and build it with no issues whatsoever. It’s wonderful. Everything came down much quicker this time around too. Didnt matter whether I was on my mac or my windows machine… it just worked ;) The ant build had an exec that pointed to ‘cmd’ which didn’t work on osx so i had to change the exec to ‘mvn’ to build the maven target.
Please feel free to contact me anytime with maven questions as I would love to help out in any way I can. Should you need/want someone to work on anything in particular, please don’t be shy. I think this project has a great deal of potential and would like to see it become all it can be! Keep up the great work and I’m looking forward to the upcoming online meetup.
-Ryan
Yay!
Nathan, I can pretty much guarantee that you will soon convert all your projects to maven.
Thanks for taking this step, I am confident that you will not regret it.
Feel free to ask about anything maven related if you get stuck.
—Jaco
My first question would be how to handle the OSGI manifest.mf info correctly. Any suggestions?
Nathan
Nathan
If you are pondering going to Maven dependency mgmt, try looking at Apache’s Ivy. Much less restrictive and great dependency management. I love it for taking care of third party jars from a central repo. My company was able to get Ivy going much faster than a Maven implementation. Those people that know maven should be able to understand Ivy.
you old build guy…
Bryce
