Play! framework comes with tons of jar libraries. I am using version 1.7 of apache commons-codec for my Play! application. But Play! is already shipped with version 1.4 and some other older versions. I have placed my commons-codec-1.7.jar in the lib folder, and 'eclipsified' so the jar file is in the class path. But when I expand the Project Explorer in Eclipse I see that both version 1.7 and 1.4 are referenced by the application. My questions are
How do I remove version 1.4 from being referenced?
Why did the app choose version 1.4 even though version 1.3 and 1.2 are present in the [PLAY_HOME]/repository/local
It is a collaborative project. I want to make sure that once I push the code in git and my colleagues pull it, they need not to do the same 'hack', just 'clean' and 'compile'. How can it be done?
BTW, I am using Play! 2.0.4
Add commons-codec to your Build.scala and you'll be fine. The dependencies will be correct since the specified dependency will override the ones that are default.
val appDependencies = Seq(
"commons-codec" % "commons-codec" % "1.7"
)
You don't have to remove version 1.4. Version 1.7 will be in effect now.
That is caused by the order they are presented in the classpath.
play compile will do it. And you'll have to eclipsify the project again.
Don't forget to remove the commons-codec from the lib folder. As said it will be downloaded and put in the classpath automatically.
Related
We were trying to bump our dotnet version from a mix of .net 2.2 & .net core 3.0 to .net core 3.1 and we followed Jeff Holan's Dev post to upgrade which is surmarised as below
To change a project between ~2 and ~3 locally, update the .csproj file of the project and change:
AzureFunctionsVersion from v2 to v3
Microsoft.NET.Sdk.Functions package version to at least 3.0.1
Optionally, you can change to target netcoreapp3.1 if you want to target the latest .NET Core version
But while debugging Azure function project locally in VS Code, it still failed with an error message suggesting that there were still config remnants pointing to 3.0. Anyone encountered this issue?
[
[
On doing a full project search, we found that VS Code itself stored [i.e. in its .vscode directory], namely in two files: settings.json and tasks.json. Some config key value pairs still pointed to .net core 3.0 [perhaps these were added during when we were debugging the project when these were the current framework]. So for the migration from 2.2/3.0 to 3.1 we need to to ensure the references to the older frameworks are removed
We have to explicitly make the changes in tasks.json from netcoreapp3.0 to netcoreapp3.1
Ensure the deploy path in settings.json points to .net core 3.1
PS: In settings.json, project runtime is bumped upto 3 if you have followed Jeff Hollans dev article, otherwise it will mostly point to ~2
I downloaded javafx-autocomplete-field-1.0.jar and used it for my development work in jdk 1.8 environment. But I need to deploy this in 1.7 environment. If I do so, I'm getting "java.lang.UnsupportedClassVersionError: np/com/ngopal/control/AutoFillTextBox : Unsupported major.minor version 52.0". Is there an alternate jar for jdk1.7? Or is there anyway I can make this jar compatible in 1.7 environment? Please help.
Just try for this jar. I have checkout in previous commit it
https://github.com/privatejava/javafx-autocomplete-field/commit/a92545e0fc33d0f54676e4fd27de743c5e0c5358 so please trythis jar
https://www.dropbox.com/s/xn01e5a3tm65mmz/AutoFillTextBox.jar?dl=0
You need a version that is compatible in both fx 2 and 8:
https://bitbucket.org/jugen/autofilltextbox/downloads
For the last two days I'm trying to push my application on Azure but I'm facing problems about the Symfony 2.4 deps (with composer). The main error is :
symfony/icu v1.2.1 requires lib-icu >=4.4 -> the requested linked library icu has the wrong version installed or is missing from your system, make sure to have the extension providing it.
I saw on the internet that the problem could be about the php_intl extension not loaded. So after hours I managed to get it by creating a bin\ext\php_intl.dll in my root directory (the documentation does not mention the ext subdirectory, and it was not working for me when I put the intl into the bin directory).
Internationalization support enabled
version 1.1.0
ICU version 49.1.2
ICU Data version 49.1.2
But I always get the same error. Do you have any idea about this?
Thanks.
Try to add in your composer.json :
require: {
"symfony/icu": "1.1.*"
}
See http://symfony.com/doc/current/components/intl.html, chapter "ICU and Deployment Problems"
A straightforward issue for java new comer:
IMO, Java should keep backward compatible, so a jar built with JDK5 should work on JRE6 or high environment, but the converse case should fail.
However from the netty page,
https://github.com/netty/netty/tree/netty-4.0.17.Final,
I found the following:
You require the following to build Netty:
Latest stable Oracle JDK 7
Latest stable Apache Maven
Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.
This really confuses me, could anyone can help explain this?
Yes, if you specified proper -source and -target option to the javac. Netty's pom.xml specifies -source 1.5 and -target 1.5 to ensure that.
How can I set my java jar application to use jre 6 instead of jre 7?
I'm doing this because there are some compatibility issue with the libraries I'm using if the application use jre 7.
Edit:
The application will come with its own installers (using advanced installer) that have a jre6 installer. But I don't know how to trace the installation folder of the jre6.
How can I trace it and make the jar file use the jre6?
You can do this from Advanced Installer much simpler. You have two options:
Force the package to use the JRE 1.6 found on the machine by going to "Virtual Machine" tab from Java Products page and setting the minimum and maximum JRE versions to 1.6
Add as bundle in the project from the same page the JRE for version 1.6. This means that Advanced Installer will automatically import in your package the JRE resources required for your application, thus increases the package size, and will install them in the application's install folder. This JRE bundle will be used only by your application and removed along with it.
When running your application using java.exe, you could provide the absolute path to a Java 1.6 installation. Something like:
absolute_path_to_java6_dir/bin/java -jar yourRunnableJar.jar
or
absolute_path_to_java6_dir/bin/java -cp .;yourJar.jar;otherJarFiles className
You could check the running JVM version when starting your application.
System.getProperty("java.version");
This way you could provide a meaningful explanation to end-user.