I'm using Maven and IzPack. I'm looking for a way to put a file into the directory of the installer file. In the install.xml I've got a file tag set with a targetdir of "." but that will only work if the installer is executed from that directory. If executed from a different directory, the file is put in the current working directory of the user instead.
Having checked IzPack documentation, there's a built-in variable for $INSTALL_PATH, but I need the path of the installer. There's no way to predict where this installer will be when executed so specifying a pre-set directory won't work. Trying to specify the local directory via Maven just gives the path to the POM.
Is there an undocumented variable that would do the job or something else I've overlooked?
Related
trunk: failed at 11/26/2019 9:50AM
Could not create parent directory for lock file C:\Program Files\gradle-5.6.4\wrapper\dists\gradle-5.6.3-bin\82hbcx3fecbatlnap0jtj8ysr\gradle-5.6.3-bin.zip.lck
The folder C:\Program Files in Windows is by default protected and can only be changed if you do it with administrator rights. For the same reason, it is not supposed to be used as a work area for temporary or downloaded files. But this is what you are attempting to do.
When you run the Gradle wrapper scripts (through gradlew), it will download a Gradle distribution to your Gradle user home. The user home can be set by the environment variable GRADLE_USER_HOME, and if not set it will default to $USER_HOME/.gradle.
To me, it looks like you have downloaded a distribution manually (version 5.6.4) and then set GRADLE_USER_HOME to that folder. You shouldn't do that - just leave it to the default, or if you don't like that, another folder that doesn't require administrator rights to modify. Otherwise, Gradle will attempt to download the required distribution for your project (in your case version 5.6.3) to that folder and after that, create lock files and fill the cache with dependencies and more.
Some people also set a variable GRADLE_HOME to point to a default Gradle distribution. You can set this to the folder where you have manually downloaded it if you like, and then add %GRADLE_HOME%\bin to your PATH. But this is optional.
I have a Lua program (written in Lua 5.1). I'm on Windows 7, trying to use srlua to convert a lua file into an executable. finally i have create an executable used
glue.exe srlua.exe myscript.lua gd.exe
when i click exe/bat to execute. it crashed . tips : no find lua51.dll in computer.
when i used cmd to execute . it work. even i only move gd.exe to other dir.
so, why ?
doesnot srlua create standalone exe without lua environment?
dir ls
error tips
You are mixing Lua environments: your directory structure shows Lua51.dll, but your error message references Lua5.1.dll, which you don't have (and those are two different files). Somehow you depend on a module that was compiled against Lua5.1.dll. You can figure out the dependency chain by using a dependency walker as it will show what DLLs are being loaded and from what locations. You can also run it in the "profile" mode, which will show where the error you see happens in the dependency chain, so you'll know what DLL or executable is at fault.
In Windows, an executable will only look in a few places for the .dll (in order):
1) Any dependency paths will be searched first. These you can set when you are creating the project (generally through the IDE).
2) The current directory that the executable is running from. For example, if gd.exe was in the folder myexe in C: drive, the directory C:\myexe would be checked.
3) The system directory. For Windows, it's something along the lines of C:\Windows\System32.
4) Anything additional paths, specified by the PATH environment variable.
So, if you moved your executable gd.exe from C:\myexe to C:\myexe2, you would either need to point to the .dll via dependencies/the PATH environment variable, or move all of the .dll files that you need to the new directory.
If command line works to run the program, but not the .exe itself, your command line has the PATH environment variable set. You can set it in the command line using setx path "%path%;c:\newpath" or use the the Control Panel -> System and Security -> System then clicking on Advance System Settings -> Environment Variables and under System Variables, look for the PATH key word.
Keeping the .dll files and executable in the directory (c:\myexe for example) and running the executable is a good way to make sure they work together and that all required .dll files are seen by your executable.
Source (even though it doesn't mention the PATH environment variable): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
I am doing what it says on the forum but can't figure out where is the problem. I downloaded the .zip and extracted it. There was 4 folders (Contrib,Docs,Plugins,Unicode) aside from Docs where do I put the rest ? From AccessControl/Plugins I put the .dll to my NSIS/Plugins folder where are the other .dll files. But the other two folders diden't contained any .nsh or .nsi file to put in NSIS/Include. Where is the problem ? I am using HM NIS Edit and when I try to compile it says Invalid Command.
I tried this code and it compiles but I dont think it does something.. or maybe I am using the wrong command. I need to give to my config folder read,write permission thats in the INSTDIR. I tried it with INSTDIR\config and INSTDIR. But nothing works at the moment. Maybe the plugin isent included.
System::Call 'AccesControl.dll::GrantOnFile (t ."$INSTDIR",t .""(S-1-5-32-545)",t ."FullAccess")'
Was going to add a comment to the above answer, but system wouldn't let me. A clarification as for NSIS 3.0+ the default folder locations didn't work. To fix it I copied the files to:
AccessControl.zip\Plugins\AccessControl.dll --> NSIS\Plugins\x86-ansi
AccessControl.zip\Unicode\Plugins\AccessControl.dll --> NSIS\Plugins\x86-unicode
You can unzip the plugin zip at the root of the NSIS directory, or at least, you need to put the plugin dll into the NSIS plugins directory (or to any directory you want if you include it with !addplugindir)
The core of the plugin is in the dll file in Plugins directory (the unicode/plugins contains the unicode version of the plugin suitable for the unicode flavor of NSIS 3.0+)
the Docs directory contains the plugin documentation
the Contrib directory contains the plugin source code useful if you want to modify the plugin and rebuild it. It is not needed in normal nsis usage.
The correct way to call an nsis plugin is not via the system plugin: you need to call directly the plugin methods from the nsis script, as illustrated in the plugin page :
# Make the directory "$INSTDIR\database" read write accessible by all users
AccessControl::GrantOnFile "$INSTDIR\database" "(BU)" "GenericRead + GenericWrite"
or from some code of mine
AccessControl::GrantOnFile `${somePath}` `(S-1-5-32-545)` `${someAccess}` ;(S-1-5-32-545) is local users GUID
I'm unable to use "Jar Bundler" on mac to create JMeter.app from ApacheJMeter.jar, I was wondering if anyone else had previous experience with configuring this tool? The problem for me seems to be that the lib folder being searched is set to an incorrect base path:
org.apache.jmeter.NewDriver: JMeter home directory was detected as: /Users/username/Applications/JMeter.app/Contents/Resources
I looked here: http://developer.apple.com/library/mac/#documentation/Java/Reference/Java_InfoplistRef/Articles/JavaDictionaryInfo.plistKeys.html
But no matter how I configured any of the said properties, the logs looked the same.
The real trick is making sure the bin and lib folders can be found. The only jar file you will need to add is ApacheJMeter.jar. Look in the bin/jmeter script for additional properties to put into the properties tab of the Jar Bundler. The java arguments in the bin/jmeter script should be copied into the VM Options field. Check Set Working Directory to Inside Application Package. Now create application. Open up the .app folder that was just created and copy the bin and lib folders into the Resources directory. Done.
I am trying to setup my TFS2010 Build and I want to access the files that are downloaded via the "Version control path to custom assemblies".
From what I can tell those files are downloaded to:
C:\User\<Build User>\AppData\Local\BuildAgent\<Built Agent Number>
I can directly access that folder via the above path, but it would be nice if there was an environment variable (or something I can use in the build) to access that folder indirectly.
Or... Is there a better way to get at these files? (I am putting a version file in there to be downloaded every time the build is run).
You can use %LOCALAPPDATA% environment variable. It expands to
RootDrive:\User\LoggedInUser\AppData\Local
Example: %LOCALAPPDATA%\BuildAgent
Note that %APPDATA% will expand to
RootDrive:\User\LoggedInUser\AppData\Roaming