Hi Jason, thank you for your detailed reply.
On 6 April 2011 13:59, Jason van Zyl wrote: >> On Apr 6, 2011, at 8:33 AM, Tim Pizey wrote: >> >> Hi Jason, Marc, >> >> Thankyou for your help. >> >> I am now back to working for M2 and M3, but it looks like I need to >> get with the plot and use Nexus. >> >> I have never understood why the maven generated site does not link to >> the default distribution repo., > > I think this would be a harmful conflation of concerns. > The site plugin's > concern is documentation, that people try to use it as a general purpose > publishing mechanism is bad. I think that this is where we differ. The beauty of Maven, as I saw it, was the conflation of code and documentation. Particularly in a CI environment there is no reason for the code and documentation to get out of step. By separating the two we have allowed the two fail situations: 1. where the artifact in the public repositories has no up-to-date documentation. 2. where the documentation exists but not the artifact referred to. I cannot see the case for publishing an artifact without publishing the site, the two steps need to be separated on a developers machine, but they should, in my view, not be separable at the publishing step. > But additionally we have found cases where > projects have published their own repositories and then don't maintain them. > They vanish, people complain and then Maven is blamed. There is no reason why central should not be an aggregating service, just not the source, so a decentralised model does not entail Maven being blamed. As long as the site has existed and the aggregator has seen it then it does not matter if the site disappears. > The chances are very > high that we can maintain your repository infrastructure better then you > can. No disputing that, I wiped mine yesterday :) It would be lovely if all previous versions were being stored elsewhere. > That's not meant to be a slight it's just that we do this everyday, > have full time people, it's monitored, replicated and users have come to > expect everything to just work, be production quality even though they are > depending heavily on an OSS infrastructure that they are not paying for. > We > try to provide that infrastructure because we know how many things can, and > do, go awry. > > > nor why the decision was taken not to persue per dependency repos. > > If by this you mean why we don't let everyone maintain their own > repositories and aggregate them? That was not what I meant, though it is what I think would be best. What I meant was that you are not able to specify in the pom a repository for a particular dependency. So to use say http://webmacro.sourceforge.net/maven2/ for one dependency it has to be polled for every dependency. There is an issue in JIRA on this marked 'won't fix'. > The answer to this is that if it were a > consortium of enterprises who's viability depended on the availability of > the repositories it might work. But with OSS projects that come and go, many > networks that go up and down, security concerns, possible outages, and the > general dissipation of interest we know that it would cause an unacceptable > level of grief for users and the system would likely collapse if everyone > just tried to manage their own repositories. I cannot think of the major OOS infrastructure sites which have disappeared. sourceforge? google code ? java.net ? I am not suggesting that there is no role for repo1 or Nexus, just that they should pull not require projects to push. > That said there is nothing stopping any project from publishing their own > repositories and providing instructions on how to use that repository as > part of project build. Users don't like it. The distributed approach is nice > in theory, but for a bunch of OSS projects in practice it fails. We've had > lots of example of project releasing to repositories, publishing POMs and > then the repositories being removed. I am not sure which ones you are thinking of, but only ones I can think of that have disappeared have been corporations. The core open source organisations are stronger than ever: apache, codehaus, sourceforge, googlecode I think they can now be taken for granted and bet on to outlast any commercial concern. >> The central repo strategy has failed a few times since maven1, and the >> repo-as-proxy (Nexus) >> would make even more sense if it were proxying a lot of other small repos. > > Maven Central since being on Contegix has had very little downtime. While on > Ibiblio, yes it stopped working all the time. That's why I moved it off > Ibiblio a long time ago. I think users of Maven Central get pretty good > service for something they don't pay for. Sure, I love the net, there is lots of free stuff on it. >> I just do not see why, as a project owner, with control over my own >> webspace I should have to involve a third party to distribute my >> artifacts. > You're not forced at all. But most Maven users have come to expect artifacts > to be in Maven Central. If you provide the instructions they can build using > your artifact wherever they are. But here the burden is on you. I feel that that burden has been engineered by the dislocation of the artefact from its documentation. > The vast > majority of users publish and consume via HTTP and expect artifacts to be in > Maven Central. That is the what we choose to support well. The SSH libraries > for Java are flaky, using executables is fraught with permissions problems, > platform problems while the HTTP libraries are far more reliable in general. > Additionally I doubt there is a single Maven developer who uses SCP to > deploy and we are all generally in favor of repository managers. So in the > spirit of OSS why would we scratch an itch non of us have. Fair point. >> Why not have a default repo generated as part of the site >> plugin? > > > What's stopping you from implementing that? I would love to, I struggle to make the time. > I personally think it's a bad idea, and would result in large scale failure. > I would never implement it but if you wanted to add that functionality to > the site plugin there's nothing stopping you. > Whether that approach would be > popular you would find out. Would the change be accepted if you thought it was a bad idea? > I believe you are in the great minority using SCP to deploy, as such much of > the burden to support this approach is yours. I will need to catch up. Presumably using basic-auth over https? Thanks for your reply, it is very cool that the project lead still finds time to reply to the user list. cheers Tim -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
