I am busy writing an integration test for a custom annotation processor. In order to do this I have a specific set of .java source files that I am running through javac in order to test my implementation. These are loaded by my test as a resource. This means that my source tree looks something like the following:
/src
/test [test source root]
/java
MyIntegrationTest.java [actual source code]
/resources
MyIntegrationClassFile.java [should be treated as plain text]
With IntelliJ, it is possible to filter what files are copied as resources using the Compiler Settings. So I removed the filter for .java files.
However, for resources to be copied, they need to be in a marked source tree. I also have my resources folder marked as test sources (yes, this is weird).
This is where the problem comes in: If the .java files are in a source tree (in order to be copied as resources), they are automatically compiled. I do not want to compile these files (they may not compile).
I have tried adding the resources to the compiler exclude list (NOT excluding it from the project), but this also results the resources not being copied.
You cannot mark a .java file as plain text, as far as I know, even though this feature is documented for other file types.
How can one mark a .java file as plain content that should be copied and not compiled?
For me it worked when I added the resource folder to the Compiler Exclude List.
Initial setup:
Rebuild project gives me this output:
Now I add the src/test/resources to the Compiler Exclude List:
After rebuild I have this in my output folder:
Using Idea 2016.3.3, go to Project Structure>src>test>resources then right click on it and select TestResources.
Then add an exclusion rule to Settings>Build, Execution, Deployment> Compiler> Excludes for your resources folder.
Also remove .java extension from Settings>Build, Execution, Deployment> Compiler>Resource patterns (you've already done this as I can see).
It works!
Related
I need to get a resource from inside the root of the application when its packed into jar. My project is like this:
ProjectRoot
resource.txt //want to access from here
src
main
java
package1
package2
package3
Main.java
target
app.jar
classes
resource.txt //works when here
package1
package2
package3
Main.class
I use this code:
Path path = Paths.get("resource.txt");
When run before packaging into a jar, it finds the file just fine (inside ProjectRoot). When running the jar, it can't find it, and transforms this path to target/resource.txt.
This code:
BufferedReader br = new BufferedReader(new InputStreamReader(new Main().getClass().getClassLoader().getResourceAsStream(
"resource.txt")));
when run before packaging looks for the resource inside target/classes. After packaging it claims to taking the resource from .../target/app.jar!/resource.txt.
This code:
BufferedReader br = new BufferedReader(new InputStreamReader(new Main().getClass().getClassLoader().getResourceAsStream(
"/resource.txt")));
I can't understand where's looking for the resource, but it doesn't seem to be ProjectRoot.
All I want to do is to place the resource inside ProjectRoot and be able to access it from both outside jar (when running the class files from IDE) and inside (after having packaged the files into a jar file using Maven).
EDIT: I NEED THE CODE TO WORK BOTH FOR PRE- AND POST- packaging. MEANING: If I run a Main.java FROM INSIDE IDE IT WOULD GET THE RESOURCE; IF I PACKAGE EVERYTHING INTO JAR AND RUN JAR IT WOULD GET THE RESOURCE - ALL WITH THE SAME CODE.
Use: Main.class.getResource("/resource.txt").
Note that your attempt using any call to getClassLoader is strictly worse (it's more text, and will fail more often, because that class loader can in exotic cases be null (specifically, when you're part of the bootstrap loader), whereas calling getResource directly on the class always works.
The reason your snippet does not work is because when invoking getResource on the classloader, you must NOT start the resource with a slash. When invoking on a class directly, you can (if you don't, it'll be relative to the package of the class you're calling it on, if you do, it'll be relative to the root).
TL;DR: Of the forms SomeClass.class.getClassLoader().getResource, getClass().getResource and MyClass.class.getResource, only the last one is correct, the rest are strictly inferior and therefore should not be used at all.
Maven uses something called the Standard Directory Layout. If you don't follow this layout then the plugins can't do their job correctly. Technically, you can configure Maven to use different directories but 99.999% of the time this is not necessary.
One of the features of this layout is that production files go in:
<project-dir>/src/main/java
All *.java files
<project-dir>/src/main/resources
All non-*.java files (that are meant to be resources)
When you build your project the Java source files are compiled and the *.class files are put into the target/classes directory; this is done by the maven-compiler-plugin. Meanwhile, the resource files are copied from src/main/resources into target/classes as well; the maven-resources-plugin is responsible for this.
Note: See Introduction to the Build Lifecycle for more information about phases and which plugins are executed by which phase. This Stack Overflow question may also be useful.
When you launch your application from the IDE (possibly via the exec-maven-plugin) the target/classes directory is put on the classpath. This means all the compiled classes from src/main/java and all the copied resources from src/main/resources are available to use via the classpath.
Then, when you package your application in a JAR file, all the files in target/classes are added to the resulting JAR file (handled by the maven-jar-plugin). This includes the resources copied from src/main/resources. When you launch the application using this JAR file the resources are still available to use via the classpath, because they're embedded in the JAR file.
To make resource.txt available on the classpath, just move:
<project-dir>/resource.txt
To:
<project-dir>/src/main/resources/resource.txt.
Then you can use Class#getResource with /resource.txt as the path and everything should work out for you. The URL returned by getResource will be different depending on if you're executing against target/classes or against the JAR file.
When executing against target/classes you'll get something like:
file:///.../<project-dir>/target/classes/resource.txt
When executing against the JAR file you'll get something like:
jar:file:///.../<project-dir>/target/projectname-version.jar!/resource.txt
Note: This all assumes resource.txt is actually supposed to be a resource and not an external file. Resources are typically read-only once deployed in a JAR file; if you need a writable file then it's up to you to use a designated location for the file (e.g. a folder in the user's home directory). One typically accesses external files via either java.io.File or java.nio.file.*. Remember, resources are not the same thing as normal files.
Now, if you were to put resource.txt directly under <project-dir> that would mean nothing to Maven. It would not be copied to target/classes or end up in the JAR file which means the resource is never available on the classpath. So just to reiterate, all resources go under src/main/resources.
Check out the Javadoc of java.lang.Class#getResource(String) for more information about the path, such as when to use a leading / and when not to. The link points to the Javadoc for Java 12 which includes information about resources and modules (JPMS/Jigsaw modules, not Maven modules); if you aren't using modules you can ignore that part of the documentation.
I am new to java,i have setup eclipse java project.I have a set of classes in jars in a folder.I have also got the java files associated to those classes downloaded (i cant compile those java files,its just to read and debug at runtime).My issue is class files are packaged in a different way than the those what appears in java file.
eg:- ABC.java is structured as platform\src\main\java\com\subplatform\sql\ABC.java
But package declared in java file if i open is
com.subplatform.sql;
I think this is the reason the debug point is not getting honored.In the previous version's of this product
java files used to be structured as
src\com\subplatform\sql\ABC.java
Thus it used to stop at the debug point.
Thanks
Rename all the package information that contains package com.[restOfPackageInfo] to be package java.com.[restOfPackageInfo] and you should be all set. (Also, if there are any import statements, you'll need to add java in front of com there too.)
There's your problem:
Originally the file structure was "src\com\subplatform\sql\ABC.java"
But by creating a folder called java and placing the com folder inside, you're changing the path to be: "src\main\java\com\subplatform\sql\ABC.java"
So, essentially in the ABC file you see package com.subplatform.sql;. This is information that the compiler uses to compile the class. So you're compiler looks for a ABC.java in src with path com.subplatform.sql but there is no such folder.
Also, read up on packaging.
It sounds like your source attachment path is wrong and should point to platform\src\main\java\ instead of the project itself.
A debug point not being honored can mean two different things.
1) The debugger isn't stopping on line breakpoints. If the compiled class files don't have line and debug information, the JVM doesn't know when it's executing those lines and will not stop there. You should still be able to stop at method entries and when exceptions are thrown. Either way, your are always required to launch your application using Debug instead of Run.
2) The debugger is stopping, but the source is not found. For a JAR file, you should have the properties of the JAR's entry on the Java Build Path point to a location where the source files exactly match the layout of the jar so that com/novice/to/sql/MyClass.class has a com/novice/to/sql/MyClass.java relative to where ever the source attachment points. If the top level contents of the JAR file contains entries like "com", "org", and "net", that's what should be in the top level of the source directory or archive you're pointing to.
I took the java implementation of the Factual API (reference http://developer.factual.com/) and made a JAR file for factual. I did this by opening a new project in eclipse with the factual java files and then exporting to a new jar file.
I put that jar file in my coldfusion installation's /WEB-INF/lib/ folder.
After restarting Coldfusion, I tried to create a new cfobject like so
<cfscript>
// Initialize the Java class.
factualClass=CreateObject("java", "src.main.java.com.factual.driver.Factual");
</cfscript>
I get an error indicating that it cannot find the Factual class.
Can anybody give me some guidance?
(Summary from comments)
It sounds like you may be exporting the source files ie *.java rather than the compiled class files, ie *.class. In the Jar Export wizard, be sure to select the "Export generated class files and resources" option. (To automatically compile the project sources before expi, enable the setting: JAR packaging > Build projects if not build automatically option). If you prefer you can also find pre-compiled jars in the MVN repository.
put that jar file in my coldfusion installation's /WEB-INF/lib/
folder.
CF10+ also supports dynamic class loading via a new application level setting THIS.javaSettings.
// Initialize the Java class.
factualClass=CreateObject("java", "src.main.java.com.factual.driver.Factual");
Just as a point of interest, src/main/java/ is not actually part of the libary class name. It is a standard directory structure used in Maven projects. It is probably included when exporting the sources, but not the compiled classes.
You can always verify the correct path and class name either by examining the API ie javadocs or by viewing one the source files. Package declarations are always at the top of the source file, such as on line 1 of src/main/java/com/factual/driver/Factual.java:
package com.factual.driver; // ie "com.factual.driver"
.. and the class declaration on line 39.
public class Factual { // ie "Factual"
Combined that gives you the exact (case-sensitive) path to use with createObject:
factualClass=CreateObject("java", "com.factual.driver.Factual");
I am developing maven plagin that obfuscates js files. It does the following -:
takes *.js files from target,
obfuscates them using google closure,
creates *.min.js files in target,
if it's necessary removes sources (unobfuscated files) from target.
In order to get point between package phase and prepare-package phase I use the following solution: https://stackoverflow.com/a/27566620/2022068
Everything is ok. Plugin is ready. However I have the following problem - if I remove source file, maven-war-plugin copies it again. Maybe it has some mechanism of checking - I don't know. The only thing that I can do now is to delete and create empty file. Than the source file exists but it's empty.
My qeustion - can I somehow remove files from target finally, forever...?
You probably need to teach this to the maven-war-plugin. I have no example that does the same thing but there are packageExcludes (see: http://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html) which seems not exactly what you need but also warSourceExcludes: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#warSourceExcludes
The war plugin has its own mechanism of copying files (aside from the resources plugin). That may be the issue here. There are some examples on filtering as well: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html
Maybe treating the files you don't want to see as excludes will work (if warSourceExcludes is something different than what you plan to do).
My Eclipse plugin project which holds libraries used by other OSGi plugins gives me the following warning:
The class folder 'lib/' is not associated to any output library entry.
What does it mean? Can I safely ignore it?
The whole feature consisting from 20 plugins works well, but I do not like to have any warnings in my code.
My build.properties file is:
source.. = src/
output.. = bin/
bin.includes = META-INF/,\
bin/,\
lib/,\
.
The search on google gave me this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=297483, but I'm still not sure how to fix this warning.
I found this hint to be helpfull (first google hit, as of 03-SEP-2013)
http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01822.html
I removed META-INF from my bundle build path, cleaned (rebuilt) the project and the warning disappeared.
About the build.properties:
META-INF/ should be included in the bin.includes because actually this folder includes all the information associated to the classpath and runtime information. If not, another warning appears.
Icons must be added as well in the bin.includes.
Actually, we should try to avoid the addition of icons in the runtime information:
Statically declared plug-in icons are not meant to be in the runtime JAR >because Eclipse wants to load plug-ins lazily. In other words, during >loading of the platform, the platform loader reads only the plugin.xml >file and will use the icons that are declared there.
Taken from: https://wiki.eclipse.org/FAQ_Can_I_add_icons_declared_by_my_plugin.xml_in_the_runtime_JAR%3F
Example of one of my plugins:
Figure 1. Adding information in the bin.includes property
The reason is simple. Think about we want to deploy our plugin somewhere else. Then, we need to maintain a track about all the information that needs our plugin to be executed.
About the MANIFEST.MF:
There is another trick to organize the information that appears in the MANIFEST.MF besides the information that appears in the build.properties:
PDE provides an Organize Manifests wizard to help ensure that the >information in your Manifest is up to date. The wizard is available >through the Plug-in Tools menu after right clicking on a plug-in project's MANIFEST.MF or plugin.xml files.
Taken from: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fpde_actions%2Forganize_manifests.htm
Example of one of my plugins:
Figure 2. Organizing MANIFEST.MF
I think your issue is that in your MANIFEST.MF the section Bundle-ClassPath does not include a listing of the libraries. This means OSGi will not know if these classes are meant to be on the internal classpath. You will have to provide that information.
If you export everything in lib, every single one has to be listed in the MANIFEST.MF and the wildcard lib/ is fine for the PDE builder.
If you only want some in lib/ then you need to list those only, and the builder will either need an explicit list, or an exclude clause for the ones that you do not want.
If you are just using the libraries internally, but do not want to export them, then the settings for the exported packages are used.
I am unsure what to do in the case where you are packing up a jar file but actually do not want it on the classpath. I am guessing that a source.exclude with the name of the library might help. This is a really unusual corner case.
Bundle-ClassPath: lib/amf-aml_2.12-4.1.19.jar,
lib/amf-core_2.12-4.1.20.jar,
lib/amf-validation_2.12-4.0.3.jar,
lib/amf-webapi_2.12-4.0.3.jar,
lib/antlr4-runtime-4.5.3.jar,
lib/collection-0.7.jar,
lib/commons-beanutils-1.9.3.jar,
lib/commons-cli-1.4.jar,
lib/commons-codec-1.11.jar,
lib/commons-collections-3.2.2.jar,
lib/commons-compress-1.19.jar,
lib/commons-csv-1.5.jar,
lib/commons-digester-1.8.1.jar,
lib/commons-io-2.6.jar,
lib/commons-lang3-3.4.jar,
lib/commons-logging-1.2.jar,
lib/commons-validator-1.6.jar,
lib/handy-uri-templates-2.1.6.jar,
lib/httpclient-4.5.5.jar,
lib/httpclient-cache-4.5.5.jar,
lib/httpcore-4.4.9.jar,
lib/jackson-annotations-2.9.0.jar,
lib/jackson-core-2.9.8.jar,
lib/jackson-databind-2.9.8.jar,
lib/jcl-over-slf4j-1.7.26.jar,
lib/jena-arq-3.11.0.jar,
lib/jena-base-3.11.0.jar,
lib/jena-core-3.11.0.jar,
lib/jena-iri-3.11.0.jar,
lib/jena-shaded-guava-3.11.0.jar,
lib/joda-time-2.9.4.jar,
lib/json-20180130.jar,
lib/json4s-ast_2.12-3.5.4.jar,
lib/json4s-core_2.12-3.5.4.jar,
lib/json4s-native_2.12-3.5.4.jar,
lib/json4s-scalap_2.12-3.5.4.jar,
lib/jsonld-java-0.12.3.jar,
lib/libthrift-0.12.0.jar,
lib/org.everit.json.schema-1.9.2.jar,
lib/paranamer-2.8.jar,
lib/re2j-1.1.jar,
lib/scala-common_2.12-0.5.64.jar,
lib/scalactic_2.12-3.0.5.jar,
lib/scala-java8-compat_2.12-0.8.0.jar,
lib/scalajs-stubs_2.12-0.6.29.jar,
lib/scala-library-2.12.6.jar,
lib/scala-reflect-2.12.8.jar,
lib/scalatest_2.12-3.0.5.jar,
lib/scala-xml_2.12-1.0.6.jar,
lib/scopt_2.12-3.7.0.jar,
lib/shacl-1.3.0.jar,
lib/slf4j-api-1.7.26.jar,
lib/slf4j-simple-1.7.12.jar,
lib/syaml_2.12-0.7.270.jar,
lib/webapi-parser-0.5.0.jar,
lib/webapi-parser-0.5.0-javadoc.jar,
lib/webapi-parser-0.5.0-sources.jar,
.