I guess the title says it all. There is a debate at our firm, weather we should deploy internal jars, which are only going to be used in one specific project, to Nexus or is there any better solution? The argument for not deploying it to Nexus is that it will not be reused so there is no point in having it there.

3 Answers 3


The jar exists. Its out there. Trying to ignore that reality by sticking it in a lib directory as a binary leads to problems down the road.

Now, if you've got Nexus, you've got Maven. This jar is a dependency of the project. If you are putting the jar in a path and bypassing maven, you are going to find that you are fighting against the tool itself which will lead to problems.

In particular, the biggest problem you will encounter is that it means the jar will be difficult to update. You've checked in a binary into that application's source tree. This means that if you need to update the jar with a new value for something, you need to build the jar, copy it to the proper spot, check that in too. Woe if you ever find that you need another dependency for the jar (which then becomes a dependency to the application).

If the jar is 'only used in one spot', why is it even a separate library? Why isn't it part of the class structure of that application instead? Building the jar and then copying the jar into the lib path of the application seems like a lot of work.

Instead, having the jar deployed to nexus means that the jar is also part of Maven's structure. It has its dependencies. It has its version. It can be snapshotted to work with. It has its plugins to build. In short, when you work with the tool, the toolchain ideally supports and aides you to make it easier. When you try to bypass the toolchain, you get specific setups that become fragile and possibly harder to test and deploy consistently.

Put the jar in maven. Deploy the jar to nexus and have it be part of the dependencies. It will make source control easier and builds easier.


You are reusing it everytime you compile the one specific project from a cleanly installed machine (i.e. one that does not have the jar in its .m2 repo). Keeping it in Nexus makes sure it's available when you need it.

  • 2
    Also every time that the JAR gets updated. The alternative being that every team member recompiles on every update.
    – kdgregory
    Oct 29, 2014 at 11:47
  • If jar would be held inside a projects classpath (like in WEB-INF/lib) that wouldn't be the case? It would be available to all, since they would check it out of repository...
    – Mougli
    Oct 29, 2014 at 11:59

Unless you have powers we're not aware of, all you really know is that you're not planning on reusing that jar. The whole point of object-oriented development is re-use. Even if you don't have a case where another application could use that jar, and can't think of one right now, doesn't mean that there will never come a time where that code wouldn't come in handy in another application. If it's useful in 1 app, it could be useful in another, so go ahead and deploy it to Nexus.

Anything that should never be used outside of a specific project should be in that project and not a separate jar. The fact that this code is in its own jar file implies that you thought it could be useful to something else, which should answer the "to deploy to Nexus or not to deploy to Nexus" question for you.

Not the answer you're looking for? Browse other questions tagged or ask your own question.