Project Kenai Documentation and Training: Features: Please add maven support

Posted: March 20, 2009 01:54 by benson_margulies

» Permalink

Throughout the open source ecosystem, maven has become a pervasive tool for java development. Many, many, tools and components are interconnected via maven dependencies.

Other open source hubs, such as the ASF and dev.java.net, have maven deployment infrastructure set up so that projects can post up maven snapshots and releases and in turn have them replicate to central.

The odfdom toolkit project, which I'm helping on a little, has users who want to consume maven artifacts.

ASF has decided to go with Sonus Nexus to allow projects to post artifacts. There are other choices, including a raw web server to which project members can push via scp.

Peter Mount

Posted: March 24, 2009 18:23 by Peter Mount

» Permalink

I was going to respond to this at the weekend but this is the first moment I've had.

Currently I'm running Nexus http://maven.retep.org for my public repository. For the projects I use two repositories, Releases http://retep.org/nexus/content/repositories/releases/ and Snapshots http://retep.org/nexus/content/repositories/snapshots/.

The Releases repository is used for final release quality artifacts identical to the downloads option on Kenai.

The Snapshots repository is used for developmental releases - i.e. builds based on the current source under version control but has not yet either passed all unit tests or are for public testing before a release. With maven you can tell a snapshot release as the version has -SNAPSHOT appended to it.

I'm currently moving away from having a dedicated server and as I'm slowly migrating my projects over to Kenai I'm also eager for some form of maven support as all of my projects use maven.
Here's my original post to the odftoolkit dev list last week when we were discussing this:

With maven when you deploy a release to the repo you can optionally deploy additional artifacts containing the sources used to generate that release. The deploy plugin will do this automatically if told to do so. Additionally if you get maven to generate javadocs then these too are deployed as an additional artifact. The purpose of this is that if you depend on a specific version of an artifact you can get the exact sources used to build that artifact. In normal use when it resolves the required artifacts it just downloads the main jar but IDE's (like Netbeans) can also download the sources/javadocs so you get auto completion etc as if you had the project open. The issues of incompatible versions doesn't happen as long as you manage the artifact versions correctly, especially by using snapshots for development and releases for stable releases. [quote]As for mercurial, all of this works outside of it (or any other like cvs or svn), although maven does have support for it. I usually add a tag in mercurial for releases as well.

Nick Sieger

Posted: March 24, 2009 18:35 by Nick Sieger

» Permalink

We've had requests a number of times already for some kind of Maven support, and are keen to provide it in some form at some point. The only thing holding us back from doing so is figuring out how a shared kenai.com maven repository would work.

I'm not familiar with Nexus, would it solve this problem? The problem as I see it is how to merge artifacts from multiple projects into a single repository while preventing uploads of artifacts not produced by your project. On Codehaus for example, they allow you to upload maven artifacts only under a certain package/namespace, but not outside of that namespace.

If you could help us gather a simple set of requirements around a shared repository (release + snapshot), we'd appreciate the help. How should it work?

Regards,
/Nick

Kenai.com Team

Peter Mount

Posted: March 24, 2009 21:17 by Peter Mount

» Permalink

With nexus there's several types of repository (release or snapshot).

Each project can have it's own set of repositories (i.e. the links I put in my earlier post) known as hosted repositories, however it also provides group repositories which can automatically include any number of hosted repositories as if they were deployed within them.

For example http://retep.org/nexus/content/groups/public/ contains my release repo and also proxies for maven central, java.net etc, but the theory is identical for multiple repos.

As for security the usual way is via the UI, however this can be changed: http://nexus.sonatype.org/dev/security-faq.html describes on how to handle authentication externally (other than using ldap).

The one thing I'm not certain is on creating the project specific repostiories progmatically and then there's the issue of the namespaces.

Anyhow this is describing using a manager like Nexus for the repository. An alternative is Maven itself. It can deploy directly to a filesystem (using webdav, ssh etc). In this case you can set something up that does restrict the namespaces using ACL's as a maven repository is just a plan directory structure.

The two things a manager like Nexus does provide is indexing and cleaning up of old SNAPSHOT's (they can eat up disk space if you are not careful).

On a side note I did find earlier how someone managed to get maven to deploy it's artifacts into a subversion repository to get around this problem on Google code... thats how flexible Maven can be.

Peter

Peter Mount

Posted: April 03, 2009 10:22 by Peter Mount

» Permalink

Just been thinking about this over the last few days (partly as I really could do with a repo right now), and here's an alternative solution:

The main requirement for projects based around maven would be a repository for releases. Snapshot repositories are good for collaborative development, but the main feature projects would need would be the releases repository.

So the idea I've just had and would prevent uploads to a package/namespace outside of the project is this.

First, enforce a base package for projects, for example com.kenai.project.projectName

Then host the repo at some specific url with webdav enabled. Within webdav you then define the security so that only members with Administrator or Software Developer have write access (or possibly just Administrator for projects that want to control the release process)

Releasing to the repo would then be done by the maven deploy plugin which would handle the creation of all relevant files/directories as required.

That would then prevent uploads outside of a project's namespace by limiting the damage to the namespaces a specific Administrator has access to.

The only issues here are:

Implementing this, could be done with Apache but it's handling the roles
Support - occasionally it's possible for maven to break the xml thats deployed, not that often but I've seen that happen
Removing old releases - sometimes required, especially if a release has a serious error and you want to prevent people using it

Just my thoughts

Peter

Brianf

Posted: May 20, 2009 14:32 by Brianf

» Permalink

Hi Nick,
Nexus would let you manage the Kenai repositories in a few different ways. You could make separate repositories for each project, or you could manage them within a single set of repos but still control who can deploy which artifacts. I manage two large OSS instances already, repository.apache.org and oss.sonatype.org. The Apache instance uses a single set of repositories and controls access based on the groupId of the maven artifacts. The oss.sonatype.org instance does a little of both based on the projects.

We make available free Nexus pro licenses for open source projects, and we'd love to assist you setting one up and configuring it for Kenai. Alternatively, projects are able to use our existing instance at oss.sonatype.org, we host projects like jetty, ehcache etc there that don't have their own infrastructure. (http://gregluck.com/blog/archives/2009/05/anyone_with_a_p.html)

--Brian

Alexandre Navarro	Posted: July 22, 2009 21:18 by Alexandre Navarro » Permalink
	It is great to have a Kenai repository only if it will be synchronize with the Central Maven Repository.

Brianf	Posted: November 06, 2009 20:49 by Brianf » Permalink
	Yes, if we get Nexus setup and have a single location for all the kenai artifacts, then the next step would be to sync to central. Is there someone I can contact to see about moving this forward?

john_brock

Posted: November 06, 2009 23:36 by john_brock

» Permalink

Hi Brian,

It will be a little while before this feature would added to the site. Many other things ahead of it still in the priority list.

If you are someone that can help with the sync to central once we do get it all hooked up, please drop a note to the kenai-admin<at>sun.com email alias and we'll keep your contact info on file for when we do get there.

Thanks for the interest in helping out.

--jb

The Project Kenai Team

Werner Keil	Posted: July 23, 2009 16:18 by Werner Keil » Permalink
	If you plan to add Maven support, considering Apache Maven Continuum CI is also worth while. Would be a good alternative to Hudson to offer more than one choice on that both of which are Open Source.