There are several standard Java dependencies that have forks with the same maven coordinates and a "redhat-xxx" suffix in their version number, for example
commons-configuration:common-configuration
org.eclipse.microprofile.config:microprofile-config-api
javax.enterprise:cdi-api
My question is
(How) can I configure renovate to exclude all dependencies whose version matches /redhat-\d+$/ ?
There is a similar question here, but that asks for a more restricted set of dependencies. If I were to define a packageRule like
{
"packageRules": [
{
"groupName" : "Exclude all redhat-xyz versions"
"matchPackagePatterns": [".*"],
"allowedVersions": "!/redhat-\\d+$/"
}
]
}
It would group all dependencies into one giant pull request which isn't helpful.
Try to set registryUrls to standard Maven repo so that Redhat dependencies and such are not checked:
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:base"],
"packageRules": [{
"matchManagers": ["maven"],
"registryUrls": ["https://repo.maven.apache.org/maven2"],
}]
}
or use your given config and add "enabled": false
Related
According to the Spring Boot gradle plugin reference, I should be able to package a particular pattern of jars into a specific layer (for making better docker files).
I'm confused about the pattern matching used in the documentation. Here's an example:
tasks.getByName<BootJar>("bootJar") {
layered {
isIncludeLayerTools = true
application {
intoLayer("spring-boot-loader") {
include("org/springframework/boot/loader/**")
}
intoLayer("application")
}
dependencies {
intoLayer("module-dependencies") {
include("com*:*:*")
}
intoLayer("dependencies")
}
layerOrder = listOf("dependencies", "spring-boot-loader", "module-dependencies", "application")
}
}
What I don't understand is what this pattern matching is matching on:
intoLayer("module-dependencies") {
include("com*::")
}
Is it the group, artifact and version of a jar ? Is it the name of the jar ?
If I have a multi-module project that has modules aa,ab and ac, equating to aa.jar, ab.jar and ac.jar and an external dependency org.something:anartifact:25 equating to anartifact-25.jar what pattern do I need to add to include aa,ab and ac in one layer and every other dependency in another layer ?
For module dependencies the pattern is <group>:<artifactid>:<version>. You can using trailing wildcard to match a subset of items or omit the item entirely to match everything. For example, com.fasterxml.jackson:: will match all artifact and all versions in the com.fasterxml.jackson group.
In the case of a multi-module project, by default the artifactid is the name of the project and the group is the value of the group value set in your build.gradle.
It's usually common to define the group in the root project's build.gradle file, for example:
allprojects {
group "com.example"
version = '0.0.1-SNAPSHOT'
repositories {
mavenCentral()
}
}
You can then define the layer patterns as follows in your application module:
bootJar {
layered {
application {
intoLayer("spring-boot-loader") {
include("org/springframework/boot/loader/**")
}
intoLayer("application")
}
dependencies {
intoLayer("module-dependencies") {
include("com.example:*:*")
}
intoLayer("dependencies")
}
layerOrder = [ "dependencies", "spring-boot-loader", "module-dependencies", "application" ]
}
}
I've uploaded a sample to https://github.com/philwebb/mutli-module-layered-gradle-example that shows this in a complete project.
I have a Spring Boot web application with actuator enabled. When I open <app_url>/info, I see below
{
"git": {
"commit": {
"time": "2016-08-31T17:53:28.000+0000",
"id": "0a52a2f"
},
"branch": "master"
},
"build": {
"version": "unspecified",
"artifact": "my-app",
"name": "my-app",
"group": "",
"time": "2016-09-02T21:09:42.000+0000"
}
}
I'm not sure how to generate a version number here. I want to use Semantic Versioning MAJOR.MINOR.PATCH+timestamp+Build_Number
What is the general consensus w.r.t storing build information of a package ? I don't want to store it in application.yml because it is managed by Puppet and is external to the application war. I would like it to be generated by Jenkins into some file and Spring Boot can pick it up from that file. Should I let Jenkins write into build-info.properties that is generated by spring-boot-gradle-plugin buildInfo ? or should the version be generated by Gradle itself when it generates the file? How does Gradle know MAJOR.MINOR.PATCH details ? I'm running out of ideas on how to integrate all these together.
A little late, but this is how I am doing it (seems to work).
springBoot {
buildInfo {
additionalProperties = [
"version" : System.properties["version"] != null ? System.properties["version"] : "unspecified"
]
}
}
and then in my Jenkins Pipeline
./gradlew clean build -Dversion=${MAJOR}.${MINOR}.${PATCH}
The output jar then will have a build-info.properties
build.version=1.0.1
I am looking in to a build.gradle file and it has the below git configuration section. Trying to find definition of each parameter in it, but could not find on web.
For instance it is not available in:
https://docs.gradle.org/current/dsl/
Where can I find this documentation.
scmVersion {
repository {
type = "git"
directory = project.rootProject.file("./")
remote = 'origin'
}
checks {
uncommittedChanges = true
aheadOfRemote = false
}
tag {
prefix = 'xxx-client'
}
}
scmVersion in your case is probably the axion-release-plugin. You didn't provide the full gradle build script content, but it could contain somthing like:
plugins {
id 'pl.allegro.tech.build.axion-release' version '1.3.2'
}
That means, that in some cases, you will not find a DSL definition on official Gradle sources, you need to look up a plugin documentation in that case. Here is the documentation you are looking for.
I'm using a local ivy repository as following:
repositories {
ivy {
url = "${project.rootDir.absolutePath}/../ivy/ivy-repositories/shared/"
layout "pattern", {
artifact "[organisation]/[module]/[revision]/[type]s/[artifact].[ext]"
ivy "[organisation]/[module]/[revision]/ivy.xml"
}
resolve.dynamicMode = true
}
}
I'm using the distribution plugin and set content with:
distributions {
main {
contents {
into ('libs')
{ from {
project(':x-impl').configurations.runtime
} }
}
}
My problem is that the filename of the resolved artifacts (jars) lacks the version. Ie 'commons-codec.jar' instead of 'commons-codec-1.6.jar'. Both on my Eclipse classpath and in the distribution.
Is there any way i can let the version be part of the filename? I can not (easily) change the layout/pattern of the local ivy repository.
Thins question was originally asked at the gradle community but received no answers:
http://gsfn.us/t/4iiml
Thanks,
Andreas
I am using Java 8 with Gradle and trying to add the Google checkstyle rules into the build, but what I get is this error:
"Expected file collection to contain exactly one file, however, it contains 14 files."
My configuration is:
apply plugin: 'checkstyle'
configurations {
checkstyleConfig
}
def versions = [
checkstyle: '8.8',
]
dependencies {
checkstyleConfig "com.puppycrawl.tools:checkstyle:${versions.checkstyle}"
}
checkstyle {
toolVersion = "${versions.checkstyle}"
config = resources.text.fromArchiveEntry(configurations.checkstyleConfig, 'google_checks.xml')
}
The issue here is that configurations.checkstyleConfig includes multiple JAR files: com.puppycrawl.tools:checkstyle, as well as all of its transitive dependencies. Debugging the issue locally, I see that these dependencies are being included:
antlr:antlr:2.7.7
com.google.code.findbugs:jsr305:1.3.9
com.google.errorprone:error_prone_annotations:2.1.3
com.google.guava:guava:23.6-jre
com.google.j2objc:j2objc-annotations:1.1
com.puppycrawl.tools:checkstyle:8.8
commons-beanutils:commons-beanutils:1.9.3
commons-cli:commons-cli:1.4
commons-collections:commons-collections:3.2.2
commons-logging:commons-logging:1.2
net.sf.saxon:Saxon-HE:9.8.0-7
org.antlr:antlr4-runtime:4.7.1
org.checkerframework:checker-compat-qual:2.0.0
org.codehaus.mojo:animal-sniffer-annotations:1.14
The fix for this is fortunately very simple. All you need to do is exclude the transitive dependencies from the Checkstyle dependency, and the rest of your script will work the way you want it to:
dependencies {
checkstyleConfig("com.puppycrawl.tools:checkstyle:${versions.checkstyle}") { transitive = false }
}
btw, for future reference, there's no need to add a new configuration to use this, it's just a matter of filtering the checkstyle dependency from the existing configuration used by the plgin.
This is the config I use:
checkstyle {
config = resources.text.fromArchiveEntry(
configurations.checkstyle.find { it.name.contains('checkstyle') },
'google_checks.xml'
)
}
For anyone interested, this is the Kotlin DSL variant of the config from #thiago answer:
checkstyle {
config = resources.text.fromArchiveEntry(
configurations.checkstyle.get().find { it.name.contains("checkstyle") }!!,
"google_checks.xml"
)
}