lbruun-net / Pre-Liquibase

Spring Boot add-on to Liquibase
Apache License 2.0
49 stars 9 forks source link

Add example with Maven Goal #4

Closed wbt closed 3 years ago

wbt commented 3 years ago

Thanks for putting this together!

The documentation notes that "The module will make sure it always fires before Liquibase itself. " That may be true for when Liquibase is run as part of Spring Boot startup, but does not appear to apply when Liquibase is run as part of a Maven goal execution earlier in the process, which sometimes has to precede the running of e.g. myBatis-generator, which has to precede compilation of source code, which has to precede actually running any compiled code.

Having an example in documentation of how this can be run as a Maven goal, with an tag within , would be useful. I think making this work will likely require some other code changes, such as adding a @Mojo( name = "runPreLiquibase") annotation line just before this class declaration and compiling with some maven-plugin plugins, but I don't feel expert enough at the moment to make a all the changes for a PR myself.

lbruun commented 3 years ago

Thank you for reaching out.

Pre-Liquibase is designed to work with Spring Boot, or at a minimum it is designed for those who want to embed Liquibase within their application. Embedding Liquibase is IMHO definitely the way to go rather than having Liquibase as something that lives outside of your executable. In the "embed scenario" there's no need for executing Liquibase from Maven, you simply execute your application.

In conclusion what you ask for is simply not in the scope of this project.

Let me know if I've misunderstood you. If not, I'll close the request.

wbt commented 3 years ago

Thanks for your response!

The application I've been working on is embedding Liquibase, but "you simply execute your application" isn't accurate when one has to run Liquibase in order to run mybatis-generator in order to create the sources to compile the application, which has to be done before "you can simply execute your application."

I found a workaround which tells Liquibase to use the default 'public' schema for its own databasechangelog and databasechangeloglock tables, and then adding a changeset for the creation of the custom schema prior to creation of any tables. However, it would be better to be able to have the schema created before connecting with Liquibase, so the Liquibase tables are created in the project schema. It seems like that is exactly the type of problem this project is intended to solve, even though it might need a bit of extension to be able to run it as a Maven goal.

lbruun commented 3 years ago

Sorry, but I still feel it is too far away from the intention of the project. The MyBatis scenario is also not something I have experience with so it would development of the type where I don't fully appreciate the use case myself. That rarely works. :-)

You are welcome to fork the project. At the moment the project is tied heavily to Spring Boot (its main raison d'être) but it would be possible to modularize the project further so that its core (the PreLiquibase class and its dependencies) is only dependent on Spring itself. The project uses Spring utility classes for parsing and executing SQL script files so you would - at a minimum - need the Spring JDBC dependency. Then you could have a Mojo call the PreLiquibase class as you suggest. There's a lot of work involved in that as the DataSource to use for PreLiquibase is currently derived from what Spring Boot would/will use for its Liquibase invocation. This is why the PreLiquibase project at the moment does not allow you to specify any DataSource properties. That would need to change too.