When using lein install or e.g. boot pom jar install, a Clojure project is packed inside a jar and installed to the local maven repository. Which is stored as a folder structure of several jars for instance under ~/.m2
These installations are mutable, meaning a project of a specific version (e.g. 0.1.0) can be overridden by calling the same command after something has changed inside the project but without the version being changed.
When pushing to a public repository such as clojars, this is not possible. There I guess only *-SNAPSHOT versions one can override existing pushs.
Wouldn't it be desirable to have this immutability already in a local repository? Are there ways to archive this?
I run a copy of Nexus an an AWS instance for this purpose, though it woule make sense to run it on your own computer. Most of the benefits (except protection against the loss of this computer) with lower latency. The price is right as well.
Related
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.
I have two different projects using maven 3.2.5/3.0.5 (3.2.5 locally, 3.0.5 on build server). The first creates jar files needed to compile the second. Both projects will run in an environment and so my second project doesn't need to have the most current version, it just needs to them to compile against.
This seems like I'm making it way harder than it needs to be. I was using system and specifying a system path, but evidently maven feels like that is substandard structure and it quit working.
We tried using our organization's artifactory instance, but that was a disaster. Probably something in their implementation of it.
I tried creating a repository for the project, and using a file URL, but it appears when you do this, that it ignores the other repository and uses that directory exclusively.
So seriously, I just need to add a couple of jar files to the path. Isn't there a way to do this in maven?
Is it possible to make the .m2 folder in my local machine a repository so that other team members can use my repository instead of checking anywhere else and get the dependencies from mine? I have seen http://www.sonatype.org/nexus/go but there, we have to upload all dependencies manually.
Can we make .m2 folder (in some machine) a maven repository so others can use it?
The important thing with you local repository is that it's stable. If you were to put it on a shared drive, everytime one of you team builds, the artifacts that the rest of the team see will change - development being what it is, this would be a nightmare as the bugs that are introduced while developing would immediately effect the whole team rather than being isolated to one person (the assumption here is that you have multiple artifacts and build with mvn install).
The correct way to do this is to setup a repo, that proxies the public Maven repos. Both Nexus and Artifactory are setup to do this out of the box and are very easy to install on either Windows or Unix. The proxy feature means that your repo only need contain the artifacts produced by your team and the repository will retrieve other artifacts from the public Maven repos as needed (often storing them for future use).
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.
I have inherited an old project that using ant to build against weblogic.jar. I am moving this into a more modern maven based build environment and I don't want to check in weblogic.jar ( which is 34MB ) into my private artifact repository and I don't want to add it to my local repository either. I am not sure what it is using from this, the project is one monolithic code base over 500,000 lines of code.
We won't actually have Weblogic on our local development machines, we are deploying to remote virtual machines to test because of corporate network topology to get the services our application needs to talk to.
What alternative do I have to building against weblogic.jar.
Using system scope is usually considered a bad practice. However, I would say in the case of weblogic.jar, using system scope makes sense. The reason is that the the weblogic.jar does not contains all the classes provided by WLS installation. If you open weblogic.jar and take a look at the MANIFEST.MF file inside, it contains a long list of jar files in the Class-Path: entry. These jar references are all using relative path. It means that if you put the weblogic.jar into the maven repository, the relative path is broken and you need to a lot more WLS jar files into your maven repository.
The catch is that if your system-scoped dependency points to the weblogic.jar in your WLS installation, you need to standardize the WLS installation directory for all your developers. Otherwise your build is not portable in other developers' machine.
Since maven downloads everything it tries to resolve into your local repository the only way (afaik) would be wrapping the existing ant task using maven-ant-task.
Personally I would prefer to add the weblogic stuff into the maven repository.
If you don't want to put it into your local repo, you could refer to it using system-scoped dependency, in which case you'd just refer to it from your disk. I'm not sure why that would be better option, but since you asked for it, you might have a solid reason.
However assuming you don't want to use weblogic.jar at all: it's not really possible to say what alternatives to building against it you have without knowing what you need from it. That needs to be found out first. If you use weblogic-specific stuff, you do need the reference.