Maven repository

So I have a bunch of Java projects, some of which are libraries that other projects depend on. At the moment, to build the projects, I'm checking out the source of the dependency and building it.

I have subversion in house. Can I use that as an artifact repository so that my dependencies can be pulled down by maven when I build my project? If not, is there a simple, free alternative? I know Artifactory is a thing, but I'd rather not go buy a huge tool when we just have a handful of projects.

At my work place we use Sonatype Nexus as well. It should work perfectly for what you want. We have Hudson automatically deploy builds to nexus and then our m2 settings point maven to our repo and internal dependencies work the same as external. All our deployable artifacts are in nexus as well.

There's all of four people in my company even using Java, so i'm wary of trying to use a product where it'll require getting 3 other teams involved to evaluate the license, purchase, and install the software. I'm kind of tempted by the idea of asking for a VM where I can SCP or FTP artifacts automatically using Bamboo, which we already have.

1. Commission new Red Hat server
2. Download JAR onto said server
3. Configure to run as service using instructions at http://archiva.apache.org/docs/1.4-M4/adminguide/standalone.html
4. Enter the web config and define an admin password
5. Configure a user for svc_bamboo
6. Add that user as a manager to both the internal repo and the internal snapshot repo
7. Edit /home/bamboo/.m2/settings.xml to contain the username and password for that account
8. Edit each project's pom.xml to contain deploy target to that location
9. Change "mvn install" to "mvn deploy" in projects
10. Create users for each of the QA team and/or configure LDAP for the QA team
11. Configure each user's settings.xml to use their newly created account for authentication
12. Done!

Well, usually only for your integration builds. Your personal / continuous builds shouldn't be deploying snapshots. Otherwise, you'll end up having snapshots where features are added, then removed, then re-added, etc.

10. Create users for each of the QA team and/or configure LDAP for the QA team

You could do that by applying a profile (or rather a pair of profiles, one enabled by default and one not) so that on the server you can deploy without having to change the POM. Changing the POM would be a sign of

I ran mvn deploy and it told me I needed a repo configured in the POM to deploy to, so I added one.

I'm going to assume you've since googled Maven profiles and figured out what he's talking about. A link to the <activation> tag example might not hurt, though. Do note that the -P option on the command line can also be used to activate profiles.

. Edit each project's pom.xml to contain deploy target to that location

The nice thing about the Artifactory / Jenkins plugin was that you could keep that stuff external, and it would also deploy only at the end when the build succeeded (though admittedly Archiva appears to have staging repositories).

If you're doing it the good old-fashioned way you should only declare it in any root POMs, and maybe consider inserting variables (called "properties" in Maven lingo) for the server URL. Our artifact server moved a few times which meant I had to go edit all POMs in maintenance branches, having it set through the build server's settings keeps environment-specific stuff out of the POM.

. Create users for each of the QA team and/or configure LDAP for the QA team

We simply allow anonymous read access.

I guess user accounts are necessary when using those afore-mentioned staging repositories as you need to administrate them through the web UI.

If you are running a proxy / virtual repository for Maven Central or other repos (strongly recommended) you can allow "overlays" for the case where someone bodged a POM file, forgot to deploy source jars or when they're one of those Ant "download it from my website" cretins. In that case you should tell the devs who to bother in case they need something uploaded manually to such an overlay repository.

. Configure each user's settings.xml to use their newly created account for authentication

We also don't specify the proxy repository in our POMs and actually force our proxy to be used for everything. To do this we have the following in our settings files:

The extra profile at the end overrides Maven's default repositories because plugin downloads would not use the mirror settings.

This does mean though that your proxy needs to be updated once every while to proxy maven central, likely some JBoss stuff, Spring repositories and whatnot. On the flipside you always have an "in-house" cache of these repositories in case one gets slow or goes offline.

It's wonderful to be able to do mvn -Pprod deploy and have that do a full update of your application, yet use virtually the identical code to deploy to testing or staging servers. Fuckups averted.

What the hell? The default deploy phase is a Maven-only affair by default as it only deploys artifacts to an artifact server or some other location.

It sounds like you coupled the Cargo project plugin in your builds to get it to push to a remote app server, though that's obviously non-standard and shouldn't be mentioned as such - Maven's deploy phase is badly named as it stands.

Okay so true facts time: the only thing we use Maven for in my entire company is Java-based functional tests. There's no production servers for this stuff, it just runs from Bamboo, but each product's tests are split into a framework and the tests themselves. I want to break these massive frameworks into a series of modules instead, so you can have tests that cross product boundaries. 90% of Maven crap is entirely beyond my use case. I just want to use it like NPM On-Premise.