If you install the latest java 1.6 jdk, without installing the public jre option, you end up having two \bin dirs with java.exe:
%JAVA_HOME%\jre\bin
%JAVA_HOME%\bin
if you compare those dirs, there are a few files that are identical (java.exe etc), and a bunch that are either in one or the other. So far I used to add %JAVA_HOME%\bin to my Path environment var, but now I am wondering, does it make a difference? Is there any side effect to choose one or the other?
And would not be much cleaner if the installation had only one java.exe and \bin folder?
The JDK embeds a version of the JRE installed in JAVA_HOME\jre, which is why you end up with both JAVA_HOME\bin (the JDK executables) and JAVA_HOME\jre\bin (the JRE executables). For the most part, I tend to add JAVA_HOME\bin to my PATH as it has a usable java and javaw, but also the various Java dev tools (javac, javadoc, etc., etc.). If you don't need any of that, you might just point to JAVA_HOME\jre\bin (but then why did you install the JDK)?
Related
Let's say, I have a completely new VPS server which I've just rolled out, which I haven't installed anything on yet.
And I've compiled and build a production release of Phoenix application on my local machine which is identical to a VPS server Linux distributive- and version-wise.
In the directory _build/prod/rel/my_app123 there have been generated 4 subdirectories:
bin
erts-12.3
lib
releases
Will copying the content of rel/my_app123/, that is, these 4 subdirectories, over to a VPS will be absolutely enough in order to run an application?
Or will I have install something extra as well? Elixir and Erlang?
How about production dependencies from mix.exs? Or are these have been included and compiled into into a release?
P.S. Assume that my web application has no "js", "css" and the like files, and doesn't use a database.
When you run mix release, it bundles all of your Elixir/Erlang dependencies for the MIX_ENV in question into the release directory, the erlang BEAM runtime/VM that you were using in your build, and any files that you specify in your mix project in mix.exs.
Because the BEAM runtime and code that bootstraps loading your code are included in the release, you won't need to install Elixir or Erlang on the target machine.
Things that are not included include:
any non-Elixir dependencies. For example, if you rely on openssl, you'll need to make sure you have a binary-compatible version of that installed on the machine you plan to run on (typically, the equivalent major verson release).
Portable bytecode. BEAM isn't like the Java VM. The compiled BEAM code needs to run on a substantially similar architecture. Build on an Arm64 machine for deployment on an Arm64 virtual machine, or x86 for Intel-compatible hardware, for instance. And it's probably best to use the same major OS distribution. There may be cases where "Any Linux * Same CPU architecture" is fine, but for example, building on a Windows or MacOS install of Elixir/OTP and deploying on Linux is a non-starter; you'd need to use a sufficiently similar OS.
As an example, one of my projects has its releases built on Alpine using Docker, so we only really have to worry about CPU compatibility. In our case we do need to make sure some external non-Elixir dependencies our app binds to are included on the docker image.
RUN apk add --no-cache libstdc++ openssl ncurses-libs wkhtmltopdf xvfb \
fontconfig \
freetype \
ttf-dejavu
(ignore the fact that wkhtmltopdf is kind of deprecated, we're working on it. But for now it's a non-elixir dependency we rely on).
If you're building for a, say, an EC2 instance and not using Docker, you'd just need to make sure your release is built on a similar OS to what you're using for production, and make sure the production AMI (image) has those non-Elixir dependencies on it, or will at the time of deployment, perhaps using apt or another package manager. For a VPS, the solution for non-elixir dependencies will depend on whether they have the option for customizing the base machine image (maybe with Packer or Ansible)
Since you may seem to have been a bit confused about it in the comments, yes, MIX_ENV=prod mix release will build all of your production Elixir/Erlang dependencies and include them in the /_build/prod folder.
I include the whole ./prod folder in our release, but it looks like protocol consolidation binaries and the lib folder .Beam files are all in the rel folder so that's a bit unnecessary.
If you do a default build, the target will be inside your _build directory, with sub-directories for the config environment and your application, e.g. _build/dev/rel/your_app/. That directory should contain everything you need to run your app -- the prompt after running mix release provides some clues for this when it says something like:
Release created at _build/dev/rel/your_app!
I find it more useful, however, to zip up the app into a single portable file (and yes, I agree that the details about how to do this are not necessarily the first things you see when reading about Elixir releases). The trick is to customize your mix.exs by fleshing out the releases option -- this is usually done via a dedicated private function but the organization of how you supply the options is up to you.
What I find is often useful is the generation of a single zipped .tar.gz file. This can be accomplished by specifying the include_executables_for option along with steps. It looks something like this:
# mix.exs
defmodule YourApp.MixProject do
use Mix.Project
def project do
[
# ...
releases: releases()
# ...
]
end
defp releases do
[
my_app: [
include_executables_for: [:unix],
steps: [:assemble, :tar]
]
]
end
When you configure your application this way, running mix release will generate a nice portable file containing your app with everything it needs. Unzipping this file is education for understanding everything your app needs. By default this file will be created at a location like _build/dev/yourapp-1.0.0.tar.gz. You can configure the build path by specifying a path for your app. See Mix.Release for more options.
Background, I currently use Izpack for my Windows installer, I bundle a java runtime and use winrun4j as a wrapper both for the installation and the actual program once installed. It worked for a long time but there are a number of problems with the installer that I have not been able to solve and have been looking to replace it.
Oracle now provide the JPackage installer so it seems like a sensible choice. But the folder structure created by the installer is different to what I currently have, I have a number of config and non java files and I have not been able to get the .exe that JPackage creates to do anything.
So is it possible to use JPackage to create the installer but in a strcuture better matching my existing structure, and use continue to use WInRun4j to actyally run my application
Existing Folder Structure
ROOT
---App.exe
---Config Files
---lib
-------jar files
---JVM64
------- Java runtime
---help
JPackage structure
ROOT
---App.exe
---Runtime Dlls
---app
----- jar files
Config files
--runtime
------Java runtime
------Runtime Dlls (again)
The structure of directories generated by jpackage is mainly set up for you and does not seem possible to change, and makes installation of Java app dependencies very easy with self contained JRE. The basic structure for Windows is as you say:
ROOT
---App.exe (for --main-class parameter)
---xyz.exe (for each --add-launcher parameter)
---Runtime Dlls (these appear to be unused except for applauncher.dll, see SO 62607300)
---app/
------App.cfg (for --main-class)
------xyz.cfg (for per --add-launcher)
---runtime/
------Java runtime
------Runtime Dlls
With --input and --main-jar params you are free to setup additional directory structure under app/ folder for anything else you want for your application. So if you used lib/myappjar.jar it would add:
---app/
-------lib/
----------myappjar.jar
If you used --input build\mypath it would copy the entire tree of files under that folder, so if build\mypath dir contained
bin/
---Scripts
---xyz.properties
README.txt
Then app would also contain:
---app/
------bin/
---------Scripts
---------xyz.properties
------README.txt
By the way the Runtime DLLs placed at top level appear to be copies of some of the DLLs under runtime/bin
[https://stackoverflow.com/questions/62607300/why-is-java-jpackage-installing-windows-dll-files-in-two-places]
For me to manually install tools like Groovy, Grails, Gradle, etc. on Windows, I need to set up a new env var (i.e. GROOVY_HOME) and then add that tool's bin directory to the system Path (i.e. %GROOVY_HOME%\bin), etc.
My understanding of GVM is that it allows you to have multiple versions of all these tools on your OS at any given point in time. But how is this possible with respect to the fact that the env vars must exist (and must point to a specific version) for these tools to run?
GVM uses symbolic links to change the current version of Groovy, Grails etc. Specifically, there is a symlink
~/.gvm/grails/current
If the current version of Grails is 2.3.5 this symlink points to
~/.gvm/grails/2.3.5
if you run gvm use grails 2.3.6 GVM changes the symlink to point to
~/.gvm/grails/2.3.6
So the GRAILS_HOME env var is always pointing at ~/.gvm/grails/current, but the target of this symlink changes when you run GVM commands.
The Windows filesystem doesn't support symlinks, which is why GVM doesn't work on Windows (though you might be able to run it under Cygwin).
I am a newb with python and just learning what to do.
I am using pyscripter and have been for a while whilst learning.
I am now going through an online course which is taught in 2.6, yet my pyscripter uses the latest.
I need to know how to change it to use an older version, I have seen replies about changing the PATH variable but not where it is or how to do it.
I have 3 versions of python on my machine, 25,26 and 33.
I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.
The easiest way I know (on Windows) is, having used the installer executable, I select from the Start menu's PyScripter folder whichever version of Python I want to run.
You can modify the PYTHONPATH (under Pyscripter>>Tools, for instance)
You can modify your External Python Interpreter with Pyscripter>>Modify Tools>>Python &Interpreter>>Modify
You can modify the default Python engine used with Pyscripter>>Options>>IDE Options>>Python Interpreter>>Python Engine Type
You can simply redirect Pyscripter to see the environment of a different Python distribution.
In Windows, do this by assigning PYTHONDLLPATH in the Pyscripter shortcut. You can r-click on the shortcut, access its properties and then set the target to:
[Pyscripter executable dir] --PYTHONDLLPATH [Python distribution dir]
See this image to help you out:
setting a shortcut target
For example, in my Win10 64-bit computer I have a Python 2.7.8 installation back from when I installed ArcGIS, which is automatically recognized by my 32-bit Pyscripter installation.
In the same computer, I also have Anaconda installed with two environments that feature two 64-bit Python distributions:
2.7.14 in "C:\ProgramData\Anaconda2"
3.6 in "C:\Users\bouzi\AppData\Local\conda\conda\envs\py3"
When I installed a 64-bit version of Pyscripter, that Pyscripter version couldn't even open, as it couldn't find the conda distributions. I had to point them to it by replacing the shortcut target to:
"C:\Program Files\PyScripterx64\PyScripter.exe" --PYTHONDLLPATH "C:\ProgramData\Anaconda2"
You can create three Pyscripter shortcuts that point to these different installations of Python within your system. It's probably not the optimal way to deal with this but it works, and allows you to combine Anaconda environments with Pyscripter.
You can also read more on opening non-standard python distributions with PyScripter from this link.
Run->Python Versions -> setup Python Versions -> Add... select folder
p.s.
python 3.7.3 - ok,
still python 3.10.5 could not be identified by PyScripter in such a way (actually works with WAY_1 Solution in this thread but pip install under such env. not succeed afterwards)
We've been using Grails for a little while now and have been through a few Grails versions now. We don't always want to migrate our 'older' apps immediately but often use a newer version for new development. Changing the Windows environment variables is inconvenient since I sometimes have to work on two related projects at the same time that are running different versions of Grails.
In Linux, I'd probably create wrapper scripts or aliases to allow me to specify on the command line a version switch but I don't believe Grails supports this.
How are others that need to code against multiple versions of Grails managing it?
Update:
I created a gv.bat file to set the GRAILS\_HOME and PATH environment variables. I added a GRAILS\_INSTALLS environment variable (c:\usr\local\grails on my box) and removed the %GRAILS_HOME%\bin reference from my PATH.
gv.bat
#echo off
SET GRAILS_HOME=%GRAILS_INSTALLS%\grails-%1
SET PATH=%GRAILS_HOME%\bin;%PATH%
To do any Grails work I run > gv 1.1.2 or whatever version I need to work with. I'd like to figure out how to do a string replace in the PATH to change the value but that turned out to be difficult for me
I have a couple of bat files which changes the GRAILS_HOME and the system PATH according to which version I'm using.
It's not the most beautifull solution at all, but at least works for me.
I have a batch file, that looks like below.
#ECHO OFF
if "%1"=="231" goto grails231
if "%1"=="232" goto grails232
if "%1"=="233" goto grails233
if "%1"=="234" goto grails234
goto end
:grails231
set GRAILS_HOME=F:\softwares\grails-2.3.1
set PATH=%GRAILS_HOME%\bin;%PATH%
goto end
:grails232
set GRAILS_HOME=F:\softwares\grails-2.3.2
set PATH=%GRAILS_HOME%\bin;%PATH%
goto end
:grails233
set GRAILS_HOME=F:\softwares\grails-2.3.3
set PATH=%GRAILS_HOME%\bin;%PATH%
goto end
:grails234
set GRAILS_HOME=F:\softwares\grails-2.3.4
set PATH=%GRAILS_HOME%\bin;%PATH%
goto end
:end
It can be run like 'setgrails 233' and it will set the grails 2.3.3
IntelliJ allows you to specify which version of Grails to apply as a per-project facet configuration. The Eclipse plugin has yet to achieve this level of abstraction.
It's now MUCH much later, and GVM is not the tool it once was. Instead, I use SDKMAN (https://sdkman.io/) and, with Windows getting some linux-like tooling, or using Cygwin, etc. it's installable on Windows.
------ OLD answer below ------
GVM is a tool for unix/mac environments to manage Groovy/Gradle/Grails/more versions, and someone finally made a Windows equivalent called Posh-gvm (short for Power-shell GVM). It's very useful and easy to use to download and configure your environment for whichever version of these tools you want to use at any point in time.
If you're using an IDE, posh-gvm is still a great way to download/install the new versions as they come out, and your IDE can point into the posh-gvm install directories.
I have the same issue as you. For my concern, I have written a batch script (grails_version.bat) accessible from my Windows PATH home.
Set up your GRAILS_HOME to your standard Grails version and each time you want to run a Grails app into another version than the standard one, open a command prompt, run the batch script (>grails_version) and run your grails commands (ex: grails run-app).
If your are using IntelliJ, you can configure the grails version per application.
Here is the code:
#echo off
set v11=1.1
set v111=1.1.1
set v12M2=1.2-M2
set v12M3=1.2-M3
set v12M4=1.2-M4
set /p grails_version= What is the grails version (%v11%, %v111%, %v12M2%, %v12M3% (default), %v12M4%)?
if "%grails_version%" == "%v11%" goto :set_grails_home
if "%grails_version%" == "%v111%" goto :set_grails_home
if "%grails_version%" == "%v12M2%" goto :set_grails_home
if "%grails_version%" == "%v12M3%" goto :set_grails_home
if "%grails_version%" == "%v12M4%" goto :set_grails_home
if "%grails_version%" == "" goto :set_grails_home_default
:no_valid_input
echo The input version is not valid
exit
:set_grails_home_default
set grails_version=%v12M3%
:set_grails_home
set GRAILS_HOME=D:\Install\grails\grails-%grails_version%
path = %GRAILS_HOME%\bin;%PATH%
echo GRAILS_HOME=%GRAILS_HOME%
Enjoy.
I do that in Windows as below.
So I just change GRAILS_VER environment variable.
I can change my grails version anytime.
On Linux/Mac, GVM is a fantastic tool for installing and working with multiple versions of Grails, Groovy, etc. You can't use GVM itself on Windows1, but there is a clone posh-gvm that will run under Powershell on Windows.
AFAIK this is because Windows doesn't support symlinks
The thing I would change about these answers is the PATH handling. Each time you run the script and change versions, you will extend your path one more node. It works, but messy. Try creating a $path2 with no reference to your JAVA_HOME or GRAILS_HOME and the path become path2+grails+java. Example: set PATH="%PATH2%;F:\softwares\grails-2.3.1;path2java7.
The only reason I add the Java7 reference is that I need Java 6 for my older grails app and Java 7 for newer grails.
Check out this link, it explains exactly how to do that using cygwin and mapping several aliases.
Also, learn how the plugins directory work and replicate it several times for each version of Grails. I also use global plugins for the ones I use often, like tomcat, hibernate, dbUtil, console, etc.
Say you want to switch between 1.1 and 1.2M4 - you could have those directories setup with the plugins you are using:
c:\Users\username\.grails\1.2-M4\projects\projectname\plugins
c:\Users\username\.grails\1.1.1\projects\projectname\plugins
Then, take applications.groovy and make several copies, like
application.groovy.1.1
application.groovy.1.2M4
Now, to switch, you just need to rename the application.groovy.X to application.groovy and you are good to go (after running grails clean of course):
grails1.1 run-app
grails12M4 run-app
Lastly, there are other differences between versions (i.e. new 1.2 is introducing dependencies DSL), but most of the time things are backwards compatible enough that you can come up with a common denominator.
Some answers are outdated.
Seems that the best option nowadays is SDKMAN!:
SDKMAN! installs smoothly on Mac OSX, Linux, WLS, Cygwin, Solaris and FreeBSD. We also support Bash and ZSH shells.
Is also possible to install on Windows, but SDKMAN "can not be installed natively on Windows and requires WLS, Cygwin or MSYS+MinGW".
After that, you can choose the Grails SDK and which version you want. For example:
sdk install grails 1.3.7