Archiva / Maven as corporate repository - java

I am setting up Maven corporate repository using Apache Archiva for my company.
Our requirements for now are quite basic - have an internal repo for our jar files and dependency management.
I want to make sure that Archiva does not upload any of our proprietary code / jar files to Central Repo (Public), but we would like to be able to download public libs from central repo if needed by the project.
(Our desired configuration: IDE/Developer <Download/Upload> Internal Repository <DOWNLOAD ONLY> Public Central Repo.)
My question is, by default, does Archiva upload my jar files to central repo if its configured as a proxy/mirror? if so, how do I prevent publishing to central/external repo while keeping the option to download from central when needed?
Appreciate any answers.

If you configure the local/managed repository which is linked to Central as read-only, then nobody can upload to it. This is done by only giving the "Repository Observer" role but not the "Repository Admin" (in fact you will most likely add additional roles, just make sure none of them is assigned for any developer to one of the mirrored repos).
BTW: you can also disallow re-deploy (aka overwrite of artifact versions) for a repository. This is generally a good idea. This is done in the repository settings (not by roles).
One additional thing you might want to look for: if you configure a repo to be Snapshot only, it still will accept SNAPSHOT uploads. This can be quite confusing, make sure nobody does that.

Related

Upload maven pom.xml to Git repository?

I want to publish my Java project on GitHub. I'm not sure if I should upload my pom.xml from Maven in my repository.
I'm using Eclipse without eGit.
On the one hand:
the pom.xml is necessary to know which libraries I used.
On the other hand:
it's a configuration file which maybe shouldn't made public.
it destroys the look of a clean repo, because it's outside of the normal source files.
What should I do best?
it's a configuration file which maybe shouldn't made public.
This is wrong. The POM is indeed a configuration file but it is intended for this file to be public. Actually, quoting Maven guide to uploading artifacts to the Central Repository:
Some folks have asked why do we require all this information in the POM for deployed artifacts so here's a small explanation. The POM being deployed with the artifact is part of the process to make transitive dependencies a reality in Maven. The logic for getting transitive dependencies working is really not that hard, the problem is getting the data. The other applications that are made possible by having all the POMs available for artifacts are vast, so by placing them into the repository as part of the process we open up the doors to new ideas that involve unified access to project POMs.
As you see, this file is actually required so that the artifact can be uploaded to Maven Central.
What should not be public is your settings, i.e. the settings.xml file. It is in this file that you should store any sensitive information, like passwords. Again, quoting the Settings Reference (emphasis mine):
The settings element in the settings.xml file contains elements used to define values which configure Maven execution in various ways, like the pom.xml, but should not be bundled to any specific project, or distributed to an audience. These include values such as the local repository location, alternate remote repository servers, and authentication information.
If you currently store any sensitive information in your POM, you should consider refactoring it to extract this info and put it inside your settings instead.
it destroys the look of a clean repo, because it's outside of the normal source files.
It is a source file in the sense that Maven only requirement is exactly the presence of this file. It describes how to build your application and declares all of its dependencies. To say it differently: this file is a Maven source file, and as such, should be commited along with the project main source files. Without it, no-one can build your application and no-one can also package it.

Make my local .m2 folder as a repository

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).

Maven downloading from central repository

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.

Merging maven .m2 repositories

I have a maven repository in an offline network.
I need to update its contents and merge in another repository .
What is the best method to do this ? I looked at the wagon plugin Wagon but I am concerned that there may be a better way.
I could replace my local repo with an offline repository manager but the problem still remains , I would have to update that Repo with regular merges from an online source.
If you can afford to get rid of all metadata (which should recover with the next mvn commands you run) for the time of your operation, just use rsync.
If building a concrete repository is not mandatory, consider using Nexus and its groups.
Vincent's answer is correct, but I would more strongly suggest that you don't do this in the .m2/repository directory. That directory is a cache, and should be able to be removed at any time. You should consider setting up a repository manager (such as Archiva, Nexus or Artifactory, or just a HTTP server) and host the repository content there so that you can let Maven manage the .m2/repository directory.

Creating/Accessing Maven repository in SVN through NetBeans 6.7 *Revised*

EDIT: Ok... so I've gathered that SVN shouldn't really be used for this... which makes sense, I suppose (why version individual files when the version should be a separate jar?).
So we should use an internal server to host a repository management tool like Nexus (etc), and access that over http to pull down and put out dependencies. We are keeping our projects in SVN now. What is the standard for deployments? Dependencies go into Maven. Projects go into SVN. Should we ignore the dist and build folders? Where would our WAR files get deployed from?
OLD QUESTION (for posterity)
I'm brand new to Maven and don't know jack about it. I'm trying to evaluate it to see how it will do with our Java development.
I would like to have a Maven repository in our SVN server so that dependencies can be pulled down from there using NetBeans 6.7. I have not been able to find how to do this throughout many google and stackoverflow searches.
What are the best practices here? I'm thinking that we'd want to download dependencies using svn+ssh, but most things online seem to point to using http.
Fill my brain with great things!
I'd strongly recommend against doing this. Maven artifacts don't belong on an SCM server. You should consider using a repository manager like Nexus to store your artifacts. See here for a comparison of the main repository managers.
Having said that. If you are determined to use Subversion to host your artifacts. See this question on using the wagon scm to deploy to a Subversion repository.
If you want to find out more about Maven, check out Maven: the definitive guide.
There is a Maven plugin for Netbeans that will manage dependencies. This article lists some best practices for Maven and Netbeans.
Update based on your updated question. What to do with your own jars:
Maven has a deploy phase that will publish your artifacts to the remote repository. You need to configure the distributionManagement section of the pom, and provide appropriate credentials in your settings.xml to allow the deployment to happen. Typically you would set up a discrete logical repository on the server for your own artifacts to keep them isolated from third party artifacts. The Nexus book gives some good guidance on configuring repositories on Nexus. In particular see the Adopting a Repository Manager section.
If you have configured your project correctly, run mvn deploy and all phases up to and including the deploy phase will run, and your artifact will be published to the repository, available for use by the rest of your team/company.
If you need to restrict access to repositories, you can configure access controls to your repository so only authenticated users can access those artifacts (for Nexus see the Managing Security section of the book for guidance).
It's worth noting you can do largely the same things (more or less) with Artifactory or Archiva as Nexus, I've included Nexus references because I prefer it, and the documentation is really good.
Don't store them in SVN.
I would do two things to make sure you're not getting too many headaches:
Mirror a repository closer to your box someplace that you and your workmates can share. This will eliminate extra downloading and allow you to fix any problems that may come up (and they will) with the mirrored pom/jar files so your mates don't have to share in the headache. There are several repo managers out there that help with this.
Do your best to work with your machine repository and push changes/modifications to any pom files that you may make to the local shared repo.

Categories

Resources