Maybe I'm missing something about the way Gradle works. What I have here is a parent project, which only contains configuration, i.e. there won't be any artifact being built when building it, it merely manages and builds all its subprojects.
Now the subprojects share some dependency configuration, so I figured what I would do in the root project's build.gradle is:
subprojects {
dependencies {
compile fileTree(dir: 'lib', includes: ['*.jar'])
}
}
that, however, does not work, it fails with a rather obscure error message:
A problem occurred evaluating root
project 'qype-android' Cause: No
signature of method:
org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.compile()
is applicable for argument types:
(org.gradle.api.internal.file.DefaultConfigurableFileTree)
values: [file set 'lib'] Possible
solutions: module(java.lang.Object)
after some trial and error, I could "fix" this issue by applying the 'java' plugin to the parent project.
How come? I don't see anywhere from the Gradle docs that a fileTree dependency requires the Java plugin. Even so, why would I need it on the project that is injecting the configuration, as opposed to on the project that is being configured (note that the subprojects all apply the Java plugin themselves)?
Does this mean that if I have N different subprojects that are all of varying natures, and apply different plugins, that the parent projects must always apply the set of all plugins beings used somewhere to itself, too?
It is not the fileTree that requires 'java' plugin.
The error message is complaining about undefined compile dependency configuration. Java plugin defines this configuration for you, so that you can add dependencies (including your fileTree) to it.
Related
I use Jenkins to build Gradle, but there was a problem when reading the settings.
I use the 'net.linguica.maven-settings' plugin and in build.gradle wrote the line:
mavenSettings { userSettingsFileName = project.property('maven.settings.location) }
And now I can run the build like this:
gradle -Pmaven.settings.location=/u01/test.xml clean build publish
But when building, I get dependency errors.
Could not resolve org.springframework.boot:spring-boot-configuration-processor:2.1.6.RELEASE.
Required by:
project :
Skipped due to earlier error
Could not resolve org.junit.jupiter:junit-jupiter-api:5.8.0.
What do I need to do?
Maven doesn't intrinsically know where to get dependencies from. It will look to the setting.xml for a list of repositories and look for any dependencies from there. If you list multiple repositories is will check each one until it finds the dependencies listed in the pom file.
I suspect because you are overriding the settings the file you are using doesn't have a repository listed which has the dependency you need.
That is what the error message is telling you - "I looked though all the registries I know about but couldn't find org.junit.jupiter:junit-jupiter-api:5.8.0 in any of them"
You can read a bit about it here https://maven.apache.org/settings.html under "Repositories"
I'm implementing unit tests for code used in a Jenkins Pipeline Shared Groovy Library. Specically, I need to mock the steps object available in the Jenkinsfile, which is an instance of org.jenkinsci.plugins.workflow.cps.DSL. In my Gradle build I've specified a dependency like so:
testCompile group: 'org.jenkins-ci.plugins.workflow', name: 'workflow-cps', version: '2.30', ext: 'jar'
which is the project hosting the class above. Without specifying the ext as a JAR, Gradle retrieves the .hpi file since this is the packaging defined in the project's pom.xml; obviously I need to override this and fetch the JAR for my project. However, in doing this Gradle does not download the transitive dependencies of the workflow-cps JAR and I find myself having to populate my build.gradle with all the dependencies determined via trial and error. Is there a way to retrieve the transitive dependencies, or is this a limitation of the workflow-cps project and how it defines its pom.xml?
The CPS class you're wanting to mock won't contain methods/variables introduced by plugins or your workflow lib, so this approach probably won't be fully satisfying.
Facing the same challenge I took the pragmatic approach of making my own TestScript interface in my test sources and Mock that, and not typing the script reference in classes.
The drawbacks are not having IDE code inspection for stuff referencing the script, and having to manually add signatures to TestScript as I add tests (which is also error-prone, since I have manually ensure that those signatures match).
But it works, and avoids getting dragged into plugin dependency hell.
I want to generate a P2 repository from OSGI bundles that reside on maven central.
I have
defined a POM-first feature project using dependencies=consider
defined Maven dependencies with scope compile and type jar
defined a feature.xml with exact references to the bundle symbolic names and versions as declared in their manifest.mf
When I attempt to build the feature, I receive
No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.codehaus.jackson.feature.group 1.9.1.qualifier to jackson-mapper-lgpl [1.9.12,1.9.13).", "Unable to satisfy dependency from org.codehaus.jackson.feature.group 1.9.1.qualifier to jackson-core-lgpl [1.9.12,1.9.13).", "No solution found because the problem is unsatisfiable."]
Where org.codehaus.jackson.feature is the feature I am building and jackson-mapper-lgpl [1.9.12,1.9.13) and jackson-core-lgpl [1.9.12,1.9.13) are the specifications of the OSGI bundles I am trying to include.
When I switch on debug mode, I see that the components are being found, which makes the behavior more odd:
[DEBUG] P2Resolver: artifact org.codehaus.jackson:jackson-core-lgpl:1.9.12 at location /home/jsuess/.m2/repository/org/codehaus/jackson/jackson-core-lgpl/1.9.12/jackson-core-lgpl-1.9.12.jar resolves installable unit jackson-core-lgpl/1.9.12
[DEBUG] P2resolver.addMavenArtifact org.codehaus.jackson:jackson-mapper-lgpl:jar:1.9.12:compile
[DEBUG] P2Resolver: artifact org.codehaus.jackson:jackson-mapper-lgpl:1.9.12 at location /home/jsuess/.m2/repository/org/codehaus/jackson/jackson-mapper-lgpl/1.9.12/jackson-mapper-lgpl-1.9.12.jar resolves installable unit jackson-mapper-lgpl/1.9.12
[DEBUG] Registered artifact repository org.eclipse.tycho.repository.registry.facade.RepositoryBlackboardKey(uri=file:/resolution-context-artifacts#/home/jsuess/workspace/org.codehaus.jackson/features/org.codehaus.jackson)
I believe taking bundles from maven and creating P2 must be a common use case, so I wonder if someone can point me to a working sample POM that I can use as a template.
Note that every module in a Tycho build has a separate target platform.
So if you are using pomDependencies=consider, but you only configure this switch and/or the dependencies on an eclipse-feature module, the POM dependencies will only be in the target platform of the module. If you then try to package the feature into an eclipse-repository, the dependency resolution of that module will fail because of missing (transitive) dependencies of the feature.
In most cases, you don't need different target platforms per module, so in general you should put all target platform configuration and POM dependencies into the parent POM.
If you have done this, but one of your modules still seems to have a different target platform, make sure that the parent POM reference of that module is correct - and that you don't reference an older version of your parent POM.
What's the difference between build, runtime, and compile, in BuildConfig.groovy (1.3.7)
grails.project.dependency.resolution = {
plugins {
build "acme:acme-cache:latest.integration"
}
dependencies {
build "com.foo.bar:foobar:1.0.5"
runtime "org.apache.httpcomponents:httpclient:4.0.3"
compile("com.thoughtworks.xstream:xstream:1.3.1")
}
}
build - dependency that is only needed by the build process
runtime - dependency that is needed to run the application, but not compile it e.g. JDBC implementation for specific database vendor. This would not typically be needed at compile-time because code depends only the JDBC API, rather than a specific implementation thereof
compile - dependency that is needed at both compile-time and runtime. This is the most common case
There are a couple of other dependency scopes:
test - dependency that is only needed by the tests, e.g. a mocking/testing library
provided - dependency that is needed at compile-time but should not be packaged with the app (usually because it is provided by the container). An example is the Servlet API
It seems the 2 previous answers conflict on the distinction between compile and build. I believe that build is the scope that includes grails compile and grails run-app, while compile is just the former.
Starting from Grails 3, dependencies are managed by Gradle. The grails-app/conf/BuildConfig.groovy file has been replaced by the build.gradle file in the project's root.
The Grails user guide explain how to set grails depencies with gradle. See also the related Gradle documentation for further details on managing dependencies using it.
A couple grails commands help illustrate the difference. Consider grails run-app and grails compile. grails compile is the compile step and will include compile-time dependencies. grails run-app is the run step and will include runtime dependencies. Build dependencies are anything that you might need to run any of these commands, for example, a custom script that hooks into some build events.
So you would pick the one that best fits when you need to be certain the dependency is included.
I'm a bit of a Grails newbie. I have an app which works fine in Eclipse but when I deploy in production falls over because of missing dependencies.
When I run the dependency report it shows all the dependencies are automatically present for 'build' but absent for 'runtime'.
What's the neatest way to migrate the dependencies from to runtime so (I hope) they get copied into my war file?
Also, I'm using the sanitizer plugin. This runs fine in development but has the dependencies missing from 'runtime' so falls over. If I manually add, for example, one of the dependencies into BuildConfig.groovy ("org.owasp.antisamy:antisamy:1.4.3") then grails falls over with this error:
loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "org/xml/sax/SAXParseException"
I'm assuming that this is a classpath issue but I'm not sure why this only happens when I manually add the dependency - surely it's present all the time?
You're right, you have to add missing runtime dependencies to BuildConfig.groovy. The simplest thing would be to copy them from the plugin's BuildConfig.groovy to your app's one. You should also raise a JIRA for the respective grails plugin to get this fixed upstream.
Lots of jars out there in the Maven repositories have their dependencies not correctly defined in their pom file.
There is a way to fix that in BuildConfig.groovy, by switching off transitivity:
runtime('org.owasp.antisamy:antisamy:1.4.3') {
transitive = false
}
Instead of 'transitive=false' you might also experiment with excluding only specific dependencies using e.g.
excludes "xml-apis", "xerces"
inside the 'runtime' closure.