I am trying to build a project using Maven but I don't know Maven.
Anyway I had a problem and I found in a link to use an older version of Maven. So I did, since the instructions for the project were about 2.0.9 anyway.
But now I am not sure how to proceed. I see under my user.home directory a .m2 folder with a repository directory.
Should I delete this or not?
The .m2 folder contains the downloaded artifacts and some other repository info, which do not depend on the used maven version. So you dont need to delete anything, just use the maven binary of your choice.
EDIT: the contents of the artifacts - .jars, .poms, .boms etc. are defined by the artifacts themselves which are the accesible through repositories/catalogues. The .pom of your project references the needed artifacts. The maven binary downloads the artifacts (and does many other things which are OT here) to your local cache - the .m2 directory. The point is, no matter what version of the maven binary you use, the artifacts remain the same.
You surely can delete your repository. As long as you have an internet connection maven will simply download the artifacts again. But there is nothing to be gained by the removal except a longer initial build time and some traffic.
Sometimes it does make sence to delete certain metadata from the repo, like the .lastUpdated files. It is only advisable if maven is unable to find a dependency which you know for sure is in your repository. You can then run find ./ -name "*.lastUpdated" -exec rm {} \;.
Related
I have local Maven repository in C:\Users\<User_Name>\.m2 directory. After getting "java.lang.NoSuchMethodError..." exception and navigating problem on the web, I see this page mentioning to remove unused jar version(s) from local repository.
My questions are:
1. When I look at C:\Users\<User_Name>\.m2\repository\org\mockito\mockito-core folder, there are 52 different version folder. I think it is similar for other jar libraries. So, should we clean unused jars periodically? Or should we keep unused versions of a jar library?
2. If I just have 3.0.0 version of mockito-core in my pom.xml, how the app use or mix another version(s) in the local repository? Normally, if I just a single mockito-core dependency in my pom.xml, may there be any problem as mentioned on that page (solving the problem after removing other jar version)?
1)
You do not need to "clean unused jars" from your local maven repo manually. How do you want to decide which jar, which version is unused? Maybe your next project will use the jar that you want to delete. Who knows.
If you have enough disk space then you can leave your local maven repo directory untouched for years. If this directory grows too big, then I suggest you delete the complete .m2 folder. Then the next time when you build a project, Maven will download automatically all dependencies that your project needs.
There is only one use-case when deleting your local maven repo can cause a headache: if you have installed some custom jars manually.
2)
It is highly possible that the different dependency versions that you see in your local Maven repo directory come from different projects that you built earlier.
Anyway, you can display your effective pon with the Apache Maven Help Plugin.
I am using Maven in my project, and for some reasons, some additional jars should be added manually (I have followed the step like Correct way to add external jars (lib/*.jar) to an IntelliJ IDEA project).
The package can be imported successfully. However, the compilation error happens, which indicates the package does not exist and cannot find the symbol of the used object.
I have tried the following tips but it remain unchanged:
Invalid caches / restarts
reimport
delete .idea file and .iml file
The scenario is quit similar to this one : https://intellij-support.jetbrains.com/hc/en-us/community/posts/206821195--beginner-question-including-external-jar-compile-error.
Please see the following sample images. It may run successfully but cannot be compiled well.
The reason is that when you add a library manually via IntelliJ, only IntelliJ knows about them and when you compile your code using Maven, it can't be find by Maven because Maven only searches for dependencies you defined in pom.xml.
You should install your libraries in your (at least) local maven repository and add them as a normal dependency in your pom.xml. Then you don't need to add them manually in IntelliJ.
You should follow the steps mentioned at Guide to installing 3rd party JARs
Update:
Also you should note that if you're working as a team, you should install this on the local maven repository of all developers (which is not practical). The best solution is to install a Maven repository (e.g. Nexus, Artifactory or Archiva) in a server on your local network and upload your private jar files on those servers. Then all developers can define the address of the local Maven repository server in their local Maven settings and use artifacts/libraries from that servers. Plus it works as a local cache/proxy to fetch any Maven artifacts and prevents unnecessary calls to public maven repositories.
When creating spring-boot projects by using start.spring.io, some maven wrapper files get included:
mvnw
mvnw.bat
Should these files be ignored when committing to a git repo?
A mvnw Maven wrapper script allows you to run a Maven command without having Maven installed and present on your PATH. It does by looking for Maven on your PATH and, if not found, it downloads and installs Maven in a default location (your user home directory, IIRC).
They are a convenience but they are not necessarily part of your project, not in the same way as your project code and configuration is. In other words:
Any given mnvw file could be used for multiple, unrelated projects
A mnvw file will almost certainly not be different from one version of your project to another
On this basis you could make a case for not committing mvnw to your code repository.
However, including a mvnw script in your repo does have these benefits:
Allows anyone who clones / checks-out your repo to build your project without having to install Maven first.
Ensures that the version of Maven in use is the version with which your project is compatible.
On this basis you could make a case for committing mvnw to your code repository.
So, there are pros and cons on both sides. Just choose the side which best fits the needs of those who will use your repo. Either:
Include something in your readme which makes clear that (a) Maven is a prerequisite and (b) which version of Maven is required.
... or:
Include a mvnw script.
It depends, if you want to use the Maven wrapper or not. If not, then you can delete those files. If you want to use it, then you have to commit the files in the repository, otherwise it doesn't make sense to use it.
We have a git project that has some 3rd party jars which are not available in any Maven repo and are in a "lib" folder in the project. I need to include them for compiling, building and then package them into the WAR in WEB-INF/lib.
I cannot add them as a local maven repo from the command line because this projects needs to be buildable for anyone cloning the repo without requiring them to run extra commands (I have no way around this requirement).
I saw some people suggesting System scope but that then Maven won't package them into your WAR:
<dependency>
<groupId>com.roufid.tutorials</groupId>
<artifactId>example-app</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/yourJar.jar</systemPath>
</dependency>
How do I get these jars to be used for compiling/inspection, building and then packaged into the WAR?
You can use :
System scope but make the packaging yourself via assembly plugin
A maven repo along with your project (i.e. maven repo on-the-fly, basically same as local repo but without having a extra moving part to worry about because this repo follows your project).
For Maven repo on-the-fly option, you can do as described here (which is, take any already existing Maven repo, which already contains your needed jars, such as your local one, put it in your project, and then reference this repo from your project using relative paths).
I'll assume you've verified that whatever mechanism you might use to distribute these jars would be in compliance with the relevant licenses. If it would, then it seems there would be little reason for the jars' creators not to provide for official Maven distribution, so your best option might be to lobby for them to do that. But if not, and yet for some reason they'll allow for you distributing the jar (either through cloning of your repo, or via a separate Maven repo you maintain):
There are several ways. I give preference to approaches that don't put the jars in the git repo.
Publish a Maven Repo
So it's possible to host a public-facing repo and serve the artifacts that way. The pom can add your public-facing repo to the build, so that those who clone can build without having to run any special commands.
Running your own repo isn't terribly difficult. The OSS versions of Nexus or Artifactory jFrog would probably be perfectly capable.
But, if we're assuming the authors' refusal to publish their own jars via Maven means they don't want them distributed that way, then there's no reason to spend much time on the details of this option. So moving on...
Distribution in the Git Repo
I guess this is what you're doing, though again if Maven distribution violates the license I'd make sure you're splitting hairs the right way in thinking that this doesn't.
So the question would be how to get Maven to deal with the artifacts distributed in this way, and again there are some options.
Your objection to putting the jars in the local repo is that it would require extra commands of the user; but actually this could be automated in the "validate" phase of the build. Binding install:install-file to the validate phase should work.
Alternately, your objection to using system scope is that the file isn't copied into the final war. You might be able to use the dependency plugin to force the issue, but I'm not sure of that. What I am sure of is you could treat the directory containing the jars as a web resource with suitable configuration in the war plugin. (You'd want it to be treated as unfiltered and to map to the WEB-INF/lib folder.)
In any case, if you distribute jars (or other large binaries) in the git repo, I strongly recommend you look at git lfs. This will require one-time configuration by each of your users, but it will prevent your repo from gradually becoming bloated and unusable.
Use forward slash (/) to backslash () in the systemPath.
<dependency>
<groupId>com.roufid.tutorials</groupId>`enter code here`
<artifactId>example-app</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}\lib\yourJar.jar</systemPath>
I am on Netbeans and don't know Maven much. Whenever I import, open some Maven project, it starts donwloading something from some central repository, sometimes huge. It downloads things in .m2\repository.cache\m2e. I have limited bandwidth and don't want this. How to stop this?
I have set Options>Java>Maven>Dependency Download Strategy to never. Also tried mvn -o install and mvn -o for offline. Not solved.
The Maven way is to get you what the project says it needs, but you have not already downloaded to your local repository.
The huge file is the list of what is actually available in Maven Central, and for some reason unknown to me it is downloaded on a regular basis. If you do it once, it should be kept for future sessions.
Maven will download all the dependency only once to the local repository and not again and again.
Weather you have limited or unlimited bandwidth you have to download it to execute your project.
Maven has a very modular architecture. That means the the thing you get when you download the Maven distribution is in reality small core functionality.
The rest is downloaded from a Maven artifact repository, like Maven Central (which is the default repo).
Note that this applies not only for dependencies (the library your project uses), but also your plugins (i.e. the stuff that compiles, packages, and otherwise builds the projects). Hence the large number of downloads.
Like the other answers said, if you don't delete your local repository it should eventually contain all the artifacts (dependencies and plugins) you need without re-downloading. The only exception are SNAPHSOT dependencies which can get re-downloaded periodically, depending what's in your POM and settings.
Ultimately, you have two possibilities:
If you have access to a higher-bandwith connection somewhere, you can build the projects while using it, and your local repo will still store the needed artifacts.
If you have several computers/configurations behind a local network, you can set up a Maven repository manager, like Nexus or Artifactory, and use it as a local mirror. Note that those still need to download the artifacts at first as well.
But there isn't much else you can do. "Maven downloading the Internet" is, unfortunately in your case, by design.