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"
Related
I am looking for a way to collect all the dependency constraints (enforced with a regular platform and/or enforcedPlatform and/or "manually") for a given project from a custom Gradle plugin.
In Maven world, you can resolve an "artifact descriptor" that will give access to the effective list of all the managed dependencies enforced on the artifact. I couldn't find so far how this kind of info could be collected in Gradle.
Any advice? Thanks!
based on the clarification of the question - below can be a start (requires more work - for some reason my local shows configuration as default - not the compile/runtime)
allprojects {
afterEvaluate {
configurations.findAll {it.canBeResolved==true}.each { println it + "\n" ; it.allDependencies.each { println it } }
}
}
The question (appears to me) is sharing the test code across modules in a multi-module project
Short answer - No - there is direct test dependency share across modules.
To share test code between modules internally via build settings
Official gradle route https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures
Simple hack
testImplementation files(project(':core-module').sourceSets.test.output.classesDirs)
add the above line either individually where you need or in root with subprojects() with appropriate condition
*there are other possible routes as well *
ex: via configuration child.testImplementation extends parent.testImplementation (or runtime)
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.
We have multiple projects/services where we do repeat same configuration over and over again as a part of build.gradle file. Examples could be configuration for spotless plugin, docker, junit/jacoco, versioning, groovy tasks, etc.
I wonder is there a way to externalize it or move to single place so that if needed we can update configuration once instead of doing the same across each and every project.
Very naive idea is to have master-build.gradle file stored in it's own git repo and where needed we can refer it as a git submodule with capabilities to extend/rewrite. Open for any ideas. Thanks!
Gradle scripts can be reused by creating external script files and importing them using apply from: my-script.gradle. apply from also accepts an URL, so you can use something like
apply from: 'https://github.com/user/myproject/raw/master/hello.gradle'
Note tough that using plain references (URLs; or GIT repo URLs) is sub-optimal; a better approach is to identify your build dependencies (and these scripts ARE dependencies!) using group:artifact:version coordinates- that is achieved by writing a plugin and publishing to a repo (eg. to https://plugins.gradle.org/).
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!
How can I use jars that buildr loads by default into the local maven repo, rather than creating new (and repetitive) artifact tasks/dependencies?
For example, if were creating a scala or groovy application buildr would automatically download the scala or groovy jars respectively. Is it possible to include or merge these (default) jars into an application rather than creating a new artifact?
I think that is not possible or doable in a one step, easy way. I recommend you talk with us on the dev list of Buildr and we can probably create an enhancement for that.
For each library you would like to depend on, you usual can grep the code to find where we define the default jar we depend on.
For the example you mention, here are the default method to retrieve the default jars:
For Groovy: Buildr::Groovy::Groovyc.dependencies
For Scala: Buildr::Scala::Scalac.dependencies
I hope that helps.