Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (nike.apache.org: domain of carlossg@gmail.com designates
 209.85.211.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=Pb+7BrYVyUO0yEHtXOpgcb8Ekl8cbXO4HquVbPjxHN9vBW/z5yHduQdPv2Ils7sFZc
         Z/e2Toi41C8BOib6G7a+T1UjsRWmBn9NitMvoMnqReapmKAlo6KRKDePuDYBSbKu7fBI
         4KHr4M7dJnOx6OLcJLgj10K0HKR2NUfn2m9Tw=
MIME-Version: 1.0
Sender: carlossg@gmail.com
In-Reply-To: <4AC38510.6020909@sun.com>
References: <4AC35577.1040806@sun.com> <4AC36D2D.2030603@apache.org>
	 <e9b1dfc0909300825h7fb1f6l4a1b24b3928a66c2@mail.gmail.com>
	 <4AC37FCB.1020606@sun.com>
	 <1a5b6c410909300901i7d4c32d3la9b9dfd625c23ab4@mail.gmail.com>
	 <4AC38510.6020909@sun.com>
Date: Wed, 30 Sep 2009 09:23:01 -0700
Message-ID: <1a5b6c410909300923u1d6fdfcbted825cf5de6a7f3e@mail.gmail.com>
Subject: Re: forcing a sync to the maven 2 repository
From: Carlos Sanchez <carlos@apache.org>
To: repository@apache.org
Content-Type: text/plain; charset=ISO-8859-1

if it's just the poms, then go for option a) copy the jars and the new
poms under _1

you can put them in a temporary folder in the web server and tell
users to try them  adding that url as a new repository


On Wed, Sep 30, 2009 at 9:19 AM, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> Thanks, Carlos. Note that the Derby zips and tarballs are fine. What is not
> correct are the poms which describe them to Maven users. Producing a release
> is a heavy-weight process for the Derby community. I do not think that the
> community will find the cycles for option (2). Our next release will
> probably happen next year.
>
> I would like to improve this situation for that next release, 10.6.1.0. Is
> there a process for test-deploying or staging release artifacts so that they
> can be vetted by Maven users before we commit them to Maven?
>
> Thanks,
> -Rick
>
> Carlos Sanchez wrote:
>>
>> it doesn't really matter if you deploy it to the maven repo or tha
>> apache dist folders, once it's out there it's a very bad idea to
>> distribute another thing with the same version.
>>
>> I'd go with b) and call it 10.5.3.1 but it depends on how "broken" the
>> release was
>>
>>
>> On Wed, Sep 30, 2009 at 8:56 AM, Rick Hillegas <Richard.Hillegas@sun.com>
>> wrote:
>>
>>>
>>> Thanks Brian and Simon. Are you suggesting one of the following:
>>>
>>> 1) That we take the 10.5.3.0 distributions and redeploy them with a new
>>> Maven-specific identifier like 10.5.3.0_1?
>>>
>>> 2) That the Derby community spend a couple weeks vetting a new 10.5.4.0
>>> release, then try deploying that to Maven--perhaps repeating this process
>>> a
>>> couple times as we debug our understanding of Maven?
>>>
>>> 3) Something else?
>>>
>>> Thanks,
>>> -Rick
>>>
>>> Brian Fox wrote:
>>>
>>>>
>>>> Only new files are pulled in, like Simon said you need to change the
>>>> version if you want them to be updated. Even if we manually loaded
>>>> your jars, anyone in the world that already has a copy would not get
>>>> the new ones and it would just create chaos because it would work for
>>>> some and not others.
>>>>
>>>> Release artifacts are immutable. It's a fundamental tenet of Maven.
>>>> (and good CM practice to boot)
>>>>
>>>> On Wed, Sep 30, 2009 at 7:37 AM, Simon Kitching <skitching@apache.org>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> Rick Hillegas wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I hope that this is the correct mailing list for this question. If it
>>>>>> isn't, please point me in the right direction.
>>>>>>
>>>>>> The Derby project has been learning how to deploy our build artifacts
>>>>>> to
>>>>>> the maven 2 repository. This has involved a fair amount of learning
>>>>>> for
>>>>>> us because we don't use maven in our project builds--we use ant
>>>>>> instead.
>>>>>> However, I think that we have learned a fair amount and we are getting
>>>>>> close to being able to deploy our artifacts correctly.
>>>>>>
>>>>>> A while ago we copied broken artifacts to the staging area at
>>>>>>
>>>>>> /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/derby
>>>>>> and they were successfully sync'd to the corresponding maven 2
>>>>>> locations
>>>>>> at http://repo1.maven.org/maven2/org/apache/derby After we were told
>>>>>> that our artifacts were broken, we copied corrected versions to
>>>>>>
>>>>>> /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/derby
>>>>>> However, those corrected versions have not been sync'd to the maven 2
>>>>>> locations. How do we force a sync to occur?
>>>>>>
>>>>>>
>>>>>
>>>>> Maven artifacts should never be replaced/overwritten/removed after
>>>>> deployment. It causes all sorts of caching problems for maven users.
>>>>>
>>>>> The usual solution is simply to deploy a new version; users will get
>>>>> the
>>>>> latest version (ie the fixed one) unless they have specifically
>>>>> requested otherwise.
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>> Note: I'm not a repo administrator..
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>