Hi Stian, > If you do start your own repository, and there's nothing in the > license of say Asyncweb or Simple preventing you from doing so, you > can include those artefacts in that repository as well. Ideally > adding the repository for Restlet and the dependency for the chosen > Restlet artefacts should then be able to pull down automatically the > rest.
That's what we thought too. Controlling the repository allows us to fix some dependencies with broken POMs or dependencies missing from other public Maven repositories. > > 1) fully free > > If you go for #1 I can contribute with at least 2 mirror sites which > should have enough bandwidth available. Thanks for the proposition. I will keep that in mind when needed :) > A commercial maven repository for a so-called open source project > don't sound quite right for me - what would prevent me from making a > competing "free" maven repository that would more easily get support > and possibly later merged with ibiblio? And if so - what is then the > point of the commercial repository except to encourage forking..? OK, let's cleanly separate things. There would be two repositories: 1) "maven.restlet.org" with a free access 2) "maven.noelios.com" with an access restricted to subscribers If we automate the refresh of the first repository every week (and immediately in case of a major security issue), I think this is reasonable for most projects depending on Restlets. What do you think? The second repository would be immediately refreshed with new releases, could also contain customer specific patches, provide a secure access, etc. The idea is to offer some extra features to Noelios customers who subscribe to a support plan, not to exclude other types of usages. I acknowledge that there are different ways to contribute to the Restlet project (code contributions, bug reports, suggestions, communication, etc.). > For me, Maven 2, definitively. I don't see a point in a maven 1 > repository, as Vincent points out, typical Restlet users are not > using Maven 1. OK, unless others disagree, we will follow your advice. > Maven 2 has lots of functionality built-in (OK, it's all > plugins) for > deploying to repositories, for instance using scp towards an Apache- > hosted (or Restlet-directory hosted, I Guess) directory. In our case, the build machine would be also hosting the repository, so the deployment part is easy. > The Maven book "Better builds with Maven" - available for free from > http://www.mergere.com/common/reg.jsp?form_source=m- > m2book&form_landing=DefaultPage - should have some references. You > don't have to move the whole build process to Maven to do the > deploy, although of course in the long run it could be worthwhile to > do that as well. Understood, its mostly a packaging/distribution indeed. We don't want to move to Maven yet as it doesn't play well with Eclipse plugins organization (flat structure), and beside that Ant fully satisfied us so far. Best regards, Jerome
