Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.liquibase -DartifactId=liquibase-core -Dversion=2.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.liquibase -DartifactId=liquibase-core -Dversion=2.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.liquibase:liquibase-core-jvm:jar:2.0-SNAPSHOT
2) org.liquibase:liquibase-core:test-jar:tests:2.0-SNAPSHOT
1 required artifact is missing.
for artifact:
org.liquibase:liquibase-core-jvm:jar:2.0-SNAPSHOT
Any maven experts know what I am doing wrong? You should be able to see the error if you build core trunk
Core builds fine, but there is a pom.xml in the root liquibase dir that should be the one to run so it builds all the parts of liquibase (core+core-jvm which gets built into the main liquibase jar with liquibase-dist as well as the samples, integration test package, and the maven module)
Unfortunately I think that my knowledge of maven would be considerably less than yours.
The only help that I can provide is when I tried ‘maven package’ from /trunk it appeared to get a lot further into the build process than your original post indicated.
Mine eventually stopped after some integration tests failed (after about 3 mins of test execution) which I assumed meant that I had not set up my environment correctly.
I have just checked out the trunk and ran a couple of builds through using various combinations of arguments. They all worked from clean, but only if you do not skip the tests (unless you have previously installed the artifacts). I would have a guess that you are trying to skip the tests in your build that you having issues with (i.e. using -Dmaven.test.skip=true)?
We have run into similar issues at work with the skipping of tests and dependencies on test artifacts. The skipping of tests, does not build the test artifacts, so you end up in a situation that builds will fail. To get around this you can add profiles that when active will stop any tests from running, but still allow the artifacts to be built.
If you do not skip the tests, the package goal will fail later on as it cannot find the liquibase-core artifact for the distribution (unless previously installed). You should really run the install goal with a multi-module build instead of package (from the parent pom that is) otherwise you can run into some artifact resolution issues (like what I have just experienced).
I also noticed that the version number in the Maven POMs is 2.0-SNAPSHOT, but you are refering to releasing a beta3 version. Is there any reason that the version number does not match what it is you are trying to release? It would most likely make life easier if you correctly connected these.
I have made a bit of progress. I found that if I set maven.test.skip.exec=false it compiles the tests and builds the jars, but doesn’t actually execute them. I had them skipped (like you had guessed) to troubleshoot the build process faster, since the test execution takes >10 minutes due the number of integration tests we have.
The build number was in there from the contributed maven support, I don’t know enough about maven versioning yet to know when to change it, that was going to be my next step. How does the snapshot versioning work? Would I change the version to 2.0-beta3-SNAPSHOT while testing it out, then change it to “2.0-beta3” when I am ready to release, or can I have it build both the SNAPSHOT and regular versions and only list the 2.0-beta3 version?
Also, we currently have 2.0-SNAPSHOT listed in all the modules, is there a way to have it pull it from a common location, so I only have to change the version in one place?
That error is due to what I alluded to at the bottom of my last post, you need to run “install” not “package” as your goal because the Liquibase Distribution has a dependency on the liquibase-core artifact, but this is not present in the local maven repository for the machine performing the build. Change the build to use “clean install” instead of “clean package” and this problem will go away.
Your own PC that you can successfully build on will have a version of the liquibase-core 2.0-SNAPSHOT artifact in its local repository from some previous build that you have run.
As for the version number, yes change it to “2.0-beta3-SNAPSHOT” whilst performing automated builds, then when you are ready to release the “2.0-beta3” build, use the Maven release plugin, which will ask you a number of questions about version numbers, perform some validation that the build is repeatable (i.e. no snapshot dependencies present and the tests pass), will tag you Subversion repository, perform the build, deploy your artifacts and then move the version number(s) on to the next version that you specified in the answers the release plugin prompted you for, and commit those changes back into the Subversion repository.
Releases are something that Maven handles extremely well, once you get your head around it (and multi-module builds do add minor complications to the process). I could write a quick guide, and debug/test the release process for you if you think it would help.
As to your last question, yes and no. The version number can be controlled in the master pom.xml file, but each of the child pom.xml files have to reference this master pom.xml file by version number, so the version numbers appear once in all pom.xml files. The Maven Release plugin takes care of updating these values for you, so it is not really that much of a hassle as long as you know what the next version number will be at the time of releasing.
The build is passing!! Yay!! I was able to get it all to work with mvn package rather than install by changing the maven-dependency-plugin unpack-jar execution to use “unpack-dependencies” rather than just “unpack”
I also updated the build numbers to 2.0-b3-SNAPSHOT.
How does the maven release process work with a build server? My usual pattern is to pull real builds from there rather than having them built on my machine, but to use the release plugin do I need to run it locally?
Any guide and help you have for the maven release, debug, and test process would be greatly appreciated. Like you can tell, I am new to maven
The release process cannot really be put into a build server, it is possible, as you can specify all the parameters that you would be prompted for, but this requires a fair amount of work. The best approach is to perform the release with user interaction.
Learning from the issues that we have had in the past from multi-module Maven projects, this is how we perform a release on our projects;
Checkout source code from Subversion
Set the build number to an appropriate value (not sure how you are doing this, but we use environment variable)
Suspend any automated builds on the build server that work off of changes to the source code, otherwise builds will be performed automatically during the release, and you do not want that
Run mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true
Run mvn release:clean to clear away the dry run release files, failing to do this will result in no tagging for the release
Run mvn release:prepare -DautoVersionSubmodules=true which will run through the actual release preparation that we already know will succeed (because we did the dry run before it)
Perform the actual release using mvn release:perform
Activate the build server builds that were disabled
If you follow the above order of events, then you will not end up tagging your repository and modifying files when/if there are failures in the build. I would suggest that you NEVER disable any tests when performing a release, these are your safety net to ensure all things are working as expected when releasing.
As part of the release, a deploy will be attempted, which will place the artifacts into a remote Maven repository. Do you have one of these? If not then I do not htink you release will succeed. If you need a repository, Sonatype do free hosting for OSS projects and Nexus is a great repository manager http://nexus.sonatype.org/oss-repository-hosting.html.
