Make part of the SQLiteProvider

[blundell]

I still think this should be part of the SQLiteProvider, perhaps with a build toggle if you want to opt in or not.

What are the positives for keeping it separate?

What are the positives for merging with SQLiteProvider?

[devisnik]

No sure about that yet.

Currently, we only use the same input as the SQLiteProvider (the migration files). And even that is not strictly necessary for the tool to work. We could alternatively feed it an existing sqlite database file.

So, there is currently no dependency on SQLiteProvider, but there are dependencies on Groovy and the java-sqlite database library which are not needed by the SQLiteProvider.

On the other hand, the current focus is definitely on generating the boilerplate you have to write when using SQLiteProvider.

[orangeman]

Why make it separate? Because we can :-)

Before Gradle there was a complexity price in integrating many small modules. It made sense to not separate if not absolutely necessary. Smooth dependency managment with Gradle enables powerful hyper-modularity like seen in the n(ode)pm community where even sqliteanalyzer would probably be broken down into many small micro-modules.

[orangeman]

This project could be seen as a gradle-plugin to hook code generators into the build process. Sqlite is just one example for deriving input to code generators. Boilerplate code that is generated for SqliteProvider is just one application of the tool.

How do you feel about making code generators modularily configurable as separate gradle dependencies?

[blundell]

Ok so we can have a dependency inside SQLiteProvider on this lib, but there are benefits as @devisnik says in having this separate as it technically doesn't always have to be used with migration files. (Nice to see an example in the demo module).