If I have:
build.gradle
System.out.println("${tasks.bootJar.mainClassName}")
Main class name has not been configured and it could not be resolved
So I comment out System.out.println, run the build again. Success.
Now if I uncomment out my System.out.println the main class name properly prints until I do a gradle clean.
Clearly some predicate job is running and being cached and that result is necessary for the println to work. Can anyone tell me how I can figure out which task it is and how to force it first?
I still don't understand how to properly troubleshoot this (ie a good reference on debugging task ordering and such). In my particular instance, browsing around on Github I found a more specific property which seems to always be available for mainClassName
tasks.bootJar.properties.mainClassName
Related
I've found this code at work in build.gradle
configurations {
all {
resolutionStrategy {
cacheDynamicVersionsFor 0, 'seconds'
}
}
integration
}
I can't find anywhere what integration keyword stands for. Can you explain to me?
In this example, the build is declaring a new configuration called integration. And a configuration can for the most part be thought of as a bucket or collection of dependencies. If a plugin or the Gradle core new about a particular configuration, there would usually be no need to declare it as it would already exist to begin with.
Let's assume that 'integration' is short for 'integration test'. Then what's going on here is that your build is saying: "Hey, I need a bunch of dependencies for running my integration test, but I don't want to pollute the classpath for the other kinds of runtime environments. So please make me a bucket of dependencies to isolate the integration test".
Later in the build file (which you didn't show), you will then find a dependencies block where the integration configuration is populated with the modules needed for running the test. And lastly, some task that actually uses it, presumably for setting the classpath.
It could be used for a number of other things of cause. But whatever it is, it is probably something custom and you could rename it (and all references to it) to 'aCollectionOfAwesomeDependenciesUsedForRunningOurIntegrationTest' if you like.
I have a Spring-Boot Gradle 4.10.3 project which is currently working fine. It uses gradle-release plugin for releases and version management.
However, I now have a new requirement that the artifacts generated for this project adhere to SemVer conventions. I know there are SemVer Gradle plugins, but I don't want to retool my entire release process if I don't have to. It would be great if gradle-release would let me specify a filename pattern.
The config docs mention a parameter called versionPatterns, which seems like it might be helpful. But I can't figure out how to modify the example given:
versionPatterns = [
/(\d+)([^\d]*$)/: { Matcher m, Project p -> m.replaceAll("${(m0 as int) + 1}${m[0][2]}") }
]
So, what I need is my file name to change from:
AppName-1.2.3-SNAPSHOT.jar
To:
AppName.1.2.3-SNAPSHOT.jar
So really it seems like simply a matter of replacing the first dash with a dot.
Can this be done with gradle-release config? If not, is there an easier way? I would like to continue using gradle-release plugin, because it is already wired in for all of my processes.
I seem to have achieved my goal by configuring the bootJar section.
I'm using an older Gradle version, so I am using some deprecated properties. But adding the following to bootJar seems to be doing the trick. Still interested in other/better ideas.
archiveName = "$baseName.$version.$extension"
What is the purpose of:
annotationProcessor "org.springframework.boot:spring-boot-autoconfigure-processor"
My application is working fine with or without it. The thin jar that I create, is also working fine in dependent project.
I am asking this because that line is working fine when I include it in local build.gradle. But as soon I push it to cloud, I get this error:
Could not find method annotationProcessor() for arguments [org.springframework.boot:spring-boot-autoconfigure-processor] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
So I was thinking to do without it. I am not seeing any affect on the thin jar or the dependent project.
Also, This page says that I must use annotationProcessor in build.gradle when using Gradle 4.6 or above. What if I use compileOnly option in Gradle 4.8?
spring-boot-autoconfigure-processor is an annotation processor that generates the file META-INF/spring-autoconfigure-metadata.properties for inclusion in your project's jar. This file helps with startup time, but is not necessary for your app to function correctly.
From the docs:
If that file is present, it is used to eagerly filter
auto-configurations that do not match, which will improve startup
time.
Our project recently started separating our unit and integration tests, which used to all be contained within the same package. We created a task to kick off our integration tests:
task intTest(type: test){
systemProperty ..., System.properties[...]
systemProperty ..., System.properties[...]
include '**/*Int*.java','**/*.func*.java','my.path.to.api.files.*'
}
However I"ve noticed that none of our Integration nor Functional tests are running. From what I can see our pattern looks correct. Any ideas as to why they're not being kicked off?
I am running from CLI using gradle :application:intTest
This works correctly. We had a dependency issue which was breaking us.
My app.gradle file was inheriting from a common.gradle file. The common.gradle file had the same name for one of the tasks, which was breaking the tests. I changed the name and it works perfectly now.
Summary: I'm trying to access project properties (such as the version) in Java, and everywhere I've read says I need to expand properties in my build.gradle file. That's all fine and dandy, but I'm using LDAP and am configuring it in my properties file. Whenever I try to expand properties, I get the LDAP error 49 52e (Invalid Credentials), so it seems that whatever Gradle does to process the properties warps the LDAP properties so they are no longer usable.
Project Info:
I've outlined what I've thought to be the applicable project info below. If there are further details needed to determine the issue, comment and I'll add them.
Language:
Groovy 2.4
Java 8
Framework:
Spring Boot version: 1.3.1.RELEASE with starter POM
spring-boot-starter-security included
spring-security-ldap included
Build Tool: Gradle
Version 2.3
Spring Boot Gradle Plugin 1.3.1.RELEASE
Applied Plugins:
groovy
spring-boot
Build Info: I've tried a few different configurations in my build.gradle file to acess the version, but the moment I add the 'processResources' block, I can no longer access LDAP when running the application. The application runs and authenticates just fine without a 'processResources' block, but as soon as I add it, it will run, but I can't access anything due to LDAP complaining about invalid credentials. I tried 3 different expand configurations and all behaved this way.
Build Config Attempt 1:
processResources {
expand(project.properties)
}
Build Config Attempt 2:
processResources {
filesMatching('**/*.properties') { expand(project.properties) }
}
At this point it occurred to me that I'm configuring my LDAP login in a properties file, so maybe the solution was to avoid properties files altogether. I found out that you can supposedly just expand the properties you need, so I tried the following.
Build Config Attempt 3:
processResources {
expand projectVersion: project.version
}
As stated before, all of the above attempts failed and I still got LDAP authentication errors for each of them. A build.gradle file without a 'procesResources' block seems to be the only way to keep LDAP happy.
Properties Info: As stated before, I configured LDAP information in my properties files. Below are the relevant properties.
application.properties
spring.profiles.active=localdev
ldap.securitygroup=DEV
logout.path=
host.securePort=
As you can see, I'm using a localdev profile, so I've included the applicable properties from it below. Since it included sensitive information, I've only specified the property names and not their values. I've used a star (*) to indicate that there was a non-empty value provided. (in the above application.properties file the values were indeed empty for a couple of the properties listed):
application-localdev.properties
host.securePort=*
ldap.username=*
ldap.password=*
ldap.base=DC=*,DC=*,DC=*
ldap.roleSearchBase=OU=*,DC=*,DC=*,DC=*
ldap.defaultUrl=ldap://*
ldap.urls=ldap://* ldap://*
The properties didn't change at all, it just all worked without the processResources block in the build.gradle file, and then didn't when I added any of those 3 versions of it.
Any assistance to help figure this help would be greatly appreciated, and if any further information is needed, let me know and I'll update this.
So a co-worker gave me a great tip and said I could check the properties in the JAR file to see if there were different from what was originally specified.
Long story short, when I don't have a processResources block in the build.gradle file, the properties don't change and everything's happy. However, when processResources is added, ESCAPE CHARACTERS ARE REMOVED, causing the username to change, since I had an escape character in it.
The workaround I'm now using is to double up on the escape characters, which seems like a hack to me, so if there's a better way to configure this, please reply!