This is the structure for my Gradle project:
- Game [parent]
|- Server [module]
-- Cache
|- Client [module]
The problem occurs when I try to access the cache from my server java project using:
new File("/cache/cacheItem.dat");
Java will now look in the parent folder (Game) for the cache instead of the server folder and I don't know how to change the root for the server project using Gradle. I would like to know how to change the root directory of the server to it's own folder instead of the parent.
You should not rely on your project structure for accessing and especially writing files. If you package your application for deployment into JARs, any of these paths will no longer be available to write data to and may change even during development, as you have noticed. Instead, you should make your cache path configurable, e.g. from a configuration file and/or command line parameter. This allows the cache path to be configured to an external location upon deployment and to some temporary path during development.
If you only need read access to files at a known location place them under src/main/resources (or src/test/resources for tests). Gradle by convention packages the content of this directory together with your code and everything therein will be available at runtime at root level, during development as well as after deployment. To access such resources on the classpath in Java use getClass().getResource("path/to/resource").
Related
I am trying to learn about the Spring framework for Java and I am not sure where about's I am supposed to put the applicationContext.xml file for configuring the spring beans. My directory structure is as follows:
Do I put in .settings? Or should it be put at the top level within springapp?
Thanks for the help.
Put into directory WebContent/WEB-INF.
Resources placed into WEB-INF folder are not accessible from web, they are application internal resources. This is good, because your applicationContext.xml shouldn't be accessible from web.
Other good options are WebContent/WEB-INF/classes or just src (both are equal).
Files and folders with . contains Eclipse configuration files, they are internal for Eclipse - do not use them.
I recommend to put it in the src (or src/META-INF) folder and access it via classpath:applicationContext.xml (or classpath:META-INF/applicationContext.xml). (Eclipse will copy this file to WebContent/WEB-INF/classes when it build the war archive.)
Because:
The mayor advantage of src over src/main/webapp/WEB-INF / WebContent-WEB-INF is, that you can access the src files even in the tests (via classpath:applicationContext.xml)
Do NOT put it .settings because the content of this directory gets not deployed in the Web App (it is eclipse configuration folder)
Of course when you use maven, then put the file in src\main\resources (or src\main\resources\META-INF), Maven will copy them to the classpath folder while compiling.
WEB-INF or its subdirectories. This folder's content is packed directly into the root war file, so files that are directly under this folder are accessible as resources with path like '/foo.xml' (or in spring notation classpath:/foo.xml
It needs to be in the classpath. You can put the original editable instance anywhere (e.g. a config directory off the root) but then you will need to have your build management tool (e.g. Ant or Maven) copy it into the classpath for the runtime.
I have a Java console application, till now it was developed in Netbeans IDE. When Netbeans builds application, it creates dist directory and builds an app into this directory as a jar archive and into dist/lib copies all dependencies. This this directory could be copied into final destination and run.
Now I'm trying to transfer this project into Maven. Everything goes ok, I can compile and package my app and a jar is created into target directory. I use maven-jar-plugin to set main class in manifest and maven-shade-plugin to package all sources into one jar file.
I would like to ask you how is such Maven project deployed in the real world? Should I use all target directory, copy it ad the final destination and run as I have been used to do with Netbeans? What are consequences when I don't use maven-shade-plugin - where are all libraries defined as dependencies located? I am asking, because in my testing project these libraries don't exist in target directory.
My question - I have a Java console application "A" packaged via Maven (without maven-shade-plugin) and Linux server "S" where this application should run. Can I copy all target directory manually to server "S" or is there some better / more automatic way how is this solved in the real world?
Simply copying over the target directory will not solve your problem. I have packaged many standalone applications using Maven and I have used Maven Assembly Plugin for it. You can create a distribution archive (zip, tar.gz) using the assembly plugin which your customer can unzip and start running.
It depends on you, how you want your target application directory structure (release). I usually end up with something like
bin/
conf/
lib/
log/
The bin directory contains a shell / batch script to run your program by calling your main class, setting appropriate classpath, providing relevant memory settings etc. I prefer using classworlds (which is used by Maven) to bootstrap my application and simplify writing of start scripts.
conf directory contains configuration files for your application as well as logging configuration files like log4j etc. This directory I add on classpath to make it easier to access configuration resources at runtime.
lib directory contains all the dependency jars a well as jar file for your code.
log is where your logging configuration will point to output log files.
Note that this structure is good for standalone server like applications. Also having a bin directory and run scripts allows you to add this directory to PATH on Windows / Linux to ensure you can run the application from anywhere.
If you are packaging a command line utility, simple shaded jar may work for you. Personally, I am not the biggest fan of java -jar application.jar
The question is too broad to be answered comprehensively, but I would like to provide an example of real-world maven deployment.
There are maven plugins for all major application servers. They have defined targets for local and remote deployment. One such plugin is the jboss-as-maven plugin. You can define the deployment properties (IP, port etc.) in your .pom or directly from command line, e.g.
mvn jboss-as:deploy -Dpassword=mypassword
There is also the cargo plugin that specializes in application deployment.
I have a custom web application project, where project and webapp are Eclipse projects. Assume a structure like the following
/project
/webapp
/_src
/com.webapp.servlets
/com.webapp.domain
/com.webapp.services
Now I want to create java command line based tool to simulate the operations of a servlet. It's going to require classes from my domain package. I also need to split this command line application from the web application project. I would also need to extract those shared classes into another project as well.
I would like to have this type of structure
/project
/webapp
/_src
/com.webapp.servlets
/com.webapp.services
/commandline
/_src
/com.commandline.simulation
/shared
/_src
/com.webapp.domain
How can I achieve this nested project structure with shared resources in Eclipse (Indigo)?
This was pretty simple. Create a new folder in your root project project. Then Create a Java Project but don't use default location, use the new folder you created. This will create a new entry in your project explorer, but on the file system you will have nested projects.
In projects that require resources from other projects just configure the build path by adding the projects you need,
I am working on a fairly big project that uses maven for dependency management. As part of this we are using Maven profiles to build and replace certain properties files that differ between test/dev/production environments.
To perform a build I would execute a Maven:build using the correct profile and mavens reactor would then build the projects in the correct order and store the jars in the .m2 folder, eg the domain jar first, then the service jar (with the domain jar included in its jar as a dependency) etc. This leads to a war file eventually with all the correct libs required by the war to run.
When eclipse performs its default build that it performs everytime you save a file the jars are not built with any profile, just a regular build.
When I then push the final war file to the server and it is exploded when the server starts up (started and deployed through eclipse) I get in the lib folder all the jars that maven had packaged into the war file but also all the jars that eclipse had built.
eg
lib/
domain.jar (built by eclipse)
domain.SNAPSHOT.1.0.jar (built by maven)
etc
Is there any way to prevent this from happening? This has the end consequence of there being two of every property file and only the order in which they are loaded determines which is used. A real hassle as different properties are used in different environments.
I found a slightly hacky solution to this problem.
In the web projects properties -> Deployment Assembly I modified the path for the offending jar files eg domain.jar from
WEB-INF/lib/domain.jar
to
WEB-INF/autogen/domain.jar
This leads to the eclipse generated jar files (with the wrong properties files) to be deployed to a folder that won't be loaded when tomcat starts. Not a perfect solution but it allows all the nice things of eclipse auto-building like code completion and error messages in the web project if the interface of the domain changes etc while also providing the correct profile when deployed.
Leaving this here for anyone else in this situation.
For example suppose I'm using the standard project structure and have
src/main/config/config.xml
To access this I presume
new File("src/main/config/config.xml");
would be incorrect
There is no "Maven Idiom" for accessing configuration files. Maven is a build platform, not an execution platform. So the conventions for accessing configuration files that apply are really just the conventions of the Java platform that you are using; e.g.
the plain J2SE way of doing it, or
the J2EE and/or webapp way of doing it, or
the J2ME way of doing it, or
...
Maven only comes into the picture because you (presumably) have resource files in your project / version control that need to be included in the JAR or WAR or whatever artifacts that you are building. To get this to work in Maven, you simply need to understand how Maven copies non-Java files into the artifacts.
In the simple (JAR) case, the default behavior is to copy anything in src/main/resources/ into the JAR, with the same relative name; e.g. src/main/resource/foo/bar.xml becomes /foo/bar.xml in the JAR file.
For WAR files, the default is to copy anything src/main/webapp to into the WAR file. So if you wanted a file to be accessible in the webapp as a classpath resource with the name /foo/bar.xml you would put it in src/main/webapp/WEB-INF/classes/foo/bar.xml. (I'm assuming that you know how webapp classpaths work ... or that this isn't your use-case.)
A config file is just a resource on your classpath like any other, so use:
URL resource = getClass().getResource("config.xml");
You'll need to do the usual Use as Source Folder on your src/main/config folder for this to work in Eclipse with m2e.
I think config files should be in src/main/resources by default.