I would like to use JDK 1.6 for a branch of a project while others keep using JDK 1.5. Developers want to occasionally switch between those.
So what is the best way to tell Ant's javac which JDK to use? By best, I mean a robust, transparent, low maintenance, versioned together with the source (Ant itself and JDK are certainly not, but they live at standard places).
The obvious -rather than best- way I guess would be outside of Ant: keep changing the JAVA_HOME env variable. However this would require developers to manually switch (another thing to remember: error prone), an changing all the -many- build servers (more work for me now).
Looking for some simple javac attribute e.g jdk-path, I noticed several instead (thanks to reading up on the net and in SO):
compiler- fair enough, but docs says "modern: .. javac1.5 and javac1.6 .. as aliases".. To me this suggests it won't make in any difference - will it?
source- seems only related to JLS version (althought not %100 clear from the docs linked above)
target - bytecode version
bootclasspath - some SO answers mention this, but pretty unclear and seems hackish
executable - path to javac, but not to libs.. -- seems the closest match, implicitly specifying JDK path? UPDATE: confirmed by JB Nizet
fork - it seems I'll need true here (otherwise it'll just ignore the above without error?). UPDATE: Any performance implications vs. default? (I guess JVM startup times are better these days, but still)
So, it seems none of these help in itself.. is any combination of these equivalent to setting JAVA_HOME prior to running Ant?
I have some hacks in mind (eg wrapping ant executable on each platform just to set that env var - quite sad), but I really hope I missed something :)
Using the executable attribute needs to set the fork attribute to true. This means that the javac ant task will launch an external process to execute javac.
When you launch javac manually, you don't have to specify any specific JDK lib directory: it knows where to find the libraries of the JDK it's part of. I'd say it will be the same if you launch it through ant's javac task (unless you override the bootclasspath).
Which version of the JDK is used to compile the classes should not necessarily matter. There may be differences in how a particular JDK compiles resources, but if the difference is just between v1.5 and v1.6, you can compile code to be compatible with Java 1.5 (or even 1.1) using a 1.6 JDK.
You can control what JVM version to compile for using the target attribute:
<javac srcdir="${src}"
destdir="${build}"
fork="true"
source="1.5"
target="1.6" />
Related
I have a working version of my project in eclipse.
I exported the project as a runnable jar.
Extracted (after converting to .zip)and tried to compile a particular java file from the command prompt
(Doing it this way since I have a project requirement, where input parameter inside that particular file can be modified and recompiled/run by users who wont have Eclipse)
I have used some external libraries( for Eg:json-simple,gson etc).They arent getting recognized , during compilation.
But if I run the class file(from the Eclipse compiled version), it gets executed properly
a)Tried to compile from root folder(using package name)
javac packageName.javaFileName.java
b) and went inside the package and compiled directly.
javac javaFileName.java
The a)part didnt compile at all saying classNotFound. The b)part started compiling but threw an error where none of the external libraries got recognized.(Getting --> error: cannot find symbol for places wherever the code/import of the external lib is used)
a)Tried to compile from root folder(using package name) javac
packageName.javaFileName.java b) and went inside the package and
compiled directly. javac javaFileName.java
The a)part didnt compile at all saying classNotFound.
Yes. javac requires you to specify a filesystem path to the (first) source(s) to compile. You appear instead to have tacked .java onto the end of the desired fully-qualified class name. Probably you want to compile from the root of the unpacked jar, specifying a correct path:
javac [options] package/name/className.java
for class package.name.className. (You can also compile from a different working directory if you specify an appropriate option, as discussed below.)
The b)part
started compiling but threw an error where none of the external
libraries got recognized.(Getting --> error: cannot find symbol for
places wherever the code/import of the external lib is used)
If the class you're compiling depends on others that also need to be compiled then javac would likely make a similar complaint about them. Either compile from the root (as in (a)), or specify the path to the source root via the -sourcepath option. Either way, there's no reason to descend into the source tree to compile.
But the external libs are actually a separate, albeit related, question. You don't need to compile these, but you do need to tell javac to use them as sources of classes. You would do that via the -classpath option, which you can abbreviate to -cp. If those were packaged in the jar itself (i.e. a "fat jar") then that should be fairly easy, something along these lines:
javac -cp .:lib/dependency1.jar:lib/dependency2.jar package/name/className.java
The "lib" part may vary, and the separator definitely differs depending on OS (on Windows it is ;, whereas on Mac / Linux / Solaris is is :, as shown).
If the external libs were not packaged into the main jar then the procedure is the same, but you might have a bigger challenge finding the needed jars. Also, such a jar is probably not runnable if you move it to a different machine. Nevertheless, you should probably look in META_INF/MANIFEST.MF, as it should contain the needed information.
Apache OfBiz is not installing correctly, and fails to compile in the command prompt.
After creating the system variable JAVA_HOME to C:\Program Files\Java\jdk1.8.0_40, and editing "Path" to be C:\Program Files (x86)\Java\jre7\bin;C:\apache-ant-1.9.4\bin, I downloaded OfBiz 13.07.01 to my C:\ folder and unzipped it there. In the command prompt, I typed the following:
C:\Users\CalS>cd C:\apache-ofbiz-13.07.01
C:\apache-ofbiz-13.07.01>ant load-seed
Then, after about 50 seconds, I get this:
BUILD FAILED
C:\apache-ofbiz-13.07.01\build.xml:229: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:248: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:39: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:91: compile failed; see the compiler error output for details.
Please note it has been years since I dealt with DOS, so I do not know how to access the error output.
This is after I get a few dozen errors like:
[javac16] class file for org.ofbiz.widget.ContentWorkerInterfaice not found
and
[javac16] warning: [options] bootstrap class path not set in conjunctions with -source 1.6
Under 'classes'.
Misc. I have tried 'ant run-install' and 'load-demo' commands without avail. I've followed step-by-step tutorials, but very likely missed something. Please let me know what I can do to fix this and run this program successfully. Thanks!
Please have a look at the following Apache Jira Tickets for OFBiz where your problem is addressed and was fixed, so that OFBiz could be build with java 1.8.
The build errors occur due to missing fileset entries in the build.xml for some applications (party, workeffort, product, order, ebay, and pos), see: OFBIZ-5835
A fix is available in related ticket: OFBIZ-6079
There was another bug in the current release branches (checked 14.12.01, 12.04.06, 13.07.02) that I fixed last week. The fix is already committed to the branches.
See: OFBIZ-6252
You have to compile/run with the same Java version.
Seems you have some inconsistencies: JAVA_HOME ist 1.8, Path is set to jre 7 and the warning states it is using an 1.6 compiler.
With the 13.07. Release, using Java 1.7 or 1.8 is recommended and supported.
Alright, so it looks like Apache OFBiz and Java JDK 1.8.XX don't get along. I found help on another forum that confirmed the discrepancy in compatibility between OFBiz 13.07.01/Apache ant 1.9.4 and JDK 1.8.XX. This will cause the compiling of the Apache Ant to fail (which seems to run off of JDK 1.6).
I remedied the problem by downloading the archived JDK 1.7.0_67 from Oracle, re-mapping the System Variables accordingly, and re-initializing the Command Prompt.
It works now! Thank you all for your contributions.
Though solved, let me add something important. JDK version is not always an issue in such errors. Ofbiz v13.X.X works well on JDK 1.7 and above. The error shown is a peculiar issue with Ofbiz v13.07.01 dist.
As Martin pointed out, one need to add widget jars in the classpath of order, party, product & workeffort. Add the below line
<fileset dir="../../framework/widget/build/lib" includes="*.jar"/>
in build.xml of order, party, product & workeffort under applications directory.
So I am using Netbeans to develop a Jenkins Groovy Post Build Script.
Jenkins runs in 32 bit mode (Production cannot touch), Netbeans wants to run in 64 bit mode.
I can get EITHER environment to work, the problem is that I need to keep switching my PATH variable so the right version of a DLL is on the path, but switch is time consuming and annoying.
I am trying to figure out how to get Netbeans to either run in 32 bit mode or to change the PATH variable in Netbeans to use the 64 Bit DLL (something Visual Studio supports).
So far, nothing I've done has convinced Netbeans to use 32 mode and I see no way to change the path for the Netbeans IDE.
Suggestions?
So I never did get -D to work properly. The values provided there just didn't seem to be reflected in the environment like I would have thought.
My eventual solution was to create a small *.BAT file that doctors the PATH before starting Netbeans. I would LOVE for someone to offer a better solution.
SET PATH=%PATH:enu\auth\x86=enu\auth\x64%
cd /d "C:\Program Files\NetBeans 7.2"
start "NetBeans with PATH Override" "C:\Program Files\NetBeans 7.2\bin\netbeans64.exe" --console suppress
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)?
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