I've written a maven mojo that makes use of all of the properties defined for the project using an injected MavenProject object like this:
project.getProperties()
I then realized that property values specified at the command line like -Dfoo=bar are not being reflected in my mojo, only the property's value as its defined in the pom like:
<foo>super</foo>
How can my mojo access the value of foo as it's defined from the command-line versus the pom? Any ideas on this would be greatly appreciated.
Thanks!
The properties defined from the command line should be available through the System.getProperties() method.
Related
I try to build a native container with Quarkus (with -Pnative flag), I use -H:+PrintClassInitialization to generate the class initializer reports. I see a initilizer_dependencies_yyyymmdd_hhmmss.dot file is generated; in this file, I see some classes marked with [fillcover=red], could you tell me what this means? and what action is needed?
Thanks
it seems to me those classes are the ones that will be called but not in reflection configuration. I add them in reflection or initialize to solve it.
I'm currently using swagger-codegen through the maven plugin: https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen-maven-plugin.
I've set the place where I want my api files to be generated with the <apiPackage></apiPackage> field in my pom.xml.
But when I generate my apis, it gets put in src/main/java/<apiPackage>. I would like to know where is src/main/java declared as part of the path and if it can be changed.
src/main/java is a Maven convention.
This folder structure is hard-coded in Swagger Codegen's code and cannot be changed.
You can extend AbstractJavaCodegen and in constructor override value of sourceFolder variable. This extended class you can passed to codegen as --lang parameter.
What are the different type of properties in Gradle and what it is the difference of using them.
From what I know there are : system properties, environment properties and ONLY properties( extra properties ) declared with -D, -P and with ext. But if there are more types and when is good to use all of them.
Please give examples.
System properties and project properties are used to pass arguments from the command line. They are very similar, and it doesn't really matter which one you use. (The former is a Java feature, the latter a Gradle feature.) Extra properties are used for extending the build model. In other words, you can add new properties to existing objects, and other build scripts will be able to see them.
The Gradle User Guide has more information on these concepts.
I'm trying to reuse common logic among multiple Gradle tasks, similar to what was suggested in this answer, but I'm having trouble with extra project properties not being visible.
Boiled down, here's the problem. Say I have a root Gradle build script, build.gradle that sets an extra project property,
project.ext.myProp = 'myValue'
I have a subproject defined in settings.gradle,
include 'subproject'
and the subproject defines and uses a custom task that references that extra project property,
class CustomTask extends DefaultTask {
CustomTask() {
doFirst {
println project.ext.myProp
}
}
}
task custom(type: CustomTask) {
println 'custom task'
}
Executing this gives me this:
FAILURE: Build failed with an exception.
...
* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating project ':subproject'.
...
Caused by: org.gradle.api.tasks.TaskInstantiationException: Could not create task of type 'CustomTask'.
...
Caused by: groovy.lang.MissingPropertyException: cannot get property 'myProp' on extra properties extension as it does not exist
...
BUILD FAILED
Note that this seems to work if:
the custom task is defined in the root project alongside the extra property
if you use dynamic properties instead of extra properties, but those are deprecated
The recommended syntax for reading an extra property named foo in a build script is foo or project.foo (rather than ext.foo), which will also search the parent projects' (extra) properties. EDIT: In a task class, you can use project.foo.
It's important to note that extra properties are only meant for ad-hoc scripting in build scripts; task classes and plugins should not use them. A task class shouldn't reach out into the Gradle object model at all; instead, it should declare properties (and, if necessary, methods) which allow build scripts and/or plugins to supply it with all information that it needs. This makes it easier to understand, reuse, and document the task class, and makes it possible to declare inputs and outputs via #Input... and #Output... annotations.
PS: Instead of calling doFirst in a constructor, a task class usually has a method annotated with #TaskAction.
We've a master build script that is used to build our source code. It has a finite set of expected properties which may be passed into it - Defaults are used for properties that aren't passed in.
Is there a way to display an error when an unexpected property is passed to this script? I'm not sure how to iterate the properties which I'd think would be a necessary function.
It is possible to retrieve all defined / evaluated properties of the current msbuild process using a custom task. See this SO question and answers for reference: How to access the MSBuild 's properties list when coding a custom task?