I have a project A and B. Project B uses project A as a dependency. I am publishing project A to Nexus repository when changes are tested and good to go to Nexus. However I don't want to publish project A to nexus whenever I want to test changes locally.
Is there a way to use project A's changes locally into project B without having it to be read from repository. Some condition that will make maven read project A from local rather than Nexus.
I want to keep project A in common maven dependencies rather than making changes in Maven profiles.
Maybe I am missing some obvious point but I would assume that you can just mvn install project A with a new version and adjust the dependency of A in project B to use that new version. By installing project A it should be available to be used in project B locally because it will be installed into your local Maven repository.
E.g.
In project A's pom.xml
<project>
<name>A</name>
<version>1.1.1-new-version-for-testing</version>
</project>
In project B's pom.xml
<dependencies>
<dependency>
<artifactId>A</artifactId>
<version>1.1.1-new-version-for-testing</version>
</dependency>
</dependencies>
First things first, there is a local repository on your computer that contains all the dependencies (by default in ~/.m2 but you can change that)
You can think about it as a local cache of the dependencies required to work with your own project
When you change the project A you can install the "updated" version by running mvn install on project A.
After that command project B when tested will not try to contact maven repository and will get a version of project A from your local repository.
For SNAPSHOT dependencies, maven once in a day will try to get the later version from Nexus anyway, even if you have a copy in the local repository, because working with snapshots assumes that you're OK with getting daily changes.
But then you have the following choices:
Don't work with SNAPSHOT-s at all. This is something that you shouldn't do anyway in production (I mean, when you release project B, it should contain SNAPSHOT dependencies in its pom)
When you compile project B, assuming you have all the dependencies in the local repository, use mvn <whatever> -o. This -o option means that maven should be run in offline mode, that is it won't attempt to contact a remote repository altogether. (BTW, If you want to do the opposite, which is to forcefully download all new dependencies from Nexus, you can run mvn <whatever> -U
In our company, thousands projects are build on 3 servers, with mvn commands.
A few projects occasionally pack too many jars to its WEB-INF/lib folder, the unwanted jars looks like another projects business code and its dependencies.
This is
the diff in WEB-INF/lib between right one(left) and too many jars one(right)
The jar in red frame looks like another project' jars, project name is "jd-common", and the other green jar on right is another project's dependencies.
This situation always reappeared until I clear local repository.
I guess the another project uses "mvn install" to install jars into local repository on build server, and our project is actually depend on jd-common-cached and jd-common-util only.
How can I avoid this?! Thanks for help.
First of all if the jars are there - you depend on them. You may depend on them implicitly (transitive dependencies). Run mvn dependency:tree to list all the dependencies (including transitive). You may find out that you depend on another project that in turn depends on those red/green jars.
Second, on the Build Server you don't want to share local repo with other projects. That's why, at least in Jenkins, there is an option Use Private Repository - this way all the project are going to be separated. This protects you from the situation when the artifact is not in remote repo anymore but the build is still green since that artifact is in local repo. But this has nothing to do with the problem you described.
It's finally be resolved!
The project A depend on a jar which deployed by another project B, the depend jar is a sub-module in B. (A->B)
Unfortunately：
1. A and B are packaged on the same build server
2. B's sub-module jar has the parent config in its pom.xml.
3. B use "mvn clean install -DskipTests" as the build command, so all the B's modules are installed in local repository.
Maven always package the local installed jar, and use the installed jar's pom file to find the sub dependencies, so when maven is executed, project A found that:"one of my depended jar has a parent, it's B, and all the B's sub-modules are found in local repository because of B installed all of them, I should package them all!".
Hi I am trying to port a mid sized Maven project to IntelliJ Idea 12 (from Eclipse).
There are around 30 different modules in the project.
I am running an MVN install on each module via IntelliJ lifecycle management.
The jars are being correctly generated, and deposited into my local repository directory. It is also correctly picking up the third party libraries.
However IntelliJ is sometimes requiring me to then add the generated jars to my classpath as a dependency. (It is not enough to simply say "Add Maven Dependency", I have to physically add the generated jar as a library.)
In other cases it works correctly. Not sure why it is not consistent.
Have you tried updating the local Maven repository in IntelliJ IDEA? You can do so by opening Preferences->Maven->Repositories, than select your local repository and click on 'Update'.
Occasionally maven complains that a particular dependency, which is built and packaged locally, cannot be found in the local repository while building another project that has it as a dependency. We get an error like:
Failed to execute goal on project X: Could not resolve dependencies for project X: Failure to find Y in [archiva repository] was cached in the local repository, resolution will not be reattempted until the update interval of internal has elapsed or updates are forced ->
Where X is the project being built, and Y is the supposedly missing artifact. If you look in the local repository, the artifact is there. This artifact is never installed in our archiva repository, so the problem is purely based in the local repository.
We have tried various profiles in settings.xml, and of course "mvn -U". Neither do any good, nor should they because this artifact never goes any further than the local repository.
The only two things that seem to work are to wait a very long time until maven smartens up, or to completely delete the local repository. Presumably the waiting option is related to the aforementioned update interval.
We have experienced this problem with maven 3.0.2 and 3.0.3. We are using Archiva 1.0.3 (but again this shouldn't be a factor). Any help would be greatly appreciated.
The local Maven repo tracks where artifacts originally came from using a file named "_maven.repositories" in the artifact directory. After removing it, the build worked. This answer fixed the problem for me.
As the options here didn't work for me, I'm sharing how I solved it:
My project has a parent project (with its own pom.xml) that has many children modules, one of which (A) has a dependency to another child (B). When I tried mvn package in A, it didn't work because B could not be resolved.
Executing mvn install in the parent directory did the job. After that, I could do mvn package inside of A and only then it could find B.
Even in offline mode, maven will check remote repositories if there is a _remote.repositories marker for the dependency. If you need to operate in offline mode, you may need to delete these files.
The simple shell command below deletes these marker files. This is safe to do if you only use offline mode for the machine. I would NOT do this on a machine that needs to pull files down from the web.
I have used this strategy on a build server that is disconnected from the web. We have to transfer the repository to it, delete the marker files and then run in offline mode.
On Linux / Unix you can delete the remote repository marker files this way:
cd ~/.m2
find . -name "_remote.repositories" -type f -delete
Maven remembers when it didn't find something. The key is "resolution will not be reattempted until the update interval of internal has elapsed or updates are forced ->"
The quick solution is to delete your local "repository" subdirectory for the problem artifact - assuming you have fixed the problem with it. :)
mvn -U will force update from remote repository - again, assuming you have now populated remote with said artifact.
When this happened to me, it was because I'd blindly copied my settings.xml from a template and it still had the blank <localRepository/> element. This means that there's no local repository used when resolving dependencies (though your installed artifacts do still get put in the default location). When I'd replaced that with <localRepository>${user.home}\.m2\repository</localRepository> it started working.
For *nix, that would be <localRepository>${user.home}/.m2/repository</localRepository>, I suppose.
If you have <repositories/> defined in your pom.xml apparently your local repository is ignored.
Catch all. When solutions mentioned here don't work(happend in my case), simply delete all contents from '.m2' folder/directory, and do mvn clean install.
Even I faced this issue and solved it with 2 ways:
1) In your IDE select project and clean all projects then install all the maven dependencies by right clicking on project -> go to maven and Update project dependencies select all projects at once to install the same. Once this is done run the particular project
2) Else What you can do is check in the pom.xml for the dependencies for which you are getting error and "mvn clean install" those dependent project first and the install maven dependencies of the current project in which you facing issue. By this the dependencies of the local project will be build and jars will be created.
I run to the similar problem when my new project depend on oracle jdbc jar(which I have installed in my local repository and work well for other projects). I tried -U option ,deleting .lastupdate file or the whole directory and downlaod again,but it did not work. finally,I deleted the directory and installed it locally again,it works.
One of the errors I found around Maven is when I put my settings.xml file in the wrong directory. It has to be in .m2 folder under your user home dir. Check to make sure that is in the right place (along with settings-security.xml if you are using that).
I had DependencyResolutionException in Ubuntu Linux when I've installed local artifacts via a shell script. The solution was to delete the local artifacts and install them again "manually" - calling mvn install:install-file via terminal.
This happened because I had http instead of https in this:
<repository>
<id>jcenter</id>
<name>jcenter-bintray</name>
<url>https://jcenter.bintray.com</url>
</repository>
check if if your artifact Y have packaging set to "jar". If you have defined it as "war" by error or copy paste, it will show this strange "was cached in the local repository, resolution will not be reattempted until the update interval of internal has elapsed or updates are forced". I would expect something like "artifact Y is war, jar type expected".
In my case I needed project Y to be a WAR to be deployed through Tomcat, as well as it needed to be a JAR to be able to add it as a dependency in project X.
So in project Y's pom.xml, I added this plugin to create a JAR along with the WAR:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<attachClasses>true</attachClasses>
<classesClassifier>classes</classesClassifier>
</configuration>
</plugin>
And while adding the dependency of project Y in project X's pom.xml, I had to add a classifier:
<dependency>
<groupId>groupId.of.project.Y</groupId>
<artifactId>project.Y</artifactId>
<version>1.0-SNAPSHOT</version>
<classifier>classes</classifier>
</dependency>
Note: when you build project Y, you will see 2 packagings in the target folder: project-Y.war and project-Y-classes.jar, so that's why while importing you are specifying the classes classifier to import the JAR and not the WAR.
Here is the long Solution to the problem
(Not Quick fix but will work if no other solution)
You're going to hate me for saying this but this is the truth about open source projects like eclipse. Because Open source is modular and allows you to build and develop a project in many ways with many tools such as maven, spring boot, options for xml or groovy, different eclipse updates & Etc. The problem is that eclipse allows you to run the project with missing maven builds because the IDE is smart enough to resolve dependencies using a remote_repository where it stores and catches the jar files that is not properly built on the project.
Because of this feature, You may actually have local build issues but just like DNS servers; if the solution is not found in the local directory, Eclipse will look for a solution in it's remote cached repository. When you delete the remote_repository and let Maven rebuild it a second time, The project may end up creating more errors and not build a second time or may possibly rebuild a cache that was missing. But that is unlikely.
So the long answer to fix your solution.
This is a project architecture issue!
SOLUTION:
What you need to do is look in to all your dependant project's pom.xml file and the maven dependencies folder in your local project and try to resolve all the missing dependency jars in your maven dependency folder. If you have a referenced library, I suggest moving those jars into your local project's maven dependency folder.
You have to work your way into solving every child project and then navigate into your root project and fix every single project by using Maven -> Build -> clean install (check off "skip tests" & "resolve workspace artifacts") until every project builds with a clean success.
most likely, when you force update your entire solution to all your projects, you will get a list of errors that you have the IDE auto-resolve. The auto-resolve will refer to a easy reference to fix the issue. But to deploy, you have to manually fix the project because Eclipse, Spring & Maven will work well together but there are maybe a few things they don't agree on. So, you have to play diplomat in those situations and figure it out.
That's the sad truth.
All said, I have a list of problems in my project. I have this issue. The war file generated has empty jar folders and the build is not clean without errors unless i force it. The WAR file generate will run a 404 error on tomcat server production and my angular application will throw a Cors-Error when executing the API.
All the errors on my front end project is artificial because the root of all issues is the WAR file generated. It did not generate with dependencies, the Main project did not execute in tomcat and tomcat server cannot run the spring initializer to deploy the cors-policy on the server to allow my angular application to communicate. But all in all, development environment works fine with no issues.
So that is my long ended solution for this thread.
I had the same error from a different cause: I'd created a starter POM containing our "good practice" dependencies, and built & installed it locally to test it. I could "see" it in the repo, but a project that used it got the above error. What I'd done was set the starter POM to pom, so there was no JAR. Maven was quite correct that it wasn't in Nexus -- but I wasn't expecting it to be, so the error was, ummm, unhelpful. Changing the starter POM to normal packaging & reinstalling fixed the issue.
In my case I had to add mavenLocal() in root level gradle dependency
mavenCentral()
mavenLocal()
Main Goal: deploy a project as jar and eclipse-plugin
current state: project builds fine as jar package
Now i want to create a second project which wraps the jar project as eclipse plugin
use tycho-maven-plugin to create eclipse-plugin
add the jar of the original project (with copy-dependency)
add an Activator
export packages from jar
create correct MANIFEST.MF
i tried to copy the jar with copy-dependencies bound to create-resources. This works as long the jar is found in repository, but the local project gets ignored.
This results in a build failure since the jar is not found.
Is it possible to tell copy-dependencies to take the jar from the target directory of the project? Or should i use some other method than using tycho?
Edit:
I solved my problem with 4 projects:
normal project (nothing special here)
the wrapper project using tycho maven and copy-dependencies.
bound copy dependencies to some goal before compile (e.g. generate-resources). Excluded all artefactid which were set as dependency in the MANIFEST.MF.
a prepare project, which calls the normal project and installs it into the repo. This is needed because the tycho-maven-plugin is bound to validate and it is not possible to call the exec plugin beforehand (at least not easy).
a multi module project which calls the prepare project before the wrapper project.
Build your local project (which artifact was missed) with "mvm install". It will be deployed in your local repository ($USER_HOME$/.m2/repositories). After this dependency should be resolved.
Alternatively you can "mvn deploy" if you have local company maven repository like Artifactory or Nexus.