To get started:
Download the starter project.
This is an example project with a dummy migration that you can start with and then tweak as needed.
Ensure you have IvyDE installed in Eclipse.
(This could be done with
m2eclipse or straight jar files if you’re so inclined, as all of the dependencies are in public Maven repositories, but I personally use IvyDE. I’d welcome a
Extract and import the
joist-starter project into Eclipse.
The project defaults to MySQL, if you’re using PostgreSQL, edit
EmployeeTest and change
build.properties file (next to
ivy.xml) and set the administrator password for your local database by adding
db.sa.password = .... (the user defaults to
root for MySQL and
postgres for Postgres).
JoistCli.java and the database name and type (MySQL or Postgres).
EmployeeTest.java – the database name and type.
Joist will create a user for the application’s database. The user’s name is
<database-name>_role and the password is
<database-name>_role. You can change these in the
JoistCli class by setting the
password fields of the
Next, run the
starter-cycle launch file with Eclipse, and this create (or recreate) the database, apply the migrations, and run the code generator.
From here, you might:
Rename the packages to fit your convention
Change the source output folders to fit your convention
Configure your automated build to run the
Cli JoistCli.cycle command
Note that, while the starter project ships with domain objects and migrations in the same project, it usually works better to have separate projects, e.g.
This is because a number of build tools these days (Maven, buildr, etc.) make fairly strict assumptions about all code within a project being compilable at once, and a single deliverable. This is not the case with migrations–they usually need to be compiled separately from the domain objects (as the domain objects require code generated by the migration), so work best off in their own project.
Configure your production deployments to run
Cli JoistCli.migrateDatabase command