I am generating my jar file with Intellij Idea, and it works. However, I extracted the jar to see why it was mysteriously bigger in size then expected. I found the resources directory, containing all my images, as expected, but... for some reason, outside the resources directory, in the 'main' folder when you first open the extracted jar, are all the images again.. duplicated. This does not reflect my project structure or anything, the only place I have images are in resources. Anyone know what's going on, and how to stop this?
Project Structure:
Check the jar artifact configuration, make sure it's not set to package the contents of the resources directory inside the jar (just the compiler output entry would be enough since it will contain the resources already).
If it's not the case, check the output directory of your project. The files from the resources directory should be present inside the root of the output directory. If there is resources subdirectory, delete it and rebuild the project, ensure it doesn't appear in the output again.
In case the resources subdirectory appears in the module output after rebuild, verify the module roots configuration. It could be that the directory above resources is configured as resources (or sources) itself.
If you can't figure out the problem, please share a complete sample project illustrating it and I'll point you to the exact configuration you should change.
Related
Hy,
I want to get the resource folder (ex: C:\Users\Raul\workspace\Serial\src\test\resources) in a Maven project but every time I run this java code:
System.out.println(getClass().getResource("").getPath());
it returns me this path: C:/Users/Raul/workspace/Serial/target/test-classes/
The last time I used Maven, worked that way without any changes from me.
Thx in advance.
With a typical setup, Maven copies the resources to the target/classes (or target/test-classes) directory. Also, the target/classes (or target/test-classes) directory is added to the classpath.
If you have a file src/test/resources/foo.txt, then you would access the file using getResource("/foo.txt").
Generally speaking, you would not want your code to refer to source folders to access resources. Resources might be put in multiple locations and it is pretty common to "filter" the resources (replace tokens with build property values). In the filtering case, you absolutely do not want the processed resource files to be in the source directory.
I have some resources that I'm working on in an Eclipse application. I need those resources to be available for access and modification by every other plugin.
I tried to place the resources under a source folder, but that causes Eclipse to copy the resources under bin, i.e. in a jar file. Therefore I can't modify them in runtime.
My question is, where and how do I place my resources so that everyone is able to see them and the resources are available for modification?
You can use the Workspace Mechanic plugin . It allows you to export , record and import preferences based on mechanic task files. You can have LAST MOD and RECONCILE tasks. For more information : http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
Hope this helps.
Here's my solution:
I created a fragment project which only contains my resources and nothing else. To prevent Eclipse from copying my resources to a .jar file on runtime, I added the following to the MANIFEST.MF of the fragment project:
Eclipse-BundleShape: dir
Bundle-ClassPath: data/,
.
("data" being the folder where my resources reside.)
Thusly my resources remain as they are, and I can modify them however I want during runtime.
I have a newbie Java question.
I had to make suite of J/DBUnit tests for some stored procedures we use in SQL Server. These tests use some XML files in a couple of sub-directories that I originally had placed in the same directory as my Java project.
Anyway, upon checking these tests in, our SVN manager wanted to keep the .java files in one part of the tree, and resources (like the XML files and required JARs) in another part of the tree.
So, my tests had originally referenced the XML files with a relative path which doesn't work now.
My question is:
Can I make the directories with my XML files available with the CLASSPATH (I hope so).
Assuming that works, how do I reference a file in my code that was included this way?
If I shouldn't be using the CLASSPATH for this, I'm open to other solutions.
Forget calsspath. Provide your tests with a parameter/configuration which defines the root dir for the relative paths of the XML files.
Using the classpath is no problem, the standard maven project layout looks like the following:
src
main
java
resources
test
java
resources
target
classes
test-classes
The compiler compiles src/main/java to target/classes, the resources of src/main/resources are copied to the target/classes folder, similar for the tests. If the tests have a classpath containing classes and test-classes, all works fine.
How is your project layout is, how is it build?
No, you should not use CLASSPATH in this instance since it is used by Java. However, you can use a similar approach by loading a value from an environment variable or configuration file which indicates the directory where the XML files are stored.
You can do this without making any changes to your classpath. The idea is to store the resource files in a separate directory, but have them copied to a directory in your classpath when you run your build process.
Here is an example configuration:
source Directory is ${basedir}/src/main/java
resource directory is ${basedir}/src/main/resources
In your build script, copy both the .java files and the resource files (.xml) to a directory in your classpath, say:
${basedir}/target/classes
Your test code runs against the target dir. The target directory is not checked in to SVN, keeping your SVN admin happy, and you don't have to make changes to your code.
I created a simple application which will read all the files and folders kepts inside a folder. Whenever I build the project, I only get the jar file but the folder where the file and folders are kept have to be created. Is this supposed to be like this or I have to code something, which will create the folder upon the final build.
Compilation gives you only executable file (i.e. *.jar). If you need something else to make you application works - you must do it (programmatically or not).
I am using ClearCase in my application which generates a whole load of ".copyarea.db" files (one in every folder).
These cause conflicts when publishing to Tomcat as Eclipse will bundle the "classes" and "test-classes" folders into one JAR (not sure why it does this - as there is no need to have test classes available on the application server).
Any folders with the same names will have a separate .copyarea.db in the classes and test-classes branches.
I managed to get around this problem in general by adding ".copyarea.db" to the Filtered resources on the Java->Compiler->Building->Output Folder preference page. This stops the file appearing in source output (package/class folders), the vast majority of cases.
However there remains the problem of the root folder, i.e. "target/classes/.copyarea.db" and "target/test-classes/.copyarea.db".
These files are not filtered as they are not part of the compile task.
Just deleting the files manually doesn't help either, as Eclipse expects to find them and doesn't.
How can I exclude these ".copyarea.db" files from the root "classes" and "test-classes" folders?
This file .copyarea.db is created in each directory of a web view (through CCRC, the remote client of ClearCase).
The simplest solution would be to not put under source control the directories classes and test-classes.
Then, as illustrated by this technote:
Otherwise, the directory should not be controlled.
If the directory is not controlled, then the .copyarea.db file within it should never be created.
If the directory was accidentally added to source control, this could be prevented in the future by adding classes to the ignore list. This would avoid the directory being passed to ClearCase during the Share.
Since you don't usually version the binaries produced under classes and test-classes, removing those folder, and adding them again manually (keeping them private to your view) is an acceptable solution.
If those folders are not under version control, then those copyarea.db come from versioned folders which contain them, and have been copied to the destination folder.
In that case, you can simply remove the copyarea.db files.
But since you said that Eclipse "expects to find them and doesn't", I assume those "classes" and "test-classes" folders are not private folder.
concerning
These cause conflicts when publishing to Tomcat as Eclipse will bundle the "classes" and "test-classes" folders into one JAR (not sure why it does this - as there is no need to have test classes available on the application server)
you can configure this in project properties, build path, order and export, or use maven and m2eclipse!