I installed the OpenJDK via Nix in Ubuntu (Linux uplink 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux).
gorre#uplink:~$ java -version
openjdk version "1.8.0_172"
OpenJDK Runtime Environment (build 1.8.0_172-02)
OpenJDK 64-Bit Server VM (build 25.172-b02, mixed mode)
gorre#uplink:~$ which java
/home/gorre/.nix-profile/bin/java
gorre#uplink:/nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02$ ll
total 24K
dr-xr-xr-x 3 gorre 4.0K Dec 31 1969 share/
dr-xr-xr-x 2 gorre 4.0K Dec 31 1969 nix-support/
dr-xr-xr-x 3 gorre 4.0K Dec 31 1969 lib/
lrwxrwxrwx 1 gorre 80 Dec 31 1969 jre -> /nix/store/n7rh8v269qb1fs6314yq0wg7q8cajw0g-openjdk-8u172b02-jre/lib/openjdk/jre/
dr-xr-xr-x 2 gorre 4.0K Dec 31 1969 include/
lrwxrwxrwx 1 gorre 76 Dec 31 1969 bin -> /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02/lib/openjdk/bin/
Now when I try build/run a project that uses Gradle 4.4 within IntelliJ IDEA 2017.3.4 (Ultimate Edition) Build #IU-173.4548.28 I get this error:
The newly created daemon process has a different context than expected.
It won't be possible to reconnect to this daemon. Context mismatch:
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02,daemonRegistryDir=/home/gorre/.gradle/daemon,pid=12824,idleTimeout=null,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=b813ba02-e4a6-4bfe-91b2-8ed32963f7cc,javaHome=/nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02/lib/openjdk,daemonRegistryDir=/home/gorre/.gradle/daemon,pid=14245,idleTimeout=10800000,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]
I've searched here and there but the other answers/solutions don't work, not even specifying the Java home in gradle.properties (inside the project or in my user's home):
org.gradle.java.home = /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02
On the other hand, if I build/run the project on a terminal it works fine. Any clues?
UPDATE #1
This is my configuration for Gradle and the SDK in IntelliJ IDEA:
Check Idea settings for Gradle daemon:
Build, Execution, Deployment -> Build Tools -> Gradle.
There is an option "Gradle JVM". Looks that Idea uses Java 9 or some other non-compatible JVM to run Gradle.
Yoy should select your Java version from Nix.
I figured this out, even though it was in front of my nose — I didn't read carefully the error message(s).
Basically, the default Java home set by Nix was at: /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02/lib/openjdk and the one I manually set inside IntelliJ IDEA was at: /nix/store/f9053w1lfrkhgqfpr6l82ssxmjpsni1j-openjdk-8u172b02 (notice the missing ../lib/openjdk segment).
After correcting that in IntelliJ IDEA everything worked fine. I didn't need anything additional and/or special.
I hope this helps someone else in the future — or any other fast-reader Nix'ers.
Related
I wanted to give CLion a try for working with the ROS source code. I created a ROS Workspace and have the following folder structure:
joesan#joesan-InfinityBook-S-14-v5:~/Projects/Private/ros-projects$ cd catkin_ws/
drwxrwxr-x joesan joesan 4 KB Sun Aug 30 10:48:27 2020 .
drwxrwxr-x joesan joesan 4 KB Sun Aug 30 10:48:10 2020 ..
.rw-rw-r-- joesan joesan 98 B Sun Aug 30 10:48:27 2020 .catkin_workspace
drwxrwxr-x joesan joesan 4 KB Sun Aug 30 10:48:27 2020 build
drwxrwxr-x joesan joesan 4 KB Sun Aug 30 10:48:26 2020 devel
drwxrwxr-x joesan joesan 4 KB Sun Aug 30 12:13:50 2020 src
joesan#joesan-InfinityBook-S-14-v5:~/Projects/Private/ros-projects/catkin_ws$
I have sourced this location in the .bash_profile as below:
# Dynamically source all setup.bash files from multiple catkin ros workspaces
find /home/joesan/Projects/Private/ros-projects -wholename '*/devel/setup.bash' | xargs source
I then source the .bash_profile from within my .bashrc
Now, when I tried to open the project in CLion, I see the following error:
CMake Error at CMakeLists.txt:65 (message):
find_package(catkin) failed. catkin was neither found in the workspace nor
in the CMAKE_PREFIX_PATH. One reason may be that no ROS setup.sh was
sourced before.
I launch CLion via a Desktop shortcut entry that I created. How do I make CLion aware of this .bash_profile such that it can find catkin?
I managed to fix this by doing the following, but make sure that you have a Desktop entry created for Jetbrains CLion beforehand!
Open the jetbrains-clion.desktop located in the .local folder:
~/.local/share/applications/jetbrains-clion.desktop
In this desktop entry, modify the Exec= line as:
Exec=bash -i -c "/opt/softwares/clion-2020.2.1/bin/clion.sh" %f
I start off by deleting Gradle's build cache
$ rm -rf $GRADLE_HOME/caches/build-cache-*
I manually confirm this directory is gone. I also clean to ensure nothing from incremental build will interfere
$ ./gradlew clean
I then run a build w/ build-cache enabled:
$ ./gradlew --build-cache --scan app:assembleDebug
...
238 actionable tasks: 172 executed, 49 from cache, 17 up-to-date
Checking the generated report I see that some tasks are still marked as FROM-CACHE. How is this happening?
FWIW I'm using Gradle 5.6.3. I also don't use a remote build cache.
UPDATE: after clearing build cache, here's what's left in the cache dir:
$ pwd
/Users/jasonatwood/.gradle/caches
$ ls -al
total 24
drwx------ 11 jasonatwood staff 352 Dec 13 18:11 .
drwxr-xr-x 9 jasonatwood staff 288 Oct 15 17:24 ..
drwxr-xr-x 14 jasonatwood staff 448 Oct 29 16:07 5.4.1
drwxr-xr-x 15 jasonatwood staff 480 Nov 26 18:25 5.6.3
drwxr-xr-x 35 jasonatwood staff 1120 Dec 11 14:14 jars-3
drwxr-xr-x 5 jasonatwood staff 160 Oct 15 17:44 journal-1
drwxr-xr-x 7 jasonatwood staff 224 Oct 15 17:50 modules-2
drwxr-xr-x 5 jasonatwood staff 160 Oct 15 17:50 transforms-2
-rw-r--r-- 1 jasonatwood staff 39 Oct 15 17:27 transforms-2.lock
-rw------- 1 jasonatwood staff 28 Oct 22 16:34 user-id.txt
-rw-r--r-- 1 jasonatwood staff 17 Dec 13 18:00 user-id.txt.lock
If I understand correctly, I don't need to delete any of these.
The local task cache in the .gradle directory within the root project might interfere.
In order to disable the local/global caching altogether, use gradle.properties:
org.gradle.caching=false
If you remove the local build cache and don't use a remove cache, Gradle should indeed not be able to fetch anything cached on the next build. However, I don't think you actually removed anything.
The GRADLE_HOME environment variable, if you have it, should points to an unpacked local Gradle distribution. It could be something like /Users/jasonatwood/gradle-6.0-all. It would be wrong to set it to a path that is not a Gradle distribution.
The Gradle build cache resides in /Users/jasonatwood/.gradle/caches/build-cache-1.
When you try to remove it with $ rm -rf $GRADLE_HOME/caches/build-cache-*, you are using GRADLE_HOME as if it is pointing to the root of your home folder (/Users/jasonatwood), which it most likely isn't.
So instead, use this for removing it: $ rm -rf ~/.gradle/caches/build-cache-*
Or, at the very least, verify that the cache folder has indeed been removed.
If I run a --scan and look at the FROM-CACHE tasks in the generated HTML report.
I then look at the build cache keys for those FROM-CACHE tasks. I then go find those keys on my local machine. I see they are generated at the same time as the rest of the build. So I'm guessing that Gradle is using build cache within a build and not just across builds.
Sometimes there is a need to invalidate cache every time you restart the IDEA. This may be due to shared indexes reuse. What I did Settings --> Tools --> Shared Indexes -> Download Automatically and it resolved all the pain.
Earlier the setting was Don't download use Local.
Any custom metasploit module I create isn't getting loaded.
I tried both of these demos:
https://www.offensive-security.com/metasploit-unleashed/building-module/ https://github.com/rapid7/metasploit-framework/wiki/Loading-External-Modules
and got the same result that the modules were NOT found.
Before posting here, I checked these out:
https://forums.kali.org/showthread.php?28940-Metasploit-modules-not-loading!
https://www.offensive-security.com/metasploit-unleashed/modules-and-locations
and from SO:
I can't get new modules to load in metasploit
How to add module in Metasploit?
no help
Just working with the github example, on the Kali host, I do indeed have the file in the right location (according to the demo):
root#kali:~/.msf4/modules/exploits/test# ls -al
total 12
drwxr-xr-x 2 root root 4096 Mar 19 13:59 .
drwxr-xr-x 3 root root 4096 Mar 19 13:58 ..
-rw-r--r-- 1 root root 9 Mar 19 13:59 test_module.rb
I then ran reload_all and when using this command:
use exploit/test/test_module it returns with Failed to load module.
I also tried to manually load that path and it failed too:
msf > loadpath ~/.msf4/modules/
Loaded 0 modules:
Posting the answer for anyone who may come across this. I'm kinda new to this; didn't know where metasploit info gets logged.
It's in: ~/.msf4/logs/framework.log
The log told me I had a syntax error... must have happened from copying and pasting the text from the browser. Cleaned that up and everything works.
I have recently upgraded my Ubuntu from 14.04 to 16.04 and started getting the following error when running any mvn commands (version 3.3.9): Error: Could not find or load main class .usr.share.maven.boot.plexus-classworlds-2.x.jar. My environment variables are declared as follows:
$JAVA_HOME: /usr/lib/jvm/java-8-oracle
$PATH: /usr/local/texlive/2015/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
$M2_HOME: /usr/share/maven
$M2: /usr/share/maven/bin
When trying to find a solution, I've tried removing the M2 and M2_HOME variables as suggested on various threads, which resulted in getting a different error: Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher. I have also tried running apt-get remove --purge maven and installing it again as well as downloading the .tar.gz archive, but in both cases, nothing has changed.
When looking into the /usr/share/maven/boot folder, there is a chain of symlinks pointing from plexus-classworlds-2.x.jar -> /usr/share/java/plexus-classworlds2-2.5.2.jar. Am I missing some dependencies? Or are there any old configuration files that did not get removed by --purge?
EDIT: When I execute mvn as root, I get the Launcher error instead of plexus-classworlds-2.x. Also, I have completely removed and reinstalled all plexus libraries, yet with no change.
Check if /usr/share/maven/boot has multiple jars with pattern /usr/share/maven/boot/plexus-classworlds-*.jar.
Mine was something like:
drwxr-xr-x 2 root root 4096 Dec 23 14:21 ./
drwxr-xr-x 6 root root 4096 Nov 14 2015 ../
-rw-r--r-- 1 root root 52684 Dec 12 2015 plexus-classworlds-2.5.2.jar
lrwxrwxrwx 1 root root 34 Dec 10 2015 plexus-classworlds-2.x.jar -> ../../java/plexus-classworlds2.jar
This messes up /usr/share/maven/bin/mvn bash script and executes a wrong java command.
I had to remove the jar and leave only the symbolic link.
I need to know the teamcity settings which prevents the re-trigger/trigger of outdated builds/jobs if the new builds are successful.
I am facing a issue where teamcity jobs can be re triggered even if the next builds are successful.And If the trigger event is fired before, then it must stop teamcity to run that job if the latest build is successful.
So I have to 2 jobs in TC for 1 branch -- Build-Precheck and the other is Build-compile
So I could see that Build-compile is just picking the latest available successful build from Build-Precheck and then queing up the next which may be the outdated build.
Build-Precheck is just taking 2 min to finish the builds , it quickly triggers the latest builds , I guess following the principal First In First Out
Build-Precheck
06 Oct 14 14:33 - 14:35 (2m:01s) –7.1.4345
06 Oct 14 14:41 - 14:43 (2m:16s)- 7.1.4346
06 Oct 14 14:45 - 14:47 (2m:10s)- 7.1.4347
Build-compile
06 Oct 14 14:35 - 15:00 -7.1.0.4345
06 Oct 14 14:52 - 15:20 (28m:02s)- 7.1.4347
06 Oct 14 16:08 - 16:33 (24m:52s)- 7.1.4346
Is there any fix for this that TC runs incremental builds rather than outdated ones
Sounds like you are looking for Configuring Build Trigger.
AFAIK, there isn't a way to cancel queued builds if a given build passes. However, you can adjust the Build Triggers that queue those builds. Most likely, you'll need to set the Quiet Period on your VCS Build Trigger to longer than it takes for your build.
For example, if your full build takes 5 minutes, you should set the Quiet Period to 7. This way additional builds wont queue while a build is running.