Develop Reference

How to make my dependency available to other developers?

I recently created my own API in maven, and I need to make the dependency available to others. I have tried using the dependency in another project, but it can't find it. What do I need to do in order to publish it?
My dependency:
<dependency>
<groupId>org.dec4234</groupId>
<artifactId>JavaDestinyAPI</artifactId>
<version>1.0</version>
</dependency>
Available on GitHub

You need to upload your library to a Maven repository. By default, every Maven project uses the Maven Central repository - which contains copies of most common publicly available libraries that you are probably used to using by just putting an entry in the <dependencies> section of your pom.xml.
Here is a guide to uploading a library to Maven Central - https://central.sonatype.org/pages/ossrh-guide.html. I've personally used it previously and whilst it does take some work, its probably your best option.
You can also host your own Maven repository, but I'll leave detailing that route to someone else's answer.

Maven BOM [Bill Of Materials] Dependency

I am not understanding what is the purpose of bom object? and I am working on Spring 3.2.8 version and with JBoss server, so which bom dependency I need to use? When I mention the following dependency in pom.xml:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.0.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Does the jar file gets downloaded into my Maven Dependencies?

What is the purpose of bom object?
Maven parent-child relationship is very handy for managing dependencies of multiple projects in a single place. However, Maven projects can have only one (direct) parent. So imports were introduced for dependency management to allow using several projects for managing your dependencies. With an import you can define a single dependency like this and get multiple dependencies managed - handy! Although you could import any project, BOM is a special project designed to be used for imports like this. Usually a BOM project will have very little defined besides dependencyManagement section, and will not have any unrelated dependencies, to avoid affecting your main project too much.
Which bom dependency I need to use?
BOM is not a requirement, you don't need to use either. Instead, you could define all managed dependencies in dependencyManagement section yourself. These can include Spring, JBoss and any other dependencies. BOM, however, simplifies this for you significantly. You can add as many BOMs as you want, so add both! But as #Jesper mentions, don't forget to use correct versions. When using multiple BOMs their order will matter if they both reference a common dependency.
Does the jar file gets downloaded into my Maven Dependencies?
Notice BOM is <type>pom</type>, not the default jar. So there's no jar to be downloaded. A single pom.xml file will be downloaded and read by Maven.

Atlassian's Confluence and Maven's POM config

I have to write a plug-in for Atlassian Confluence by using Atlassian SDK and and Java's SDK v8 on Eclipse IDE. Apache Maven (3.2.1) comes with Atlassian SDK which I have to use it from there (because there are a couple of dependencies that are shipped with the sdk that are not available in a maven repository); so I set the environment variables to point in there. Although, the POM file that I have to use comes with errors.
For example:
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.2.2-atlassian-1</version> <!-- 2.2.2 -->
</dependency>
<dependency>
<groupId>com.atlassian.confluence</groupId>
<artifactId>confluence</artifactId>
<version>${confluence.version}</version>
</dependency>
On both dependencies it says, missing artifact, e.g.,
Missing artifact com.atlassian.confluence:confluence:jar:5.8.10
Although, in both cases, for example:
com.google.code.gson
the jar file at m2 actualy exists, yet the error at the POM file notifies that the artifact is missing.
I tried the atlas-mvn clean package, even after wiping the m2 repository explicitelly, and rerunning that command though it did not resolve the problems.
Did any body come across such a problem?

I needed to take each the *.repositories file under specific artifact dir (which causes problems), and perform following modifications, for example:
maven-confluence-plugin-6.2.2.jar>atlassian-public=
Needs to appear in the following format:
maven-confluence-plugin-6.2.2.jar>=
And it's done!

Websphere maven dependencies

I want to create bean which will integrate with WOLA (integration with COBOL).
In order to do so I need annotate bean by #RemoteHome(com.ibm.websphere.ola.ExecuteHome.class). However this is IBM artifact which should reside in ola_apis.jar.
Do you know how can I resolve this dependency? How to add it to pom? I'm searching for some IBM repository but cannot find any.
My understanding is that for creating EAR for Websphere I should be able to create simple maven project in Netbeans.

IBM provides the APIs required for the Liberty profile in an IBM hosted maven repository. The maven repository is here. Once your maven can find this repository for the WOLA API you would want to use the following in your pom:
<dependency>
<groupId>com.ibm.websphere.appserver.api</groupId>
<artifactId>com.ibm.websphere.appserver.api.zosLocalAdapters</artifactId>
<version>1.0.0</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
Technically these are the Liberty profile APIs, but in this case they APIs are common between liberty profile and full profile so there shouldn't be a problem using it.

You can either include the dependency as system scope in your POM (however, this is not recommended), or you take the JAR file and upload it in a custom Maven repository within your company (or at least install it in your local repository). You can choose the group and artifact id as you want, when you do that.
Since those JARs are part of WebSphere, which has a proprietary license, there is no public Maven repository, where you could download it.

Maven dependency within dependency with different scope

Say I have two Maven dependencies defined in a project like below.
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.3.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>mycompany.library</groupId>
<artifactId>mylibrary</artifactId>
<version>1.0.1</version>
<scope>compile</scope>
</dependency>
Then, within mylibrary, I also have a dependency defined as below.
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.3.1</version>
<scope>compile</scope>
</dependency>
When I package my project, I don't see xstream packaged within it. I think the project's xstream dependency scope, 'test' is overriding the mylibrary's xstream dependency scope, 'compile'.
In this kind of situation, what's the best way to include the xstream for the whole project so the submodule can have access to it when packaged within the project?
I've read Apache Maven website's explanation on Transitive dependencies, but I'm struggling to understand what it means, and also to find out the best practice in this situation.

This feels really odd to me, and if it's "feature", I think it is a really dangerous one.
Anyway, it's not a Maven bug and it's in the maven documentation here.
Regarding best practices on this issue, I haven't heard of any, but the safest way to proceed ought to be to entirely remove xstream from your pom, relying on the transitive dependency. Doing this will result in a build failure if the dependency to mylibrary is removed. This will act as a notification to you that you need to fix something. You won't silently loose required dependencies, and you won't silently have dependencies you no longer need.
On a side note, mvn dependency:analyze can be used to check for dependencies that are included but not used.

As mattb's answer says, declaring the dependency as test scope overrides the transitive compile-scoped dependency declaration, and as a result the dependency is not included in your packaged war.
If you only need the dependency in your tests because 'mylibrary' needs it to execute, you shouldn't declare the dependency at all in your project's pom. Let the transitive dependency resolution process handle it.
If your project does use the xstream jar directly, you can still rely on the transitive dependency, as you will need a compatible version for your project and 'mylibrary' to both run against the xstream jar. You should have unit tests that exercise the functionality, and if mylibrary changes version of xstream to an incompatible version, your builds should fail, and you can address the issue at that point.
In general I'd say you should try to avoid declaring dependency versions directly in multi-module projects. I declare the versions in a dependencyManagement section of a parent POM so that the child need only declare the groupId/artifactId. Alternatively, from Maven 2.0.9 onwards there is an additional dependency scope of import:
This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM's section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
So using import scope you can define your common dependency versions in a single POM, import the dependencies of that POM into your dependencyManagement section, and just declare the groupId/artifactId of the dependency in your other POMs.

By declaring your own dependency on xstream, and setting the scope to test, you are overriding the dependencies declared by mylibrary.
This is actually a Maven feature - it allows you to do things such as depend on a later version of a transitive dependency within your own project, and not end up packaging two different versions of the same artifact. For example, you might depend on version 1.2.15 of log4j, but because you also use libraryX which depends on log4j-1.2.14 - you wouldn't want both log4j-1.2.15 and log4j-1.2.14 to be packaged with your project.
If you actually want xstream to be packaged within your project, you should not be declaring the scope as test. In fact if you remove your listed dependency on xstream, things will work out as you like, since mylibrary has a compile dependency on it..

If you want it packaged, why are you declaring scope? If it is required at compile and execution time, shouldn't you leave the scope blank? If you did that, then you would only need
<dependency>
<groupId>mycompany.modules</groupId>
<artifactId>submodule</artifactId>
<version>1.0.1</version>
</dependency>
in your pom. Unless there is a reason to descope it during compile but not during packaging?