I'm doing some java development on aosp and currently lsp-java cannot find or resolve classes outside the project folder. I'm getting alot of warnings that lsp/flycheck cannot resolve imports such as android.util.Log and android.content.Context, to give two examples.
Is there any way to configure this in lsp-java, either a path to where those classes can be found or SDK file?
Note that I'm not using gradle but pure aosp make files (Android.bp/Android.mk) to compile the apps. I don't need compilation to be supported in lsp but at least the imports should be resolvable, so I can navigate dependencies etc.
I have used ggtags before which is able to resolve such imports, but would prefer to use lsp.
Related
I have an IntelliJ with Scala plugin intalled on the server. The server is disconnected from the global internet and all the updates can be done ocsasionally only.
Would like to download some libraries once (e.g. Spark libraries, some libraries from Java) and use them in IntelliJ in the multiple projects without need of downloading them, but loading from local direcories. Also it would be great to have a 'full' bundle of libraries (e.g. all Spark libraries) and be able to use only particular classes when it's necessary (e.g. Spark Context only).
TK
P.S. Question is somewhat related to the: Use Scala on computer without internet connection
As #MarioGalic sugested, the cluse was to move a required libraries to the ~/.ivy2 directory.
Somethimes the case is to add libraries manually in IntelliJ project setup, insted of using SBT or Maven to manage the dependencies.
I wrapped a source github for b4a with Eclipse.
I added core.jar but when I compile the project in b4a it shows this error:
trouble processing "java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class": Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
This is often due to inadvertently including a core library file in your application's project, when using an IDE (such as Eclipse). If you are sure you're not intentionally defining a core class, then this is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core namespace, the source of which you may have taken, for example, from a non-Android virtual machine project. This will most assuredly not work. At a minimum, it jeopradizes the compatibility of your app with future versions of the platform.
I changed package name from
java.com.lsjwzh.widget.materialloadingprogressbar
to
com.lsjwzh.widget.materialloadingprogressbar
Why show in error -
"java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class"
?
I rebuilt the project in eclipse and compile with SimpleLibraryCompiler for b4a.
I forgot use
#DependsOn
for calling Additional jar in folder libs.
One of the most common uses of eclipse fragments is as a container for JUnit test classes. But how to write JUnit tests for Eclipse fragment when it plays another, more important role? For example, when it has platform specific code.
The problem is that it is impossible to create a fragment for a fragment. And you can't write tests for host plug-in to test the fragment because it doesn't even compile as a fragment is "merged" into a host only at runtime.
I don't know of a satisfactory solution, however, you may want to consider these workarounds.
Eclipse-ExtensibleAPI
You can use the Eclipse-ExtensibleAPI manifest header like this
Eclipse-ExtensibleAPI: true
It causes the packages exported by the fragment to be re-exported by the host bundle. Now you can create a test bundle that imports the desired packages and therefore has access to the public types in the fragment.
This isn't as close as test-fragments where you benefit from tests and production code using the same class loader that gives access to package-private types and methods. But you can at least test through the publicly accessible means.
Note, however, that this header is specific to Eclipse PDE and not part of the OSGi specification. Hence you are tied to this development environment. Furthermore, the packages of the fragment will be exported through its host bundle and will be visible not only for the test bundle but for all bundles.
Java Library
If your fragment has few dependencies and doesn't require the OSGi/Eclipse runtime you could consider treating it as a plain Java library w.r.t tests. Another sibling Java project could contain tests and have a project-dependency (Properties > Java Build Path > Projects) on the fragment project. Again, access to package-private members would not work.
And if you use a build tool like Maven/Tycho, some extra work would be required to declare dependencies and execute these tests during the build.
Bndtools
You could also look into Bndtools to see if this development tool fits your needs better than the Eclipse Plug-in Development Environment (PDE).
Plain JUnit tests are held in a separate source folder in the same project as the production code. This would give your test code access to the production code in the same way as if test-fragments were used.
Bndtools also supports executing integration tests, though I doubt that you would have access to the fragment code other than through services or other API provided by the fragment.
For CI-builds, Bndtools projects usually use Maven or Gradle with the help of the respective bnd(http://bnd.bndtools.org/) plug-in. Just as Maven/Tycho is used to build and package PDE projects.
Since Bndtools is an IDE extension to develop OSGi bundles, it doesn't know about Eclipse plug-in specificities such as extensions declared in the plugin.xml. Hence there is no builder and editor for these artifacts. But if you are lucky, you may even be able to use the PDE builder to show error markers for invalid extensions and extension points.
Another downside that comes with having production- and test-code in the same project, is that pure test dependencies like JUnit, mock libraries, etc. are also visible for the production code at development time.
Of course, the produced (fragment) bundles do neither contain test code nor test dependencies.
However, Bndtools itself is developed with Bndtools. So there is proof that Bndtools can be used to write Eclipse plug-ins.
I am currently trying to develop a plugin for IntelliJ that will use a "core" library. The core library already has it's own dependencies (JAR files) and is used in other non-IntelliJ projects. Unfortunately some of the dependencies of the IntelliJ SDK are the same as that for the plugin core, but with conflicting versions. So far this has been manageable because we remove the dependencies in the SDK and provide the core's dependencies instead, and running the plugin through IntelliJ to work fine. However, I really want to be able to write automated unit tests for the plugin, and this causes problems.
Following the instructions from here, I set my first unit test to extend LightCodeInsightFixtureTestCase. However, this fails to get past the setUp method, throwing NoClassDefFoundErrors. See the gist of the error here (picocontainer is the conflicting dependency).
By inspecting the classes loaded while running the plugin, I can see that the same class from a conflicting dependency is loaded in two different classloaders, a URLClassLoader for the com.intellij dependency, a PluginClassLoader for my plugin's dependency. This explains why the plugin can be executed successfully, but the test fails.
A small, self contained example of a project that fails in this way is available here: https://github.com/holger-s/libraryconflict
My question is, what is the recommended way to resolve these conflicts that allows unit testing with the IntelliJ test fixtures?
Full disclosure: I have also sought an answer on the IntelliJ Plugin Development forum.
So this is late, but was running into the same problem, and I fixed it by adding the library under Project Structure/Libraries, then going to Modules/Dependencies, and changing the scope to Provided.
https://confluence.jetbrains.com/display/PhpStorm/Setting-up+environment+for+PhpStorm+plugin+development
Have installed Android Sources Eclipse Plugin, and wonder how can I access the source code to Java standard library classes, e.g., java.lang.String?
Indeed, I could extend the sources.zip-file (installed by the plugin) with the missing source files, like the java.* packages source files, but is there any other more seamless way to deal with this?
The sources of java library are situated in the project libcore. The full path libcore/luni/src/main/java There you can find java.lang package where String class is defined.
So you have two possibilities to look into resources:
Download the sources of AOSP
Browse sources in the Internet.