I'd like to generate sequence diagrams with EA. I set up a build script, the debug section looks like this:
jre=C:\Program Files\Java\jdk1.6.0_20,-Djava.class.path=C:\path\to\my\app
When I try to debug it (which is needed for the diagram generation), I get the following message:
Failed to load C:\Program Files\Java\jdk1.6.0_20\jre\bin\client\jvm.dll, dll or dependent dll is missing
The file jvm.dll is indeed located at the path it tries to load it from. What am I missing here?
Short Answer:
Enterprise Architect(EA) is having some struggles using the "Program Files" directories.
Reason Why(Partial):
I copied the jvm.dll out of its %java_home%\jre\bin\client directory and put it in c:\Temp to test if EA could now "see" the file.
Sure enough, when I pointed EA to the new location it found it just fine. The test still wouldn't run, but at least the file could be "seen" by EA.
Resolution:
Re-install the JDK to a non-"Program Files" and non-"Program Files(x86)" directory, then re-point all of the pertinent System Environment Variables (e.g. JAVA_HOME, PATH) and Enterprise Architect Commands to the newly installed JDK location.
There is always FilePathName 8.3 equivalent in Windows.
Instead of C:\Program Files\Java\jdk1.8.0_05
You can write (or similar): C:\PROGRA~1\Java\jdk1.8.0_05
Try in Dos prompt: dir C:\PROGRA~1
Related
Here is what I am dealing with. I have a WIX project, that outputs a MSI file. This works like a charm.
I got a new requirement, that I need to analyse in order to figure out how to approach it. As the new requirement is, I need to get as output, a ZIP file, that contains the files and folders as described in the WIX project...
I searched for the "ZIP" keyword on the official documentation, but did not have any luck in finding something helpful...Maybe some of you guys have an idea?
Obviously, I could use other tools to perform this, like maven and the maven assembly plugin, but that would cause maintenance issues, as there would be 2 different projects, 2 different technologies, and since the files and directories structure is quite big, this could cause issues like one developer modifying a project, and forgetting about the other..
So yeah...difficult question...any input would be welcomed :)
Thx
Administrative Installation: Windows Installer / MSI features a built-in capability to extract all files and make a "network installation point" (a network location where installation can be kicked off from to install on all workstations on the network - ensures all source files are available for repair operations and patching). This is called an administrative installation - in plain terms a glorified file extraction mechanism.
Given the availability of the administrative installation, is a ZIP file really necessary? I suppose you could zip up the extracted admin image? Note that any files that need to go to system, shared or userprofile folders may cause issues and prevent successful launching of your application from the extraction folder (obvious, just mentioning).
Command Line: Try it, from a cmd.exe command prompt (see above link for more details):
msiexec.exe /a MySetup.msi
You could set the Compressed="no" attribute of the Package element to create an uncompressed layout. The result could be easily zipped (excluding the *.msi file) by running any of the freely available command-line zippers (e. g. 7za.exe of 7-zip).
Note:
File elements can override the Compressed attribute of the package.
I have the latest STS4. I am using installed java-1.8 JDK not embedded as the execution environment. My project just runs fine without any issue.
However when I launch the STS application itself I have a pop up saying
"Missing tools.jar"
I have already tried:
pointing JAVA_HOME to different JDK
added -vm args in the .ini file.
Yet I cannot get rid of this pop up.
I solved this same problem by modifying the file "eclipse.ini". First I tried to solve it by modifying the file SpringToolSuite4.ini, but nothing happened, because I previusly had installed the eclipse ide, and the change in SpringToolSuite4.ini didn't work. then I modified the file eclipse.ini; and it worked.
The changes that I did in eclipse.ini are detailed below:
To check with what Java version (JRE or JDK) Eclipse is running, do the following:
Open the menu item Help > About Eclipse. (On the Mac, it’s in the Eclipse-menu, not the Help-menu)
Click on Installation Details.
Switch to the tab Configuration
Search for a line that starts with -vm. The line following it shows which Java binary is used.
Depending on the name and location of the used Java binary one can figure out if a JRE or a JDK is used:
If the path contains “jre” (e.g. as in C:\Program Files\Java\jre6\bin\client\jvm.dll) it is a JRE
If the path contains “jdk” (e.g. as in C:\Program Files\Java\jdk1.6.0_31\bin\javaw.exe) it is a JDK.
If no JDK is used for Eclipse, change it:
Quit Eclipse if it is running
Go to the Eclipse installation directory and open the file eclipse.ini in a text editor.
Search for the line -vmargs
Before the line -vmargs, add two lines:
On the first line, write -vm
On the second line, write the path to your JDK installation (usually something like: C:\Program Files\Java\jdk1.6.0_31\bin\javaw.exe on Windows)*
source: https://matsim.org/docs/devguide/eclipse/jdk
The fix is in the -vm parameter. the order and the absolute path of the javaw.exe seems to be the issue.
the readme file mentions _
"To run Eclipse with an alternate Java runtime environment, the path to the Java virtual machine's binary must be identified. With an Eclipse installation from the distribution, altering the $PATH variable to include the path to the alternate Java runtime environment is often not enough as the Eclipse that Linux distributions package often performs a scan internally to pick up GCJ by itself whilst ignoring what's on the $PATH."
So I have edited now the SpringToolSuite4.ini and made this entry
-vm
C:\UserTemp\Softwares\java\jdk\oracle-jdk-1.8-64bit\bin\javaw.exe
Restarted my STS and it works perfect.
The reference to set the JVM Specifying the JVM was very useful in understanding this.
Don't spend too much time looking for tools.jar. If you get an error like that, don't be upset.
If you already have java JDK1.8, go to its lib folder, tools.jar should be available there. Copy and paste the same in JRE1.8 lib folder.
I have STS4 so I have modified SpringToolSuite4.ini
I changed from:
[...]
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.8
[...]
to exactly this
[...]
--launcher.defaultAction
openFile
-vm
C:\Program Files\Java\jdk1.8.0_152\bin\javaw.exe
-vmargs
-Dosgi.requiredJavaVersion=1.8
[...]
And the message dissapeared
SOLUTION :
Check your Path JAVA_HOME - system property "Environment Variables"
for example: JAVA_HOME:
C:\Program Files\Java\jdk-12.0.1\lib
usually you only need add \lib at JAVA_HOME
Just remove this line from variable "Path"
"C:\Program Files (x86)\Common Files\Oracle\Java\javapath"
System Properties > Advanced > Environment Variables > Path > Edit > Reboot
Worked for me
In my case I had installed jre, and not jdk!
Observe that you have jdk installed!
I had the same issue when i upgraded to Java 11.
I simply edited SpringToolSuite4.ini and added
-vm
C:\Program Files\Java\jdk-11.0.4\bin\javaw.exe
For me, I had to do two things to make it work:
Remove vmargs:
vmargs
Dosgi.requiredJavaVersion=1.8
Setting the JDK:
vm
C:\Program Files\Java\jdk1.8.0_131\bin
By downloading the tool file and paste it in the jre\lib path. but make sure you should rename the pasted file as "tools.jar".
step 1
download the tool file.
download link http://www.java2s.com/Code/Jar/t/Downloadtools160jar.htm
step 2
extract the zip file.
step 3
you should rename the included .jar file as "tools".
step 4
then copy the renamed tools.jar file and paste in the C:\Program Files\Java\jre8\lib\ path.
then restart the STS ide.
I have fixed this from Window->preferences->Java->Installed JREs .
Then add the jdk bin path, uncheck other related jre paths
Copy JDK directory to your STS installation or extraction library and and rename JDK to jre. the directory structure of STS should look like this
.eclipseproduct
artifacts.xml
configuration
dropins
eclipsec.exe
features
jre
license.txt
META-INF
open-source-licenses.txt
p2
plugins
readme
SpringToolSuite4.exe
SpringToolSuite4.ini
Once STS open, initially its looking for tools.jar in jre\lib folder its not available in jre\lib folder.
so we need copy the tools.jar from jdk\lib folder and paste in jre\lib folder.
restart the STS, issue will resolve.
VTK_DIR-NOTFOUND is returned when using CMake. I am using CMake GUI and, as other path errors, I can point then to proper path. However, for VTK doesn't work. I am pointing to directory where VTConfig.cmake file and others are. Also tried with all of other VTK dirs but without any sucess. I am using Visual Studio 12 2013 Win 64 configuration for generation but tried with 2010 too.
pointing to path manually,
The first thing I would check is what is the actual find_package() command being invoked where the error occurs? Perhaps that call is something a bit unusual or explicitly has the MODULE keyword (this would prevent the VTKConfig.cmake file from being found).
If that looks okay, check to see if something is modifying the VTK_DIR variable. Insert the following near the top of your top-most CMakeLists.txt file:
variable_watch(VTK_DIR)
This should tell you what, if anything, is modifying it in ways you didn't expect.
Assuming VTK_DIR is not actually being changed, the next thing you could try is setting CMAKE_PREFIX_PATH to the directory containing the VTKConfig.cmake file (you can add this in the CMake GUI if it isn't there already). Maybe also try variable_watch(CMAKE_PREFIX_PATH) too just in case something is modifying that internally in unexpected was as well.
If that still doesn't reveal anything, then it would seem likely that there is something wrong with either your CMake or VTK installation. Perhaps try an earlier CMake version and see if you get any different behaviour.
Although the currently accepted answer is a good way of debugging, it looks like you're building Point Cloud Library (PCL) with the binaries from unancyowen. In which case I suggest ensuring your system environment variables are setup correctly which will automate the process you are currently going through and facilitate the job of the find_package() methods.
Assuming you installed everything in the same directory (i.e. where you have already linked to FLANN and Eigen) the following default PCL 3rd Party Libraries should be added to Path:
C:\Program Files\PCL 1.7.2\3rdParty\FLANN\bin
C:\Program Files\PCL 1.7.2\3rdParty\VTK\bin
C:\Program Files\PCL 1.7.2\3rdParty\Eigen
C:\Program Files\PCL 1.7.2\3rdParty\Boost
Then Qt, OpenNI etc. which are installed separately.
And you can also add:
BOOST_INCLUDEDIR : C:\Program Files\PCL 1.7.2\3rdParty\Boost\include\boost-X_XX\boost (Replace X_XX with your version number)
BOOST_LIBRARYDIR : C:\Program Files\PCL 1.7.2\3rdParty\Boost\lib
BOOST_ROOT : C:\Program Files\PCL 1.7.2\3rdParty\Boost
EIGEN_ROOT : C:\Program Files\PCL 1.7.2\3rdParty\Eigen
In the field where it is showing that
VTK - DIR : NOT FOUND
You can either copy paste the location or type in, or just browse for the file called VTKConfig.cmake. Generally found inside the build folder of VTK. This is how it solved in my case. Have a try!!
I am trying to update an application that was developed a couple of months ago on VB of Visual Studio 2005.
The "Build output path:" for the project is pointing to a folder in which I collected a few executables related to my activity, BinDir/. It is just next to the project's folder ProjName/ on my disk.
Contrary to the past, when I build my project now, the .exe is created in the ProjName/obj/Debug folder, instead of being directed to the BinDir/Debug folder.
In the IDE's Output tab (while building), the path of the generated executable appears correctly, but in reality it is located somewhere else.
Why is it so?
UPDATE: Something very peculiar is going on my computer today... A couple of hours later I tried again and now it seems like the executable is created in both places. The obj/ version is just redundant now.
What you describe seeing in the Update is what usually happens with Visual Basic builds in Visual Studio 2005. The build creates the executable in an intermediate directory (obj\debug) and then copies the executable from there to the final build output directory (bindir\debug)
With the usual minimal logging turned on, if you examine the build output, you should see the vbc command include the switch /out:obj\Debug\yourproject.exe which tells the compiler to create the executable in the obj\debug fdirectory. Then you should see the file get moved to the build output yourproject -> C:\TestPrograms\Vb.net\yourproject\bin\Debug\yourproject.exe
If you use Tools | Options | Projects and Solutions | Build and Run to set the "MSBuild project build output verbosity" property to "Detailed" you can see a lot more activity against the obj\debug directory and then see the various project output files being copied from that intermediate directory to the build output directory.
The macros $(Targetdir) and $(IntermediateOutputPath) can be used to access these two directories as can be seen using a build event like this...
echo target: $(Targetdir)
echo intermediate: $(IntermediateOutputPath)
In the original question, it sounds like the copy from intermediate to build output either failed or was not attempted leaving you with only one copy of the exe in the intermediate directory.
It's too late to go back and look now but typically the build output window will tell you more about why the copy failed.
I'm getting the following error when running an executable I created on a 64-bit machine using C++ code:
"Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries"
My PATH (shown below) obviously points to jvm.dll since I have that file in both C:\Progra~1\Java\jdk1.6.0_17\jre\bin and C:\Windows\System32
PATH=C:\Program Files (x86)\Gmake\bin;C:\Program Files (x86)\apache-ant-1.7.1\bin;C:\Progra~1\Java\jdk1.6.0_17\bin;C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools;C:\Progra~1\Java\jdk1.6.0_17\jre\bin\server;C:\Progra~1\Java\jdk1.6.0_17\jre\bin;C:\Windows\System32
Does anybody have any ideas as to what would cause this error? Thanks.
Use dependency walker to figure out what dll is missing.
I have the same issue when I run the java.exe in my Windows2008 R2 version.
my path was
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32
\WindowsPowerShell\v1.0\;C:\Program Files\System Center Operations Manager 2007\
;C:\Java\jdk1.6.0_33\bin
when I run the java.exe under C:\Java\jdk1.6.0_33\bin, it works fine. I found that within the c:\Windows\System32\ comes with a copy of java.exe. When I run the c:\Windows\System32\java.exe, it shows the same error:
C:\>Windows\System32\java.exe
Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries
I fixed this issue by moving the C:\Java\jdk1.6.0_33\bin to the beginning of the PATH environment:
PATH=C:\Java\jdk1.6.0_33\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\
Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\System Center
Operations Manager 2007\
Hope this help.
This is how I solved a similar problem:
Used JavaRa: http://singularlabs.com/software/javara/ to remove old java versions.
Restarted the PC.
Re-installed the latest JDK version.
In my case, there was a jvm.dll file in the same folder as my exe file. I simply deleted the jvm.dll from there and it worked. Probably, it preceded the one in the PATH
I got this error as my PATH (environment variable) has not set correctly.
while setting PATH variable, set path of jvm.dll as a very first path in the list
Reboot your machine.
Note: Do not move jvm.dll to your project directory.
I had a complicated case. There was a jvm.dll file in the same folder as my exe file. I deleted it (because it shouldn't be there) but jvm.dll couldn't be find then.
I wanted to solve it by adding %JAVA_HOME%\jre\bin\server to my PATH because jvm.dll is located there. However, it didn't work. It turned out that the Windows loader won't expand the JAVA_HOME variable during searching for jvm.dll in the paths specified in PATH because I defined JAVA_HOME as user's variable. When I defined JAVA_HOME as a system variable, it started working as expected.