I searched a lot in apache documentation and ibiblio.org and I could not find a decent straight answer.
My questions:
When I download a jar using maven dependency (setup in pom), how can I be sure that the file does not change on the remote repository? for example, if I'm using log4j version 1.2.3, downloaded from ibiblio.org (or any other repo for that matter), how can I be sure I'm getting the exact same jar each time?
Does maven delete jars from the local repository? let's assume I'm not clearing the repository at all, will it fill up eventually? or does maven have some kind of mechanism to clear old jars?
In Maven conventions a released version like log4j 1.2.3 will never be changed. It will be left in your locale repository until you manually delete it. It can't be changed by anyone except for the admins on maven central, but i suppose they don't do such a stupid thing.
Furthermore the download by default is done from maven central (repo1.maven.org/maven2 instead of ibiblio).
One of the "tricks" in Maven is download an artifact (released) only once...that improved your build performance in contradiction to the SNAPSHOT dependencies.
You could configure your own repository, and point all your project poms at that. It's easy to configure your poms to use a different (private) repository, but I've never set one up myself. Doesn't seem too hard, other than managing it to keep all the needed artifacts available.
Related
Are https://mvnrepository.com/repos/central and http://central.maven.org/maven2/ the same maven repository (called Maven Central)?
Also there is https://repo.maven.apache.org/maven2/ which also calles itself a Central Repository.
I use mvnrepository.com as I find it more convenient, but many referencies to Maven Central in Internet lead to http://central.maven.org
Besides both sites above are for Maven2, right?
What are the analogues for Maven3?
Besides is Maven3 widely used?
As far as I know, mvnrepository is just a search site that is not maintained by the maven people directly. It's a search site as I see it. It has been around for a while. Since it contains multiple repository source to search in and lets you select which one you work with its pretty transparent and I don't see any harm there.
If you execute mvn help:effective-settings you should be able to determine what repositories are used, in case some changes where made. The current central default in maven seems to be https://repo.maven.apache.org/maven2/ - the official search interface being https://search.maven.org/
You can also look into the maven sources of the pom what config you running on.
The /maven2/ part in the Uri only means what repository format is used within. This has not changed for maven 3 (it was different for maven 1). So it's the correct and current one today, there is no maven 3 repository format. Everything new could be added to the maven 2 format (for example some search index files or checksum files).
As we just migrated all projects to maven projects, one question came up and I couldn't find any suitable solutions yet.
What if maven shuts down forever or just one artifact is not available anymore? Or what if some versions are not available anymore, and the software cannot run with the newer ones?
Since we're not hosting a copy of the artifacts locally, should we host copies of every jar somewhere for such a scenario?
Thanks
Unlikely, but if you build your artifacts with Maven, you already have a copy of each relevant artifact - in your local repository. If you backup it from time to time, you have the necessary level of security.
Alternatively, use a company repository manager (Nexus/Artifactory) to proxy MavenCentral. It will also keep copies of the used artifacts.
In a project with an online dependency management done by ivy/maven, is it good practice to back-up the artifacts e.g. by including them in the projects source code / version control (e.g. svn, git) or is it (safe) enough to so so with pom.xml / ivy.xml? Of course, having the artifacts not backed up somehow makes the project totaly depend on the availability of the maven repo.
EDIT:
The reason for my question is that I fear that certain artifacts are no longer available on the official maven repository, or even that the repository itself is down. In such a case, having the libs under version control gives the security to be able to build the project in such a case.
My advice is not to backup the artifacts . if the artifact is not available , then you should consider it to change with replacement however I see very rare possibility of this to happen . Any way , you can always get old artifact JAR from your previous build for the scenario when we do't have any option and you have to use old artifact So i will not suggest to keep separate backup .
thanks ..
i'm using Intellij IDEA 12.1.6, almost everyone in my company use Eclipse and dont notice my problem. We have a local nexus repository where we deploy artifacts, but some of them are systematically created with an invalid maven-metadata.xml (the latest snapshot timestamp and build number does not match the effective artifact name on repo) and intellij ends up telling me those libraries have broken classpath.
Is there a way to force intellij on hooking the maven jars on my local repository without worrying about those metadata additional information? Eg eclipse hook the jar in his classpath taking the version which does not include those data (in my m2 repo dir i see both 2 jars downloaded, the one with full data and the other one without them)
eg.
library-0.0.6-SNAPSHOT.jar
library-0.0.6-SNAPSHOT-20131028.111135-10.jar
Thank you for your help.
If Importing the eclipse project did not work. You should be able to Configure the library contents . The step for Configure Library Dialog should allow you to point the library to a different location.
I have a following problem. We have a central maven repository hosted on our company server. Our team is working on a project. Everyone here uses that repository to get the required artifacts. If something is missing at the moment and is required for the task that the developer is currently dealing with, he installs this artifact manually to the central repository, so that his commits don't break the automated builds.
Now, each developer also has Glassfish v2 installed on his machine. That is for testing and debugging purposes. Before committing the changes, developer makes the .ear for the project with Maven help. However, after the developer deploys the ear to it's local glassfish, frequent errors arise, because the set of glassfish libraries may not contain all the latest dependencies of the central company repository.
Right now in case of the error the developer simply reads the log and looks what exactly is missing. After that he manually copies the required jar inside his local $GLASSFISH_HOME$/lib dir. But that seems a little bit frustrating. How can this be done automatically?
Right now we are trying to implement the following solution. The developer has to synchronize his local maven repository gathering all the artifacts from the central one that are required by the project. This local repository has to be placed on the java classpath, so that glassfish would also see it. Is that a correct approach? Maybe there is a way to install directly all the required artifacts from the central repository inside $GLASSFISH_HOME$/dir and this can be done automatically during deploy?
About having to install dependencies. If the developers need to install dependencies missing from public maven repositories, take into account that usually maven proxies have the ability to cache public repos. For instance, archiva has a proxying cache. If the dependencies are your own project deliverables you should consider releasing and deploying with maven to your company repo.
About latest versions. You need to specify maven what version of dependencies should use. I would prefer editing my poms manually, anyway there's a variety of ways to achieve that.
The libraries should be part of the project, I think. If not standard libraries of glassfish, they should be included, for instance, in your war file as part of your project. If not standard but not part of your project (not the regular approach) consider managing this glassfish as a project on its own (own git/svn repo, own pom, own versions, own everything).
Good luck.