在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):stevesaliman/gradle-properties-plugin开源软件地址(OpenSource Url):https://github.com/stevesaliman/gradle-properties-plugin开源编程语言(OpenSource Language):Groovy 97.5%开源软件介绍(OpenSource Introduction):Gradle Properties PluginThe Properties plugin is a useful plugin that changes the way Gradle loads properties from the various properties files. See the CHANGELOG for recent changes. NEW: Starting with release 1.5.0, environment files can be optional, so you won't need to make a
bunch of empty files when you only need to override properties for certain environments. See the
description of the The Properties plugin is designed to make it easier to work with properties that change from environment to environment, or client to client. It makes life easier for developers who are new to a project to configure and build, because properties for multiple environments can be stored with the project itself, reducing the number of external magic that needs to happen for a project to run. It makes life easier for experienced developers to create different configurations for different scenarios on their boxes. The Properties plugin also adds support for validation methods inside a task that can prevent the task from running if it doesn't have all the properties it needs. Gradle adds properties to your project in several ways, as documented in the Gradle User Guide. Gradle processes property sources in a particular order, and the value of a property in your project will be the value from the last thing that set the property. Gradle's default order of processing is:
The properties plugin enhances this sequence by adding two additional types of property files. One is for properties that change from environment to environment, and the other is for properties that are common to a user (or client), but change from user to user (or client to client). The order of execution for the properties plugin is:
If the project was three levels deep in a project hierarchy, The steps 1 and 2 would apply to the root project, then the plugin would check the files in the parent project before continuing on with steps 3 and 4. More formally, the plugin applies project and environment files, when found, from the root project down to the project that applies the plugin. The property names for You can also change the directory where the gradle-${environmentName}.properties files live. The
As with standard Gradle property processing, the last one in wins. The properties plugin also
creates a "filterTokens" property that can be used to do token replacement in files, allowing Gradle
to edit configuration files for you. See Gradle's documentation for the Gradle can also set a Java system property from the properties it sees in the various property
files. The Gradle User Guide
describes the process in more detail, but basically, properties that start with "systemProp." will
be converted into Java system properties, but only if they are in the Gradle plugins can also be applied to a Settings object by applying the plugin in the settings.gradle file. Gradle handles properties a little differently when processing a settings.gradle file, so the plugin's behavior changes as well. When applied in a settings.gradle file, the plugin processes files in the following order:
Gradle technically allows plugins to be applied in an init.gradle file, but Gradle recommends
against it, because the init.gradle file is designed for configuration and not plugin application.
If you really want to apply this plugin in the init.gradle file, you can do it by wrapping it in an
initscript {
repositories {
mavenCentral()
}
dependencies {
classpath "net.saliman:gradle-properties-plugin:1.4.6"
}
}
allprojects {
apply plugin: net.saliman.gradle.plugin.properties.PropertiesPlugin
} Note that this example uses a class name instead of a plugin id. This is to workaround a bug in Gradle that prevents plugins from being found by id inside an init.gradle file. Why should I use it?One of the challenges to building a project is that it often contains things that should be changed from environment to environment. This includes things like the log file directory, or the JNDI data source name. The values of these properties are often complicated by platform differences between the OSX and Windows environments most developers use and the Unix environments used for deployments. It gets even messier when you consider that these values are often scattered amongst several files buried in the project. This can be a real hindrance to new developers to a project, who don't know all the touch points of project configuration, or experienced developers who don't remember all the things that need to be changed to spin up a new environment. The solution is to extract all the environment specific information to a single file for each environment, with everything the project needs in that single file. Files that need these values, like persistence.xml or log4j.properties, become template files with tokens that can be replaced by the build. This provides an added benefit; new developers see some of the things that need to be setup external to the project. For example, if the project mentions a tomcat home, the developer knows they need to install tomcat. If they see a JNDI data source, they know they need to set one up inside their container. You should also use it if you have any Gradle tasks that depend on a property definition to work.
This plugin adds a How do I use it?The initial setup of a project is a little involved, but once done, this process greatly simplifies things for the developers who follow. Step 1: Extract environment sensitive files to a template directory Make a directory to hold the template files and copy files that change, like log4j.properties, into it. Edit the files and replace the environment specific values with tokens. For example, if the file had a property like "log.dir=/opt/tomcat/logs", replace it with "[email protected]@". Step 2: Create property files Create a file for each named environment you use for deployment. For example, if you have "qa", "uat", and "prod" environments. You would create gradle-qa.properties, gradle-uat.properties and gradle-prod.properties files. There is no limitation on environment names, they are just labels to tell the plugin which file to read at build time. If no environment is specified, the properties plugin uses the gradle-local.properties file, which should not be checked in to source control, because this is the file where developers setup the properties for their own machines. In our example, the gradle-local.properties file might contain "applicationLogDir=c:/opt/tomcat" or "applicationLogDir=/Users/steve/projects/myproject/logs" to define the log directory needed by the log4j.properties template. Step 3: Include and apply the plugin To use the plugin with Gradle 2.1 or later, add the following to the build.gradle file: plugins {
id 'net.saliman.properties' version '1.5.2'
} To use the plugin with Gradle 2.0 or older, add the following to build.gradle: // Pull the plugin from Maven Central
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'net.saliman:gradle-properties-plugin:1.5.2'
}
}
// invoke the plugin
apply plugin: 'net.saliman.properties' Note that this only applies the plugin to the current project. To apply the plugin to all projects
in a multi-project build, use the following instead of allprojects {
apply plugin: 'net.saliman.properties'
} If you also use your properties during the initialization phase in When the properties plugin is applied, three things happen. First, the plugin processes the various property files and property location as described above. Next, the plugin creates a property named Finally, the properties plugin - if applied to a project rather than a settings instance - adds some property closures to every task in the build (and causes them to be added to new tasks defined later). These properties can be used in the configuration of a task define which properties must (or should) be present for that task to work. Properties will be checked between the Gradle configuration and execution phases. Step 4: Define prep tasks Before the build can happen, tokenized files need to be copied to the right locations in the project. This can be done with a task like the following: task prep() {
requiredProperties "applicationLogDir", "logfileName", "defaultLogLevel"
outputs.file new File(resourceDir, 'log4j.properties')
doFirst {
copy {
from templateDir
include 'log4j.properties'
into resourceDir
filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: project.filterTokens)
}
}
} Note that this Once a compileJava.dependsOn prep The reason we copy into the source resource directory instead of the build directory is to keep IDEs happy. In general, you'll want to run the prep (or a prepTest) task whenever properties or template files change, or to switch environments. Properties added to each taskThis plugin adds some methods to each task, which can be used to check for the presence of properties after configuration, but before any tasks are executed. These methods will also add properties to the task's inputs that can be used to determine when a task is up to date. A task is never up to date if there are no outputs, but if the task has defined any outputs, Gradle will consider the task up to date if the other inputs and outputs haven't changed, and the properties haven't either. requiredProperty requiredProperty "somePropertyName" This method throws a MissingPropertyException if the named property is not defined. requiredProperties requiredProperties "property1", "property2", ... This method throws a MissingPropertyException if any of the named properties are not defined recommendedProperty recommendedProperty "somePropertyName", "default File Text", "Additional informational text" This method is handy when there are properties that have defaults somewhere else, or is not needed in all environments. For example, the build file might define it, or the application might be able to get it from a system file. It is most useful in alerting newer developers that something must be configured somewhere on their systems. The method checks to see if the given property is defined. If it is not, a warning message is displayed alerting the user that a default will be used, and if the defaultFile has been given, the message will include it so that the developer knows which file will be providing the default value. If additional text is provided, it will be appended to the warning message. recommendedProperties recommendedProperties names: ["property1", "property2", ...],
defaultFile: "default File Text",
additionalInfo: "Additional information" This method checks all the given property names, and prints a message if we're missing any. NotesIf a property is set in the build.gradle file before the properties plugin is applied, and it happens to match a property in one of the standard locations defined earlier, the build.gradle property's value will be overwritten. If you need to set a property in build.gradle, it is best to do it after the properties plugin is defined. Keep in mind that properties set in the build.gradle file will not be in the filterTokens. There are a few ways to change the Gradle user home directory. The properties plugin uses the Gradle user home directory that also Gradle itself uses, but I haven't done much testing of that yet. It is not required to have a gradle-local.properties file, but if you specify an environment with
the AcknowledgementsA special thank you to to Hans Dockter at Gradleware for showing me how to dynamically define the requiredProperty method and attach it to the right place in the Gradle build lifecycle. |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论