www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: forcing a sync to the maven 2 repository
Date Wed, 30 Sep 2009 16:19:28 GMT
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..
>>>>
>>>>
>>>>         
>>     


Mime
View raw message