Caused by: org.gradle.api.GradleException: Could not create ZIP '/jenkins/repository/workspace/profile/build/libs/../profile.jar'.
Project
common << I build under this directory
profile
build.gradle(in common)
...
dependencies {
compile project(':../profile')
...
settings.gradle(in common)
include '../profile'
It works on windows environment. But it does not work on linux environment even using root account
The project paths accepted by the include and project methods are logical paths, not physical paths. They cannot contain a ... Physical paths must be declared separately in settings.gradle (if they divert from the logical path). The easiest way to declare a flat physical directory layout is to use the includeFlat method:
common/settings.gradle
includeFlat 'profile'
common/build.gradle
dependencies {
compile project(':profile')
}
You can find more information on this topic in the "multi-project builds" chapter of the Gradle User Guide.
Another common issue that can happen here especially if you're using windows is you could have opened the previous jar up in 7zip or some other tool and that's causing the file to be locked. To test this try to delete the jar that's sitting in build/libs if you can't delete the file it's locked by another program more than likely. :D
An even shorter way to fix this: Add the following line to the build.gradle file of the included profile project:
archivesBaseName = 'profile'
This overwrites the default name of the jar.
Related
I have following part of the build.gradle:
def external = file('../external').absolutePath
repositories {
maven {
url file(external).toURI()
}
}
dependencies {
api 'ch.qos.cal10n:cal10n-api:0.7.7'
}
Third-party library that my project uses is stored in the ../external/ch.qos.cal10n/cal10n-api/0.0.7/(.jar and .pom).
However when running gradle build I got following:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
> Could not find ch.1qos.cal10n:cal10n-api:0.7.7.
Searched in the following locations:
- file:/home/a/b/external/ch/1qos/cal10n/cal10n-api/0.7.7/cal10n-api-0.7.7.pom
Why /home/a/b/external/ch/1qos/cal10n/cal10n-api/0.7.7/cal10n-api-0.7.7.pom
and not /home/a/b/external/ch.1qos.cal10n/cal10n-api/0.7.7/cal10n-api-0.7.7.pom ?
UPD: .pom and .jar files are downloaded manually from Maven Repository and placed into /home/a/b/external/ch.1qos.cal10n/cal10n-api/0.7.7/`
Because that is the layout of local-maven repositories, i.e., the group will be turned to directories. This is in part for performance and usability reasons. Consider the alternative, you'd have one huge directory containing all the groupIds. Working with directories with lots of entries slows down processing a lot. Instead, this layout is hierarchical, reducing the number of files/sub-directories per directory.
So to solve your problem, just change your directory layout accordingly.
/home/a/b/external/ch.1qos.cal10n/cal10n-api/0.7.7/cal10n-api-0.7.7.pom
->
/home/a/b/external/ch/1qos/cal10n/cal10n-api/0.7.7/cal10n-api-0.7.7.pom
I got some source code and was asked to build it. It was a Gradle project. So I changed to the project directory and ran:
$ gradle clean assemble
and the following error came up:
...
* What went wrong:
A problem occurred evaluating root project 'pcase'.
> Could not get unknown property 'postgresql.jdbc' for root project 'pcase' of type org.gradle.api.Project.
...
There is a settings.gradle file in the project folder too. It contains:
rootProject.name = 'pcase'
I took a look at build.gradle and found lots of occurrences like
${project['x']}
For example:
buildscript {
dependencies {
...
// FlywayDB, JOOQ.
classpath "org.postgresql:postgresql:${project['postgresql.jdbc']}"
classpath "org.flywaydb:flyway-gradle-plugin:${project['flywaydb.plugin.version']}"
classpath "nu.studer:gradle-jooq-plugin:${project['jooq.plugin.version']}"
...
What could be ${project['x']}? Looks like associative array in bash and the build script tries to get the value of the key 'x'.
But I didn't find the place in code where this array would be declared and initialized.
The question is: Is the project buildable or is it better to consult the company that worked at it before me?
From the information provided, the project is perfectly buildable, to some certain extend. First of all, project['a.b.c'] is Groovy syntax to access properties from the project object. They're referred to as project properties.
They can be set via
Project properties via command line: gradle -Ppostgresql.jdbc=x.y.z
System properties via command line: gradle -Dorg.gradle.project.postgresql.jdbc=x.y.z
System properties via gradle.properties: org.gradle.project.postgresql.jdbc=x.y.z
All 3 properties (postgresql.jdbc, flywaydb.plugin.version, jooq.plugin.version) denote the version numbers of the particular build script dependencies. However, which versions to use best is beyond my knowledge. I would certainly consult the respective project websites, Maven artifact search or simply ask the company.
org.postgresql:postgresql is the database JDBC driver and certainly depends on the database version.
org.flywaydb:flyway-gradle-plugin is for database migrations. Try with the latest version.
I wasn't able to find gradle-jooq-plugin on Maven central. It's most likely available on the Gradle Plugin Portal.
I want to add a subproject to my Gradle project. The project is located somewhere on my hard disk drive, for example:
/A/Path/to/a/ProjectA
/Another/Path/to/another/ProjectB
What I want to achieve is to use ProjectB as a source module within Project A. However, all my attempts to do this so far - either by adding include /Another/Path/to/another/ProjectB or by adding include ':ProjectB'; project(':ProjectB').projectDir = ... in settings.gradle - just failed. Apparently, Gradle is not able to find the project.
How can I add ProjectB as a dependency without moving it from it's location?
Using Gradle 3.4.1, the following works for me (full example here):
include 'app', 'common'
def MY_PATH = '/Users/johndoe/foo'
assert new File("$MY_PATH/random/path/common").exists()
project(':common').projectDir = new File("$MY_PATH/random/path/common")
Thanks for your responses.
Turns out I've made several mistakes:
Adding the project to the built was dependent on the value of an environment variable. I replaced that with a property within gradle.properties.
I tested this by running the settings.gradle usind IntelliJ. I mistakingly expected this to work, but it didn't
I did not add the project as a dependency to the build.gradle file of the parent project.
It works now. Thank you all again!
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.
I'd like to create a subproject that acts as sole anchor for dependencies, ie. it includes no source code. Users can simply depend on the artifact created by the subproject in order to get all the required dependencies. So i've created foo-bar/build.gradle:
dependencies {
compile project(":foo-barz")
compile project(":foo-batz")
}
jar {
enabled = false
}
That seems to work as expected, until signing comes into the build process. I've then get an error message
:foo-bar:signArchives FAILED
What went wrong: Execution failed for task ':foo-bar:signArchives' >
java.io.FileNotFoundException:
/data/flo/code/foo/foo-bar/build/libs/foo-bar-4.0.1.jar (No such file
or directory)
How can I tell the signing plugin that it needs to sign just the pom file for this subproject?
I'd say either do not apply the java plugin, then you also don't need to disable the jar task, or also disable the signArchives task like you disabled the jar task.
I've came up with just creating an empty file with
foo-bar/src/main/java/org/foo/bar/FooBarDummy.java
so that all tasks are happy and an empty jar is created, signed and deployed. Thaks to Peter Niederwieser, Vampire and Daryl Teo for their input. I've found no elegant an easy solution to avoid that Dummy.java workaround.
This question was based on implementing smack-java7