I developed a plugin using Eclipse Indigo. It depends merely on the usual suspects like org.eclipse.core.runtime etc., there is only a single unusal prerequisiste org.eclipse.imp.runtime.
I am quite sure that the latter should run with 3.5.
Now I have the problem telling potential users what Eclipse version they'd need at least to install it.
Will it even be installable on previous versions when developed with 3.7?
If so, how can I find out what the minimal required versions are (I hope that I do not need to edit version numbers etc. in the plugin.xml?)
If not, does this mean I have to install, say, Eclipse 3.5 somewhere and build it there if I want to support 3.5 and higher?
Can this help you: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fdependencies.htm
It is said, that:
You can also specify the Minimum Version and Maximum Version of the plug-in dependency.
Related
My SVN Connector in Eclipse shows the following message:
Picture of the error message
Can someone help me solve this error? I have Subclipse and Subversive installed.
You need to install only 1 I think. Not sure if installing both causes new problems.
There are several issues with both subclipse and subsersive.
Both I think can use a java library called " SVNKit" or use a native library "JavaHL" to access SVN.
The error complains about javahl missing. You manually hjave to install javahl in your system, eg How to upgrade JavaHL on Ubuntu?. But even then it often does not work. I think this is due to version conflicts or so...
The alternative, svnkit, is less prone to such version conflicts. Adapters are not used by default however, apparently nobody has time to fix the libraries to use them properly. So they sometimes work, sometimes not. There also is a problem with java >9 because the svnkit library (at least the usual version) uses some java calls that have been restricted/security-walled in newer java. Not sure how/why/which versions, it also depends on the OS. You need to dig down in the preferences/settings to disable the JavaHL and turn on the SVNKit.
Overall both adapters need a lot of massaging and it's totally unclear to me which adapter works on which system and eclipse version.
I have an application which I would like to deploy, compiled for java 1.8.0_151. However, the user has only 1.8.0_25. User cannot launch the app because LocalDateStringConverter is missing.
As written here (https://docs.oracle.com/javase/8/javafx/api/javafx/util/converter/LocalDateStringConverter.html) this class has been added only in 8u40
How can I compile (is it possible?) a jar with dependencies for the specific java version of the user?
Or maybe I misunderstood something, new to java here
EDIT I tried specify the pricise version with update number in my pom.xml but it didn't help
There are a two ways to approach this:
You have to set your environment to use the JDK that is expected by the user. In this case 1.8.0_25 - you need to develop all logic using this JDK and the classes available in it. If LocalDateStringConverter is your only dependency missing, you can easily find out the source code and duplicate the logic inside your project as utility class and use that instead.
You can ask/help/advise your user to upgrade their environment to more recent JDK version (security reasons and such). As you are aware most software has minimum requirements to run and it's expected from the end user to meet those requirements in order to run the software.
As already mentioned you can use the Maven Enforcer Plugin to enforce specific java version, but this will not make the functionality from 1.8.0_151 available in 1.8.0_25.
Compiling your code with 1.8.0_25 and hoping that the newer versions are backward compatible is probably the easiest solution. Assuming you have automated tests this will catch problems like a missing class.
The other option would be to build an executable bundle containing both your application and the entire JRE 1.8.0_40 or newer. This is going to result in your software bundle growing by dozens of MBs so I would not recommend it. However one way to do it would be to use Launch4j as advised here.
You can try implementing your own LocalDateStringConverter but how many other classes are you missing? What if there are other subtleties in behaviour between versions? Based on java.com 1.8.0_25 was released on October 14, 2014 while 1.8.0_151 on October 17, 2017. That's 3 years of Java development that your user is missing.
Recently I was assigned to a task wherein I have to upgrade the existing standalone java application from Java 1.6 to Java 1.8.
I'm yet to go through the code and I have no idea about this project.
They were using
ANT 1.6.1,
AXIS 1.5.1,
ABINITIO 2.15,
ORACLE 11.1.0.7,
AUTOSYS R11,
Java 1.6.
I got to know that first I need to identify whether the above mentioned Tools/Frameworks are compatible with Java 1.8.
Please suggest what are the other challenges I might encounter while compiling and building the application?
Although Java is supposed to be backward compatible between versions, it's also known that backward compatibility in any language isn't aways as straight forward as the name suggests. Some (most) projects release it's libs versions compiled specifically targeting one or another development kit, to take advantage of new features and enhancements added to the language.
That being said, I believe the smarter way to go would be: first, update the project's JDK and rebuild it targeting the new bytecode's version. There's a chance you'll have to upgrade both Ant and (if that's your IDE of choice) Eclipse (see here why).
Second, you'll have to check for compilation errors, which will most likely lead you to update libraries conditionally to get them fixed. With those solved, you MUST run your app and see if it's running as intended; remember that compilation problems are just the top of the iceberg when the subject are dependencies.
Carefully check the app's logs looking for exceptions of any kind but mainly the ones related to class loading exceptions such as ClassCastException, ClassNotFoundException, NoClassDefFoundException, UnsatisfiedLinkError and others. If any apear, you'll have to pinpoint one by one and search for the specific solution of the specific troublemaker library.
With all that covered, you should have your app running healthily again.
One last hint, if this project of yours is still being developed, it would be a very good practice to keep the tools you use updated to their very last release. Keep also the development tools updated, like build (such as Ant, Maven, Gradle and others), JDK's and IDE's. It way easier to upgrade the pieces as they are release than to handle a mass scale upgrade :)
I'm maintaining a parent pom for my team which will provide the latest compatible version of various maven plugins per the JDK that the project uses. Sometimes if a project utilizes an older version of Java (like 1.5) maven will fail due to a plugin requiring a newer version. Is there a way to get a map of a given plugin and see what the minimum java version is for said plugin? I was thinking there was some sort of report or something that would show me that, but I'm not seeing anything.
What about: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html Apart from that on every plugin page you can find the goals page which contains the information you need. One more thing if you are using not the most uptodate versions all older versions pages are available where you can look at which version which JDK versions uses. It shouldn't be problem to write some kind of script to programmatically extract the information of the older plugins. The above site contains the informations of the uptodate plugins.
Apart from that plugin version selection basead on JDK version is not a good idea. The plugins have only a minimum version for JDK they need to run with. Apart from that they run on all versions (already on JDK 9 with one exception)...Furthermore plugins might require a minimum Maven version to run with which is either Maven 2.2.1 or Maven 3.0+ which shouldn't a problem.
You should define your plugins versions simply based on problems you might have but i would recommend to keep uptodate with your plugins.
If you need running you build with JDK 6 for example, but you use Maven 3.3.X which needs JDK 7 to run you can achieve this by using toolchain to handle this situation.
In theory this shouldn't be an issue. Maven will use the Java version you run it with, so the plugin's dependency will be satisfied, independent of the project's language level. Just make sure your devs are using a current version.
Example: running Maven with Java 8 will satisfy the dependency of a Plugin that requires Java 8, independent of the project's source and target level.
(With dependencies it's more complicated, I am afraid, but since you are not actually coding against your plugins, you should be fine)
I use Eclipse Indigo for java development but I want to experiment with scala. Since I have to download a nightly build to run on Eclipse : http://scala-ide.org/download/nightly.html is this safe ?
Is there a chance the plugin can corrupt my eclipse installation since the plugin is not a full blown release as yet ?
I run the latest Scala milestone with no problems right now, which is probably safer than the nightly, and has better highlighting features. If you do run into trouble you can always revert to a previous installation state in Eclipse, so I would consider it safe
The plugins architecture is designed so that Eclipse is protected from instability, unless they maliciously delete files on your installation, I doubt they would break Eclipse permanently. To be extra careful you can make a backup of your eclipse directory.
Nighly builds gives developers a chance to use latest features (not certified to be working on all environments) of the plugin which are not yet made available to end users. In general they work fine but there may be few undiscovered issues. You can always rollback your installation if something goes wrong or if you find any bugs.
If your aim is to learn or develop using scala, better to use stable build. A stable scala-ide plugin is available for Eclipse Indigo. Please visit 'http://scala-ide.org/download/current.html' for more details.