The demo address gitee.com/youngboyvip…
First of all, what is liquibase
Liquibase is an open source database refactoring tool for tracking, managing, and applying database changes. It saves all database changes, including structure and data, in XML files for easy version control
What can Liquibase do?
- Does not depend on the specific database, the current support including Oracle/Sql Server/DB2 / MySql/Sybase/PostgreSQL/Cache of 12 kinds of database, so that the database deployment and upgrade link can help support multiple database application system.
- Provides database comparison functionality, the comparison results are saved in XML, based on which you can easily deploy or upgrade the database using Liquibase.
- Database changes are stored in XML, where a change (ChangSet) is uniquely identified by author and ID, and consolidation of database changes is supported, thus enabling multiple developers to work simultaneously.
- Save DatabaseChangeHistory in the database and automatically skip applied changsets when the database is upgraded.
- You can roll back the changed applications by time, quantity, or tag. In this way, developers can easily restore the state of the database at any point in time.
- Generate database modification document (HTML format)
- Standalone IDE and Eclipse plug-ins that provide data refactoring.
Why liquibase is used for database modification in traditional development mode
In daily project development, the development team often regards database and application as separate entities, which leads to the separation of database team and application development team, resulting in poor information exchange between the team, information exchange is not timely, this situation is usually manifested in the following behaviors
- Manually changing the database
- Database changes cannot be shared with other members of the team
- Using inconsistent methods to change databases or data
- Using inefficient manual methods to manage changes between database versions
The above behaviors are problems we encounter in actual development. They are not only inefficient but also have a high probability of making mistakes. Even old drivers will overturn their cars
The idea to solve the above problem is to reduce the chance of manual changes to the database, using procedures to manage the replacement of the database version
Use Liquibase to manage changes to the database
Using the step
- Step1: create a database change log file.
- Step2: create a change set inside the change log file.
- Step3: run change sets against the database from the command line or build script.
- Step4: verify the changes in the database.
Step1: create the change log file (changlog.xml)
The change log file does not have to be written in XML but can also be written using JSON SQL
<? xml version="1.0" encoding="UTF-8"? > <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="Http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
</databaseChangeLog>
Copy the codeStep2: Add a change set
<? xml version="1.0" encoding="UTF-8"? > <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="Http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
<changeSet id="1" author="bob">
<createTable tableName="department">
<column name="id" type="int">
<constraints primaryKey="true" nullable="false"/>
</column>
<column name="name" type="varchar(50)">
<constraints nullable="false"/>
</column>
<column name="active" type="boolean" defaultValueBoolean="true"/>
</createTable>
</changeSet>
</databaseChangeLog>
Copy the codeEach change set is uniquely identified by the “ID” and “author” attributes. The author attribute minimizes the possibility of duplication. Liquibase treats each change set as an atomic change to be applied to the database. It is usually best to include only one change in a change set
Step3: Run ChangeSet liquibase you can use the command line Ant Maven Spring and other tools to run the command demonstration
liquibase --driver=com.mysql.jdbc.Driver \ --classpath=/path/to/classes \ --changeLogFile=com/example/db.changelog.xml \ --url="jdbc:mysql://localhost/example" \
--username=user \
--password=asdf \
update
Copy the codeStep4: check your database you can see that the database now contains a table named “department”. Two more tables are created: “Databasechangelog” and “Databasechangeloglock”. The Databasechangelog table contains a list of all statements that have been run against the database. The Databasechangeloglock table is used to ensure that two computers do not attempt to modify the database at the same time.
Using Liquibase in your project (the Way Spring integrates)
Liquibase provides Spring support, so you just need to reference the corresponding JAR package and configure it to use it
Here we use gradle as an example step1: add dependencies
compile "org.liquibase:liquibase-core"
compile "com.github.sabomichal:liquibase-mssql"
compile "com.microsoft.sqlserver:mssql-jdbc"
testCompile "com.mattbertolini:liquibase-slf4j"
Copy the codeStep2: Add the liquibase file
Create the liquibase folder in the Resource directory, And create the master. The XML file as the primary file using the < include file = “XML config/liquibase changelog/XXX.” relativeToChangelogFile = “false” / > The directory imports the Changelog file
Step3: configuration liquibase
@Bean public SpringLiquibase liquibase(DataSource dataSource, LiquibaseProperties liquibaseProperties) { SpringLiquibase liquibase = new SpringLiquibase(taskExecutor, env); liquibase.setDataSource(dataSource); // Specify the location of changelog, where a master file is used to refer to other files liquibase.setChangelog ("classpath:config/liquibase/master.xml");
liquibase.setContexts(liquibaseProperties.getContexts());
liquibase.setDefaultSchema(liquibaseProperties.getDefaultSchema());
liquibase.setDropFirst(liquibaseProperties.isDropFirst());
return liquibase;
}
Copy the codeLiquibase updates the database at startup and can be configured to execute asynchronously
Applying refactoring to an existing database & common database operations
As new features are added to the application, it is often necessary to change the structure of the database or modify table constraints. LiquiBase offers more than 30 database refactoring support (see Resources). This section covers four types of refactoring: Add Column, Drop Column, Create Table, and manipulate data.
Add columns
At the beginning of a project, it is almost impossible to consider all the columns in the database. Sometimes, users request new features – such as collecting more data for information stored in the system – which requires the addition of new columns. Listing 4 adds a column to the distributor table in the database using the LiquiBase addColumn refactoring:
Listing 4. Refactoring the Add Column database using the LiquiBase change set
<changeSet id="4" author="joe">
<addColumn tableName="distributor">
<column name="phonenumber" type="varchar(255)"/>
</addColumn>
</changeSet>
Copy the codeDelete the column
Suppose that in later versions you want to remove the phonenumber column added in Listing 4. Just call the dropColumn refactoring, as shown in Listing 5:
Delete a database column
<dropColumn tableName="distributor" columnName="phonenumber"/>
Copy the codeCreate a table
Adding a new table to the database is also a common database refactoring. Listing 6 creates a new table Distributor, defining columns, constraints, and default values:
Listing 6. Create a new database table in LiquiBase
<changeSet id="3" author="betsey">
<createTable tableName="distributor">
<column name="id" type="int">
<constraints primaryKey="true" nullable="false"/>
</column>
<column name="name" type="varchar(255)">
<constraints nullable="false"/>
</column>
<column name="address" type="varchar(255)">
<constraints nullable="true"/>
</column>
<column name="active" type="boolean" defaultValue="1"/>
</createTable>
</changeSet>
Copy the codeOperational data
After structural data refactoring is applied, such as adding columns and creating tables, it is often necessary to insert data into the tables affected by the refactoring. In addition, you may need to modify existing data in lookup tables (or other types of tables). Listing 7 shows how to insert data using a LiquiBase changeset:
Listing 7. Inserting data using a LiquiBase changeset
<changeSet id="3" author="betsey">
<code type="section" width="100%">
<insert tableName="distributor">
<column name="id" valueNumeric="3"/>
<column name="name" value="Manassas Beer Company"/>
</insert>
<insert tableName="distributor">
<column name="id" valueNumeric="4"/>
<column name="name" value="Harrisonburg Beer Distributors"/>
</insert>
</changeSet>
Copy the codeYou should write SQL scripts to manipulate data, because using LiquiBase XML changesets is very restrictive. Sometimes it is easier to apply a large number of changes to the database using SQL scripts. LiquiBase can also support these scenarios. Listing 8 calls the insert-distributor-data.sql in the change set to insert distributor table data:
Listing 8. Run a custom SQL file from the LiquiBase change set
<changeSet id="6" author="joe">
<sqlFile path="insert-distributor-data.sql"/>
</changeSet>
Copy the codeLiquiBase supports many other database refactorings, including Add Lookup Table and Merge Columns. You can define all of this support in the way shown in Listings 4 through 8.
Changeset XSD reference
<! -- Childrenfor changeSet -->
<xsd:group name="changeSetChildren">
<xsd:choice>
<xsd:element ref="comment" maxOccurs="1" />
<xsd:element ref="createTable" maxOccurs="unbounded" />
<xsd:element ref="dropTable" maxOccurs="unbounded" />
<xsd:element ref="createView" maxOccurs="unbounded" />
<xsd:element ref="renameView" maxOccurs="unbounded" />
<xsd:element ref="dropView" maxOccurs="unbounded" />
<xsd:element ref="insert" maxOccurs="unbounded" />
<xsd:element ref="addColumn" maxOccurs="unbounded" />
<xsd:element ref="sql" maxOccurs="unbounded" />
<xsd:element ref="createProcedure" maxOccurs="unbounded" />
<xsd:element ref="dropProcedure" maxOccurs="unbounded" />
<xsd:element ref="sqlFile" maxOccurs="unbounded" />
<xsd:element ref="renameTable" maxOccurs="unbounded" />
<xsd:element ref="renameColumn" maxOccurs="unbounded" />
<xsd:element ref="dropColumn" maxOccurs="unbounded" />
<xsd:element ref="mergeColumns" maxOccurs="unbounded" />
<xsd:element ref="modifyDataType" maxOccurs="unbounded" />
<xsd:element ref="createSequence" maxOccurs="unbounded" />
<xsd:element ref="alterSequence" maxOccurs="unbounded" />
<xsd:element ref="dropSequence" maxOccurs="unbounded" />
<xsd:element ref="renameSequence" maxOccurs="unbounded" />
<xsd:element ref="createIndex" maxOccurs="unbounded" />
<xsd:element ref="dropIndex" maxOccurs="unbounded" />
<xsd:element ref="addNotNullConstraint" maxOccurs="unbounded" />
<xsd:element ref="dropNotNullConstraint" maxOccurs="unbounded" />
<xsd:element ref="addForeignKeyConstraint" maxOccurs="unbounded" />
<xsd:element ref="dropForeignKeyConstraint" maxOccurs="unbounded" />
<xsd:element ref="dropAllForeignKeyConstraints"
maxOccurs="unbounded" />
<xsd:element ref="addPrimaryKey" maxOccurs="unbounded" />
<xsd:element ref="dropPrimaryKey" maxOccurs="unbounded" />
<xsd:element ref="addLookupTable" maxOccurs="unbounded" />
<xsd:element ref="addAutoIncrement" maxOccurs="unbounded" />
<xsd:element ref="addDefaultValue" maxOccurs="unbounded" />
<xsd:element ref="dropDefaultValue" maxOccurs="unbounded" />
<xsd:element ref="addUniqueConstraint" maxOccurs="unbounded" />
<xsd:element ref="dropUniqueConstraint" maxOccurs="unbounded" />
<xsd:element ref="setTableRemarks" maxOccurs="unbounded" />
<xsd:element ref="setColumnRemarks" maxOccurs="unbounded" />
<xsd:element ref="customChange" maxOccurs="unbounded" />
<xsd:element ref="update" maxOccurs="unbounded" />
<xsd:element ref="delete" maxOccurs="unbounded" />
<xsd:element ref="loadData" maxOccurs="unbounded" />
<xsd:element ref="loadUpdateData" maxOccurs="unbounded" />
<xsd:element ref="executeCommand" maxOccurs="unbounded" />
<xsd:element ref="stop" maxOccurs="unbounded" />
<xsd:element ref="output" maxOccurs="unbounded" />
<xsd:element ref="empty" maxOccurs="unbounded" />
<xsd:element ref="rollback" maxOccurs="1" />
<xsd:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xsd:choice>
</xsd:group>
Copy the codeThe Gradle liquibase plugin is used
Install the Gradle plugin
Written above gradle 2.0
plugins {
id 'org.liquibase.gradle' version '2.0.0'
}
Copy the codeGradle 2.0 is written as follows
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "Org. Liquibase: liquibase - gradle - plugin: 2.0.0." "
}
}
apply plugin: 'org.liquibase.gradle'
Copy the codeConfiguration depends on
dependencies { ... // Select the dependency liquibaseRuntime you need'org. Liquibase: liquibase - core: 3.6.1'
liquibaseRuntime 'org. Liquibase: liquibase - groovy - DSL: 2.0.0'
liquibaseRuntime 'mysql: mysql connector - Java: 5.1.34'. }Copy the codeConfigure Liquibase Activities (similar to profiles)
/ / generated. The location of the record file project. Ext diffChangelogFile ='src/main/resources/config/liquibase/changelog/' + new Date().format('yyyyMMddHHmmss') + '_changelog.xml'// Generate the SQL file location project.ext.generatesQL ='src/main/resources/config/liquibase/sql/' + new Date().format('yyyyMMddHHmmss') + '_update.sql'
liquibase {
activities {
prod {
driver 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
url 'jdbc:sqlserver://localhost:1433; database=damManager'
username 'SA'
password 'yourStrong(!) Password'
changeLogFile 'config/liquibase/master.xml'
defaultSchemaName ' '
logLevel 'debug'
baseDir 'src/main/resources/'
outputFile project.ext.generateSql
}
dev {
driver 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
url 'jdbc:sqlserver://localhost:1433; database=damManager'
username 'SA'
password 'yourStrong(!) Password'
password 'sql_2008dba'
changeLogFile 'config/liquibase/master.xml'
defaultSchemaName ' '
logLevel 'debug'
baseDir 'src/main/resources/'
outputFile project.ext.generateSql
}
diffLog {
driver ' '
url 'jdbc:sqlserver://localhost:1433; database=damManager'
username 'SA'
password 'yourStrong(!) Password'
changeLogFile project.ext.diffChangelogFile
defaultSchemaName ' '
logLevel 'debug'
classpath 'src/main/resources/'
}
runList = 'dev'// Select which configuration parameter to replace}}Copy the codeEntry Class Configuration
You can customize the entry class, expand the functions of Liquibase expand example project address gitee.com/youngboyvip…
The default entry class liquibase.integration.com mandline. Main
Configuration method
liquibase {
mainClassName = 'liquibase.ext.commandline.LiquibaseAlternativeMain'
}
Copy the codeWhen configured, you can see liquibase’s task in Gradle
Note: File=” XXX/XXX /xxx.xml” absolute and relative paths. If you set relativeToChangelogFile=”false” you’re using an absolute path, true is using a relative path, You can customize resource loaders to address absolute and relative paths, as shown in the sample project above
Task additional parameter Settings
The parameters in liquibase.activities are mandatory. Some commands may require additional parameters. In this case, you need to use the command line to create parameters dynamically
If you are using gradle Wrapper, you need to execute the command using gradlew
The sample
Gradlew < task name > -pliquibasecommandValue ="--xx=yy --aa=bb"
Copy the codeExperience with
Do not manually change the database do not change the original Changeset use the new Changeset to change the timing of the tag to facilitate rollback
Liquibase is being used in projects under development
Use idea: the previous database changes (such as table structure, stored procedures, basic data) to export, and then use Liquibase management, later development unified use liquibase database management changes)
Step1: export changes in the database
You can use the database tool to export as an SQL file, or use the generateChangelog command of the Liquibase command line tool to export the XML change file
Step2: Use Liquibase to manage database changes
Because the corresponding change already exists in the database, you only need to mark the exported change record as executed
For this operation, you can use the Liquibase command line based on changelogSync or changelogSyncSQL. The difference between the two commands is that one directly modiates the database, the other does not directly modify the database, and the other generates the corresponding SQL, which needs to be manually pointed to the SQL
Appendix to the liquibase command
| Name of the command | Command description |
|---|---|
| update | Update the database to the current version |
| updateSQL | Write SQL to update the database to CurrentVersion or STDOUT |
| updateCount <num> | Apply the next NUM change to the database |
| updateCountSQL <num> | Write SQL to apply the next NUM change to the database |
| updateToTag <tag> | Updates the database to a changeset using the specified tag |
| updateToTagSQL <tag> | Writes THE SQL (to standard output) to the change set using the specified tag |
| rollback <tag> | Rollback the database to the state of the specified label is WAS |
| rollbackSQL <tag> | Generates SQL for database rollback to the specified label |
| rollbackToDate <date/time> | Rollback the database to the given date/time state is WAS. Date format: YYYY-MM-DD ‘HH: MM: SS |
| rollbackToDateSQL <date/time> | Write SQL to roll back the database to the state of the given date/time version to STDOUT |
| rollbackCount <value> | Rollback is applied to the last < value > change set of the database |
| rollbackCountSQL <value> | Write SQL to roll back the last < value > change set to stDoutApply applied to the database |
| futureRollbackSQL | Write SQL to roll back the database to the current state when the changes in the change log are complete |
| futureRollbackSQL <value> | After the < value > change in the change log is complete, write SQL to roll back the database to the current state |
| futureRollbackFromTagSQL <tag> | Write (to standard output)SQL to roll back the database to its current state after changes |
| updateTestingRollback | Update the database, and then roll back the changes again. Used to test rollback support |
| generateChangeLog | Write the change log XML to copy the current state of the database to standard output |
| snapshot | Writes the current state of the database to standard output |
| snapshotReference | Write the current state of the referenceUrl database to standard output |
| Diff Commands | Database Comparison command |
| diff [diff parameters] | Database Comparison command |
| diffChangeLog [diff parameters] | Database Comparison Log |
| Documentation Commands | Document command |
| dbDoc <outputDirectory> | Generate Javadoc-like documents based on the current database and change logs |
| Maintenance Commands | Maintenance commands |
| tag <tag string> | Label the current database for later rollback |
| tagExists <tag string> | Check whether the corresponding label exists |
| status [–verbose] | The output is the number of lines executing Changeset |
| unexpectedChangeSets[–verbose] | Output the number of changeset rows that do not exist locally |
| validate | Check whether there is an incorrect Changelog |
| calculateCheckSum <id> | Check the checksum value of the specified Changeset IDfilepath::id::author |
| clearCheckSums | Deletes all saved checksums from the database log |
| changelogSync | Marks that all changes have been made |
| changelogSyncSQL | Generate markup changes to executed SQL and output to standard output |
| markNextChangeSetRan | Mark the next change as executed |
| markNextChangeSetRanSQL | Generate SQL that marks the next change as executed and print it to standard output |
| listLocks | Lists liquibase database locks |
| releaseLocks | Release all liquibase database locks |
| dropAll | Delete database tables (use with caution!) |
Will pass parameters
| parameter | describe |
|---|---|
| –changeLogFile=<path and filename> | Change the file log path |
| –username=<value> | Database user name |
| –password=<value> | Database password |
| –url=<value> | Database url |
Optional parameter
| parameter | describe |
|---|---|
| –classpath=<value> | The classpath contains migration files and JDBC drivers |
| –driver=<jdbc.driver.ClassName> | Database driver class name |
| –databaseClass=<database.ClassName> | Customize liquibase.database. Databaseimplementation use |
| –propertyProviderClass=<properties.ClassName> | Custom property implementation to use |
| –defaultSchemaName=<name> | The default database schema to use |
| –contexts=<value> | Change the context in which to execute |
| –labels=<expression> | Defines an expression for the tag change set to execute |
| –defaultsFile=</path/to/file.properties> | Files with default option values (default :./liquibase.properties) |
| –delimiter=<string> | Used with the executeSql command to set the string used to decompose a file containing multiple statements. |
| –driverPropertiesFile=</path/to/file.properties> | A file that sets custom properties on the JDBC connection to be created |
| –changeExecListenerClass=<ChangeExecListener.ClassName> | Customize the Execlistener implementation to use |
| –changeExecListenerPropertiesFile=</path/to/file.properties> | Properties for customizing change Exec listeners |
| –liquibaseCatalogName=<name> | The name of the directory with the Liquibase table |
| –liquibaseSchemaName=<name> | The name of the schema with the Liquibase table |
| –databaseChangeLogTableName=<name> | Liquibase ChangeLogtable name (default :DATABASECHANGELOG) |
| –databaseChangeLogLockTableName=<name> | Liquibase ChangeLogLock The name of the table (default :DATABASECHANGELOGLOCK) |
| –liquibaseSchemaName=<name> | The name of the schema with the Liquibase table |
| –includeSystemClasspath=<true|false> | Include the system classpath in the Liquibase classpath (default :true) |
| –promptForNonLocalDatabase=<true|false> | Prompts if it is not a localhost database (default :false) |
| –logLevel=<level> | Execution log levels (Debug, Info, Warning, Critical, Closed) |
| –logFile=<file> | The log file |
| –currentDateTimeFunction=<value> | Overrides the current date-time function used in SQL. Applies to unsupported databases |
| –outputDefaultSchema=<true|false> | If true, the SQL object reference includes the schema name and even ifit is the default schema. The default value is true |
| –outputDefaultCatalog=<true|false> | If true, the SQL object reference includes the directory name and even ifit is the default directory. The default value is true |
| –outputFile=<file> | Write output files for commands that write output, such as updateSQL. If not specified, sysout is written. |
| –help | Print this message |
| –version | Print the version information |
The diff command is mandatory
| parameter | describe |
|---|---|
| –referenceUsername=<value> | Compare database user names |
| –referencePassword=<value> | Compare database passwords |
| –referenceUrl=<value> | Compare database urls |
Diff command This parameter is optional
| parameter | describe |
|---|---|
| –defaultCatalogName=<name> | Default database directory |
| –defaultSchemaName=<name> | Default database schema |
| –referenceDefaultCatalogName=<name> | The reference database directory to use to compare databases |
| –referenceDefaultSchemaName=<name> | Compare the database schema to use for the database |
| –schemas=<name1,name2> | The database schema that contains objects from the comparison |
| –referenceSchemas=<name1,name2> | Reference to the database schema to contain objects from the comparison is required only if it differs from the — schema |
| –outputSchemaAs=<name1,name2> | On diffChangeLog/generateChangeLog, using these names as schemaNameinstead of the real name. |
| –includeCatalog=<true|false> | If true, the directory defaults to false in the generated change set |
| –includeSchema=<true|false> | If true, the pattern is included in the generated changeSetsDefaults |
| –referenceDriver=<jdbc.driver.ClassName> | Reference database driver class name |
| –dataOutputDirectory=DIR | Outputs data in a given directory in CSV format |
| –diffTypes | A list of diff types, including inChange logs, is separated by a comma |
The official reference www.liquibase.org/documentati…
Gradle command reference
| parameter | describe |
|---|---|
| -? , -h, –help | Display help – -….. |
| -a, –no-rebuild | Ignore “project dependencies “, assuming that the module web depends on base. If this parameter is used, the base module will not be built, even if there are updates to the base module code. (Note: if the base module is clean, then the base dependency will not be built into the project.) |
| -b, –build-file | Gradle file in the current directory or build.gradle in the subproject according to settings.gradle configuration. -b ignores setting file. |
| -c, –settings-file | Executes the specified *.gralde file, default settings.gradle. |
| –console | Specifies the console output type. The options are ‘plain’, ‘auto’ (default), and ‘rich’. Plain generates plain text, which disallows all color and rich text output. Auto (default) Starts color and rich text output when the builder is associated with the console, or generates plain text when it is not; Rich starts color and rich text output, regardless of whether the builder is associated with the console, and outputs ANSI control characters to produce rich text output if no build output is associated |
| –no-color | Deselect console coloring, but this option is no longer recommended and –console=plain is recommended instead. |
| –continue | Ignore the error and continue building. By default, the build is terminated. |
| -d, –debug | Specify the log output level as DEBUG to display general stack information. |
| -q, –quiet | Specifies that the log output mode is quiet and only errors is printed. |
| -i, –info | Specify the log level as INFO. |
| -S, –full-stacktrace | Specifies the log level as full-stackTrace, and prints complete stack exception information. |
| -s, –stacktrace | Specifying the log level as StackTrace prints all stack exceptions. |
| -D, –system-prop | The -d property is passed to the JVM that started Gradle and is used by the JVM as a system property (for example, -dname = Tom). |
| -P, –project-prop | Gradle project parameters are loaded directly into the Gradle domain object (for example: -pversion =1.2). |
| –configure-on-demand | Apply Only relevant projects are configured in this build run. This means faster builds for large multi-builds. [incubating] |
| –daemon | Use the Gradle daemon to perform the build, or start one if there is no daemon. |
| –no-daemon | Disable daemons and do not use daemons to perform builds. |
| –stop | If a daemon exists, terminate it. |
| –foreground | Start the daemon as foreground. |
| -g, –gradle-user-home | Specifies the default Gradle user home directory. The default is “user directory /.gradle”. |
| –gui | Run the Gradle GUI graphical interface program. |
| -I, –init-script | Execute the specified init script, which is executed before build. According to the current directory, USER_HOME /. Gradle /, USER_HOME /. Gradle/init. D/GRADLE_HOME/init. D/order for init. Gradle file |
| -m, –dry-run | Simulate the execution of the task and print it out, not actually executing it, just so you know what steps will be performed. |
| –max-workers | Specify how many CPU cores are used to perform the build / |
| –offline | Build projects in offline mode, of course, if you have + in your GAV, beware of build failures. |
| -p, –project-dir | Specifies the directory where the build.gradle script is located. Default is the current directory. If you specify a subproject directory with this parameter, the build.gradle file in the specified directory will be executed by default. |
| –parallel | Run in parallel mode |
| –parallel-threads | The number of threads used for parallel build execution, deprecated and recommended instead for –parallel –max-workers. |
| –profile | Store an execution report to <build_dir>/reports/profile, including total time and details during configuration and task execution phases. The tasks are arranged in reverse chronological order, and the execution of tasks is recorded. Gradle names these report files according to the build time. |
| –project-cache-dir | Specifies the project cache directory. Default is the. Gradle folder in the project root directory. |
| –recompile-scripts | The cached script is discarded, then recompiled and stored in the cache. In this way, you can force Gradle to regenerate the cache. |
| –refresh-dependencies | Force a refresh dependency, ignoring the cache and re-downloading |
| –rerun-tasks | Forced re-execution of the task, ignoring the task cache, is an incremental build by default |
| -t, –continuous | Continuous build mode, which listens for all build file changes and automatically rebuilds files when they change |
| -u, –no-search-upward | Do not apply the ettings. Gradle file in the parent directory. Setting. Gradle in the parent directory overwrites the Settings in the child directory if this is not added. |
| -v, –version | Print gradle version information. |
| -x, –exclude-task | Task exclusion: Skips the execution of specified tasks. |