You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Rick Hillegas <Ri...@Sun.COM> on 2009/09/30 14:56:23 UTC
forcing a sync to the maven 2 repository
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?
Thanks,
-Rick
Re: forcing a sync to the maven 2 repository
Posted by Rick Hillegas <Ri...@Sun.COM>.
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 <ca...@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 <Ri...@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 <Ri...@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 <sk...@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..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
Re: forcing a sync to the maven 2 repository
Posted by Brian Fox <br...@sonatype.com>.
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 <ca...@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 <Ri...@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 <Ri...@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 <sk...@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..
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: forcing a sync to the maven 2 repository
Posted by Carlos Sanchez <ca...@apache.org>.
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 <Ri...@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 <Ri...@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 <sk...@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..
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: forcing a sync to the maven 2 repository
Posted by Rick Hillegas <Ri...@Sun.COM>.
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 <Ri...@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 <sk...@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..
>>>>
>>>>
>>>>
>>
Re: forcing a sync to the maven 2 repository
Posted by Carlos Sanchez <ca...@apache.org>.
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 <Ri...@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 <sk...@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..
>>>
>>>
>
>
Re: forcing a sync to the maven 2 repository
Posted by Rick Hillegas <Ri...@Sun.COM>.
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 <sk...@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..
>>
>>
Re: forcing a sync to the maven 2 repository
Posted by Brian Fox <br...@sonatype.com>.
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 <sk...@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..
>
Re: forcing a sync to the maven 2 repository
Posted by Simon Kitching <sk...@apache.org>.
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..