The modules that actually use an artifact carried in the in-project repository can declare a dependency on the “lib” module, ensuring that the needed artifact will be present in the local repository prior to the module’s build. That module contains all the artifacts in its “lib” folder and declares them as dependencies, so that the local Maven repository is populated during the build of the module. One approach to deal with that is to declare the “lib” repository in a separate module dedicated to the in-project repository. Where to put arftifacts depends on the build order: the first module that needs an artifact has to contain it in the “lib” folder figuring this out is tedious – and empty “lib” folders left around by the build are not pretty ? Artifacts are being looked up in the “lib” folder under each module.
Modulesįor multi-module projects, a “lib” repository declared in the parent POM is inherited by each module. With Maven 3, “legacy” layout is going away, so the default layout has to be used. Sub-directory “java-sources” is needed only if you want to publish the sources. That means that under lib directory there are directories for each groupId that you need: It is somewhat simpler to use the Maven1 repository layout. Mvn install:install-file -Dfile=myArtifact.jar -DgroupId=x.y.z -DartifactId=$ -Dpackaging=jar -DgeneratePom=trueĪnd then copy resulting files from the local repository into the in-project one. Install the artifact in the local repository with This structure can be created manually – or using Maven itself, thus reducing the risk of typos (thank you + vmp for the idea and + Jeremy for the generatePom tip!): SHA1 checksums are not necessary either – if you indicate in the repository definition (see below) that they should be ignored. But if you do not have them, Maven will attempt to retrieve the POMs from the other repositories (including central) for each build. POMs for in-project dependency artifacts are not, strictly speaking, necessary. (Above assumes that you want to turn off the SHA1 checksum checking for your in-project repository.)
To embed a Maven repository in the project:Ĭreate a subdirectory “lib” in the project directory.ĭefine this subdirectory as a repository in the project’s POM: (Also, if your in-project dependency is needed only for tests, there is no way to specify a “test” scope for it…) Unfortunately, system-scoped dependencies break the transitive dependency resolution of Maven. It is possible to describe in-project dependencies using “system” scope and URL that references a jar co-located with the project. (Actually, a repository manager should be used even when all artifacts are available in public repositories, but that is a different story :)).īut what if this is not an option? What if – for political or technical reasons – you really need to carry some dependencies with your project? How do you do it? The “system scope” attempt
One solution to such problems is to run an instance of (Nexus) repository manager, upload the missing artifacts there and configure it in you project’s POM.