I guess by asking this I might sound a bit illegible, but I'm still unsure as to how to approach the problem.
In my spring project (not really my, work stuff) I've got some groovy scripts which are initially treated as resources, yet in reality they are rather the "source code" which is compiled not during the gradle assembly of the project but during the runtime by the application itself. And everything's fine with that.
The problem is that the IDE doesn't treat the groovy file properly. Dumb example to somehow describe what I mean:
import myproject.example.blabla
import groovy.transform.CompileStatic
#CompileStatic
class SomeClass1 implements SomeClass2 {
private final SomeClass2 someName1
SomeClass1() {
someName1 = new something
}
#Override
String getSmth() {
return someName1.getSmth()
}
}
The problems:
when I make "command + left_click" on SomeClass2, it says Cannot find declaration to go to, but when I press "command + O" it finds the file because it actually exists
.getSmth() is red, because Cannot resolve symbol
So it seems that I need to somehow show the dependencies via gradle to IDE only. Like, somehow specify the dependencies explicitly for IntelliJ IDEA so that it would understand that it is a source code as well and stop underlining everything with red.
Such files must be located in the module's Source Root directory for the IDE to recognize them as sources and so that navigation would also work.
In a Gradle-based project IDE configures Source Roots automatically based on the Gradle's Source Sets configuration. For each Gradle source set IDE creates a module with one Source Root directory.
So you must configure Gradle to create source set for the directories where these files are located: add them into default sources sets or create a custom source set for them.
Related
I'm new to the whole programming stuff but here's my problem:
I used to add my JUnit test cases in Eclipse by right clicking on the project, and just add New > JUnit Test Case.
Currently, I am not able to implement any test methods because Eclipse tells me on the line
import static org.junit.jupiter.api.Assertions.*;
the error message
The type org.junit.jupiter.api.Assertions is not accessible.
Error I get in the IDE:
I tried the following:
Reinstalling Eclipse, using a fresh workplace.
Adding the JUnit to Build path
Nothing helped.
It worked and works in older projects just fine.
Here is how the Package Explorer looks:
What am I missing?
You use the Java Platform Module System (JPMS) by having a module-info.java file in the default package probably without the required requires <module>; statement. JPMS was introduced in Java 9.
Do one of the following:
Delete the module-info.java file (if needed, you can recreate it via right-clicking the project folder and choosing Configure > Create module-info.java)
In module-info.java add the corresponding requires statement, e.g. by going to the line with the import statement and using the corresponding Quick Fix (Ctrl+1)
I know there are a lot of questions that seem similar. I have also spent a few hours getting to grips with Gradle multiprojects. But I still don't understand what the best course of action is here. Incidentally I am using Groovy as my coding language, but explanations referencing Java would be just as good.
I have developed an Eclipse Gradle project, "ProjectA", which in particular has a class, IndexManager, which is responsible for creating and opening and querying Lucene indices.
Now I am developing a new Eclipse Gradle project, "ProjectB", which would like to use the IndexManager class from ProjectA.
This doesn't really mean that I would like both projects to be part of a multiproject. I don't want to compile the latest version of ProjectA each time I compile ProjectB - instead I would like ProjectB to be dependent on a specific version of ProjectA's IndexManager. With the option of upgrading to a new version at some future point. I.e. much as with the sorts of dependencies you get from Maven or JCenter...
Both projects have the application plugin, so ProjectA produces an executable .jar file whose name incorporates the version. But currently this contains only the .class files, the resource files, and a file called MANIFEST.MF containing the line "Manifest-Version: 1.0". Obviously it doesn't contain any of the dependencies (e.g. Lucene jar files) needed by the .class files.
The application plugin also lets you produce a runnable distribution: this consists of an executable file (2 in fact, one for *nix/Cygwin, one for Windows), but also all the .jar dependencies needed to run it.
Could someone explain how I might accomplish the task of packaging up this class, IndexManager (or alternatively all the classes in ProjectA possibly), and then including it in my dependencies clause of ProjectB's build.gradle... and then using it in a given file (Groovy or Java) of ProjectB?
Or point to some tutorial about the best course of action?
One possible answer to this which I seem to have found, but find a bit unsatisfactory, appears to be to take the class which is to be used by multiple projects, here IndexManager, and put it in a Gradle project which is specifically designed to be a Groovy library. To this end, you can kick it off by creating the project directory and then:
$ gradle init --type groovy-library
... possible to do from the Cygwin prompt, but not from within Eclipse as far as I know. So you then have to import it into Eclipse. build.gradle in this library project then has to include the dependencies needed by IndexManager, in this case:
compile 'org.apache.lucene:lucene-analyzers-common:6.+'
compile 'org.apache.lucene:lucene-queryparser:6.+'
compile 'org.apache.lucene:lucene-highlighter:6.+'
compile 'commons-io:commons-io:2.6'
compile 'org.apache.poi:poi-ooxml:4.0.0'
compile 'ch.qos.logback:logback-classic:1.2.1'
After this, I ran gradle jar to create the .jar which contains this IndexManager class, initially without any fancy stuff in the manifest (e.g. name, version). And I put this .jar file in a dedicated local directory.
Then I created another Gradle project to use this .jar file, the critical dependency here being
compile files('D:/My Documents/software projects/misc/localJars/XGradleLibExp.jar' )
The file to use this class looks like this:
package core
import XGradleLibExp.IndexManager
class Test {
public static void main( args ) {
println "hello xxx"
Printer printer = new Printer()
IndexManager im = new IndexManager( printer )
def result = im.makeIndexFromDbaseTable()
println "call result $result"
}
}
class Printer {
def outPS = new PrintStream(System.out, true, 'UTF-8' )
}
... I had designed IndexManager to use an auxiliary class, which had a property outPS. Groovy duck-typing means you just have to supply anything with such a property and hopefully things work.
The above arrangement didn't run: although you can do build and installdist without errors, the attempt to execute the distributed executable fails because the above 6 compile dependency lines are not present in build.gradle of the "consumer" project. When you put them in this "consumer" Gradle project's build.gradle, it works.
No doubt you can add the version to the generated .jar file, and thus keep older versions for use with "consumer" projects. What I don't understand is how you might harness the mechanism which makes the downloading and use of the dependencies needed by the .jar as automatic as we are used to for things obtained from "real repositories".
PS in the course of my struggles today I seem to have found that Gradle's "maven-publish" plugin is not compatible with Gradle 5.+ (which I'm using). This may or may not be relevant: some people have talked of using a "local Maven repository". I have no idea whether this is the answer to my problem... Await input from an über-Gradle-geek... :)
You should be able to update the Eclipse model to reflect this project-to-project dependency. It looks something like this (in ProjectB's build.gradle):
apply plugin: 'eclipse'
eclipse {
classpath.file.whenMerged {
entries << new org.gradle.plugins.ide.eclipse.model.ProjectDependency('/ProjectA')
}
project.file.whenMerged {
// add a project reference, which should show up in /ProjectB/.project's <projects> element
}
}
These changes may be to the running data model, so they may not actually alter the .classpath and .project files. More info can be found here: https://docs.gradle.org/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseModel.html
This issue is discussed here: http://gradle.1045684.n5.nabble.com/Gradle-s-Eclipse-DSL-and-resolving-dependencies-to-workspace-projects-td4856525.html and a bug was opened but never resolved here: https://issues.gradle.org/browse/GRADLE-1014
I know I am asking the very popular question. But I can not find the solution to the problem. I have a sandbox to which I added a code of the unit test MulticurveBuildingDiscountingDiscountAUDTest.java file and commented it.
Then I added the main method and I could successfully run the program (print something in a console).
Finally, I uncommented the code of the MulticurveBuildingDiscountingDiscountAUDTest.java file and I saw the following error:
The import com.opengamma.analytics.financial.instrument.index.GeneratorSwapFixedONMaster cannot be resolved.
And further in the code:
GeneratorSwapFixedONMaster cannot be resolved
I know that this import is located in the og-analytics src/test/java location, which I believe is not listed anywhere in the build path. I believe the problem is with a build path options and specially with classes like GeneratorSwapFixedONMaster which were created specially for tests. I have been playing around with cleaning, rebuilding projects, reinstalling and as a result updating the JRE. I have visited these Import *** cannot be resolved [duplicate] and these Eclipse error: “The import XXX cannot be resolved” questions.
Do you know what shall I do to cure the following error?
I have many problems with other imports from the original MulticurveBuildingDiscountingDiscountAUDTest.java file as well.
Update: #1 is a location of my file. #2 is the location of classes this project uses. The MulticurveBuildingDiscountingDiscountAUDTest.java file is taken from the src/test/java
Update 2: one may see that in Libraries I have included all the dependencies I might need (at least I do not know what else to add). The Maven Dependencies contains the hole og-analytics package:
You included the source (src) folder og-analytics/src/main/java which contains the *.java files instead of the classes (bin or classes) folder with the *.class files (in your case, probably og-analytics/target/classes).
But instead using Add Class Folder... you should add the project og-analytics in the tab Projects. Or even better, in the Maven pom.xml file add the dependency to the project og-analytics like you did for og-util.
I know that this import is located in the og-analytics src/test/java location, which I believe is not listed anywhere in the build path.
Perfectly explains your problem. In order to import any class, you must either have the source in your build path, or some directory that contains a compiled version of that class. It is that simply.
The answer is: get clear on your project setup. If you intend to use classes from somewhere, you have to make them available somehow. Otherwise it will not work. In your case: if your tests want to make use a certain thing - then you should probably add that "thing" to your test project (you should avoid putting test-only stuff to your "product" projects).
That is all there is to this.
Motivation:
I'd like to try if compile-time annotation processing fits my problem. It needs to work out of the box, no compiler arguments etc.
Current state:
I have:
The annotation
An annotation processor
A .jar containing both of these and a javax.annotation.processing.Processor file containing the FQCN of my processor in META-INF/services
What should happen:
It should autodetect the processor
It should process the annotation and create a new class (WiredAnnotated)
I should be able to use this class in one step of compilation (not multiple phases)
I wan't the editor to accept this class is generated (e.g. AndroidAnnotations manages this as well)
What actually happens:
It autodetects the processor
It creates a new class (in out/production/*/generated/)
I am able to use this class
The source code looks right
When decompiling it looks ok too
The editor cannot resolve the class (see screenshot)
What I tried:
Restarting IntelliJ
Invalidating caches
Checking for output of the annotation processor
Screenshot:
When compiling, it actually works as expected. I guess it has something to do with inspecting the wrong directories.
Does anyone have an idea/clue on what I'm doing wrong? Did I miss information which could help you help me?
Thanks in advance, Till
Well, you need to add you out/production/*/generated/ to projects source folder. So, IntelliJ will know about your generated classes.
You can make it via Right click on directory > Mark directory as source root.
or
Project structure (F4) > Modules > Sources tab > Source folders should contain all directories with your source codes, generated one inludes.
In android there is a gen dir in root folder, but notice, it glows blue or green which means it marked as Source folder, it is also visible in Project structure > Modules. It contains R, BuildConfig and Manifest.
Here are the steps I have followed so far, with no luck. I am extremely new to Java projects so I suspect I may be missing something obvious.
Using Eclipse, I have created a simple Java project called TestSDK, created within that a package called com.test.testsdk, and within that the following class:
package com.test.testsdk;
public class TestClass {
public void TestMethod() {
}
}
This compiles without errors or warnings.
I then export this as a JAR file (TestSDK.jar) using Eclipse and the standard export options (export generated class files and resources, compress the contents of the JAR, generate manifest file). I have tried both sealing and not sealing the JAR which makes no difference.
I then create a new Android application project from File->New->Project in the Wizards list. This compiles and runs without warnings or errors on both the Android emulator and my test device (I get the hello world message).
I then add a reference to my TestSDK.jar file (using a variety of different methods as I will expand on shortly), import it into the main (and only) Android activity, and try to instantiate my TestClass and call TestMethod on it, like so:
package com.apptest.mobilesdktestapp;
import android.app.Activity;
import android.os.Bundle;
import com.test.testsdk.TestClass;
public class MobileSDKTestAppActivity extends Activity {
/** Called when the activity is first created. */
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TestClass test = new TestClass();
test.TestMethod();
}
}
This compiles fine without warnings or errors. When trying to run it on the emulator or the device, however, I get the following error in my LogCat window:
AndroidRuntime Uncaught handler: thread main exiting due to uncaught exception
AndroidRuntime java.lang.NoClassDefFoundError: com.test.testsdk.TestClass
Searching the web for the NoClassDefFoundError results in a lot of suggestions on how to import the JAR file such that the class path is correct. As a result, I have tried all of the following methods of importing the JAR file:
"Add External JARs..." from the Libraries tab of Java Build Path in the project properties, followed by checking (or not checking, I tried both) the JAR in the Order and Export tab. Also tried moving the JAR to the top of the Order and Export list, which made no difference.
Creating a "libs" folder in the project, and adding the JAR there. I confirmed that the JAR is then also added to the "Android Dependencies" thing in the project list. Also tried right-clicking the JAR file and selecting Build Path->Add to Build Path which made no difference.
Moving the JAR into my Android Application project directory and doing "Add JARs..." instead of external JARs as in step 1, also all permutations of exporting or not and moving it to the top of the order list or not.
I have subsequently downloaded other 3rd party SDKs that are packaged as JAR files and included those in the very same Android application project, and those have all worked fine using any of the 3 methods above (I am able to instantiate classes from those SDKs and use them without error), which leads me to believe I am missing something or doing something wrong in my TestSDK project and/or class which is preventing it from being used in the Android Application project.
As I said, I am very new to Java, so I'm hoping it's something simple that I've overlooked. Any help or guidance would be appreciated.
If you are on R17 or higher version of the Android tools and ADT in Eclipse, then the first sentence of #2 is the correct answer; everything else listed in your question is unnecessary at best or harmful at worst.
I would recommend that you create a clean project, create the test activity, create the libs/ folder, copy the JAR into the libs/ folder, code to the JAR's API, compile, and run. If that works, then your original project still has stuff lingering around from your previous efforts that is causing you grief. If it fails, then something fairly strange is going on. The JAR itself is presumably fine, otherwise you would get compile errors.
I think I figured out what the issue was (or at least how to fix the issue, I'm still not 100% sure what I did)--
When I created the original TestSDK java project, I let it target the default JRE in the project creation dialog (jre7).
Checking the project properties of a new Android Application project, the Java Compiler section has "Compiler compliance level" set to 1.5. So, I tried recreating my TestSDK project again, but told it to use J2SE-1.5 as the execution environment instead of the defalut jre7.
After doing this, exporting the JAR and importing it to the Android project's libs directory, I am now able to instantiate the TestSDK classes and use them just fine without the NoClassDefFoundError exception.
Best guess is that the Android application was being compiled against an older version of the JRE than my TestSDK class (which I believe was targeting JavaSE-1.7), causing the issues. Matching the two versions up has solved it.