"Eclipse-based builds exporting directly from eclipse.org Hudson to third-party repositories is a violation of vendor neutrality."
a simple caveat would address that as well, while sonatype.org may be in the url the first part is 'oss' which has been a massive help to countless open source projects seeking a simple path to maven central....its less a vendor repository in the traditional sense and more of an open source repository, akin to pushing artifacts from eclipse.org -> maven central imo at least jesse -- jesse mcconnell [email protected] On Fri, Dec 9, 2011 at 07:38, Jesse McConnell <[email protected]> wrote: > To make the maven.eclipse.org instance really useful it needs to have > staging support which is not in the version of nexus there at the > moment. If that were to exist then I would certainly be willing to > invest a bit of time to help make it the place for eclipse maven > artifacts, with syncing to central etc. I would even push on the > orbit->eclipse issue...but in its current state its not worth > investing more time in. > > and until there is staging support (and central syncing) its just not > worth trying to use it as the deployment location for jetty...I make > mistakes and staging can catch them. :) > > anyway, aside from that addition, I agree with igor. I mailed the > webmasters last week about getting access to the disk to clean up the > errors that igor mentioned, but haven't heard back. I realize I ought > to have opened a bugzilla issue for it, but if your giving access to > experts on it then at the least the sonatypes guys ought to have disk > access to the instance. I could have fixed the days long battle with > that maven.eclipse.org instance in a couple of minutes, instead I now > have settings.xml files checked into source repositories and > indigestion thinking about it. Or shoot, just give the keys to the > maven.eclipse.org instance and ask them to make it a best practices > setup for p2/mvn artifacts. Now that tycho is running into these > issues perhaps we can get momentum to address these things. > > cheers, > jesse > > -- > jesse mcconnell > [email protected] > > > > On Fri, Dec 9, 2011 at 06:43, Wayne <[email protected]> wrote: >> The EF hasn't taken over maven.eclipse.org yet. We've approached this like >> we approached git and gerrit: set up a server, give access to experts, >> provide support to them while they sorted it out. Once the experts have it >> sorted out, the EF takes over responsibility, works out robustness, and >> scalability issues, etc. >> >> We're still very much in the first stage. If something needs to be done >> better or different, we are dependent on experts stepping up to weigh in and >> help. >> >> Am I naive to think that this is a point-in-time issue? >> >> In my mind, the ideal is that we have maven.eclipse.org as the official >> repository. Projects can deploy directly to it from eclipse.org Hudson. We >> can replicate selected artifacts from there to Maven Central and anywhere >> else they need to go. >> >> This is very much like what we do with our git repositories and GitHub >> today. There is vendor neutrality because we can easily accommodate >> alternative vendors who want to do something similar. >> >> FWIW, I'm in favour of a project like Tycho doing what needs to be done in >> the short term while we sort this out. By its nature, Tycho needs to be in a >> Maven repo. However, in the long term, vendor neutrality issues need to be >> addressed. >> >> Wayne >> >> Gunnar Wagenknecht <[email protected]> wrote: >> >>>Am 09.12.2011 07:13, schrieb Igor Fedorenko: >>>> I honestly think you are overreacting. oss.sonatype.org is just an >>>> artifact repository, a file server essentially. >>> >>>Vendor neutrality is important. Why isn't it possible to publish to >>>download.eclipse.org (or whatever.eclipse.org) and then mirror the bits >>>you need? >>> >>>Becoming a mirror is dead easy. >>>http://www.eclipse.org/downloads/mir_request.php >>> >>>> Third, maven.eclipse.org has to be officially supported part of eclipse >>>> infrastructure and treated the same way as download.eclipse.org from >>>> availability and reliability point of view. >>> >> >From what I've heard, Maven/Tycho will play an important role in the >>>coming common build infrastructure. Thus, I think that it may be >>>possible to support that system like Hudson. >>> >>>> Things like 365727 [1] simply should not happen. >>> >>>Frankly, I don't really see who is too blame for the issue. It could >>>very likely be a bug in the software being used. It could also be a user >>>error. In any case, you certainly can't expect that such issues won't >>>happen even if you hire dedicated server operators. >>> >>>> Fourth, Eclipse Foundation needs to decide if maven.eclipse.org should >>>> be synced to the Central repository or not and negotiate with Sonatype >>>> conditions and procedures if the sync is desired. >>> >>>That confuses me a bit. Anybody is free to setup an Eclipse mirror at >>>their will. No negotiation is necessary. Can't Sonatype just mirror >>>maven.eclipse.org as others mirror download.eclipse.org? I'm pretty sure >>>Denis is willing to allow rsync from maven.eclipse.org as well. >>> >>>-Gunnar >>> >>>-- >>>Gunnar Wagenknecht >>>[email protected] >>>http://wagenknecht.org/ >>>_______________________________________________ >>>cross-project-issues-dev mailing list >>>[email protected] >>>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
