Over at Project Kenai one minor issue is that it doesn’t currently support maven repositories. Although it is on their list of features to implement it’s probably not going to be available for a while.
So what if your project needs a public maven repository on Kenai?
Well the trick is to:
- add an additional subversion repository to your project which will host your repository.
- Then on your local machine check out that new repository and tell maven to deploy to that directory instead of a remote repository.
- Manually add any new files that have been added by maven
- commit the changes
To use the repository simply use the subversion repositories public url as a repository definition.
Here’s the gory details on what to add to your pom’s. For all of these examples you will need to substitute reteptools~maven with the name of your subversion repository. I’m using a releases subdirectory within the repo but that is optional.
In your pom.xml you need to add a distributionManagement element pointing to your local checked out copy of the repository. If your project has child modules in it you can put this into the parent pom as it will be inherited.
<distributionManagement> <repository> <uniqueVersion>false</uniqueVersion> <id>retep.releases</id> <name>Retep.org repository</name> <url>file:/Users/peter/repository/reteptools~maven/releases</url> </repository> </distributionManagement>
Next if your pom’s need to refer to your public repository you need to reference it with a repository and/or pluginRepository definition. In this case you need to use http://kenai.com/svn/ and your project~repository name as the url. Here’s what you would use to access my repository on kenai:
<repository> <id>retep.releases</id> <name>retep.org Maven 2 Repository</name> <url>http://kenai.com/svn/reteptools~maven/releases/</url> </repository> <pluginRepository> <id>retep.releases</id> <name>retep.org Maven 2 Repository</name> <url>http://kenai.com/svn/reteptools~maven/releases/</url> </pluginRepository>
Now you have done this, you can build as normal. However when it comes to deploying you first run:
mvn deploy
to deploy to your repository. Because of the distributionManagement element it will deploy to your checked out copy.
Next change directory into your repository and add any new files:
cd /Users/peter/repository/reteptools~maven/releases svn status svn add ...add any files shown as unknown... svn commit -m “brief commit message”
That’s all there is to it.
At some point I’m going to see if it’s possible to automate the commit process into subversion, but for now this works.
Update:
2009-04-24 12:14: ODFToolkit (which uses a subset of kenai and was partly why I started looking into this issue) doesn’t have subversion available just Mercurial so we had the question – would this work with mercurial.
Well it looks like it is possible, just base your repository path with the template: http://kenai.com/hg/projectName~repositoryName/raw-file/tip/
This appears to serve the files cleanly.
Peter Mount's Blog 
Funny… I thought the point of Maven was because source control systems should only hold source and not binaries. All things aside, it's an interesting temporary solution to this issue.
It's also out of date as kenai how supports webdav via their website feature, although the technique still applies for google code (which is where I originally found it).For example the repo is now at http://reteptools.kenai.com/maven/releases/ can be updated with the following url in distributionManagement: dav:https://kenai.com/website/reteptools/maven/releases/
The problem here is that central can't replicate from this sort of thing.
Yes that's one of three issues I have, the other two being speed of writing (it can time out) & dependencies not in central.Hopefully by the end of next month I may have an alternate solution.