Javalobby

Fabrizio Giudici

Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. View Full User Profile

Using a Maven Repository on Kenai

07.20.2009

We Recommend These Resources

5 Critical Application Deployment Mistakes (You Don’t Want to Make)

Getting Started with FUSE Mediation Router

Real-Time SQL Access to Salesforce.com Data

Migrating to FUSE Mediation Router

Micro Focus SilkTest 2011

One of the missing things on Kenai is a Maven repository. I mean, an "official" Maven repository managed by Kenai staff. This doesn't mean you can't create your own repository on Kenai. Peter Mount explains (part one, part two) how you can just create a Maven repository as a Subversion site - in his latter post, Peter shows how to automatically perform a deploy by using Hudson, with some script trickery.

But, thanks to the wagon-svn maven plugin, it is possible to do that directly with Maven. The plugin implements a Maven extension making it able to deploy to any Subversion-based repository (actually, it has been developed for Java.Net, that has got such a repository).

So, I've just created a Tidalwave project on Kenai, that I'll use for hosting some common facilities for all my projects, then I added a Subversion repository named "tidalwave~maven-repo". To deploy to that repository, a pom needs the following elements:

    <repositories>
        <repository>
            <id>maven2-repository.dev.java.net</id>
            <name>Java.net Repository for Maven</name>
            <url>download.java.net/maven/2</url>
            <layout>default</layout>
        </repository>
    </repositories>

    <distributionManagement>
        <repository>
            <id>maven2-repository.tidalwave.kenai.com</id>
            <name>Tidalwave Maven Repository</name>
            <url>svn:https://kenai.com/svn/tidalwave~maven-repo/2</url>
            <uniqueVersion>false</uniqueVersion>
        </repository>
    </distributionManagement>

    <build>

        <extensions>
            <extension>
                <groupId>org.jvnet.wagon-svn</groupId>
                <artifactId>wagon-svn</artifactId>
                <version>1.8</version>
            </extension>
        </extensions>
    ...
    <build>

The declaration of the Java.Net repository is used to find the wagon-svn plugin, that takes care of target repositories whose URL starts with svn:.

The first time you do a mvn deploy, the computer will ask for the username and password of the target repository; after you set once, they will be remembered in the Subversion preferences, so this thing will also work with Hudson.

You can check out a very small Maven project using my new brand Maven repository from here: https://kenai.com/svn/thesefoolishthings~svn/trunk/src - TheseFoolishThings is a collection of tiny libraries (mostly made by a single file) for functions that so far I used to copy & paste in different projects, and that now I'm refactoring.

Average:

Your rating: None

Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Java
kenai
maven
Build Automation

Comments

Gérald Quintana replied on Mon, 2009/07/20 - 3:13am

Very interesting post. Now that I know it's possible to deploy/upload an artifact to a Kenai hosted repository, is it possible to deploy/upload the generated Maven Site to Kenai?

Milos Kleint replied on Mon, 2009/07/20 - 4:30am

I would recommend to define also snapshotRepository element in the distributionManagement section and keep snapshots separated from final version bits. That probably means yet another svn repository..

Unfortunately kenai.com doesn't yet provide a nice centralized solution, like codehaus.org does (with syncing of the release repo to central)

Fabrizio Giudici replied on Mon, 2009/07/20 - 5:05pm

Alexandro,

the Central Maven Repository doesn't accept snapshots - at the moment, many of my projects are still in the snapshot stage, so I can't publish them (yet). Then, not everybody wants to publish in the central maven repository - while I don't have objections for generic projecs such as BetterBeansBinding, there's a cluster of specific projects of mine for which I prefer to keep my own repo.

As a last point that I still have to study, the Central Repo forces the constraint of setting the group id as "com.kenai" that some people could dislike. Indeed, to me it doesn't make much sense, as if you want to change the source repository, you have to change it and break continuity.

Which is the problem with multiple repos, BTW?

Brian Fox replied on Wed, 2009/07/22 - 8:40pm

Alexandro, Most of your comment is simply not correct.

The java.dev.net repository is not central, repo1.maven.org/maven2 is. No projects are allowed to deploy to central directly. Only Maven PMC members have access to this machine. All artifacts that get on Central are rsynced from various sources. If you want to get artifacts into Central, you need to setup your own repository and request that we rsync it, or use one provided for you.

At Sonatype, we have setup an instance of Nexus for projects who simply need a hosted Maven repository. You can read more about that here. We've also offered to help Kenai get an instance setup, I'll have to ping Nick again to see if they're ready to move forward. In the meantime, any oss project, Kenai hosted or not is welcome to use our oss instance.

--Brian Fox

Apache Maven PMC

Brian Fox replied on Tue, 2009/07/21 - 8:29pm

Fabrizio, deploying snapshots to an svn repository is not a great long term solution. If you do frequent deploys, this will eat up disk space in svn very quickly since each deploy represents at least one new file. Even if you delete them from svn, it would take an svn admin to fully purge the contents from the history and reclaim the disk. If everyone at Kenai started doing this, it would potentially be a very big problem. Regarding putting things into Central, com.kenai isn't an absolute rule. That would be the default I would expect for things originating at Kenai, just like net.sf is for sourceforge. You must use some domain as a groupId as we strongly discourage the old technique that got things like ant:ant and junit:junit, but the actual groupid should generally match your java packages and be some real dns tied to the project.

Peter Mount replied on Wed, 2009/07/22 - 9:32am

Thank's Fabrizio for the good follow up. Although I've not written it up I've actually progressed a little further in using a local Nexus instance for maven to deploy to, but the directory Nexus is using is actually the directory of a checked out copy of the subversion 'repo'. This seems to be working fine, and keeps the pom clean of additional plugins from the java.net repo.

As I use Hudson for building releases, I run the release from within a special job and then using the m2-extra-steps plugin run the add and commits against the repository as steps run after maven.

Peter Mount replied on Wed, 2009/07/22 - 9:45am in response to: Brian Fox

Yes using svn isn't a long term solution (which I stated in my first article - it's a hack until Kenai supports maven). It's also horribly slow (to me).

As Fabrizio stated earlier, one of the nice features on kenai is the option to delete and recreate repositiories, so if that becomes an issue then we can always delete and recreate the temporary repo.

The other topic about deploying to central - I already knew about the restrictions with what a pom in the central repo can contain and personally I'd love to have my stuff deployed in central.

The problem I have is the multiple repo problem - most of my projects depend on recent versions of plugins or artifacts on the java.net or other repo's (specifically JAXB/XJC on java.net) and the versions in central are woefully out of date. Terracotta is the other one for some of my projects.

Brian Fox replied on Wed, 2009/07/22 - 8:39pm in response to: Peter Mount

Hi Peter, Which multiple repo problem are you referring to? Although we try to avoid having repos listed in poms, it's obviously unavoidable. What is required is that things are obviously available on other repos. This alone would not exclude your stuff from being synced to central. --Brian

Alexandre Navarro replied on Thu, 2009/07/23 - 3:28am in response to: Brian Fox

I think I was not very explicit and my post can be misunderstood. I rewrote my post and explain it.

1) Precisions on the main goal of my post

"You can deploy with this technique on Maven Central Repository"

means

"You can make available in the Maven Central Repository (MCR) with this
technic and by synchronizing your svn repository"

2) Precisions on sync

After, you can ask to sync your svn maven repository with MCR.
There is 2 protocol to sync with the MCR.

- use rsync protocol but rsync (on ssh server) is not available on kenai for instance (not
like sourceforge) so you can't use it if you are on kenai (or googlecode)

- use svn orotocol very unknow thing very useful if you don't have a rsync server

If you don't have a rsync, you can do it with svn as do Spring or
Findbugs.

3) Precisions on the different repositories

We should all stop to deploy in n repositories (like codehaus,
javanet, jboss ...) and we should all deploy in the MCR to have only one great Maven Central Repository.

means

We should all stop to deploy in n repositories (like codehaus, javanet,
jboss ...) without synchronization with MCR and we should all make
available in the MCR to have only one great Maven Central Repository .

4) Comments on your post

I didn't know about oss.sonatype.org/index.html. It is great to
have a repo (or n) for Open Source Project synchronized automatically to the MCR not like javanet or jboss. Your method is clearly better than what I described. Will you sync jboss, javanet ... repo
maven in the future?

I ask because I had the problem "I want to make available a lib in the MCR but I have a dependency (with a lot of transitive dependencies) in Java Net or JBoss repo and so I can't"? I had the problem with SwingJavaBuilder (where is a dozen of depencies, some are in the MCR, some on javanet, some on jboss, some nowhere) and it takes 3 or 4 months by migrating some dependency projects to maven (which the Project Manager accepts to migrate), or ask manual uploads, ask sync between some libs from java net. It was just a nightmare and it is so painful.

Why you said "The java.dev.net repository is not central,
repo1.maven.org/maven2 is"? I totally agree with you, do you
confuse on my post <repository> with <distributionManagement> I suppose.

After my precisions, can you tell me what is incorrect in my post
(except of course your technic is better than mine but I did know the
existence on oss repository at the moment I wrote).

Conclusion

Thanks for your precisions, I think it can be great if your will make an article on JavaLobby "how to make available in MCR" with your links and contact the main repositories (like javanet or jboss) mainteners to add the sync with the MCR. For me it is just an aberration to have n Open Source Repositories without sync with MCR and so it is a great idea what you will do with oss repository.

Peter Mount replied on Fri, 2009/07/24 - 6:55am in response to: Brian Fox

I think it's where the docs about syncing to central say about not allowing external repos defined.

As I stated earlier it's java.net thats the problem, primarily for jaxb. Now I've just checked central and jaxb does appear to be in sync so I'm going to do some experimentation to see what works with just central involved.

The terracotta repo doesn't appear in central, so that one would probably be unavoidable but it is a publically accessible repo, so does this mean this wouldn't be a barrier if there's no other option?

Brian Fox replied on Sat, 2009/07/25 - 7:54am in response to: Alexandre Navarro

Hi Alexandre, thanks for the clarification, it makes more sense now. The oss.sonatype.org instance is meant to provide projects access to a Maven repository when they wouldn't otherwise have one...such as on github, sf.net and kenai etc. Syncing existing repos like java.net or jboss is entirely different. These repos can be synced if they want to, but we don't/can't sync without their permission.

Tanya Huff replied on Thu, 2011/05/05 - 11:01pm

I'm about to give this a try, the phrase 'script trickery' makes me very nervious though about it's stablilty.

Sewing Needles

Arun Kumar replied on Fri, 2011/08/12 - 12:57am

Hi, We are using SVN to store maven dependencies. SVN runs on a webserver with https protocol. Currently if a new dependency is added all developers have to update their local copy of maven repo manually. Is there a way to download\update new dependency automatically during maven build cycle itself? tried with wagon plugin no help. Any helps will be appreciated.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.