This is more of a pattern question. I am using maven to create a three module project.
Domain, Services, Site
The services module depends on the domain module. Now in the services module I am using an ORM (MyIbatis) and I need to have lots of XML files in my services module. I could place the XML files in the package that contains the .java files, or I can place the XML files under the resources directory.
My question is, what is the best pattern for when you have resources that are mapped to a single .java in the same module. Would you place that resource in the package that contains the .java or in the "resources" directory that maven uses? What are the pros and cons?
I know at the end of the day the resources and java directories get merged into the artifact (.jar), but on principal I would like to know what others do.
Update -- The reason I would like to place the XMLs in the java src directory is because I dont want to recreate the package structure under the resources directory -- to help with the maintainability of package structure changes, etc.
I would put them alongside my Java files personally. You're going to be bouncing back and forth between the object and the XML a lot, in all likelihood. It's annoying to be constantly switching between the two folders.
I put the stuff I don't go to as much while coding, such as property files or log4j.xml, in the resources folder.
But that's just me.
Related
I created a new simple maven project. I was following the project structure found here, however, it doesn't state where to place .js, .sql, .html, .css, .jsp files. Where do I place static client side files such as these in my maven project?
Here is the project structure that I have now:
EDIT:
Also, this question is different from the one posted as a duplicated since my question involves general static files whereas the other question involves specific files like javascript. Please reopen.
If you are using WAR packaging, in webapp. If you are using JAR packaging, in resources.
EDIT: the .sql files should go always in resources
I have two eclipse projects.
One of them is a library that contains property files.
Second one is a Dynamic Web Project.
In my library there are few configurable classes, that load their configuration parameters from property files.
String path = "Resources/Properties/Main.properties";
InputStream stream = getClass().getClassLoader().getResourceAsStream(path);
Properties properties = new Properties();
properties.load(stream);
My dilemma is that when I export my Web project into WAR, dependent library project gets packed into a jar and placed inside my WAR into "WEB-INF/lib" directory, which means that I can't load them as I would usually do.
My ideas are:
Copy those property files into my Web Projects, which is very
painful, because this library is meant to be used in many projects,
I do not want to have multiple instances of property files scattered
around projects.
Place property files into some system fixed path on the server, still is a bad desigion, makes it harder to deploy this application.
Is there a way to load property files from JAR files, or maybe a way to tell eclipse project to export property files from my library into my Web Project explicitly?
I would appreciate your help and ideas on this matter.
It works just fine if you load the resource file from classpath.
It goes trough classpath and searches for matching resource.
My problem was classpath resource collision, I had classes with similar package.classname and resources with similar path and filename.
When loading these resources, JVM silently ignores duplicated entities from .jar libraries.
So stay sharp and beware of non-unique entities when composing a complex library structure.
I need to access some resources (for a contextual help system) which may be located either in a directory tree (somewhere in the filesystem) or contained into a specific .jar.
Resources in the filesystem should take precedence over "packed" ones.
I should provide a runtime (not a compile-time action) command to migrate all resources from filesytem directory tree to the .jar package.
I want to build a separate .jar to contain just those resources. I don't want/need to modify code. I need to deliver a product with minimal help and allow the costomer to refine it and update need to recompile. Customer will then distribute the "improved" version.
What is the best way to implement this?
I'm interested specifically in the "migration" part, since I should be able to code the resource access part, but comments are always welcome.
There are various ways this can be implemented but re-using Java's ability to read resources from a directory on the classpath looks the easiest to me.
Deliver the application with a zip-file containing the updatable help-resources. At application start, extract this zip-file to apphome/help-resources but do not overwrite newer/modified files. Use the technique in this answer to add the apphome/help-resources directory to the class-path. From then on resources can be loaded as if they are in a jar-file on the classpath (no special code needed).
The customer can update the files in apphome/help-resources and using a runtime-command the zip-file can be updated/recreated with the files in the apphome/help-resources directory. Or if the customer has 7-zip or something similar, just create the zip-file using the zip-tool.
I am wondering why some resources files are put under the META-INF directory in the JAR? I am always put the resources like test.properties under the root diretcory. Any advantage to put them in the META-INF?
Lot of Java (EE) APIs have a contract that when you put a specific configuration/metadata file in the META-INF folder of your (or a 3rd party) JAR, then the API will automatically do the API-specific job, such as scanning classes, preloading specific classes and/or executing specific code based on the meta information.
An example provided by the standard Java SE API is the ServiceLoader. Among others, the JDBC 4.0 compatible drivers implement this. This way just dropping the JDBC driver JAR file folder will automatically load the driver class during Java application's startup/initialization without the need for any manual Class.forName("com.example.Driver") line in your code.
Further there is also the Java EE 6 provided JSF 2.0 API which scans during application's startup all JAR files for a faces-config.xml file in the META-INF folder. If present, it then will then take it as a hint to scan the entire JAR file for classes implementing the JSF specific annotations like #ManagedBean so that they get auto-instantiated and auto-configured. This saves time in potentially expensive job of scanning thousands of classes in all JARs in the entire classpath. In older versions of those API's the configuration was usually done by (verbose) XML files.
All with all, the major goal is to save the developer from code and/or configuration boilerplate. The JAR's META-INF folder is used for configuration files/hints. Some API's indeed also put static files/resources in there for own use. The META-INF folder is also part of the classpath, so the loading of those files by the classloader is easy done.
In servlet 3.0, certain static resources are available through the web context, such as .css, java script, and .png files, so you no longer need to use ServletContext getResource() and getResourceAsStream(). For more information, check out web-fragment.xml (https://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment) which is one resource that covers this subject.
Personally, I prefer to structure my projects the way Maven likes them, with a src/main/resources directory which is part of the application's classpath.
It's just a convention that some (most?) third party jars use to look for files that you provide. For your own classes and files, you can choose to put them where you like.
I have just imported a WAR file from an external site, which is basically a servlet into Eclipse IDE (the project runs on Apache-Tomcat).
When I import it it has a folder called Web App Libraries. So here are a few of my newbie questions:
I am unsure about what the exact purpose is of this folder is? What does it do, why would you choose to have it in your project?
I see that it has a folder called Improted Classes and foobar.class files inside it - why?
(These seemed to be mirrored in Web Content folder - although here you can modify the code as they are foobar.java.)
There are references to foobar.jar files too - these are also mirrored in WEB-INF/lib folder too - why?
I know these are basic type questions but I'm just getting to grips with Java and website dev, so apologies if they sound a bit dumb! - BTW if anyone knows any good online resource to understand more about project file structures like this, then let me know. I just need to get to grips with this stuff asap - as the project deadline is fairly soon.
Cheers.
Here's a screenshot just to help you visualise:
I assume this is a screenshot from the 'Project Explorer' view. It does not display exact folders and files structure, is adds a few candy constructed from project's metadata.
To see real structure of your project, try switching to the 'Navigator' view.
During a WAR file import, Eclipse basically does two things:
Creates a new web project and copies WAR's content to 'WebContent' subfolder of the new project.
Based on the WAR, it constructs project's metadata (.project and .classpath files).
The 'Web App Libraries' section displays list of jar files that the WAR contained (in WEB-INF/lib
'Imported classes' (which I also see for a first time) seem to contain classes found in the imported WAR (WEB-INF/classes), for which Eclipse was not able to find any corresponding source files. To fix this, create a new Java source folder in the project and move the classes you now have in 'firstResource' folder to it.
Web App Libraries isn't a real directory, but rather a listing of what Eclipse thinks are this project's libraries.
Generally, this consists of all the jar files in WebContent/WEB-INF/lib/
Sometimes, Eclipse no longer lists them in their real directory in Eclipse's Package Explorer... but they're still there if you look with another program.
In Eclipse, if you are using the Java Web Development view, you'll have configured:
A Tomcat Server runtime that provides the servlet libraries
A Java Runtime
Other required libraries
The Web App Libraries that are in the project duplicate the first setting, so that you don't need a local Tomcat installed on the development box.
The rest sounds messy to me.
You have your src / JavaSource folder with the raw Java files in it. They shouldn't be in Web Content - that's for your HTML, images, JSPs, etc.
So a typical project setup:
Project Name/
JavaSource/ or src/ // holds all the Java Source Files, Servlets, Struts Actions
WebContent/ // Nice root folder to hold web content files
content files and folders
WEB-INF/ // Web App Config folder
lib/ // Libraries (but not tomcat ones)
web.xml
classes/ // Where your compiled Java goes, and configs (log4j.properties)
Some people put the JSP inside WEB-INF too, as it isn't required to be accessible in the JSP file state, only in the compiled state that Tomcat does itself.
Its simple, eclipse provides multiple view to your project structure. The view you are looking at is definitely the Package Explorer view. In that view, everything that has a special icon in front is a helper item which is there to help you out by simplifying access to certain stuff like external libraries (which are provided by software on your computer or eclipse itself or other project).
In eclipse, go to menu->window->show view->navigator
The Navigator view will tell you the real folder structure of your project.