lombok issue with springtoolsuite - spring-boot

i installed lombok-1.18.20.jar to my gradle project
lombok install screen
but log / getMethod() / contructor build error occured.
my enviorment is sts 4.14.0 and using adoptopenjdk-11
error console
i already tried changing javaagent value to "lombok.jar" or "..somePath/lombok.jar" in /Applications/SpringToolSuite4.app/Contents/Eclipse/SpringToolSuite4.ini
sry to my poor english skill
if u know what is problem, plz give a blessing to me

Related

VSCode Spring Initializr Error : Failed to fetch metadata

When I try to create a new project on Spring Initializr on VSCode, it produces the error on right bottom screen
Fail to create a project. Error: Failed to fetch metadata
Fail screenshot
I have checked Developer : Toggle Developer Tools and checked the error, it's not common JSON tag (html error return) problem.
I have checked the access to https://start.spring.io/ on my browser : no problem.
I have checked the internet access via proxy : There's no proxy.
I have completely removed VSCode (including extensions) and re-installed, still the same problem.
Windows 10, using gradle 6.9, java 11.0.12, vscode 1.59.0
Ok I've resolved the problem.
In case anyone comes up with the same issue, here it is :
open Spring Initializr Java Support extension from VSCode extensions.
click settings icon, then choose Extension Settings.
scroll down, and click "Edit in settings.json"
In my case spring.initializr.serviceUrl was empty. It should be :
"spring.initializr.serviceUrl": "https://start.spring.io/"
Sometimes the issue can be resolved by simply restarting the vs code editor.
Because extensions will get reflected only after restarting the editor
I received the same error message after having installed the extension pack and starting up a new maven project. Yet, for me the solution of #sayginify did not work.
In my case lowering the version to 0.4.8 did help. I was on 0.8.0. Also the versions in between did not work either. Obviously there are some known bugs in some versions. The solution came in here on the VS Code Spring Boot initializr Github page: https://github.com/microsoft/vscode-spring-initializr/issues/162#issuecomment-726832226 .
I had same issue, when I was at work. Removed work network connected to personal network and able to proceed. I got the feeling work network preventing downloading. Or may be have to edit your proxy settings

Class Library (Package) project with error when installing SpecFlow.NUnit

I have just created a Class Library (Package) project. I have never used this template before. When I install SpecFlow.NUnit, my References folder is displayed "References (Errors - see error list)". My SpecFlow.NUnit has that warning sign. Maybe I shouldn't use this type of project but I would like to understand why. Thanks.
Update: I've tried installing SpecFlow.xUnit in a second project too without success. I've installed them through Nuget.
Follow the instructions, should not be any problem. And use a Test project, that is the easiest way to get started.
Specflow documentation

Gradle project refresh failed, Error: Cause: invalid address family type

I run OpenSUSE v 13.1 32-bit and recently installed Android Studio v 0.8.6 (updated to v 0.8.9). If I remember correctly, it comes with Gradle v 1.12.
When I'm trying to create a new project as soon as I click the magic Finish button the IDE does it's thing and creates the project with Gradle instantly throwing an error:
Gradle project refresh failed, Error: Cause: invalid address family type.
I have already tried searching it online, including these forums, and so far came across nothing. I have posed the same question on Gradle forums but apart from two other poor souls, that have the same problem, nobody suggested any solutions so far.
set JAVA_HOME var to Oracle Java, from
http://forums.gradle.org/gradle/topics/gradle-project-refresh-faild-error-cause-invalid-address-family-type
I had the same problem, setting the $JAVA_HOME as described above didn't solve my problem.
My solution was to delete the $HOME/.gradle directory
After doing this Android-Studio installs gradle and configures it again and it worked :-)

Exporting eclipse plugin fails under Mountain Lion

I'm developing a plugin for Eclipse Juno under Mountain Lion.
I can test my plugin without problem by doing run as > Eclipse application.
However when I try to export the plugin by doing the following action it fails.
Open plugin.xml
Go to the tab Overview
Select Export Wizard
It returns the following error:
/Users/luca/Documents/University/PhD/FODA/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/compile.org.eclipse.pde.container.feature.xml:4: The following error occurred while executing this line:
/Users/luca/Documents/University/PhD/FODA/it.unibg.robotics.featuremodels.model/build.xml:31: /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/Classes does not exist.
The following error occurred while executing this line:
/Users/luca/Documents/University/PhD/FODA/it.unibg.robotics.featuremodels.model/build.xml:31: /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/Classes does not exist.
What's the problem?
Just ran into this problem myself today. As far as I understood, it comes from the fact that recently Apple stopped maintaining their version of Java in favor of an official version for the MacOS X from Oracle. The Oracle version, however, doesn't have the same directory structure as before, and the build script generated by Eclipse assumes the old structure.
You can see many bug reports related to this. E.g.,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=371215
https://bugs.eclipse.org/bugs/show_bug.cgi?id=378596
https://bugs.eclipse.org/bugs/show_bug.cgi?id=385077
I heard that switching to using Java 6 would solve the issue, as MacOS X still has the Apple Java 6 installation with the old directory structure. I didn't want to go back to Java 6, so I didn't try this.
Instead, I tried creating the directory that is reported missing (i.e., /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/Classes), with nothing in it. Oddly, it seems to have worked.
Let me know if it works out for you as well... Future updates of Eclipse might also fix this (I updated mine today, but the problem was still there).
This is fixed in Eclipse 3.8.2 and 4.3.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=392434

Scala Eclipse IDE suddenly ignoring breakpoints

I've been using Scala 2.8RC1 and Scala Eclipse plugin for 2.8 RC1 happily for a few days. However, last night after adding a couple jar files to my environment (apache http client jars) the debugger just stopped stopping at breakpoints in scala code.
Java code stops fine at breakpoints. I tried creating a new mimimal scala app breakpoints don't stop. I've tried switching to sun-jre-1.6.0.20 from the openjdk-1.6.18 I had been using. I've switched to the scala 2.8 nightly and also eclipse plugin for scala nightly builds. No luck.
I would greatly appreciate ideas for fixes. Rather frustrating as the initial experience with 2.8 was really great.
https://www.assembla.com/spaces/scala-ide/tickets/2731-breakpoints-against-objects-in-default-package-are-not-honoured
Says that scala eclipse plugin doesn't stop at breakpoints if you're class is in the default package (no package)
Adding a package and moving my class to it - make the debugger start working again.
It's possible that you've discovered a bug in the Scala tooling for Eclipse. The best place to take the issue is the scala-ide-user list here,
http://groups.google.com/group/scala-ide-user
If you're already sure that you've found a bug you can find instructions for opening a ticket here,
http://scala-ide.assembla.com/wiki/show/scala-ide/Bug_Reporting
I've just encountered this problem. Code is not in default package. I'm getting a warning about missing line numbers, but apparently that bug has been fixed and I can ignore the warning, per https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000155-its-impossible-to-add-line-numbers-debug-info-to-compiled-project#/activity/ticket:
It did seem to stop at breakpoints in the main file, though.

Resources