buildship | The Eclipse Plug-ins for Gradle project | Code Editor library

Here is what you can do , First of all you can make sure that you have the environment variable needed , GRADLE_USER_HOME is usually located at Users/%USERNAME%/.gradle .

Then you can make sure that you add the /gradle_installation_Foler/bin to path .

Then try to go with gradle build , using command link at the location of your build.gradle , this will definitely make sure if you are able to download the dependency and have no issue with access .

if you do have connection issue , and you need to use a VPN here is an old answer of mine for how to do that .

let me know in comments if new error occurred .

Ok. It turns out that creating an empty "C:\Eclipse" directory solved this problem. Don't know or care how.

Gradle 6.8 does not work with Java 16.
Java 16 supported starting with Gradle 7

"In previous Gradle versions, running Gradle itself on Java 16 resulted in an error."

https://docs.gradle.org/7.0/release-notes.html#java-16

It looks like you are using Gradle 6.x which does not support running on Java 16. You could downgrade to Java 15 or earlier or upgrade to Gradle 7.x.

If you downgrade Java, you could still build and run your app on Java 16 by using Gradle’s toolchain support.

If you upgrade to Gradle 7.x, you should also upgrade to Spring Boot 2.5.x which added support for Gradle 7.

Java Reading Resource Files

You are managing files in your Java program. If you are using java.io.File class to get a reference to a specific file it will take those references as actual paths:

• Absolute path: "/myfile.yaml" -> will point to the root of the hard drive, in your case D:\myfile.yaml
• Relative path: "myfile.yaml" -> will point to the root of your java project

Now your goal should be to get the project specific path to load configuration files. This can be achieved with ClassLoader instance. You can read the content of the file like in the example below. classLoader.getResourceAsStream() will search for a file inside your resources.

You must supply -x test as Program Arguments like this:

Or you just run assemble instead of build. assemble is a lifecycle task that aggregates all archive tasks in the project and, besides other tasks, does not execute check tasks, such as test.

Have you considered running the "assemble" task instead of "build"?

There were a few things I was unclear/wrong about and couldn't find relevant documentation to learn the details. Here's a summary of what needs to be known to get this right (some of which I got right from the get go, but not everything):

1. Gradle/Buildship integration in Eclipse attempts to make use of Eclipse's internal compiler. This is by Eclipse's design and has its own advantages during development ... as well as disadvantages during times like this - inability to leverage the external/production builders (Gradle model in this case) to do the building. For this reason any bytecode enhancement (plugins or not) operating inside Gradle will have no effect in Eclipse at all (unless they do something Eclipse-specific). (I got this right)
2. To perform bytecode enhancement in Eclipse (not apt or what some Eclipse plugin could do), one has to add custom builders and position them after the default Java builder (manually or automatically). (I got this right too)
3. Out of box Eclipse offers two kinds of builders - "Ant" and "Program". No Gradle there. "Program" kind is not cross-platform, only Ant is. Ant can be used to do things or launch Gradle in a cross-platform way (Java exec on Gradle's main() method). (I got this right too)
4. [I WAS WRONG HERE] Eclipse offers four "events" to which one can bind an Ant builder: After a "Clean", Manual Build, Auto Build and During a "Clean". I did not understand when do they run. For example, I thought that "During a Clean" runs while the clean is happening and that After a "Clean" is there to run after that, to allow the custom builder to do its own after-clean cleaning. I thought that this would be followed by Auto build if "Build automatically" is enabled or "Build immediately" is checked in the "Clean" dialog. This is NOT the case. After a "Clean" actually refers to a build step, not cleaning and will NOT be followed by the *Auto Build" step (that step only runs when one saves an edit and "Build Automatically" is enabled. In the builder's *.launch file this is much more apparent - the After a "Clean" is actually called full and Auto and Manual builds are called auto and incremental. This means that en enhancement builder has to be set to run on After a "Clean" in addition to Auto Build and Manual Build and should NOT be set to run on *During a "Clean". My mistake was to only set it to run for Auto and Manual builds.
5. [I WAS WRONG HERE TOO] I specified the working set of relevant resources in the Build Options tab for the enhancement builder. I set those resources to be the source code (to be enhanced) and build.gradle (containing the enhancer). Since these do not change on most builds, Eclipse chooses not to run the builder. The now obvious 20-20 vision truth is that relevant resources for this builder are the Java builder's output binaries (and build.gradle), not the Java source code. However, this isn' the entirely correct choice (in isolation) either as Eclipse, in our case, ends up in an infinite loop - it thinks that the enhancer changed the binaries and, as it is set to run when binaries changed, runs the build again. We cannot NOT set the relevant resources at all as that seems to mean "everything/anything". The enhancer must be made in such a way to NOT even touch the files that are already enhanced [UPDATE] and that isn't enough. Read on.

I still don't definitively know why the informational builders I used to research this have their output appended to the common log file in order that isn't chronological. I can only assume that this has to do with Eclipse's output buffering and periodic writing to these files somehow.

[UPDATE 1]

1. [I DIDN'T KNOW THIS] Eclipse has a workspace setting (checkbox, overridable per project) in Preferences -> Java -> Compiler -> Building -> Output Folder called "Rebuild class files modified by others" officially described as "Indicate whether class files which have been modified by others should be rebuilt to undo the modification.". By default it is unchecked/off, which seems right for this case. This, however, does not work as advertised. Whatever the setting is, Eclipse's Java Builder will react to its output changes (as if they were inputs, I call this a defect) and "undo the modification", causing infinite build loops. I found this symptom reported many times - search for this. With "correct" setup and no hacking the Java builder keeps undoing the modifications and Eclipse keeps re-running them, causing the infinite loop regardless of the setting.
2. [HACK THAT SEEMS TO WORK PRESENTLY] In addition to having everything above set up correctly I modified the enhancer to ensure two things (either only one or both may be required, not sure): (a) that existing *.class files are NOT deleted and recreated but rewritten and (b) that their last modified time is changed back to what it was before the enhancement. This seems to trick the Eclipse's modification detection enough to break out of the loop even though the file sizes are different. This is with Eclipse 2019-12 (4.14.0.v20191210-0610) and it may stop working with any update. I hope they fix the infinite build loop defect by then.