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.
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 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"
I am totally new to Gradle (and Groovy syntax) so I have difficulties understanding some concepts.
One of them are dependencies and configurations.
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile 'org.springframework:spring-core:4.1.1.RELEASE'
}
From the above build.gradle file I understand that dependencies is a build script script block (a method which takes a closure as a parameter). It is defined in the Project object.
The compile is a so called configuration. It is defined in the Java plug in.
Is it also a method which takes one argument as a parameter?
How it affects the dependencies script block or the overall build in this case?
The build script is the entire content of a .gradle file, hence the dependencies {} block is not the build script, it's part of the build script.
I would term dependencies {} a configuration block, not in the sense of dependency configurations but in the general sense of configuration. Within that block you define dependency configurations and attach modules/libraries to them.
In answer to your specific questions:
Is it also a method which takes one argument as a parameter?
There are several different syntaxes that you can use, but this is the simplest. It is in effect a method call with one argument that is the dependency coordinate (group:name:version).
How it affects the dependencies script block or the overall build in this case?
I don't really understand this question. It doesn't affect the dependencies {} block. What you're doing is interacting with the Gradle API to model your build. In this case, you're simply telling Gradle that one of the compilation dependencies for your build is Spring Core 4.1.1.RELEASE.
Hope that helps.
While reading this gradle document, I came across this wordings saying that dependencies for each configuration. Here what does this configuration meant to be. Because I usually used to specify the dependencies in such a vague way like
dependencies {
compile 'org.springframework:spring-core:4.0.5.RELEASE',
'org.hibernate:hibernate-core:3.6.7.Final'
}
Is there any other possible way to specify the dependencies(based on configuration)?. I am little curious to know about that.
If yes, what is advantage of specifying dependencies like that. Can someone able to throw some light here?
Also how the below command will be useful?
gradle -q dependencies api:dependencies webapp:dependencies
In Gradle dependencies are grouped into configurations. Configurations have a name, a number of other properties, and they can extend each other. Many Gradle plugins add pre-defined configurations to your project.
These are the configurations added by Java plugin. As you can see, compile is a configuration, it is extended by many other configurations. You can create your own configuration:
configurations {
myConfig {
description = 'my config'
transitive = true
extendsFrom compile
}
}
Also how the below command will be useful?
This command prints the dependencies of main project and api and webapp subprojects.
I have been struggling to figure out what's the use of scoping that is provided by Maven
as mentioned here.
Why should you not always have compile time scoping? Real life examples would be really appreciated.
The compile scoped dependencies are only used during compilation.
The test scoped ones -- only during tests. Say you have tests using junit, or easymock. You obviously do not want your final artifact to have a dependency on them, but would like to be able to just depend on these libraries while running your tests.
Those dependencies which are marked provided are expected to be on your classpath when you're running the produced artifact. For example: you have a webapp and you have a dependency on the servlet library. Obviously, you should not package it inside your WAR file, as the webapp container will already have it and a conflict may occur.
One of the reasons to have different scopes for dependencies is that different parts of the build can depend on different dependencies. For example, if you are only compiling your code and not executing any tests, then there is no point in having Maven downloading your test dependencies (if they're not already present in your local repository, of course). The other reason is that not all dependencies need to be placed in your final artifact (whether it's an assembly, or WAR file), as some of the dependencies are only used during the build and testing phases.
compile
Will copy these jar files into prepared War file.
Ex: hibernate-core.jar need to have in our prepared War.
provided
These jars will be considered only at complie time and test time
Ex:
servlet.jar will be provided by deployed server, so no need to provide from our prepared War file.
test
These jars are only required for running test classes.
Ex: Junit.jar will be required only for running Junit test classes, no need to deploy these.
Scopes are quite well explained in here:
https://maven.apache.org/pom.html#Dependencies
As a reference, I copied the paragraph:
scope: This element refers to the classpath of the task at hand
(compiling and runtime, testing, etc.) as well as how to limit the
transitivity of a dependency. There are five scopes available:
compile
- this is the default scope, used if none is specified. Compile dependencies are available in all classpaths. Furthermore, those
dependencies are propagated to dependent projects.
provided - this is
much like compile, but indicates you expect the JDK or a container to
provide it at runtime. It is only available on the compilation and
test classpath, and is not transitive.
runtime - this scope indicates
that the dependency is not required for compilation, but is for
execution. It is in the runtime and test classpaths, but not the
compile classpath.
test - this scope indicates that the dependency is
not required for normal use of the application, and is only available
for the test compilation and execution phases.
system - this scope is
similar to provided except that you have to provide the JAR which
contains it explicitly. The artifact is always available and is not
looked up in a repository.
there are a couple of reasons that you might not want to have all dependencies to be default compile scope
reduce the size of final artifact(jar,war...) by indicating different scope.
when you have a multiple-modules project, you have ability to let each module have it's own version of dependency
avoid class version collision by provided scope, for instance if you are going deploy a war file to weblogic server, you need to get rid of some javax jars, like javax.servlet, javax.xml.parsers, JPA jars and etc. otherwise you might end up with class collision error.