This isn't intended to be a question. Rather, an observation which is a common problem found in Android when you use external APIs for development and android.jar isn't duplicated into your project!
After searching through various forums, Google and stackoverflow, I seem to get a solution by myself and thought of sharing it.
Whenever you are linking external libraries, better link it by creating a /lib folder and dump those .jars there(means to COPY the files and NOT linking them). Link them using Eclipse -> Build Properties -> Configure Build path -> Library tab -> Add external Jars. Add the required .jars saved in /lib folder in this. (Note that, the jar included as a "Referenced Library" in Eclipse will disappear in /lib folder! But, not to worry as proper linking has happened. Another note is to check that the /lib jar that was referenced should NOT be visible in Libraries tab of Build Properties as it will be inherited.)
Another major problem was when Google APIs are being used. Specially the ones, which use some core library functions of java/javax. Be very careful of this. The error is that, the DalvikVM tries to link these but fails as there is a duplication found and is unable to decide which one to refer to. Below is the error.
Dx trouble processing "javax/xml/namespace/QName.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
In such cases, what I have observed is that, this class is used in xpp3-1.1.4c.jar. If you've copied this into your /lib folder, PLEASE REMOVE IT. Then clean the project, and give a fresh build. And the ship sails smoothly thereafter.
Do this for other referenced .jars if such duplication exists.
Cheers!
This worked for me. I'm using maven, and the xpp3-1.1.4c dependency shows up under "Maven Dependencies"; I had to exclude it using (right click the dependency) Maven-> "Exclude Maven Artifact...". Thanks a bunch -- this was really obscure.
This error show only when you trying to generate signed APK.
There are 2 ways to fix this.
1. As commented Amira Elsayed Ismail in this post this
we should revert to gradle 2.3.3.
To do this you should also download Android Studio 2.3.3 because studio 3.0.1 require gradle plugin 3.0+
This was the first solution. But reverting Android Studio and gradle plugins is a painful solution.
2. Resolve all dependency conflicts.
When i revert gradle, Studio 2.3.3 showed we interested warnings(i do not know why studio 3.0.1 don't show dependency conflict warnings)
Warning:WARNING: Dependency xpp3:xpp3:1.1.4c is ignored for debug as it may be conflicting with the internal version provided by Android.
Warning:WARNING: Dependency org.apache.httpcomponents:httpclient:4.3.3 is ignored for debug as it may be conflicting with the internal version provided by Android.
So these dependencies are ignored for debug but NOT FOR RELEASE.
I fixed this by excluding these dependencies.
configurations {
all*.exclude group: 'xpp3', module: ['xpp3' ,'httpclient']
}
After this, i successfully generated signed APK using gradle 3.0.1.(without reverting).
Related
So I have been facing these issues in so many JavaFX Gradle based projects in Intelli J Idea IDE. This has pushed me to the point where I had to manually download library files and make them part of my projects as a workaround.
The gradle projects I have they keeping failing when ever i run the > Task :compileJava in the IDE, for example in this particular that made me create the issue is that i have successfully imported the socket io lib from maven implementation 'io.socket:socket.io-client:2.0.1' , i have managed to import it and write a bit of sample code for it and i have added
requires engine.io.client;
requires socket.io.client;
in the module info file . So when its time to run this fails stating that
error: module not found: socket.io.client
requires socket.io.client;
error: module not found: engine.io.client
requires engine.io.client;
I have tried on JDK 13,16,17 to see if I am missing something but keeps on failing to run , so I have noticed now as a trend in my previous JavaFX project in which i managed to get away with.
So if there is anyone who understands what's wrong with Gradle set up please help.
This answer outlines an approach rather than a concrete solution.
socket.io.client and engine.io.client are not module names.
The socket.io-client library is not Java platform modularized (as far as I can tell), so it will be an automatic module.
The name of the module will be derived from the jar name. I don't know the exact translation as the jar name has . and - characters which may be remapped (or not) to make the module name valid. Try first the exact jar file name. There can be only one module per jar.
Additionally to requiring the right name, the jar needs to be on the module path. Maven will do this automatically for automatic modules, Gradle will not. I am not a Gradle expert, so will not provide advice on how to do that for Gradle.
If you use the right name in module-info and ensure the jar is on the module path, then it may work, or it may be incompatible with the Java module system in ways that are not easily fixable by you (i.e. the broken module must be fixed by the module maintainers).
You can raise an issue for the library maintainer for them to create module-info.java files for the modules and update their documentation on how to use their libraries in a Java module environment.
If the library you are trying to use is incompatible with the Java module system when used as a module, then you could try making your project non-modular by deleting module-info.java from your project and adding appropriate command-line switches. To understand how to do this, refer to documentation on non-modular projects at openjfx.io.
I'm trying to get Google Cloud Vision API working with Java in IntelliJ. I've followed all the steps at https://cloud.google.com/vision/docs/quickstart-client-libraries. I'm running the following code, just trying to import the packages I need and when I scroll over google, it is underlined in red and says 'cannot resolve symbol google'. How do I fix this?
code and error
The error shown in your screenshot usually happens when an external dependency could not be loaded.
Please make sure you accurately followed the steps in the Install the Client Library section of the guide you followed, in the Java tab of the widget.
From the screenshot I can not really tell what build settings you configured for the IntelliJ project. If you chose no build tools or the regular Ant setup, it might be easier for you to re-setup a project based on either Maven or Gradle.
With Gradle and Maven it is pretty straightforward to add the dependency to the project as described in the guide, otherwise you will have to download all the dependency libraries yourself and add them to your project folder and build environment manually as files.
If you did already use Gradle or Maven for your project, and did follow the guide but it still shows the error, then it's usually a case of IntelliJ not loading those changes yet.
In that case you can fix it by selecting your Gradle or Maven tab in Intellij, and clicking the re-import button (looks like a refresh icon from browsers) to reload the configuration, usually triggering a download of missing dependencies.
Otherwise you can also trigger a full build with running the gradle build or mvn compile targets, which also should download all configured missing dependencies.
I'm trying to debug an Eclipse plugin that developed a bug around the 2019-09 timeframe. Something must have changed in the platform that causes it not to work anymore.
I can run the rcp 2018-12 distro and test it, and I verify that it works. I was able to step through the handler code.
If I run the 2019-12 distro, I can't fully compile the project, as it says "The type javax.inject.Inject cannot be resolved.". When I try to open type javax.inject.Inject in the 2018-12 distro, it finds it in "eclipse/plugins/javax.inject_1.0.0.v20091030.jar" in the distro. When I inspect that "plugins" directory, I find lots of separate plugin jars.
In the 2019-12 distro, it can't find javax.inject.Inject, and when I look in that plugins directory, I only find a single jar, the "org.eclipse.equinox.launcher" jar.
I remember this subject of the single launcher jar, but I don't know if this is a direct cause of this compile error, or what I have to do to move forward.
Update:
In response to the much appreciated answer, here's what I found:
I do find a ~/.p2 directory, and I found the javax.inject plugin in there. When I inspect the "Target Platform" settings, I see very similar information in both the 2018-12 and 2019-12 instance (plugin count varies by a very small number).
I inspected all of the MANIFEST.MF files, and none of them have a single "Import-Package" statement. I understand the advice is to add one, but I'd like to understand why I'm NOT seeing an error in 2018-12.
When I look at the "Plug-in Dependencies" list in the Project Explorer, I see "javax.inject" in the list in 2018-12, but I don't see it in 2019-12.
When I select the MANIFEST.MF file and view it in the form mode and select "Dependency Analysis" and then "Show the plug-in dependency hierarchy", I can then see that "org.eclipse.core.runtime", which is version 3.15... in 2018-12 and version 3.17... in 2019-12 has different dependencies. In particular, in 3.15, one of the dependencies is "javax.inject". In 3.17, that is not one of its dependencies.
So, I can see that a possible solution is definitely to add an "Import-Package" for "javax.inject", but can you explain why it might be that NONE of the MANIFEST.MF files have a single "Import-Package" statement as of yet?
If you are using an Eclipse installed with the Oomph installer the plugins can be in a different location (the .p2 direcory in your home directory I think). The javax.inject plugin should still be present along with all the other Eclipse plugins.
Plugins normally reference javax.inject using Import-Package in the MANIFEST.MF rather than specifying the required plugin use Require-Package so:
Import-Package: javax.inject
There haven't been any significant changes in this area between 2018-12 and 2019-12. The version of javax.inject is still exactly the same.
Check what you have configured as your Target Platform (Preferences > Plug-in Development > Target Platform) - that determines what plug-ins are available.
Update:
The reason you now need to add the Import-Package is the change made by Eclipse bug 487676 which removed the 're-export' of the javax.inject dependency from org.eclipse.core.runtime so that you now have to explicitly add it. This is also documented in the Whats New for Eclipse 2019-09 (4.13)
I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?
These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".
I've created Android Library Project which depends on three libraries : google-play-services_lib, android-support-v7-library and pull-to-refresh ( https://github.com/chrisbanes/Android-PullToRefresh/blob/master/library/src/com/handmark/pulltorefresh/library/PullToRefreshBase.java )
I marked my project as library and want to create jar which can be used as jars are used is google_play_services and android-support library. My question is what I have to do to be sure that libraries that my project depends on are not included in my jar. I want 3rd person - who will use my library - to add them with my projectes as dependencies and get it work.
Unchecked export options in java build path is enough?
I don't know exactly if you have used Gradle or not. But if it's the former, then you don't have to do nothing. If you have include your dependencies in your library project like this:
dependencies {
compile 'whatever:library'
}
Then it's ok.
Note: If your project includes resources (like layouts and more) it can not be compiled as a jar!
Note2: If you didn't use Gradle, notify me in the comment and I'll update this post explaining how to achieve that.
UPDATE 1:
First of all, let me link you to another related answer I did the last week. It gives you useful links to learn Gradle in a hurry (at least all the basics).
Second, do you use Android Studio?
UPDATE 2:
It's just a matter of taste ;)! But with Android Studio (Intellij) you don't need to configure the extra step to get Gradle working.
Well, after you have read those links I've put before, the next step is to create a library project (in Android Studio it will generate the required folders/files automatically for you).
In your lib or library folder (where you put your source code of your library) in your build.gradle put the following:
dependencies {
compile 'com.google.android.gms:play-services:4.4.52'
compile 'com.android.support:gridlayout-v7:19.1.0'
compile 'it.sephiroth.android.library.fork.actionbarpulltorefresh:actionbarpulltorefresh:0.9.92'
}
And with that you can generate your library in aar format.
NOTE: Android-PullToRefresh library is not Gradelized, so I had to search for another alternative that has been uploaded to MavenCentral (like sephiroth's one). Remember to use Gradle, please! To search already Gradelized libs!