[ANN] LiquiBase 2.0 Beta 2 Available

General Discussion
1

LiquiBase 2.0 beta 2 is now available.  You can download it from http://www.liquibase.org/liquibase-2.0.b2.zip and http://www.liquibase.org/liquibase-2.0.b2-src.zip. 

There is still no new major functionality, but lots of reorganized code and a plugin-framework that works with the command line.

Let us know if you have any issues with it

Nathan

2

Hi Nathan,
    This is great news, however would it be too much trouble to publish the same version of liquibase-plugin as well?  I’m running into issues building/running this project in the current trunk and would like to see if the same issues exist in your version.

-Ryan

3

The maven plugin you mean?  I can do that, although I will probably just set it up as a 2.0 snapshot so people don’t accidentally get upgraded to 2.0.  Is there a better maven way to handle that?

Nathan

4

As I’m still not quite sure how you guys release the maven project I can’t offer any advice on how to put out a snapshot of the plugin. I assumed the artifact got created when running the “all” ant task but I’m seeing this is not the case.  I’ve resorted to running “all” then importing the newly created POM into IntelliJ as a Maven project as the classpaths are incorrect in trunk when building as a whole.  I’ll see what I can figure out for this.

Thanks, man.

5

After you have done an “ant all” there are “ant maven” and “ant maven-snapshot” targets that build the maven repositories in liquibase/maven-repository and liquibase/maven-repository-snapshot.  I just committed a few fixes to the ant script that makes that work correctly again.

What classpaths are you seeing wrong in trunk?  I also re-committed my intellij project files so that may help too.

I uploaded a 2.0.b2.0-SNAPSHOT to our old sourceforge server and it should sync up with the main maven repo soon.

Nathan

6

Ok, great… I’ll do an update and get back to you on the classpath issue in hopes that your new project files remedy the problems I was seeing. Also, thanks for putting out a snapshot of the plugin… I will test it and get back to you on my results of that as well!

7

Nathan:
   I’ve done an update and here’s what I’m experiencing with IntelliJ using your newly updated project files:

The following element gets modified when opened with IntelliJ unless my working copy path matches yours…
This could lead to accidental commits of the file as it shows as modified through SVN status.  This is a good reason not to have to maintain IDE specific project files, IMO.  Using maven, devs could simply do a mvn idea:idea and have them generated for them.

   

Modified as well, since I have jdk1.5.0_19

   

ANT build.xml references a hard-coded path:

src.dir property does not exist.

also references non-existent properties file:
build.local.properties doesn’t exist.

lib.compile.dir property does not exist…
this should be changed to jvm.lib.compile.dir mentioned in build.properties.
(Committed fix to trunk)

Following jars are committed but get generated in the build which show as modified. 
These should be removed from SVN as they are created by doing a build, IMO.
/core-jvm/lib-test/liquibase-sample1.jar
/core-jvm/lib-test/liquibase-sample2.jar

Running an “ant all” produces the following output (truncated for obvious reasons):
warnings:
\core-jvm\src\java-test\liquibase\changelog\filter\ContextChangeSetFilterTest.java (22:68)
non-varargs call of varargs method with inexact argument type for last parameter;
\core-jvm\src\java-test\liquibase\changelog\filter\ContextChangeSetFilterTest.java:22:
warning: non-varargs call of varargs method with inexact argument type for last parameter;
cast to java.lang.String for a varargs call
cast to java.lang.String[] for a non-varargs call and to suppress this warning

Errors during Compilation Javadoc: (Hibernate, and others it to the classpath):
/core-jvm/src/java/liquibase/database/core/HibernateDatabase.java:16: package org.hibernate.cfg does not exist
(Committed fix to trunk)

Hope this helps.  I’ll try out the snapshot shortly… Thanks for working w/ me on this!!!

8

I made a few changes based on your suggestions:

  • I looked at the .ipr file directly and removed a reference to the old grails project
  • The fact that it includes the path on my machine seems to be a bug in intellij (http://www.jetbrains.net/jira/browse/IDEADEV-38112)
  • I pulled out the env variable from the ant properties.  It should be managed within the script itself.
  • I moved the ikvm path to a property in build.properties
  • I fixed the src.dir property reference
  • The reason there is the build.local.properties file is so individual developers can override the standard values in a file that will not be checked into svn.  So if you want a different ikvm.home or java.home etc. you can specify it in the build.local.properties file
  • I made the build-sample-jars ant target stand-alone and not ran on package
  • I fixed the compiler warnings

As a side note, I am going to be on vacation next week, so if I suddenly stop responding to messages that is why.

Nathan