We Keep Coding

How to identify in Eclipse PDE the plugin or dependency that provides a package?

I am facing many instances of the following error message in the process of migrating an Eclipse plugin from Java 8 to Java 11. The build is using Tycho, but I'm not sure that matters much.
The package org.xml.sax.helpers is accessible from more than one module: <unnamed>, java.xml
The package javax.xml.parsers is accessible from more than one module: <unnamed>, java.xml
…
The message is explicit. The solution I consider is excluding the dependency that causes the duplication since this is now provided by the runtime environment.
My problem is that the target platform that I am using includes hundreds of JAR files and I can't sift through the uncompressed version of each file to find out which one provides the packages.
If I could identify the dependency, or have the Java compiler write a more detailed error message, that would help me solve the issue.
Therefore, I used https://github.com/javalite/jar-explorer to search my Maven dependencies and the plugins folder of my target platform (Eclipse 2020-09), to no avail.
Is there in PDE a possibility to identify the plugin that provides a specific Java package?

How to find if I need to exclude dependencies in a maven java project?

I use both Intellij IDEA (2018.3.5) & Eclipse IDEs, but I prefer Intellij. I have a maven based Java project with multiple poms. I added some dependencies to one of the pom files. I need to find out if there are any dependency conflicts which could prevent the build from running when its deployed, and then exclude them. I tried the steps given below to find conflicts which could cause problems. Are they enough or do I need to do more ?
Check if there are any compile time dependency conflicts with mvn clean install -DskipTests. Build was successful with no errors.
Check if Intellij shows no problems under File > Project Structure > Problems. There are no problems.
I also saw the dependency tree with mvn dependency:tree -Dverbose. It has a lot of "omitted for duplicate" and "omitted for conflict with" items, but the build was successful. I don't see any errors though. Does this mean that everything is okay or do I have to do something more about these conflicts ?

The best way to tell if everything is fine with your application is to have good tests.
However normally one doesn't exclude transitive dependencies from project's <dependency> libraries. Doing it can potentially break the dependency in a subtle and hard to notice way. It's usually safer to remove the whole <dependency>.
There are few scenario when one should use <exclude>:
Dealing with incompatible transitive dependencies between different libraries e.g. A requires library C-1.0 but library B requires library C-2.0 while C-1.0 and C-2.0 can't coexist on the classpath.
Having transitive dependencies already provided by system e.g. deploying to Tomcat with additional JARs in the TOMCAT_HOME/lib directory.
If you decide to exclude a dependency it's important that you check the final artifact because sometimes plugins do weird things e.g. there were versions of maven-assembly-plugin affected by a bug that resulted in different dependencies being resolved during shaded JAR creation than maven-dependency-plugin used for compilation.

Dependency org.json:json:20090211 is ignored for debug as it may be conflicting with the internal version provided by Android

While I am running android studio, the warning below appears:
Dependency org.json:json:20090211 is ignored for debug as it may be conflicting with the internal version provided by Android.
In case of problem, please repackage with jarjar to change the class packages
How can I resolve this error?
Thank you.

CommonsWare answer is correct. Dependency org.json:json:20090211 is ignored for debug as it may be conflicting with the internal version provided by Android.
If you are using gradle dependency try excluding org.json from the package.
compile ('com.your.dependency.name:0.0.0'){
exclude group: 'org.json', module: 'json'
}
This one worked for me.

It would appear to be that you are trying to use some Java dependency that is not set up for Android. Most likely, it is whatever dependency you just added. That could be for org.json:json, or it could be for something else that has a transitive dependency on org.json:json.
If you added the dependency on org.json:json yourself, just use the copy of those classes that are in the Android SDK.
If you added a dependency on something else, and it is what is requiring org.json:json, talk to the developers of the library you are trying to use and discuss with them how best to use that library on Android.

Compile, Provided, APK - Android dependency scope

While adding new dependencies to android project especially in Android Studio in Dependencies there are three scope options Compile/Provided/APK.
What are the effects of choosing each one, when should we use them ? Besides what the name says.
EDIT:
"Properly handle 'provided' and 'package' scopes to do what they should be doing.
'provided' and 'package' cannot be used with Android Libraries, and will generate an error" .. this is from http://tools.android.com/tech-docs/new-build-system

provided - compile-time only dependency
package - package-time only dependency
compile - compile-time and package-time dependency
provided is commonly used for annotation processing based libraries. Usually these libraries are separated in two artifacts - "annotation" and "compiler". "compiler" is provided dependency because you do not need to use it in application, only for compilation; and "annotation" is compile dependency - it is used in application code and therefore compiles. Or generated code may require additional dependencies while your application may not. E.g. dagger dependencies configuration:
compile 'com.squareup.dagger:dagger:1.2.2'
provided 'com.squareup.dagger:dagger-compiler:1.2.2'

These properties come from maven scopes.
They simply indicate how to treat particular dependencies during each step of build process.
compile - a default approach, it simply means that all dependencies should be available at compile-time. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects. A compile-time dependency is generally required at runtime.
package - declares additional configuration for building an application. You can list plugins that add additional functionality to the build process.
provided - it means that runtime environment has these dependencies included. For example, when you look into android.jar library internals you will see java.lang.RuntimeException: Stub! in every method body.
That has some consequences:
You can develop Android applications locally, without having complete Android environment.
Your APK you must run it on an android device or an emulator because they provide implementation of these methods.
Your apps that reference the SDK classes will build properly, because the jar provides the class metadata.
Unless you use some library that provides artifacts (e.g. Robolectric), you have to run tests on your emulator/device.
provided and package cannot be used with Android Libraries, and will generate an error.
Here is how sourceSet looks like:
More info about build system: https://www.youtube.com/watch?v=LCJAgPkpmR0
An awesome article about Gradle: http://www.sinking.in/blog/provided-scope-in-gradle/

Xavier talks here about the APK scope.
in the Android plugin, The equivalent (sort of) of runtime is called apk. You can do
dependencies {
apk files('libs/foo.jar')
}
and it'll only get packaged but won't be on the compile classpath.

With gradle 6.5.1 provided gives the below error
Could not find method provided() for arguments [directory '....'] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
I used compileOnly to use the dependencies at only compile time and not to inlcude in the final build artifact

Gradle transitive dependency to JAR inside of a library module

I'm migrating an Android multi-module project from Ant to Gradle.
We have some jars in the repo in the libs directory of a library module.
The dependency is as follows:
AppModule depends on LibModule.
The code in AppModule cannot access contents of the library jar that is in LibModule.
Although it can access from-source classes of LibModule (proving that the dependency in general is established).
Gradle documentation says, that all dependencies are transitive by default, but this experience seems to invalidate such claim. Is this a bug or is there some legitimate reason?
I've managed to hack it by adding a workaround dependency in AppModule:
compile fileTree(dir: '../LibModule/libs', include: ['*.jar']) // HACK!
But there should be a more DRY way to do this, right?
Gradle version: 2.1.
Interestingly, Android Studio appears to respect the transitiveness of the jar and does not signal an error.
The error occurs when I'm building using
./gradlew assembleDebug
Thy typical java error is signalled:
error: package net.jcip.annotations does not exist
import net.jcip.annotations.NotThreadSafe;
^
I know I can also specify deps in a maven-ish style, but we would like to be able to work with jars-in-the-repo as well, for our purposes.
TIA, Karol