I wanted to de-compile forge src, but when I typed in the command, it gave me an error. What does it mean and how can I fix it?
Last login: Sat Feb 6 20:59:20 on ttys000
Quangs-MacBook-Pro:~ quangnguyen200415$ bash /Users/quangnguyen200415/code/nullum\ et\ vacuum/gradlew setupDecompWorkspace
Exception in thread "main" java.lang.RuntimeException: Could not locate the Gradle launcher JAR in Gradle distribution '/Users/quangnguyen200415/.gradle/wrapper/dists/gradle-2.0-bin/5h57m9vra0mjv9qs45oqtsb5c0/gradle-2.0'.
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:39)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:56)
Quangs-MacBook-Pro:~ quangnguyen200415$
I am running latest version of java 8
EDIT: tried simplifying it, no effect
Quangs-MacBook-Pro:nullum et vacuum quangnguyen200415$ ./gradlew setupDecompWorkspace
Exception in thread "main" java.lang.RuntimeException: Could not locate the Gradle launcher JAR in Gradle distribution '/Users/quangnguyen200415/.gradle/wrapper/dists/gradle-2.0-bin/5h57m9vra0mjv9qs45oqtsb5c0/gradle-2.0'.
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:39)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:56)
Quangs-MacBook-Pro:nullum et vacuum quangnguyen200415$
It's likely you've installed something that has either modified your JDK installation, or has messed with your 'JAVA_OPTS' env var. Are you running code from eclipse? it could be a change in Eclipse that is causing Gradle to be run with a different environment. Do you get the same error when running Gradle directly?
bash /Users/quangnguyen200415/code/nullum\ et\ vacuum/gradlew setupDecompWorkspace
uhm... whats up with the preceding commands...
Just do ./gradlew setupDecompWorkspace
I'm pretty sure one of those commands you've added messes up the gradle path finding.
Execute gradlew without the fancy own commands, then add your own commands till it breaks. then you know what breaks.
Related
After years of working fine, for the last few months I've not had the ability to Run As Groovy Script.
I can select it from the menu, but nothing happens.
Today I installed the latest Eclipse and plugin in an attempt to fix, but no luck.
What went wrong? Is there a log file to check?
https://dist.springsource.org/release/GRECLIPSE/3.8.0/e4.16
The output of the launch is written to the Console view. If there was a problem launching you can check the Error Log view for an entry. The launch configuration under Run > Run Configurations... > Groovy Script may also reveal classpath or other issues.
The Payara with GlassFish 5.192.0 does not start using the Intellij Idea.
If I run payara\bin\asadmin start-domain is works just fine, and the server starts and runs.
These are the final lines from the console output with the --verbose property set on true.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized option: --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
Command start-domain failed.
The DAS was stopped.
The root case of the issue is logged here.
Windows launcher prepends PATH with JetBrains Runtime bin directory in order to load certain DLLs without issues. It turned out to be not the best solution and we are working to address it in a different way.
asadmin.bat uses the first java.exe from PATH. It doesn't try to detect it via JAVA_HOME.
The workaround for now is to switch IntelliJ IDEA boot JDK to JBR8 per this document or start IntelliJ IDEA using idea.bat instead of idea64.exe.
The issue is fixed in 2019.2.1 RC.
I'm working my way through a book about "Java EE 7 for Glassfish", with the server installed on Fedora Linux.
I have a simple stateless session bean SimpleSessionBean deployed on the server and I am trying to approach that SimpleSessionBean via SessionBeanClient and the Glassfish command line tool appclient, running a client jar. Everything from the book, so it should work. The client however can't find SimpleSessionBean. Apparently a class path issue. In the server logs nothing happened.
I can't find any pointers how Glassfish should be properly installed. Everything works within the server. I can approach installed war files from facelets running in a browser.
It is probably a matter of setting $PATH right or something or some other environment variable. Any pointers to relevant literature?
Thanks in advance for any suggestions!
UPDATE1: error message
From the bash terminal window where I run appclient:
[fedora#localhost bin]$ ./appclient -client /home/fedora/Downloads/6886EN_04_Code/ch04_src/simplesessionbeanclient/target/simplesessionbeanclient.jar
Jul 06, 2017 12:52:57 PM org.glassfish.apf.impl.DefaultErrorHandler error
SEVERE: Class [ Lnet/ensode/glassfishbook/SimpleSession; ] not found.
Error while loading [ class net.ensode.glassfishbook.SessionBeanClient ]
Exception in thread "main" java.lang.NoClassDefFoundError: net/ensode/glassfishbook/SimpleSession
at net.ensode.glassfishbook.SessionBeanClient.invokeSessionBeanMethods(SessionBeanClient.java:12)
at net.ensode.glassfishbook.SessionBeanClient.main(SessionBeanClient.java:19)
Caused by: java.lang.ClassNotFoundException: net.ensode.glassfishbook.SimpleSession
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at org.glassfish.appclient.client.acc.ACCClassLoader.findClass(ACCClassLoader.java:237)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
UPDATE2: From the Glassfish book:
We are using Maven to build our code. For this example, we used
the Maven Assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/) to build a client JAR file
that includes all dependencies; this frees us from having to specify
all the dependent JAR files in the -classpath command-line option
of the appclient utility. To build this JAR file, simply invoke mvn
assembly:assembly from the command line.
SOLUTION: the missing link was producing a client jar with additional jar's "on board" so to speak. Proceed as follows (at least in Eclipse): select pom.xml > right-click > Run As > Maven build... > enter in Goals field: assembly:assembly> Apply/Run.
The result will be that you will find TWO jars under your target folder: xxxclient.jar and xxxclient-jar-with-dependencies.jar.
From the command line in bash execute from the folder with latter jar:
/path_to/appclient -client xxxclient-jar-with-dependencies.jar
After a very long wait (on my $200 mini Linux box) the HelloWorld-ish server EJB gets finally properly called.
Your assumption is right.
You are missing net.ensode.glassfishbook.SimpleSession in your classpath.
From an older book online:
...executed through the appclient utility. This utility can be found at
[glassfish installation directory]/glassfish/bin/. Assuming this path
is in the PATH environment variable, and assuming we placed our client
code in a JAR file called simplesessionbeanclient.jar, we would
execute the above client code by typing the following command in the
command line:
appclient -client simplesessionbeanclient.jar
It seems that you've started from
.../bin/./appclient -client
/home/fedora/Downloads/6886EN_04_Code/ch04_src/simplesessionbeanclient/target/simplesessionbeanclient.jar
You need SimpleSession.class in your CLASSPATH (or in a jar in that classpath).
Usually java checks the current directory first (which is your bin folder). If the class is not found (its not, since its in your simplesessionbeanclient folder), it searches for that class in the classpath (where you did not add the simplesessionbeanclient folder).
Try
appclient -client simplesessionbeanclient.jar
from the folder where simplesessionbeanclient.jar is located.
If you don't want to add the appclient folder to your path start with
/your/path/to/appclient -client simplesessionbeanclient.jar
(again from the folder where simplesessionbeanclient.jar is located)
Update:
If you still get a ClassNotFoundException have a look if it is missing in your jar file (jars are Zip-File, you could use your Zip-Tools):
jar tf simplesessionbeanclient.jar
if there is a SimpleSession.class
I did the following to fix my problem:
Use appclient -classpath (instead of appclient -client)
Use the regular project JARs (instead of the one generated by mvn assembly:assembly)
Deploy the EJB to Glassfish (simplesessionbean.jar)
The example code from a more recent book "Java EE 8 Application Development" by David R. Heffelfinger (the same author of "Java EE 7 for Glassfish") is almost exactly the same (the only minor difference is classes are packaged in "net.ensode.javaee8book" instead of "net.ensode.glassfishbook").
When running appclient.bat -client simplesessionbeanclient-jar-with-dependencies.jar I kept getting:
java.lang.ClassNotFoundException: <mainclass>
errors. This was because the POM was assembling a manifest with <mainClass> value of "net.ensode.glassfishbook.SessionBeanClient" (instead of "net.ensode.javaee8book.SessionBeanClient"). So I decided to avoid using the -client option for appclient.bat and switched to -classpath which allowed me to specify the main class on the command line (which is easier than updating the POM or refactoring the packages to suit the manifest).
But then when running the appclient command:
PS C:\home\programs\java_ee_sdk-8u1\glassfish5\glassfish\bin> .\appclient.bat -classpath "C:\home\code\Java-EE-8-Application-Development-Code-Samples-master\ch04_src\simplesessionbean\target\simplesessionbean.jar;C:\home\code\Java-EE-8-Application-Development-Code-Samples-master\ch04_src\simplesessionbeanclient\target\simplesessionbeanclient.jar" net.ensode.javaee8book.SessionBeanClient
I kept getting:
Root exception is javax.naming.NameNotFoundException: net.ensode.javaee8book.SimpleSession#net.ensode.javaee8book.SimpleSession not found]]
errors. This was solved by deploying the EJB (simplesessionbean.jar) to Glassfish via the Admin Console (this missing step was not mentioned in the book). Running the appclient.bat command then worked.
Screenshot of appclient.bat (takes about 15 seconds to load):
Screenshot of EJB deployment:
Alternatively
You can manually compile the client to include all the dependencies by copying SimpleSession.java and SimpleSessionBean.java from the "simplesessionbean" project to the "simplesessionbeanclient" project (remember to refactor the package statements). This will generate simplesessionbeanclient.jar with the EJBs included (Nb: you still have to deploy the EJBs to the GlassFish server). Also make sure that the <mainClass> element in the POM points to the correct package.
You can now use the -client option:
This error happens when I run with Gradle through from Intellij IDEA.. but from console everything works fine... someone knows why?
Executing external task 'run --stacktrace'... :compileJava UP-TO-DATE
:compileScala UP-TO-DATE :bower FAILED
org.gradle.api.tasks.TaskExecutionException: Execution failed for task
':bower'.
Caused by: java.io.IOException: Cannot run program "bower" (in
directory "/Users/eduardo/Development/projects/jhipster"): error=2, No
such file or directory
I contacted JetBrains support about this. The one thing they suggested was running IntelliJ from the command line, which is working for me:
open -a "/Applications/IntelliJ IDEA 15.app"
At a guess, you are running IntelliJ on OSX, maybe with a brew install of bower?
Recent versions of OSX (at least 10.10.1) don't let you easily set the PATH for graphical applications (launchctl seems to have a bug in regards to PATH). Combined with there being no way to modify the current environment PATH for launching subprocesses in Java, this results in being unable to find the bower executable. A Complete rundown of the root problem can be seen here (Setting the environment for ProcessBuilder), but essentially IntelliJ must have your PATH set correctly in order for non standard PATHs to be searched.
My solution for now is a complete hack taken from https://apple.stackexchange.com/a/51737 - essentially, create a wrapper script:
create /Application/IntelliJ\ IDEA\ 14.app/Contents/MacOS/idea.sh with contents of:
#!/bin/sh
. ~/.bash_profile
logger "`dirname \"$0\"`/idea"
exec "`dirname \"$0\"`/idea" $#
then chmod +x /Application/IntelliJ\ IDEA\ 14.app/Contents/MacOS/idea.sh
then edit /Application/IntelliJ\ IDEA\ 14.app/Contents/Info.plist and set CFBundleExecutable to idea.sh
lastly, run /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -v -f /Applications/IntelliJ\ IDEA\ 14.app
It's a hack, but it works... and until Apple fixes launchctl, it's the only solution I've come up with.
When running the top level maven target
test
I get the following error:
FATAL: command execution failed
java.io.IOException: Cannot run program "mvn" (in directory "/var/lib/jenkins /jobs/selenium/workspace"): java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:475)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:709)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$ProcStarter.join(Launcher.java:345)
at hudson.tasks.Maven.perform(Maven.java:263)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1502)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.<init>(UNIXProcess.java:164)
at java.lang.ProcessImpl.start(ProcessImpl.java:81)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:468)
... 15 more
Build step 'Invoke top-level Maven targets' marked build as failure
This seems to be an issue concerning the maven pathway, but I've setup the maven pathway on my host machine. M2_HOME, M2, and PATH are all correct. I know they are correct because I can run the maven commands from the command line. When I try to invoke maven commands in jenkins though I get the error.
So I went into Jenkins->Manage Jenkins->Configure System and I clicked on Maven installations...
I checked off on
Install automatically
Version 2.2.1
I clicked save and tried to run my project again with the same error. When I do mvn -version I get 2.2.1 so that should be right.
From the Configure System page I have also tried
Name default
MAVEN_HOME /usr/local/apache-maven/apache-maven-2.2.1
Any ideas?
The solution to my question has two parts. First I needed to make sure that after creating the maven Installation setup on the Configure System page, that I specified that same configuration in the build itself. Second Jenkins does not seem to have sufficient privileges on the redhat box I'm running it on. Once I finally got it pointed to the right maven instance I got a lot of unable to create file/folder errors. These permission errors could be the real reason I had so much trouble with maven on this machine. I have not solved these permission errors and will create a new question for them.