www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Sanchez <car...@apache.org>
Subject Re: forcing a sync to the maven 2 repository
Date Wed, 30 Sep 2009 16:23:01 GMT
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..
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Mime
View raw message