Not a big patcher, so hopefully I did this right.
Attached please find a patch against the trunk that allows compilation to run. It adds a stanza to the pom.xml under liquibase-core.
Best,
Laird
Not a big patcher, so hopefully I did this right.
Attached please find a patch against the trunk that allows compilation to run. It adds a stanza to the pom.xml under liquibase-core.
Best,
Laird
I’m trying to figure out what our maven project config is supposed to look like, so it will deploy nicely. The parent pom.xml seemed nice because it was one maven config you can run that compiels everything, but I was worried that when it comes time to deploy to a maven repository, since I had a node on liquibase-core it will list the parent project as another exported library, which is not the case.
If I add to liquibase-core, what impact does that have on module deployment?
As you can tell, I’m new to maven…
Nathan
Well, if you want to have a setup that is familiar to Maven users, it would look something like this, starting from the root of your project, where the root is defined as the place where the Grand Supreme Ruler of All Liquibase POMs Shall Live (maybe CORE?):
pom.xml <-- the parent pom, specifying defaults for everything in the universe
liquibase-core/pom.xml <-- one kid
liquibase-somethingelse/pom.xml <-- another kid
liquibase-stillsomethingelse/pom.xml <-- still another kid
The top level pom will contain all the boilerplate cr*p concerning your organization, description, etc. etc. In addition, it should have really beefy and sections. These define default versions and configurations for all the external “things” kid poms will refer to. It will have a type of pom.
It will also have a section, with one referencing each kid.
Each kid pom will specify a stanza that points back to the parent pom. Parent has modules (kids); kids each point back to the parent that contains them.
In addition, each kid pom will specify only those things which differ from the parent pom. Kid poms are generally quite small, since usually you’re using defaults configured higher up.
Finally, every project in Maven really really really wants to produce only one artifact, which, IMHO, I side with the Maven developers on: this is a good thing. You can subvert it, but try not to.
I hope that helps; I’m happy to help sort out the Maven issues if you need a hand.
Best,
Laird
We have the single parent pom.xml that lists all the sub-modules, then a pom.xml file for each “module” which include: “liquibase-core” (the library itself) and “liquibase-maven-plugin” which are real projects which would be deployed to the maven repository. We then have a pom for the other modules in our codebase. but these are groups of integration-tests and test extensions, they are nothing that should be deployed.
Since the “main” output is liquibase-core, I was concerned that if we specify the root pom as the parent, the deployed module descrition would reference the integration and extension tests as well.
Since we also have the maven module separate, does that mean that we shouldn’t have the parent pom at all since there should be just one output? That was part of my theory in removing the node from the sub-modules, but keeping the parent pom let me compile them all in one command.
Nathan
Not entirely sure what you’re getting at, but let me say this:
The section in a parent pom does nothing other than dictate in what order Maven will build those modules. It has nothing to do with artifacts, deployments or anything of that nature. It exists merely to set up the topological sort of the kid poms.
So A with modules B, C and D will run Maven over projects B, C and D and at the end of the day after running a mvn install you will have:
A .pom file for the parent, A (remember his packaging type is “pom” so no jar is produced)
A .jar file for B
A .jar file for C
A .jar file for D
Best,
Laird
Originally posted by: Nathan
but these are groups of integration-tests and test extensions, they are nothing that should be deployed.
There’s something odd here from a Maven perspective. Usually, a deployment of an artifact doesn’t take place unless unit and integration tests have passed. So it sounds like you have things set up currently so that it’s possible to run a mvn install from some level within your source code tree and have a .jar file installed without having integration tests run. Is that correct?
If so, there are better ways to set this up. Have a look at the maven-surefire-plugin and the maven-failsafe-plugin for details.
Additionally, people often deploy test artifacts in their own jars/projects. The standard Maven jar plugin has a goal explicitly for this, in fact.
Best,
Laird
OK, I’ve had a spin through the pom.xml files, and I think I know how they should be refactored. I’m willing to do it if you like; otherwise here’s a rough description.
First off–and this is more a matter of opinion than reality/fact–the integration tests should be sprinkled throughout the two main projects (liquibase-core and liquibase-maven). So that would eliminate a maven module right there. I’ll cover this more in a moment.
So, for the moment assuming that there is a liquibase-core module and a liquibase-maven module, here’s how you or someone else would do it:
In terms of the tests, I would throw them in the src/test/java directory of whatever project they most directly concern (probably liquibase-core in almost all cases). If you name them ITSomethingOrOther.java, and you use the maven-failsafe-plugin, then they will be run as integration tests, not unit tests. Only if they pass will the liquibase-core jar file, for example, be installed into your local repository.
I hope this helps; let me know if you want help here.
Best,
Laird
I was thinking we could move the integration tests into hte liquibase-core source. Some integration tests depend on the sample extension modules and some depend on the maven plugin, though. Will the liquibase metadata published to the maven repository need to include those as depenedencies as well then, or can they be marked as just used for build, and not a dependency that liqubase users would ever worry about?
It sounds like having the root type as pom instead of jar resolves my question on how the root project is handled.
If you wanted to make the maven changes you think should be made, that would be great. If you have a login on liquibase.jira.com you can commit directly instead of sending patches if you prefer, and I can look at the diffs.
Nathan
I will take a crack at it. Thanks for the trust. I’ll post here when/if I get to it (probably tonight; eastern time). I’ll restrict myself to general pom reorganization; I won’t move code.
Regarding the integration tests: the ones that depend on the maven plugin would probably go in that source tree. Sample extension modules…not sure offhand; I’d have to look. I will not move all this stuff around without your say-so. We can talk–if my hacking goes OK–about how to move the tests around after this first round of changes goes in.
Best,
Laird
Sounds like a good plan. Let me know if you have any questions.
Nathan
I completed the pom.xml refactoring. The trunk had tests that would not pass; I refrained from modifying anything and simply made sure that we were no worse off than when I started. 
With -DskipTests, the mvn clean install build from the root (CORE) completes normally. Without it, the build fails on a command line test as before.
In general, I restricted my changes to including stanzas where appropriate and dependency refactoring.
The one dependency refactoring I did not perform was in the samples area. The samples aggregator pom has several children, and each child declares exactly the same list of dependencies. I could have moved those dependencies up into the samples parent pom, but wasn’t sure if the homogeneous nature of the dependencies was deliberate or a coincidence.
I hope this helps and that I’ve stayed within the bounds you expected. Let me know what you think and we can talk about other changes if this one seems OK.
Best,
Laird
Hi, Nathan (and others); what’s your take on how my pom.xml changes went? Shall we talk about more significant refactoring? Or do you want to hold off until an rc2 release?
Best,
Laird
I haven’t gotten to looking at it yet. Hopefully this weekend. Sorry for the delay.
Nathan
I think the changes looked generally good. I ended up removing the sample/pom.xml since it didn’t do a lot. I figured the less the better. There were a couple problems building that I was able to clean up, and a couple more changes I see you made. I think the sample ones are good to have separate because I want individual jar files to test the liquibase extensions on their own if I need to.
I think the tests should pass in trunk, although if they are failing it may not be because of your pom changes. I think I’ll move the integration tests to core, that should be a pretty straightforward move and will make things simpler.
What additional changes should be made to support deploying liquibase-core and liquibase-maven-plugin over scp to my sync’ed maven repository on sourceforge?
Nathan
That’s fine. Regarding the samples pom.xml, that (was) the one serving only as an aggregator, right? If so–and I don’t mind at all that you removed it–bear in mind that it itself did not produce any jar artifacts (a pom with pom is there only to serve as (a) a parent, (b) an aggregator or © both). So you wouldn’t remove it to cut down on the number of jar artifacts, you would remove it because you made a conscious decision to duplicate its information in each of its sub-poms. Perhaps there wasn’t enough stuff in it to warrant its existence; I honestly don’t remember.
Regarding deployment: short answer is if everything is going to the same repository and basically sharing the same distribution information, then you’d put all that stuff up in the topmost pom you can. I’ll make the changes later and you can see if they work for you.
Best,
Laird
There wasn’t enough stuff in the sample pom.xml to make it worth adding the hierarchy.
I looked at moving the integration project into liquibase-core, but decided against it. The reason is because the integration tests depend on some of the sample modules, and I don’t want to add them as dependencies in liquibase-core. I think it’s better to build liquibase-core as pure as we can, then have another module that combines it with other depenedencies for test.
Nathan