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 18:21:02 GMT
Thanks Brian and Carlos. I have created a new distribution called 
10.5.3.0_1. It contains the Derby 10.5.3.0 jars and better poms. I have 
asked for feedback from the user who filed the following issue against 
the broken poms: https://issues.apache.org/jira/browse/DERBY-4390 I have 
temporarily staged the new distribution at

    http://people.apache.org/~rhillegas/repository/org/apache/derby/

Thanks,
-Rick

Brian Fox wrote:
> I agree, I would go with renaming them in this case, instead or
> respinning a whole new release.
>
> Regarding staging, you can deploy them to an alternate location for
> vetting prior to release. You could also use
> http://nexus.sonatype.org/oss-repository-hosting.html which very
> shortly will have rules to check certain quality issues before
> allowing things to be promoted and synced. (the deployment in this
> case is an http put, so I don't know if this is a change to your
> current build or not, but it's an option)
>
> On Wed, Sep 30, 2009 at 9:23 AM, Carlos Sanchez <carlos@apache.org> wrote:
>   
>> 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