I was browsing TSS and found this article. It's a good read for any seasoned Maven 2 developer, talking about repository theory and a piece of software called Artifactory. I like that Artifactory combines caching of external artifacts with a nice Web-UI where you can manage your repository. The article does a great job of explaining why and when to use Artifactory.
Artifactory looks like a real helpful piece of software. I'll stick to my dead simple repository setup for now, but I am going to give it a try real soon. The caching alone makes it worth using, as I have found in the past it speeds up Maven's execution time.
Showing posts with label distribution management. Show all posts
Showing posts with label distribution management. Show all posts
Wednesday, June 27, 2007
Thursday, June 14, 2007
Using Snapshots for Rapid Development
The problem:
You are working on a project with a number of other related sub-projects. You would like to release snapshots of your project's artifact (maybe a war or jar) for use in these other projects. This will help those other projects move along while your project is being developed.
The solution:
You can configure your project to produce a snapshot artifact, just add '-SNAPSHOT' to the end of your project's version number in it's pom. Now when you package the project you will get a artifact labeled with SNAPSHOT. You now can take advantage of releasing the snapshot for other projects to use. You should configure a 'snapshotRepository' section in your 'distributionManagement' section of your pom. Here is an example of how this works:
With the above pom you could type 'mvn deploy' and a unique jar will get deployed. You can check this by checking /test_snapshot_repo/test_snaps/test_snaps/0.0.1-SNAPSHOT/. Run the 'mvn deploy' command a few times and you will see a bunch of these begin to build up.
You are working on a project with a number of other related sub-projects. You would like to release snapshots of your project's artifact (maybe a war or jar) for use in these other projects. This will help those other projects move along while your project is being developed.
The solution:
You can configure your project to produce a snapshot artifact, just add '-SNAPSHOT' to the end of your project's version number in it's pom. Now when you package the project you will get a artifact labeled with SNAPSHOT. You now can take advantage of releasing the snapshot for other projects to use. You should configure a 'snapshotRepository' section in your 'distributionManagement' section of your pom. Here is an example of how this works:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test_snaps</groupId>
<artifactId>test_snaps</artifactId>
<packaging>jar</packaging>
<version>0.0.1-SNAPSHOT</version>
<distributionManagement>
<snapshotRepository>
<id>test_snapshot_repo</id>
<uniqueVersion>true</uniqueVersion>
<name>test_snapshot_repo</name>
<url>file:/test_snapshot_repo</url>
</snapshotRepository>
</distributionManagement>
</project>
With the above pom you could type 'mvn deploy' and a unique jar will get deployed. You can check this by checking /test_snapshot_repo/test_snaps/test_snaps/0.0.1-SNAPSHOT/. Run the 'mvn deploy' command a few times and you will see a bunch of these begin to build up.
Saturday, June 2, 2007
Per user server authentication
The problem:
Each user has their own username and password for network machines that are accessed by Maven when deploying artifacts, websites, or maybe some other files. You wouldn't want this type of information in your project pom.xml so what do you do?
The solution:
The settings.xml file in your {HOME_DIR}/.m2* folder is your ticket. You can define servers and for each one define your username and password. Note that each server entry must have an id that matches with the one defined in the distribution management or other part of your pom.xml. Here is the example:
* This is /Users/{username} on Macs, Documents and Settings/{username} on Windows or /home/{username} on most linux machines.
Each user has their own username and password for network machines that are accessed by Maven when deploying artifacts, websites, or maybe some other files. You wouldn't want this type of information in your project pom.xml so what do you do?
The solution:
The settings.xml file in your {HOME_DIR}/.m2* folder is your ticket. You can define servers and for each one define your username and password. Note that each server entry must have an id that matches with the one defined in the distribution management or other part of your pom.xml. Here is the example:
<settings>You should fill in the username, password and path to keys. On my Mac the path to ssh keys is /Users/ottaway/.ssh/known_hosts. You will need to do a little investigation on this if using a Windows machine. Please let me know if you figure it out.
<servers>
<server>
<id>hood</id>
<username>ottaway</username>
<password>Cm0nkeyz</password>
<privateKey>/Users/ottaway/.ssh/known_hosts</privateKey>
</server>
</servers>
</settings>
* This is /Users/{username} on Macs, Documents and Settings/{username} on Windows or /home/{username} on most linux machines.
Subscribe to:
Posts (Atom)
