I have a maven project, that has resources files under dir src/main/resources. I noticed that in Eclipse, when I run the project, the source files are copied to target/classes without the resources directory, just the files under resources dir.
But after I exported the project to a runnable jar by using Right clieck on the project -> Jar -> Runnable Jar , these resource files are under resource directory:
As you see, the resource files are in diffrenent locations in two cases.
and below code works well in Eclipse, but not worked in runnable jars
getClassLoader().getResourceAsStream("database.properties")
How to solve this problem? I want the above code can work in both cases.
Answer is simple - do NOT trust Eclipse or any IDE for similar cases. Matters only separate build that will be running on the separate environment. The same also applies to the testing using embedded in IDE application or web servers - it's a source of a huge number of potential issues
Unfortunately, this is two different build processes, and most projects will use a single build system. It is a lot of effort for not a lot of benefit. You can initiate mvn package from eclipse as well. I would recommend maven since it is a standard. If you must do it, here are some ideas
In your startup process, test to see if /resources exists and prefix all paths with it
If its a single file, you can test and fall back on the second path
Tweak your pom.xml to put your resource folder at /resource
Related
I am writing a Bukkit plugin in Eclipse in which I separate different functions into different packages and export each package as its own jar file.
However, I would still like to keep these packages in the same project, rather than separating them into different Eclipse projects. These plugins each have files which must be in the root of the jar file, such as plugin.yml. I have moved each jar's files into their respective packages, but these files are put into plugin.jar\com\Preston159\plugin rather than in the root of the jar file (plugin.jar\), causing the plugin not to work.
Does Eclipse have any function to make these files automatically compress into the root of the jar file even though they are contained within the package in the source, or, is this something that I could solve by using Maven? My current solution to this problem is to move the files manually after exporting the jar, but this is becoming increasingly annoying.
EDIT:
The project builder XML I ended up using to complete this task can be found here
You would need to use a Build Tool. There are several supported by Eclipse. Ant and Maven are now built-in, but there are several build tools that run directly within Eclipse, but Eclipse can also be configured to run an external build tool as well.
Do a quick search on build.xml for examples of ANT build jobs.
Unless you're specifically required to use MAVEN for continuous integration, etc. then what you want to accomplish would be easily done with ANT.
I made a simple standard-lone java Application using Spring,Apache Camel,Activemq for processing messages.
Note: My Application don't have any GUI.
My project structure is in the following way.
SACLib folder have nearly 70 external jars(all Spring,Camel and Activemq corresponding jars).
It's working fine in Eclipse. SO Now We want to deploy into Jar file.I tried in Eclipse,But I didn't seen Rod1,Rod2,Copy1 and SACLib folders in my Jarfile.
after Deploying Jar, If I run FirstConsumer.java it runs Rod1-->ThMapInfratab1-2.exe file. For this I mention Real paths of .exe file.
How can I make Jar file with including all my folders.
Thanks
Well, this is a kind of work that is typically done with build automation tools like Apache Ant, Maven or Gradle, so you can investigate there if you want to make this happen automatically next time.
But, if you want to do it manually...
First, you project needs a META-INF folder where you will place a file called a MANIFEST.
That manifest contains a Main-Class entry pointing to you main class. You can read about this in the Java Tutorial: Setting Application's Entry Point.
But it can also contain a Class-Path entry, pointing to all other jars required by your application and that should be loaded by the executable jar.
You can read about it the Java Tutorial: Adding Classes to your Jar Class Path.
If you are building your executable jar with Eclipse, it will let you choose the MANIFEST file that you want to use during the creation process.
Now, if you want to use build automation tools, there are other answers here that explain how to do it:
Creating a bundle jar with ant
How to create executable jar with dependencies with Maven
How to export an executable jar in Gradle
simply using ant download it , and then make a build.xml file and put it
Here's an simple example of an ant target that will create a jar (named test.jar) that includes all jar files under the lib directory. Maybe this will solve your problem?
for using apache ant, see this
http://ant.apache.org/manual/using.html
I have a Java console application that I am ready to deploy onto a Unix server. I am writing a shell script to run the application.
I plan to put my shell scripts in one folder, my application jar and dependent jars (spring, etc.) into a different folder and properties files (those that need to be maintained 'live') in a separate folder again. I would then have my shell script iterate through the files in the 'jars' and 'properties' folders, appending them to the classpath, before finally calling java ...
Is this a 'good' deployment structure? Are there any guidelines for how to arrange files to maximise maintainability and stability? Are there obvious 'wrong' ways to do this that are best avoided?
I should add that, for a previous project, I put all shell scripts (those that start java processes and those that don't) into a scripts folder, my application jar into a folder with the library jars in a library subfolder and external resources into a config subfolder. I then wrote a script that explicitly loads all the files. It was long winded to write and needs to be maintained whenever I upgrade a library jar. This time around I'd like to do it better. Also, it feels unnecessary to separate my application JAR from the libraries.
For what it's worth, this is what we use;
/
/class
//package hierarchy here, raw .class files
/lib
//library jars here, apache commons, gson etc, all .jars
/conf
//.properties files go here, including ones for libraries
/doc
//program documentation files, typically .txt
/javadocs
//java doc html root
/sh
//shell scripts including execute.sh and compile.sh
We use ant for building, often have a src folder for the source tree if necessary. This way you just add /class and /lib to your classpath, and that never changes.
Good structure for your case is so called uberJar or oneJar, that can be made with number of utils, just google it. Also I can recommend such a nice piece of code as http://www.jdotsoft.com/JarClassLoader.php
Frankly, if it is just a small app, I would put it all under /opt/<my_java_app> and have a directory substructure there just like you did in dev.
If you want to be more compliant with the UNIX recommended practices, then put your executable (including your jar) in /usr/local/bin/<my_java_app>, config files in /etc/<my_java_app>, log files and other data files in /var/<my_java_app>.
Also, you may want to refer to this document.
Build a system-native package, and use system defaults. If using Debian, create a .deb direct from your build system (for instance, using ant deb task). If using rpms, use the rpm task. That way you can easily deploy, undeploy and update the application just like any other one.
The system package should separate libraries (I use /usr/share/java/AppName for my jars) and configuration (to /etc/AppName or /home/UserName/.AppName); the launch-scripts I symlink to /usr/bin. Beyond that, there is no great complication getting things to work. I recommend finding well-known java-based packages in your distribution and copying their launch scripts (in particular, their VM-locating magic).
So I'm fairly new to Java and especially Eclipse, so please excuse my ignorance. I took a project from a server and copied it locally to my machine. When I opened the workspace, I had many errors due to it not being able to find the jars. This makes sense because I don't have the same dir structure as the server I copied from. So if I copy the same external jar's to my machine and get it to compile into a jar and copy it back to the server, will it work? Or will it fail because now the external jar's are in a different place than it is expecting?
Also, down the road should I put the external jars into regular jars to avoid this problem?
You should be OK. Java is using what is called classpath to locate dependencies. The classpath may be different on the development machines, but as long as all the dependencies are on the classpath in the production everything should work.
To avoid issues with the synchronisation of directory structures the most common way is to use Maven - it will manage all the dependencies for you (but you have to manage the pom.xml - the Maven's project descriptor). A little clumsier way is to have the dependencies in the project, however you may end up with many projects having to include same jars, and then there will be version conflicts and so on.
For small projects you can manage dependencies yourself, however larger projects will need a more thought through strategy (like Maven).
In regard to the executable jars, make sure the Class-Path entry in <jarfile>:\META-INF\MANIFEST.MF is correct, e.g. where it references other jars, those jars are going to be there in the production. For example, assume we have ourjar.jar and assume this is a snippet from its MANIFEST.MF:
Class-Path: lib/myteamjar.jar
It will then be expected that a following directory structure is in place:
lib/myteamjar.jar
ourjar.jar
No, the location of the external jars does not mater. What you want to do is put the external jars on your classpath. How you do it depends on how you are running your java code. If you are running it from the CLI using the java command, it takes the classpath as an argument. If you want your code to build/run in Eclipse, you need to right click on your project, select "Build Path" > "Configure Build Path..." Use the "Add JARs..." button to add jars that are part of a project you have open and "Add External JARs..." to add jars that reside outside of the project. See specific documentation for your tool for more details about classpaths.
I would not recommend Maven to somebody who is fairly new to Java and Eclipse. I would forget about Eclipse, too.
You have a packaging and CLASSPATH issue. Focus on that.
What kind of project are you talking about? The answer you get will depend on what type of app you're creating. Is it an executable JAR? Then the right way to do it is to package everything into a ZIP file that's laid out exactly as the CLASSPATH in the JAR manifest expects.
If it's a web app, the right thing is a WAR file, with all the JARs your app needs in the WEB-INF/lib directory.
If you package things properly, you should end up with a single package that has everything laid out the right way. You should be able to deploy it to the server and make it all work.
Specifically, I am using JDBC libraries to work with databases in my Java program. When I perform "Export Runnable Jar" in Eclipse, it includes the referenced libraries but I am never given an option to include my assets folder (containing the databases) in the runnable jar file. If I try to export a regular jar file via Eclipse, I can add the assets folder, but the referenced libraries are not included.
What should I do here?
Thanks a lot.
Try using Ant scripts or maven script to do this.
Where you can import all the referenced jar and files to your desired location.
Personally i liked ant script, since it was easier and you will surely get lot of results for the same if you google.
Are your asset directories declared as Source Folders in Eclipse?
Right Click on the folder, choose Build Path->Use as Source Folder. Then retry the export.
In the longer term, you should really be looking at a build tool such as maven or ant, they are much more flexible, and they are less dependent on Eclipse, so changes in your project configuration in Eclipse won't affect the final build so much.
It's been some time since I last generated a JAR file with Eclipse, and back in the day I remember the Fat-Jar Eclipse Plug-in to be quite useful.