Develop Reference

How to list all dependencies of a package from maven (including scopes)

I have a graph with 40K artifacts and I can list all possible dependencies of a package (I do so by parsing a list of effective poms)
For example, I have the following for this package:
There's 2 dependencies without taking in mind different versions.
I would like to show that this results are valid by showing that maven also lists these dependencies for this package. But when I use mvn dependency:tree after I add the com.google.guava:guava:14.0.1, I get no dependencies listed.
This is the pom file of the package:
It clearly has those 2 dependencies, but their scopes are provided. Even if I use -Dinclude=provided or -Dscope=provided as a parameter, I still cannot list them.
So, how do I list all dependencies of a package no matter the scope used?

Use Analyze Dependencies... action in the Maven tool window:
It will show the list of dependencies in the project with their scopes and usages in project:

Scope provided means it's provided at runtime, which implies that it's not a package dependency:
A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath. It is not transitive.

How do I setup springframework on gradle with only using local directories as repositories?

I'm new to both using gradle and springframework.
How can I use springframework as a gradle plugin without using any external repositories (including a local maven repository.)? i.e. just use dowloaded springframework files, place them on my local directory and tell gradle to reference to them instead.

You may be looking for Flat directory repository:
Some projects might prefer to store dependencies on a shared drive or
as part of the project source code instead of a binary repository
product.
As an example, in the build.gradle add:
repositories {
flatDir {
dirs 'lib'
}
flatDir {
dirs 'lib1', 'lib2'
}
}
This adds repositories which look into one or more directories for
finding dependencies. Note that this type of repository does not
support any meta-data formats like Ivy XML or Maven POM files.
Instead, Gradle will dynamically generate a module descriptor (without
any dependency information) based on the presence of artifacts.
However, as Gradle prefers to use modules whose descriptor has been
created from real meta-data rather than being generated, flat
directory repositories cannot be used to override artifacts with real
meta-data from other repositories. For example, if Gradle finds only
jmxri-1.2.1.jar in a flat directory repository, but jmxri-1.2.1.pom in
another repository that supports meta-data, it will use the second
repository to provide the module.

verify maven managed dependencies

maven allows you to define in pom file:
(A) dependencies -> the actual direct dependencies of the project
(B) dependencyManagement/dependencies -> managed dependencies that affect dependencies of category (A) with undefined version and transitive dependencies.
If I put wrong/unknown artifact on category A - maven will surely fail.
If I put wrong/unknown artifact on category B - maven will fail only if it affects category A (for instance, A defines dep on foo:bar and B defines dep on foo:bar:<unknown-version>.
I wonder if there is any existing plugin that will allow me to verify all managed deps (category B) - make sure they actually exist.
I have 1 global pom project with deps management that serves multiple projects and I want to verify any change to the deps in the CI before uploading new version to remote repository

In maven dependency plugin there is goal dependency:analyze-dep-mgt. You may use it to check dependencies in dependencyManagement section of your pom.xml.
If you need deeper control or more functionality, options would be to create your own plugin or have a dummy project which would use all your managed dependencies (although I should say this is a cumbersome solution).

What happens to a dependency defined in a root project in a subproject in gradle?

I have a gradle project with several subprojects. I have defined several dependencies with version numbers in the root project but not all subprojects use all of these dependencies.
root
- build.gradle
- compile 'math:math:1.0.0'
- settings.gradle
- include 'messages'
- include 'message-handler'
\ messages
- build.gradle
- //no math
\ message-handler
- build.gradle
- compile 'math:math'
Will my artifact of the messages project contain a dependency on the math library?
In other words, if I make a separate project that depends on the messages artifact from a nexus repository, would my dependency tree show the math library for this new project?

Yes - your messages project artifact will contain a dependency on the math library.
According to Gradle Documentation:
For most multi-project builds, there is some configuration which is
common to all projects. In our sample, we will define this common
configuration in the root project, using a technique called
configuration injection. Here, the root project is like a container
and the subprojects method iterates over the elements of this
container - the projects in this instance - and injects the specified
configuration
In other words, every configuration which is included in the root project will hold for all the sub-projects.

How can I force maven to leave the version number out of dependency file names?

I'm using maven to build a ".ear" project that resolves dependencies from a maven repository, and then packages them into an ear (that's probably a redundant sentence...).
When the dependencies show up in the ear file, they're named according to this format:
<artifactId>-<version>.<type>
I'd like them to be named:
<artifactId>.<type>
Can someone point me in the right direction?

If you're using the maven-assembly-plugin to build your ear, you can use the outputFileNameMapping property in your descriptor: http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet
However, you're probably better off using the maven-ear-plugin, in which case you can customize the bundleFileName, as described here.

Set the finalName property. See http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html for more details