We Keep Coding

SimGrid-3.13 Can't load classes

There are steps for building .jar file of SimGrid.
I downloaded archive from here.
Then I made following
cmake -DCMAKE_INSTALL_PREFIX=/home/Documents/simgrid -Denable_maintainer_mode=off -Denable_compile_optimizations=off -Denable_java=on -Denable_model-checking=off
make
make check
100% tests passed, 0 tests failed out of 586
ctest
100% tests passed, 0 tests failed out of 586
make install
There is simgrid.jar in SimGrid-3.13 folder.
But when I write code I can't load classes from this .jar file.
How can I fix it?
UPDATED
If I download ready simgrid.jar from thence, error occurs
Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/simgrid-java2166199247712718748/libsimgrid.so: libcgraph.so.6: cannot open shared object file: No such file or directory
Where I have to add libsimgrid-java.so, libsimgrid.so?
UPDATED2
After installing graphviz graphviz-dev. New error occurs
Invalid XML (XML input line 2, state 2): Bad declaration <!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">.
If your are using a XML v3 file (check the version attribute in <platform>), please update it with tools/simgrid_update_xml.pl
[0.000000] /builds/workspace/SimGrid-Multi/build_mode/Debug/node/simgrid-ubuntu-trusty-64/build/SimGrid-3.13/src/surf/xml/surfxml_sax_cb.cpp:55: [surf_parse/ERROR] Parse error at (null):2: Parse error in /home/ken/IdeaProjects/Sim2Sim/src/main/java/LHCb/platform.xml
[0.000000] /builds/workspace/SimGrid-Multi/build_mode/Debug/node/simgrid-ubuntu-trusty-64/build/SimGrid-3.13/src/surf/xml/surfxml_sax_cb.cpp:57: [xbt/CRITICAL] Exiting now

As for the second update, you should read the error message that you copy-pasted:
If your are using a XML v3 file (check the version attribute in <platform>), please update it with tools/simgrid_update_xml.pl
Can you confirm that:
(1) the version attribute in the <platform> is 3
(2) running the tools/simgrid_update_xml.pl script on the platform fixes the problem?

I just checked the Debian package search page, in the second search box. I looked for /usr/lib/libcgraph.so.6 and it says that this library is in the package libcgraph6. So you have to apt-get install libcgraph6 to get it.

gradle process command java finished with non-zero exit value 1

I am getting the following error when I type gradle bootRun --stacktrace --debug in the CentOS 7 terminal to use gradle to launch this sample spring boot app.
Caused by: org.gradle.process.internal.ExecException:
Process 'command '/opt/jdk1.8.0_45/bin/java'' finished with
non-zero exit value 1
I have googled this error and read other SO postings that are similar but not duplicates. For example, this is in eclipse in CentOS 7 and a web app. This is not an android app, etc. Also, commands given in other postings have not resolved this problem.
All of the code required to reproduce this problem is in the github link above, and all of the logs to diagnose the problem is in this OP below. How do I resolve this error so that I gradle bootRun can succussfully launch the sample app?
STEP BY STEP REPRODUCTION OF THE PROBLEM:
I downloaded the app as-is by navigating to /home/user/workspaces/ and typing git clone https://github.com/jrodenbostel/beyond-the-examples
I then navigated to cd /home/user/workspaces/beyond-the-examples/part-5 and typed gradle bootRun --stacktrace --debug, which resulted in the stack trace and logs that you can read by clicking on this link to a file sharing site. (The logs are too long to include in this OP.)

This was my original error message:
Changing my %JAVA_HOME% in Window's Environmental Variables from Java 9 (file directory C:\Program Files\Java\jdk-9.0.1) to Java 8 (C:\Program Files\Java\jdk1.8.0_151) was what fixed it for me. You can figure out what path you set %JAVA_HOME% to by typing echo %JAVA_HOME% in Command Prompt.
So yea, as of 12-20-2017, gradle bootRun doesn't play well with Java 9. Hopefully that will be fixed soon and I can delete this answer.

Looking at the logs this appears to be your problem:
nested exception is org.springframework.dao.DataIntegrityViolationException: PreparedStatementCallback; SQL [inser t into users (username, password, enabled) values (?,?,?)]; Data truncation:
Data too long for column 'password' at row 1; nested exception is com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'password' at row 1.
Anyway you can truncate the password size? Otherwise increasing the 'password' column size should do the trick.

In My case, I was getting this error when I was trying to launch my spring boot application. The reason for the error was the port 8080 (default port for running my app in my case) was already being used by another application (mySql) on my machine.
I killed that other application and retried to launch my app, and it worked!

Just wanted to add my experience with this error. I used the Grails Application Forge and included the full package in the name when generating my Grails 5.1.2 application. When I ran it, I got the "...java'' finished with
non-zero exit value 1" error. I went back and generated the application with only the application name, removing the package, and it worked. Also, this was only a problem on Windows 10 in a command prompt. Both versions of my application worked in a Cygwin command prompt.

Error when push Liberty for Java application in IBM Bluemix

when I run sample IBM Bluemix Liberty for Java application https://github.com/ibmjstart/bluemix-java-postgresql-uploader.git following error:
-----> Downloaded app package (1.9M)
-----> Downloaded app buildpack cache (4.0K)
OK
/var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:101:in build_pack': Unable to detect a supported application type (RuntimeError) from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:74:inblock in compile_with_timeout'
from /usr/lib/ruby/1.9.1/timeout.rb:68:in timeout' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:73:incompile_with_timeout'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:54:in block in stage_application' from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:inchdir'
from /var/vcap/packages/dea_next/buildpacks/lib/buildpack.rb:50:in stage_application' from /var/vcap/packages/dea_next/buildpacks/bin/run:10:in'
FAILED
Server error, status code: 400, error code: 170001, message: Staging error: cannot get instances since staging failed
TIP: use 'cf logs jpu-henryhan --recent' for more information

The top error looks like you left off the -p <path_to_war> parameter when doing a push. If you just push a directory containing a WAR file, it will not be detected by the Java buildpack.

The tip provided in the output of your cf push request is relevant.
TIP: use 'cf logs jpu-henryhan --recent' for more information
Running that command will tail the log files produced during the staging process and let you see what error may have been raised. Often, it can be a missing dependency or a transient failure of some sort.
I just successfully deployed the sample using the "deploy to Bluemix" button and manually via the cf command line tool. Unless you changed the code, it is most likely that this error is a transient failure.

Run following command:
$ cf push jpu- -b https://github.com/cloudfoundry/java-buildpack --no-manifest --no-start -p PostgreSQLUpload.war
add the parameter to set the buildpack "-b https://github.com/cloudfoundry/java-buildpack"

Build Failed in Liferay 6.2

I am getting Build Failed, while deploying the Portlets,Themes and Layouts in liferay 6.2 on ubuntu OS .
The console messages are:
The Build Failed Message on Console:
BUILD FAILED
/opt/scrum-6.2/plugins/layouttpl/20x80-layouttpl/build.xml:7: The following error occurred while executing this line:
/opt/scrum-6.2/plugins/layouttpl/build-common-layouttpl.xml:5: The following error occurred while executing this line:
/opt/scrum-6.2/plugins/build-common-plugin.xml:5: The following error occurred while executing this line:
/opt/scrum-6.2/plugins/build-common.xml:47: The following error occurred while executing this line:
/opt/scrum-6.2/plugins/build-common-ivy.xml:17: The specified destination is a directory
Can any one help me?

Solution -> Edit build-common-ivy.xml and change line 17 so that it looks like this:
dest="${ivy.home}/ivy-${ivy.version}.jar"
Also, it complains that you need Ant 1.8, so be sure to upgrade to 1.8.

I have resolved the build failed issue
The following file is missing in plugins:
---> build.username.properties file
And inside the .ivy folder,cache folder and ivy-2.3.0.jar files are missed.
I just have added the above things in plugins.

TCLBLEND FAILURE - Centos 6.4

I have been trying to use a home grown test tool and after doing an update to Centos 6.4, I am no longer able to run the tcl based tool. I am getting the following error and I have no internet access on this server. Kindly advise how do I solve this problem?
Thanks
"XpUtils::iload -d /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1 tclblend" failed:
couldn't load file "/usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1/libtclblend.so": libjava.so: cannot open shared object file: No such file or directory
while executing
"error "\"XpUtils::iload -d $dir tclblend\" failed:\n $errMsg""
(procedure "loadtclblend" line 168)
invoked from within
"loadtclblend /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1"
("package ifneeded java 1.4.1" script)
invoked from within
"package require java"
("eval" body line 1)
invoked from within
"eval package require $pkg"
("foreach" body line 2)
invoked from within
"foreach pkg $pkgList {
set ::${pkg}Version [eval package require $pkg]
}"
(file "/usr/local/testtool/testtool" line 165)

If you read the error message trace, you'll see that it says that this is all caused by:
libjava.so: cannot open shared object file: No such file or directory
The first steps would then be to ensure that you've got a version of Java actually installed, to check that it includes the file libjava.so, and that the file has been indexed by the system shared library catalog.
It might also be worth checking that all its dependencies are also present and that you've got the architecture for the Tcl library and the Java library matched (e.g., both 32-bit) as those can cause odd failures when they go wrong.