hawk base wrote:I tried putting the jars folder in src/main/resources but still getting the same error.
I like idea 3 most. It looks like your initial idea, but it makes an actual repository (with the necessary meta-data), instead of just a bunch of files.
Tim Holloway wrote:Perhaps you could clarify some things. Is this a personal project that only you need to build? A corporate/departmental project? An open-source project?
And while it would appear to be a stand-alone Java application and not a webapp or other specialized environment resource, could you explicitly tell us what it is?
You have JARs that are "not in Nexus". Do you mean a local Nexus repository, or are you looking at an Internet-wide public repository?
Now let's start from the ground up. If memory serves, the target command "mvn install" will build a Maven project and install it into your local Maven repository cache. So you don't need Nexus to resolve those artefacts. On the other hand, if Jenkins does the build, Jenkins has its own Maven repository cache. So to get those artefacts into that cache, you just have to make them Jenkins-managed products as well (with "install" goals), and setup Jenkins dependencies so that Jenkins will ensure that those artefacts have been built and installed before building your dependent project.
Which brings up another item. Is this copy of Jenkins something that you're running on your local machine, or is it a site-wide server? And if it's site-wide, can't you get permissions to install (via "mvn deploy") to the Nexus server? Seems like if you're expected to use the one, you should have some support for authorized use of the other as well. And incidentally, if there are versioning issues, don't forget that Nexus supports snapshot versions for development in addition to the formal versioning for official releases.