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.
-
My company uses Sonatype Nexus for our internal Maven repository. Not sure what the cost or license is, but it seems to work well enough.
-
@Yamikuronue
I thought the basic hosting of Maven artifacts can be done using the free versions of both Artifactory and Sonatype Nexus.Stuffing things in subversion is technically possible but you would have to keep metadata in sync - by hand.
We have been running the free edition for years, though I have to admit it's also been kept at that same old version.
-
@JBert What sort of metadata?
There doesn't seem to be a free version of Artifactory anymore.
-
Versions lists, checksums, the main plugin list...
All stuff which a repo manager would automate for you.
BTW: I think it's the Artifactory Open-source edition now.
-
For the record, the differences between Artifactory editions: https://www.jfrog.com/confluence/display/RTF/Artifactory+Comparison+Matrix
All of the editions allow you to deploy your own Maven artifacts.
-
Sonatype Nexus also has a free version. Their comparison blog post is here.
They don't disclose their pricing publicly but it seems like from FAQ posts it's per-user (not per-concurrent-user)
-
This topic is well timed. I was thinking about this exact problem the other day, but got side-tracked before looking into it.
-
Looks like Apache Archiva is a thing.
List of compatible software (basically Artifactory, Nexus, and Archiva)
-
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.
-
It's actually possible to host Maven artifacts directly on an HTTP server just by creating them using
mvn package
and and uploading them to the server. I wouldn't recommend it, though.Edit: There's still an Open Source version of Artifactory.
-
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.
-
@Yamikuronue Well, I've had artefacts held in a SVN repository and that works despite being fugly and making my teeth itch a whole lot.
-
I use s3. http://jmchung.github.io/blog/2015/03/01/using-amazon-s3-as-a-private-maven-repository/. Biggest issue is each user needs to add the key to their m2 settings.
-
I know I said
mvn package
earlier, but it's actually themvn deploy
plugin instead. It's been a while since I had to manually create and upload artifacts.
-
I think this is essentially what I want to do:
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!
-
@Yamikuronue said in Maven repository:
9. Change "mvn install" to "mvn deploy" in projects
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
Por que?
-
@JazzyJosh Won't we need users to bring down and install the artifacts when we're working on projects that depend on them?
(and yes, I meant "on the build server, change
mvn install
tomvn deploy
")
-
@Yamikuronue Yeah, I don't know why I derped on LDAP. I was thinking about users to configure the repo or something. Sorry.
-
@JazzyJosh Awesome. Tomorrow I can bring this to the architecture office hours and see if I can get it approved so we can just go ahead and do this.
-
@Yamikuronue I've never actually set up a maven repo, but I didn't see a problem with the steps you were taking.
-
@Yamikuronue said in Maven repository:
(and yes, I meant "on the build server, change mvn install to mvn deploy")
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
-
@dkf said in Maven repository:
applying a profile
A what now?
I ran
mvn deploy
and it told me I needed a repo configured in the POM to deploy to, so I added one.
-
-
@FrostCat said in Maven repository:
@Yamikuronue said in Maven repository:
install the artifacts
?
-
Sometimes failure is a good thing
-
@Luhmann the original image that is there is 16x16. The fallback image is bigger!
-
@ben_lubar said in Maven repository:
The fallback image is bigger!
Another case where the bigger one is better then
-
@Yamikuronue said in Maven repository:
@dkf said in Maven repository:
applying a profile
A what now?
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.
-
@powerlord Precisely. (I'd intended to write more, but got distracted by something. Can't remember what now.)
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.
-
@Yamikuronue said in Maven repository:
I think this is essentially what I want to do:
- 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:
<?xml version="1.0" encoding="UTF-8"?> <settings> <!-- <localRepository>D:\mavenrepos</localRepository> --> <mirrors> <mirror> <id>any</id> <name>All repos</name> <url>http://artifactory.example.org/repo/</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors> <profiles> <profile> <id>defaultrepo</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>central</id> <name>internal-repository</name> <url>http://artifactory.example.org/repo/</url> </repository> <repository> <id>snapshot</id> <name>Maven Proxy Snapshots</name> <url>http://artifactory.example.org/repo/</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url>http://artifactory.example.org/repo/</url> </pluginRepository> <pluginRepository> <id>snapshot</id> <url>http://artifactory.example.org/repo/</url> </pluginRepository> </pluginRepositories> </profile> </profiles> </settings>
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.
-
@dkf said in Maven repository:
@powerlord Precisely. (I'd intended to write more, but got distracted by something. Can't remember what now.)
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.
-
@JBert said in Maven repository:
The default deploy phase is a Maven-only affair by default as it only deploys artifacts to an artifact server or some other location.
The bad thing about Maven is how confusing all the lifecycle stuff is. It's marvellous when it works, but it is ever so poorly discoverable.
-
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.