Building Hibernate 3.2.0 on Linux OS 64 bit - linux

I need to build the jars for Hibernate 3.2.0 but I am having trouble finding directions. I am trying to follow along in the tutorial but it is wanting me to create classes and other files, is that really necessary just to compile the jars? I need to compile on a 64 bit Linux CentOS machine.
Also the directions in the tutorial are for 3.5 or 3.6 and they say to use maven but when I downloaded the source it came with a build.xml file, so am I supposed to use ant? and when I try ant it tells me I am missing antl/tools.
I am a brand new intern and I am just trying to figure this out so I can do what is asked of me. Any help would be greatly apprecited.
Thank You in advance.

For branch 3.2, you'll just need to run the run.sh (Linux) or run.bat (Windows). It should be enough. But keep in mind that 3.2 is an old branch. If you are developing a new application, consider using a newer version (3.6, for instance).

Binaries for Hibernate 3.2 can be downloaded from their SourceForge project page. Hibernate distributions typically contain hibernate3.jar, dependent jars, reference manuals and source files. The jars can be used on any JVM with version higher than 1.5 (or 1.4, I don't remember precisely) available on 64-bit CentOS.

Related

Eclipse - cannot download version 3.6.1

I need to download an old version of Eclipse on Linux 32bit (Eclipse version: 3.6.1).
But I face a problem with downloading - all mirrors are unavailable (https://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.6.1-201009090800/eclipse-SDK-3.6.1-linux-gtk.tar.gz)
Do anyone knows another way to download it?
Inb4 "try to use other/new version" - I cannot. The project needs to be configured on Eclipse 3.6.1, Linux 32bit. It is impossible to use other or the new one.
Thanks!
The Eclipse "Classic" version is not available (or almost, I cannot found it) but checking on releases page (http://www.eclipse.org/downloads/packages/release/helios/sr1) you can download all the rest versions:
Java EE
Java
C/C++
...
It could be helpful for you, I think.

Is IBM Maximo 7.6 businessobject jar compiled in Java 1.8 compatible to run in java 1.7?

I have got jar compiled in java 1.8 from maximo dir and on my machine i have java 1.7 installed do i need to update my machine java before i run this jar. I can not run it before knowing this since it will get recorded in some logs and will update some server side files.
This is more of a Java question than a Maximo question, but no, it will not. You will get an "Unsupported major.minor version 52.0" if you do. This is not because of any features issue, this is simply because the bytecode is tagged as being from Java 8 and so earlier JREs will not run it.
Now this assumes you actually compiled the class files using Java 8, which probably only happened if you have custom code in there. If you are just using the out-of-the-box Maximo classes, those came pre-compiled (in I don't recall which version of Java) and so all you might have done was to bundle them into a jar, or more likely into the Maximo ear (since you don't run the businessobjects.jar). In that case, it doesn't matter what version of Java you used to created the jar/ear, it will run on any version of Java that is the same as or higher than whatever version IBM used to compile the code into classes.

JavaFX missing from JDK 1.7/1.8 in Linux?

I have a problem that allegedly isn't possible, so I'm having a heck of a time finding an answer.
I have the latest version of NetBeans 7.4, running on fully-updated Fedora 20 x64. Officially, this can work with JavaFX. Period. I have both the JDK from the repo (1.7.something) and the very latest version I could find (1.8.0). Officially, these have JavaFX with them. Period.
If I try to create a new JavaFX project, it has this to say:
Failed to automatically set-up a JavaFX Platform.
Please go to Platform Manager, create a non-default Java SE platform, then go to the JavaFX tab,
enable JavaFX and fill in the paths to valid JavaFX SDK and JavaFX Runtime.
Note: JavaFX SDK can be downloaded from JavaFX website.
Well alright, I'm used to things getting confused, I think I can fix this. Go create a new platform, and... there's no "JavaFX" tab. It took a bit of research to even find out what it was talking about, and in the process I discovered that the tab has actually been removed from 7.4. Because NetBeans 7.4 will absolutely, definitely recognize JavaFX automatically. Period.
Going to the actual JavaFX site tells me, as expected, that it's bundled with the Java SE 7 JDK I already have. Period.
Since the end result I'm after could technically be achieved by integrating one JavaFX component into my Swing application, I attempted that, but NetBeans still can not find anything related to JavaFX and therefore yells at me if I try to import such a thing.
So, given that things that are supposed to just plain work just plain aren't... where can I go from here?
Currently in Debian and Ubuntu (probably others) JavaFX is a separate package from the OpenJDK (openjdk-8-jdk) and so needs to be installed:
sudo apt-get install libopenjfx-java libopenjfx-java-doc
Notable issue (this issue does not impact a Maven, JavaFX application so if that is your preferred build method then ignore the following issue):
If you try to create a new project:
Categories > JavaFX
Project > JavaFXApplication
You'll get:
Internal error. Missing resources [/resources/web-files/javafx-loading-100x100.gif]
/home/ken/NetBeansProjects/vestFxReports/nbproject/jfx-impl.xml:1465: The following error occurred while executing this line:
/home/ken/NetBeansProjects/vestFxReports/nbproject/jfx-impl.xml:3093: The following error occurred while executing this line:
/home/ken/NetBeansProjects/vestFxReports/nbproject/jfx-impl.xml:2055: Error: -includedt requires the java deployment toolkit, which is not included in this distribution
BUILD FAILED (total time: 1 second)
To fix the above error [following steps are derived from here: http://hongouru.blogspot.com.uy/2015/09/solved-error-building-new-project-using.html]:
Switch to the files tab (usually you're on the Project tab).
Expand the node for your project >
expand the nbproject node > open the "project.properties" file.
Find the line javafx.deploy.includeDT=true and change true to false.
Now you can create and run a JavaFX application, on OpenJDK.
Next steps, although beyond the issue at hand you'll probably at some point want to download the JavaFX scene builder: http://www.oracle.com/technetwork/java/javafxscenebuilder-1x-archive-2199384.html
Apparently, the issue is indeed a discrepancy between the open-source OpenJDK provided by most Linux distributions, and the proprietary Oracle JDK. Ironically, this is a well-known issue, but you have to specifically search for it to find it, and by then you already know.
The solution is to download the official Oracle JDK, and if necessary create the matching platform in NetBeans (located under /usr/java/jdk... at this moment). It should work perfectly fine after that.
Perhaps the official documentation
https://netbeans.org/kb/docs/java/nb_fx_screencast.html
https://netbeans.org/kb/72/java/javafx-setup.html
may help you to set it up

Can a groovy code be compiled to run in JRE?

I am new to groovy and I cannot understand, if it is possible to compile a groovy program, so it runs at all computers, were the JRE is installed.
The application I am developing has to run on any computer with JRE 1.5. Is it possible to start using groovy and maintain this flexibility? With JRE 1.6?
I have heard about the library groovy-all-VERSION.jar. Is this the one required library to be shipped with my application?
The answer is yes. In fact, all groovy code compiles down to Java classes that run on the JRE. All you need is JRE 1.4 or higher and the groovy-all-*.jar on the classpath of your application.
Since you are looking to support JRE 1.5 or higher, make sure your source compatibility is set on your compiler to this level.
There are a few options for compiling your groovy code. Groovyc (Ant Task), GMaven (Maven) and Gradle are all options.
Another option you have is to 'not' compile your groovy code. The groovy distribution only requires the JRE to be installed. You can ship your application as a set of scripts that can simply be run using the groovy install. It depends on how sensitive your source code is.
The short answer is yes. How you do this depends on your build system. I do all my development in eclipse, right click my project, select export, select runnable jar file, and all the required librarys are exported in the jar file. I can then run this file on a machine with out Groovy installed. I know build systems like Maven support Groovy but don't know the details on how they do it or how good there support is. According to this question Java 1.4 or above is fine. When looking at the "Setting up your Java environment" section of the initial tutorial it looks like you need Java 1.5 installed.

.exe generated in cygwin 1.7 is not running on cygwin 1.52

A year back i have developed a small script in perl for a customer and developed its .exe using pp .
we delivered .exe file along with basic cygwin(1.52) install files to run that .exe to customer.
Now we got an enhancement in the script .we lost all dev environment for cygwin .Again we installed fresh cygwin with 1.7 version ,coded and generated .exe file.this file is not running in the customer environment who have cygwin 1.52.Just it will be balnk after executing the .exe
we cannot ask customer to upgarde the test environment.
what is other way to make it run .exe with cygwin dll 1.7 on cygwin 1.52.
Any help would be higly appreciated.
Rgds,
sowm
The developers of Cygwin are strict about upward compatibility, but they don't try to provide backward compatibility between major releases, like between 1.5 and 1.7. This means you can build a program on 1.7 that runs on 1.5 only as long as you avoid calling functions that were added to the Cygwin DLL in 1.7.
Most likely the reason your code calls 1.7-only functions is that it is using libraries that auto-discover platform features. There could be other reasons, but without any details about what exactly is failing, it's difficult to guess.
If the problem is due to third-party libraries, as I'm guessing, it may be practical to spend time to figure out how to make them revert to the common functionality provided by both 1.5 and 1.7. For instance, with an autoconf-based system, you can hand-edit the config.h file the configure script produces to turn off use of some discovered features. This in turn means building all those libraries from source yourself, rather than downloading binary versions from the Cygwin project repository and using them directly.
It may be easier to pull a Cygwin 1.5 environment out of the Cygwin Time Machine.
By the way, you are aware that distributing Cygwin and executables built with it requires that those executables comply with the GPL, or that you buy a Cygwin commercial distribution license, right? If not see the FAQ.
Install 1.5 with http://cygwin.com/setup-legacy.exe

Resources