In Gradle's Java projects we can use PMD via pmd plugin. To configure the rules which we want to use can do it in two ways:
ruleSetFiles - The custom rule set files to be used. See the official documentation for how to author a rule set file. Example: ruleSetFiles = files("config/pmd/myRuleSet.xml")
ruleSetsThe built-in rule sets to be used. See the official list of built-in rule sets.
With ruleSetFiles there is no problem you can find the names of the rules and to add or exclude ones, but in the documentation there is no information about the ruleStes? From where to find the exact names? From what I found from another projects the names are similar to the names from the PMD documentation but lower case. For example:
Braces - > java-braces
Clone - > java-clone
Implementation - >java-implementation
Code Size - > java-codesize
But this like Security Code Guidelines do not transform in -> java-securitycodeguidelines but just in java-sunsecure. I found that the names which works with PMD 5.1.1. are:
pmd {
ruleSets = [
'java-android',
'java-basic',
'java-braces',
'java-clone',
'java-codesize',
'java-comments',
'java-controversial',
'java-coupling',
'java-design',
'java-empty',
'java-finalizers',
'java-imports',
'java-j2ee',
'java-javabeans',
'java-junit',
'java-logging-jakarta-commons',
'java-logging-java',
'java-migrating',
'java-naming',
'java-optimizations',
'java-strictexception',
'java-strings',
'java-sunsecure',
'java-typeresolution',
'java-unnecessary',
'java-unusedcode'
]
toolVersion = '5.1.1'
ignoreFailures = true
}
How to find mapping between PMD names which are shown in their documentation and Gradle names?
The docs for RuleSetReferenceId are helpful, as is I believe this directory in the source tree. Basically put java- in front of any of these files to turn on the rules there.
Related
Following the setup described in Simple sharing of artifacts between projects, we are in the special case where we have a multi module gradle build that produce different types of jars and we would like to declare a dependency to those jar in a configuration.
dependencies {
instrumentedClasspath(project(path: ":producer", configuration: 'instrumentedJars'))
}
from the docs works great.
In the project dependency-tests I have a project that reproduce the setup (with different names, but the idea is the same).
But I am doing this in a Gradle-plugin and I would like to have the same declaration in java.
DependencyHandler dependencyHandler = project.getDependencies();
// this adds a dependency to the main jar of the 'producer' project:
dependencyHandler.add("instrumentedClasspath", project.getRootProject().findProject(":producer"));
// this is not working:
dependencyHandler.add("instrumentedClasspath", project.getRootProject().findProject(":producer").getConfigurations().getByName("instrumentedJars"));
Failing with:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':printConf'.
> Could not resolve all dependencies for configuration ':instrumentedJars'.
> Cannot convert the provided notation to an object of type Dependency: configuration ':producer:instrumentedJars' artifacts.
The following types/formats are supported:
- Instances of Dependency.
- String or CharSequence values, for example 'org.gradle:gradle-core:1.0'.
- Maps, for example [group: 'org.gradle', name: 'gradle-core', version: '1.0'].
- FileCollections, for example files('some.jar', 'someOther.jar').
- Projects, for example project(':some:project:path').
- ClassPathNotation, for example gradleApi().
Comprehensive documentation on dependency notations is available in DSL reference for DependencyHandler type.
* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
project(...)
inside the dependencies block comes from the DependencyHandler, and
path: ":producer", configuration: 'instrumentedJars'
is actually a map {"path"=":producer", "configuration"="instrumentedJars"}.
So something like that should work in Java:
Map<String, String> map = new HashMap<>();
map.put("path", ":producer");
map.put("configuration", "instrumentedJars");
dependencyHandler.add("instrumentedClasspath", dependencyHandler.project(map));
Note: When using Kotlin build script you can easily see types and declarations of functions and might be easier for discovering API. So in Kotlin project(...) in the dependencies block is an extension method defined as:
fun DependencyHandler.project(
path: String,
configuration: String? = null
): ProjectDependency =
uncheckedCast(
project(
if (configuration != null) mapOf("path" to path, "configuration" to configuration)
else mapOf("path" to path)
)
)
I am building my own ROM and want to use a aar file Library in one system service.
Is there any way this could be achieved?
If you are using Android.bp this can be done via android_library_import module type (link to soong spec).
Also, if you try to grep the AOSP source tree, you will easily find many examples of its use, for example: packages/apps/Settings/Android.bp:
android_library_import {
name: "contextualcards",
aars: ["libs/contextualcards.aar"],
}
android_library {
name: "Settings-core",
....
srcs: ["src/**/*.java"],
static_libs: [
...
"contextualcards",
...
}
When generating the Javadoc, it adds on prefix to the imported class name, as shown below on the first line 'java.lang'.
How to properly disable that?
Have tried adding -noqualifier in Other command line arguments in my IntelliJ popup window but the following error occurred:
javadoc: error - Illegal package name: "/Users"
Below is a snippet from the Javadoc I generated:
public TrainRoute(java.lang.String name,
int routeNumber)
Creates a new TrainRoute with the given name and number.
Should meet the specification of Route.Route(String, int)
Parameters:
name - The name of the route.
routeNumber - The route number of the route.
I know this is an old question, but still relevant. I am aware of two solution which can be used alone or in combination:
To suppress prefixes on java packages use:
-noqualifier java.*
To suppress prefixes and link to the actual Java docs use:
-link https://docs.oracle.com/javase/8/docs/api
Both suppress the java name qualifiers. The second also links to the Oracle docs.
See javadoc options docs for more info.
In my Skylark rule, I am looking through all my deps - some of them are maven_jar instances defined in my WORKSPACE file. For those, I would like to access the value of maven_jar.artifact, but as far as I can tell it isn't available. Is it possible to get at that value?
For example, if my WORKSPACE has:
maven_jar(
name = "com_google_guava_guava",
artifact = "com.google.guava:guava:20.0",
)
And my BUILD file has something like this:
my_rule(
name = "foo",
deps = ["#com_google_guava_guava//jar"]
)
In the implementation of my_rule, I would like to get the value com.google.guava:guava:20.0.
I think you'll need to file a feature request for this:
https://github.com/bazelbuild/bazel/issues/new
The instance of the maven_jar rule in the workspace file isn't available to the rules in BUILD files, only the rules which the workspace rule generates are (i.e., #com_google_guava_guava//jar). Off the top of my head, maven_jar would have to generate a rule into the jar's workspace which has an attribute with the value of artifact, and that rule would need to create a provider containing that value for other rules to consume.
(There does happen to be META-INF/maven/com.google.guava/guava/pom.xml inside the jar, which seems to have the information you want, but I don't know if you can rely on that for all jars from maven, but either way, the contents of the jar aren't available at analysis time (within the rule implementation))
Is there a Java library similar to libconfig for C++, where the config file is stored in a JSON-like format that can be edited by humans, and later read from the program?
I don't want to use Spring or any of the larger frameworks. What I'm looking for is a small, fast, self-contained library. I looked at java.util.Properties, but it doesn't seem to support hierarchical/nested config data.
I think https://github.com/typesafehub/config is exactly what you are looking for. The format is called HOCON for Human-Optimized Config Object Notation and it a super-set of JSON.
Examples of HOCON:
HOCON that is also valid JSON:
{
"foo" : {
"bar" : 10,
"baz" : 12
}
}
HOCON also supports standard properties format, so the following is valid as well:
foo.bar=10
foo.baz=12
One of the features I find very useful is inheritance, this allows you to layer configurations. For instance a library would have a reference.conf, and the application using the library would have an application.conf. The settings in the application.conf will override the defaults in reference.conf.
Standard Behavior for loading configs:
The convenience method ConfigFactory.load() loads the following
(first-listed are higher priority):
system properties application.conf (all resources on classpath with
this name)
application.json (all resources on classpath with this
name)
application.properties (all resources on classpath with this
name)
reference.conf (all resources on classpath with this name)
I found this HOCON example:
my.organization {
project {
name = "DeathStar"
description = ${my.organization.project.name} "is a tool to take control over whole world. By world I mean couch, computer and fridge ;)"
}
team {
members = [
"Aneta"
"Kamil"
"Lukasz"
"Marcin"
]
}
}
my.organization.team.avgAge = 26
to read values:
val config = ConfigFactory.load()
config.getString("my.organization.project.name") // => DeathStar
config.getString("my.organization.project.description") // => DeathStar is a tool to take control over whole world. By world I mean couch, computer and fridge ;)
config.getInt("my.organization.team.avgAge") // => 26
config.getStringList("my.organization.team.members") // => [Aneta, Kamil, Lukasz, Marcin]
Reference: marcinkubala.wordpress.com
Apache Commons Configuration API and Constretto seem to be somewhat popular and support multiple formats (no JSON mentioned, though). I've personally never tried either, so YMMV.
There's a Java library to handle JSON files if that's what you're looking for:
http://www.json.org/java/index.html
Check out other tools on the main page:
http://json.org/