I need javascript i18n in my web application which is based on Spring MVC.
For javascript 18n I am using jQuery.i18n.properties and the URL where I found it is http://code.google.com/p/jquery-i18n-properties/
When I run a sample application, it works properly but when I integrate it in my application it does not work.
Basically my javascript code is not able to load the js properties files. When I show a alert using keys, it always shows key but not the key values.
Here is my project structure.
└── WebRoot
├── resources
│ └── scripts
│ ├── i18n
├ ├── resourceBundles
├ ├ ├── Messages_en
├ ├ ├── Messages_fr
├ ├── jquery.i18n
├ ├── jquery.i18n.properties
├──jquery-1.4.min
├──jquery-ui-1.8.2.custom.min
└── WEB-INF
├── spring
│ ├── app
│ │ ├── controllers.xml
│ │ └── servlet-context.xml
├── jsp
│ ├── home.jsp
│
└── web.xml
I have a resources folder where I have a scripts folder where I have my jquery js files. scripts folder also has a i18n folder where I have my i18n js files. i18n folder also has resource bundles folder where I have en and fr messages files.
In web inf I have a jsp folder which has my home jsp file. It has following code
jQuery(document).ready(function() {
loadBundles('en');
});
function loadBundles(lang) {
jQuery.i18n.properties({
name:'resources/scripts/i18n/resourceBundles/Messages',
mode:'both',
language:lang
});
}
Please help.
Try adding mime-type to the web.xml file (Tested in Tomcat 6)
<mime-mapping>
<extension>properties</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
Try by adding the path :-
name:'Messages',
path:'resources/scripts/i18n/resourceBundles/',
mode:'both',
language:'en'
Related
I have project2 that depends on project1. They are both next to each other on my file system.
When I try to build project2 (after successfully building project1) I get the error:
Could not determine the dependencies of task ':app:distTar'.
> Could not resolve all task dependencies for configuration ':app:runtimeClasspath'.
> Could not resolve project :project1.
Required by:
project :app
> No matching configuration of project :project1 was found. The consumer was configured to find a runtime of a library compatible with Java 11, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
- None of the consumable configurations have attributes.
Project2 adds the dependency to project1 as follows...
build.gradle
/*
* This file was generated by the Gradle 'init' task.
*
* This generated file contains a sample Java application project to get you started.
* For more details take a look at the 'Building Java & JVM projects' chapter in the Gradle
* User Manual available at https://docs.gradle.org/7.2/userguide/building_java_projects.html
*/
plugins {
// Apply the application plugin to add support for building a CLI application in Java.
id 'application'
}
repositories {
// Use Maven Central for resolving dependencies.
mavenCentral()
}
dependencies {
// Use JUnit test framework.
testImplementation 'junit:junit:4.13.2'
// This dependency is used by the application.
implementation 'com.google.guava:guava:30.1.1-jre'
implementation project(':project1')
implementation files('../../project1/lib/build/libs/lib.jar')
}
application {
// Define the main class for the application.
mainClass = 'project2.App'
}
Settings.gradle
rootProject.name = 'project2'
include('app')
include ':project1'
project(':project1').projectDir = new File(settingsDir, '../project1')
The source for project1...
/*
* This Java source file was generated by the Gradle 'init' task.
*/
package project1;
public class Library {
public boolean someLibraryMethod() {
return true;
}
}
The source for project2
/*
* This Java source file was generated by the Gradle 'init' task.
*/
package project2;
import project1.*;
public class App {
public String getGreeting() {
return "Hello World!";
}
public static void main(String[] args) {
System.out.println(new App().getGreeting());
bool someBool = Library.someLibraryMethod();
}
}
the complete folder structure of the two projects. Although it looks like project2 is under project1, that is just how the copy pasted output looks, they are indeed sibling folders.
── project1
│ ├── gradle
│ │ └── wrapper
│ │ ├── gradle-wrapper.jar
│ │ └── gradle-wrapper.properties
│ ├── gradlew
│ ├── gradlew.bat
│ ├── lib
│ │ ├── bin
│ │ │ ├── main
│ │ │ │ └── project1
│ │ │ │ └── Library.class
│ │ │ └── test
│ │ │ └── project1
│ │ │ └── LibraryTest.class
│ │ ├── build
│ │ │ ├── libs
│ │ │ │ └── lib.jar
│ │ ├── build.gradle
│ │ └── src
│ │ ├── main
│ │ │ ├── java
│ │ │ │ └── project1
│ │ │ │ └── Library.java
│ │ │ └── resources
│ │ └── test
│ │ ├── java
│ │ │ └── project1
│ │ │ └── LibraryTest.java
│ │ └── resources
│ └── settings.gradle
└── project2
├── app
│ ├── build.gradle
│ └── src
│ ├── main
│ │ ├── java
│ │ │ └── project2
│ │ │ └── App.java
│ │ └── resources
│ └── test
│ ├── java
│ │ └── project2
│ │ └── AppTest.java
│ └── resources
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── settings.gradle
69 directories, 37 files
Types of Builds
First you have to decide if this should be a multi-project build or a composite build.
Multi-Project Build
This is when you have a single Gradle project that is made up of multiple sub-projects. You should use a multi-project build if the various modules are highly coupled.
You create a sub-project by using include in the settings.gradle[.kts] file. But you should only have the one settings file. Each individual sub-project may have its own build.gradle[.kts] file, and typically does, but does not necessarily have to. There are various ways to cross-configure sub-projects. See the documentation linked above for details.
I do not provide an example of a multi-project build in this answer.
Composite Build
This is when you have two (or more?) relatively independent projects, but one depends on the other like any other external dependency. Yet you want to use the artifacts of the Gradle project directly rather than grab the binaries from a repository. At least some of the time, anyway.
There are a few ways to create a composite build.
Use --include-build on the command line. This requires the least amount of modification to either project (none).
Use includeBuild in the settings.gradle[.kts] file (not include, as that's for multi-project builds). This requires modifying at least one of the project's configurations, which may not be desirable.
Create a "parent" Gradle project for the "real" projects with a settings.gradle[.kts] file. Then add includeBuild for the "real" projects that you want to composite.
In a composite build, the way dependencies are resolved is described in the documentation linked above. Here's an excerpt:
Included builds interact with other builds via dependency substitution. If any build in the composite has a dependency that can be satisfied by the included build, then that dependency will be replaced by a project dependency on the included build. Because of the reliance on dependency substitution, composite builds may force configurations to be resolved earlier, when composing the task execution graph. This can have a negative impact on overall build performance, because these configurations are not resolved in parallel.
Note you don't use project("...") to define a dependency on an included build. You simply use the regular Maven coordinates like normal, and if the included build has a project matching those coordinates, then it will be substituted in.
Example Composite Build
This example uses --include-build to create a composite build. Although this example can be reproduced by following the instructions below, it can be a little error-prone and tedious, so here is a GitLab repository of the final example. I make no promise to keep the repository alive.
Source Code
Here is how the two projects were generated and any changes I made to the build configurations and or the code. Note I used Gradle 7.6 when running the init task. Also, when prompted with:
Generate build using new APIs and behavior (some features may change in the next minor release)? (default: no) [yes, no]
I answered, "no".
Project 1
This project is the "library". It was generated with the following command:
...\demo\project1> gradle init --type java-library --test-framework junit-jupiter --project-name project1 --package sample.project1 --dsl kotlin
I only made modifications to the following files:
lib\build.gradle.kts
I added:
group = "sample.project1"
version = "1.0"
lib\src\main\java\sample\project1\Library.java
Changed it to:
/*
* This Java source file was generated by the Gradle 'init' task.
*/
package sample.project1;
public class Library {
public static void printMessage() {
System.out.println("Hello, this is a composite build!");
}
}
lib\src\test\java\sample\project1\LibraryTest.java
I deleted this file.
Project 2
This project is the "application". It depends on project 1. It was generated with the following command:
...\demo\project2> gradle init --type java-application --test-framework junit-jupiter --project-name project2 --package sample.project2 --dsl kotlin
I only made modifications to the following files:
app\build.gradle.kts
I added:
group = "sample.project2"
version = "1.0"
And added the following to the dependencies block:
// ADD DEPENDENCY ON PROJECT 1
implementation("sample.project1:lib:1.0")
app\src\main\java\sample\project2\App.java
I changed it to:
/*
* This Java source file was generated by the Gradle 'init' task.
*/
package sample.project2;
import sample.project1.Library;
public class App {
public static void main(String[] args) {
Library.printMessage();
}
}
app\src\test\java\sample\project2\AppTest.java
I deleted this file.
Directory Structure
Here is the directory structure of the two projects after generating them and making the above modifications. The output excludes the .gradle directory.
...\DEMO
├───project1
│ │ .gitattributes
│ │ .gitignore
│ │ gradlew
│ │ gradlew.bat
│ │ settings.gradle.kts
│ │
│ ├───gradle
│ │ └───wrapper
│ │ gradle-wrapper.jar
│ │ gradle-wrapper.properties
│ │
│ └───lib
│ │ build.gradle.kts
│ │
│ └───src
│ ├───main
│ │ ├───java
│ │ │ └───sample
│ │ │ └───project1
│ │ │ Library.java
│ │ │
│ │ └───resources
│ └───test
│ ├───java
│ └───resources
└───project2
│ .gitattributes
│ .gitignore
│ gradlew
│ gradlew.bat
│ settings.gradle.kts
│
├───app
│ │ build.gradle.kts
│ │
│ └───src
│ ├───main
│ │ ├───java
│ │ │ └───sample
│ │ │ └───project2
│ │ │ App.java
│ │ │
│ │ └───resources
│ └───test
│ ├───java
│ └───resources
└───gradle
└───wrapper
gradle-wrapper.jar
gradle-wrapper.properties
Running Example
Running the example with the following command:
...\demo\project2> .\gradlew app:run --include-build ..\project1 --console plain
Note: I used --console plain in order to see all the task output. That way you can see tasks from the included build were executed. You do not need to include this option if you don't want to.
Gave the following output:
> Task :app:processResources NO-SOURCE
> Task :project1:lib:compileJava
> Task :project1:lib:processResources NO-SOURCE
> Task :project1:lib:classes
> Task :project1:lib:jar
> Task :app:compileJava
> Task :app:classes
> Task :app:run
Hello, this is a composite build!
BUILD SUCCESSFUL in 1s
4 actionable tasks: 4 executed
Make directories project1 and project2 both modules, one application and one library module.
Files gradle, gradlew, gradlew.bat, settings.gradle need to be moved one level up. The root project needs it's own build.gradle. Including
the modules in settings.gradle is straightforward:
include ':project1'
include ':project2'
Then one can depend on module :project2 in module :project1:
dependencies {
testImplementation project(':project2')
api project(':project2')
}
The library could also be published to the default local repository mavenLocal(). Unless publishing a sources package to Maven (eg. lib-sources.jar), it's usually easier to debug with two modules. The library module still can be made a Git sub-module.
I've written a short documentation for my Java program. When clicking on the menu Help -> Documentation the default PDF reader of the OS should open the documentation.pdf.
I'm trying to open the PDF which is located in the directory src/doc with Desktop.getDesktop().open(new File("doc/documentation.pdf")); in Controller.java.
However, Java does not find the file. When I open the icon for the program with primaryStage.getIcons().add(new Image("icon/icon_512x512.png")); it works perfectly in Main.java.
Here you can see layout of my IntelliJ project.
src
├── META-INF
├── de
│ └── myapp
│ ├── model
│ │ └── *.java
│ ├── view
│ │ └── *.java
│ ├── Main.java
│ └── Controller.java
├── doc
│ └── documentation.pdf
└── icon
└── icon_512x512.png
My stack
IntelliJ 2016.2
Java 1.8.0_77
It works with new Image("icon/icon_512x512.png") because internally it gets is from the context ClassLoader which is not the case of new File("doc/documentation.pdf") that gets it from the user working directory in case of a relative path, so you could simply apply the same logic.
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
URL resource = contextClassLoader.getResource("doc/documentation.pdf");
Desktop.getDesktop().open(new File(resource.toURI()));
3-rd party applications can not access src dir in your application, in case, when your app assemble in jar archive. You should place your file separately from src.
Of course, java find icons, because it's java API.
You can access any resources in src folder through follow methods:
URL url = getClass().getResource("/path/in/src");
InputStream is = getClass().getResourceAsStream("/path/in/src");
If your app is NOT assemble in JAR - try provide full path to file like this:
URL url = getClass().getResource("/path/in/src");
File file = new File(url.toURI());
The files from Classpath can be loaded by using ClassLoader's getResourceAsStream Method.
So you can try with generating an Input stream object
InputStream is = Controller.class.getClassLoader().getResourceAsStream("doc/documentation.pdf");
And After generating Input Stream you can read it by Java Program.
I'm using google identity toolkit to make a library. When I give this library to others, their app crashes at startup complaining that NoClassDefFoundError on GitkitClientException.
To me this is strange because:
The GitkitClientException.class is in the final jar (in fact this happens to Spring Boot application we well)
I checked every method, none of my public method throws a GitkitClientException. My understanding is, if the Exception is handled internally and not thrown. The library user should not need the dependency.
EDIT:
I know when the library user add gitkitclient as their dependency as well they will not have this crash. But I really want this to be transparent.
The final fat jar looks like this: (this is a dropwizard app)
├── ch
│
├── com
│ ├── google
│ │ ├── common
│ │ ├── identitytoolkit
│ │
│ └── fasterxml
├── META_INF
├── net
│ └── models.go
├── org
└── about.html
└── jetty-dir.css
I just spent a little while learning the hard way that Gradle can't make a working jar file if the directory (and thus jar file) is labeled something LIKE_THIS.
Does anyone know why this is? I'm just picking up Java and would like to know why. I've heard it's bad practice to label packages with capital letters as well.
EDIT:
If the directory is all caps, I'd get Error: Could not find or load main class src.main.java.HelloWorld but it would work perfectly fine if it's lableded something like_this.
EDIT:
My directory structure after fixing the label was just from a tutorial, but here it is:
alexanders-mbp:VALID_JAVA alexanderkleinhans$ tree
.
├── build
│ ├── classes
│ │ └── main
│ │ └── net
│ │ └── petrikainulainen
│ │ └── gradle
│ │ └── HelloWorld.class
│ ├── dependency-cache
│ ├── libs
│ │ └── VALID_JAVA.jar
│ └── tmp
│ ├── compileJava
│ └── jar
│ └── MANIFEST.MF
├── build.gradle
└── src
└── main
└── java
└── net
└── petrikainulainen
└── gradle
└── HelloWorld.java
Changing the directory to something_else and re-building makes everything work. BTW, no build errors.
EDIT:
I was following this and couldn't get it to work so I finally cloned the git-repo where I discovered my issue.
To run, I would do
gradle assemble
gradle build
java -jar build/library/VALID_JAVA.jar
(VALID_JAVA being the directory name and thus jar file name.)
It looks like you try to launch src.main.java.HelloWorld, but if you look at the sources from the GIT repository the fully qualified class name is net.petrikainulainen.gradle.HelloWorld (which also matches your directory structure).
To launch the application, use
java -classpath build/libs/VALID_JAVA.jar net.petrikainulainen.gradle.HelloWorld
Note also, according to the decription at the GIT repository, the gradle build creates a runnable jar file which you can launch like
java -jar pathToJarFile
I'm a little bit new with Java, so I apologize in advance. In a Google API Quickstart, a .credentials file is loaded from the method getResourceAsStream and the path as "/client_secret.json". From here, I learned that this getResourceAsStream get's the file from the CLASS path, which confuses me because my src directory structure looks like the following.
.
└── main
├── java
│ └── GmailQuickstart.java
└── resources
└── client_secret.json
When I open a new project (using a servlet) and try to load this, I'm finding this InputStream is null. The src directory of the following project looks like so:
.
└── main
├── java
│ ├── GmailQuickstart.java
│ ├── com
│ │ └── something
│ │ └── HelloWorldServlet.java
│ └── somepackage
│ └── Thing.java
├── resources
│ └── client_sercret.json
└── webapp
└── WEB-INF
└── web.xml
I've tried changing it to what I though would be the same CLASSPATH, but I guess that's not correct. From the previous advice, I've also tried "/main/java/resources/client_secret.json". Obviously I'm not doing something right here.
Could someone help point me in the right direction?
Try to add resources folder to your classpath.
If you are using eclipse, right click your project, configure build path, add your resources folder in Source tab.