I have a SpringBoot(2.6.2)/Gradle(7.3.3) application. I am using Jib(3.1.4) to create the docker image. After the image is created and pushed to the registry (successfully), my build would fail with this error -
java.nio.file.NoSuchFileException: <Project-Dir>\build\jib-image.digest
After much trial-and-error and some help from this documentation, I figured out how to make the error go away. What was needed on my build.gradle was this -
jib {
outputPaths.digest = "${buildDir}/jib-image.digest"
outputPaths.imageId = "${buildDir}/jib-image.id"
outputPaths.imageJson = "${buildDir}/jib-image.json"
}
This forces these files to be created in the specified directories.
My questions are -
What are these files?
Why is my build not able to create them under my project diretory (as is the default)?
Why don't I see any discussion on these files anywhere?
Is there another way to avoid this error?
Related
I have a really simple java spring-boot gradle application.
When I build an image from source with:
pack build testapp:0.0.1 --builder paketobuildpacks/builder:base
and try to run it with docker I get the following error:
ERROR: failed to launch: determine start command: when there is no default process a command is required.
The generated Entrypoint in this image is "/cnb/lifecycle/launcher".
When I inspect the image with pack inspect-image there are no processes.
I tried this with different java spring-boot gradle applications. When I use the "bootBuildImage" gradle task, it does nearly the same but uses the pre-build .jar-file and the resulting image works. The generated Entrypoint in this image is "/cnb/process/web" and pack inspect-image shows three processes.
Any ideas?
I can't see your build output, but it sounds like you're hitting a known issue. If this is not your problem, please include the full output of running pack build.
Onto the issue. By default, Spring Boot Gradle projects will build both an executable and non-executable JAR. Because this produces two JAR files, it presently confuses the buildpacks.
There are a couple of solutions:
Tell Gradle to not build the non-executable JAR. The buildpack requires the executable JAR. You can do this by adding the following to your build.gradle file:
jar {
enabled = false
}
This is the solution we have used in the Paketo buildpack samples.
If you don't want to make the change suggested in #1, then you can add the following argument to pack build: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/<your-jar>.jar. For ex: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/demo-0.0.1-SNAPSHOT.jar. You can use glob-style pattern matching here, but you need to make sure that what you enter does not match *-plain.jar. That will be the non-executable JAR that gets built by default.
This option just simply tells the Gradle buildpack more specifically what the JAR file to pass along to subsequent buildpacks.
We also have an open issue that should help to mitigate this problem. When the executable-jar buildpack gains support for multiple JARs, it'll be less likely that you'll need to set this. Essentially, this fill will add support so the executable-jar buildpack can inspect and detect an executable JAR, which would allow it to throw out the -plain.jar file since it's not executable.
I really don't have much experience in developing let alone using build tools.
I was assigned a task to build dependencies locally and get the jar files.
say I have a list of deps (GAV) like this:-
1. org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC
2. com.auth0:java-jwt:3.18.2, etc
3. openapi4j:openapi-operation-validator:1.0.7, etc
So i was able to download the source code url from maven repository and source code from github programmatically, for example :-
org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC - https://github.com/JetBrains/kotlin
com.auth0:java-jwt:3.18.2 - https://github.com/auth0/java-jwt
openapi4j-openapi-operation-validator-1.0.7 https://github.com/openapi4j/openapi4j
but there are many build.gradle files in different directories, how do I know which directory should I move into before running the gradle build command.
Things I have already tried and failed:-
For deps like this openapi4j:openapi-operation-validator:1.0.7, i can directly go into the openapi-operation-validator folder in the Github repo (https://github.com/openapi4j/openapi4j ) and run the gradle build command, but not all projects are structured like that I guess?
For deps like this com.auth0:java-jwt:3.18.2, the artifactId (java-jwt
) is already present in the github path (https://github.com/auth0/java-jwt), so i can run the gradle build command on the root github repo.
From the spring guides , among all the Gradle.build files available I can check which file has:-
jar {
archiveBaseName = <artifactId>
archiveVersion = <version>
}
, then I can move to that dir and run Gradle build, but not all build.gradle files have this.
None of the above approaches are concrete, is there any other firm approach that I can use to tackle the problem?
Your approach is generally correct.
You need to find the source code in github/gitlab/wherever, read the readme file and try to build it with whatever build tool was used there.
This may or may not work.
I have a libgdx project that has multiple modules like 'core' and 'desktop' within the project root. I was missing the Gradle tab. I wanted to add new dependencies to the project and needed to sync the project.
Apparently reimporting is the way to fix that.
Issues:
Importing the project just gives me an empty project with a .gradle and .idea folder without any of my project.
Copying the projects manually just adds the modules as normal directories, the Gradle build fails.
Adding the modules through project structure adds them as separate project roots, the build fails again.
Errors:
Cause: invalid type code: 53
https://pastebin.com/d8VRbJp9
https://pastebin.com/hSzeW0ai
Build:
https://pastebin.com/BwkCJMaD
I noticed your build.gradle doesn't have any source setting going on.
The easiest way to remedy this is to create a new project using the setup tool (I personally prefer this one and then just copy your source files and assets across. After that, only change the build file to name the project etc. try not to fiddle with other things.
I am unsure as to whether this next method will work but you can try it. If you really want to keep your original project, try adding the following to the build.gradle under each specific project:
sourceSets.main.java.srcDirs 'src'
sourceSets.main.resources.srcDir 'assets'
So each project should look like:
project(":desktop") {
apply plugin: "java"
sourceSets.main.java.srcDirs 'src'
sourceSets.main.resources.srcDir 'assets'
...
}
If anyone tries this and it doesn't work, let me know and I'll remove it from the answer.
I am new to Bazel. I need to download external dependency jar files using Bazel. Where to configure to download external jar files. I tried to add jar files in BUILD and WORKSPACE files , but not working.
Workspace file
maven_server(name="myserver",url="https://mvnrepository.com/artifact/org.apache.flink/flink-java")
maven_jar(name="flink-java",artifact="org.apache.flink:filnk-java:jar:1.2.0",server="myserver")
bind(name="flink-java",actual="#flink-java//jar")
Build file
java_binary(
name="read_files",
srcs = glob(["ReadFiles.java"]),
main_class="com.ibm.cdo.gts.contracts.pipeline.preprocess.ReadFiles",
deps=["//external:flink-java"],
)
The logical mistake you have there is that the workspace name (flink-java) is illegal see here and here. What is needed is to change the - to _ in maven_jar and of course the reference in the bind.
maven_jar(name="flink_java",artifact="org.apache.flink:flink-java:jar:1.2.0")
bind(name="flink-java",actual="#flink_java//jar")
Two more mistakes you had in the above were:
In the artifact coordinates you wrote filnk-java when you needed flink-java
The mvnrepository URL you used doesn't seem to be legal. I tried a few variants but couldn't get it to work. Additionally from the site they seem to link downloads to Maven Central itself so I'm not sure they server the jars. Having said that since Bazel fallbacks to Maven Central I just omitted the maven_server and the build passes. If you need help with the maven_server part and you need to use a private Maven repository please double check the URL first.
PS: It would have really helped if you added to your question the Bazel outputs since I needed to create my own workspace to know what were the problems you encountered.
I have a Maven project which performs a number of time consuming tests as part of the integration-test Maven cycle. I'm using Jenkins as the CI server.
During the integration test a number of files are produced in the target folder. For example, an "actual" BMP file is produced and compared to an "expected" BMP file. If the test fails, I need to look at the files in the target folder to determine how to deal with the error. Maybe the actual BMP looks fine and so it should be promoted to the new expected BMP. On the other hand, it may reveal a problem that requires a code fix.
The thing is I don't have any way to get access to these files, other than to ssh into the CI server and manually scp the files over to my own machine for closer inspection. It would be extremely helpful if I could access these files from the Jenkins web interface.
I tried using the build-helper-maven-plugin to attach the relevant files as Maven artifacts, but the problem is that there is no suitable phase in Maven that executes after an integration-test, if any test fails.
What can I do? Can I use the "Copy Artifact" plugin for this?
1) The files in the target folder can be accessed using a link such as /ws/projectname/target/filename...
2) Rather than typing the url each time, the SideBar plugin can be used to add a link to the file to Jenkins' left menu, making it easily accessible.
You need to copy your files into your workspace in a build step and archive them from there - Jenkins lets you specify artifacts only relative to the workspace.
I usually create a directory keyed by the BUILD_ID in the workspace, so that artifacts from different builds do not get mixed up in case I do not clean the workspace and archive from there (specifying ${BUILD_ID}/**/* in the archiving step).
In case your build fails before it can run the copying step and because of it does not do the copy, take a look at this question.