Re: [cross-project-issues-dev] deploying snapshot builds from hudson.e.o

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

"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
jesse.mcconnell@xxxxxxxxx



On Fri, Dec 9, 2011 at 07:38, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> 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
> jesse.mcconnell@xxxxxxxxx
>
>
>
> On Fri, Dec 9, 2011 at 06:43, Wayne <wayne@xxxxxxxxxxx> 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 <gunnar@xxxxxxxxxxxxxxx> 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
>>>gunnar@xxxxxxxxxxxxxxx
>>>http://wagenknecht.org/
>>>_______________________________________________
>>>cross-project-issues-dev mailing list
>>>cross-project-issues-dev@xxxxxxxxxxx
>>>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev