www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Problems with unwanted published artifacts
Date Tue, 21 Oct 2008 12:00:03 GMT
> The real problem is what we should have used the maven release plugin.

Well, I would debate that. Personally I think the maven-release-plugin sucks, badly. But I
agree that it does have the (one) advantage that it ensures the version-number in trunk is
set to SNAPSHOT.

I would suggest that the "real problem" is that you have the <repository> tag of your
<distributionManagement> section pointing at the repo used for mirroring to ibiblio.
If this pointed at a staging repo (which is NOT mirrored) then "mvn deploy" would not do any
harm even when a snapshot is mislabelled as prod. Well, it would stomp on your release-candidate
in the staging repo which might not be nice, but hopefully someone would spot that.

See the master pom for the Apache MyFaces project for example:
  http://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
which has
  <repository>
    <id>myfaces-staging</id>
    <name>Apache MyFaces Staging Repository</name>
    <url>scpexe://people.apache.org/www/people.apache.org/builds/myfaces/m2-staging-repository</url>
  </repository>

Regards,
Simon


Guillaume Nodet schrieb:
> The main problem is that:
>   * we did not use the maven release plugin to create these releases
>   * the version was manually bumped to a non snapshot version
>   * artifacts were uploaded to a staging repo and a vote called
>   * the version has not been reverted to snapshot immediately after
> creating the tags
>   * we have nightly scripts that run a "mvn deploy" on those projects
>
> So the problem is that our nightly scripts deployed non snapshots
> artifacts, hence they ended up in the m2-ibiblio-rsync-repository
> instead of the snapshot repository.
> Makes sense ?
> The real problem is what we should have used the maven release plugin.
>
> On Tue, Oct 21, 2008 at 12:13 PM, Simon Kitching <skitching@apache.org> wrote:
>   
>> I don't quite understand. If a project uses staging then snapshots
>> (should) get deployed to a snapshot repo, and releases get deployed to a
>> staging repo. Only after a release vote passes would someone manually
>> run the stage plugin to move the approved binaries that are in the
>> staging repo to the mirror dir. So even if a snapshot accidentally got
>> deployed like a release, only the staging dir would be affected and not
>> the mirror. At least that's how I would imagine things would be set up
>> when using the stage plugin.
>>
>> Have I misunderstood something? (NB: not important; I'm just curious...)
>>
>> Guillaume Nodet schrieb:
>>     
>>> We do use the staging plugin, but these artifacts have been uploaded
>>> because the trunk stayed with a release version longer than needed and
>>> our nightly deploy scripts thus deployed those non snapshots
>>> artifacts.
>>>
>>> On Tue, Oct 21, 2008 at 10:03 AM, Simon Kitching <skitching@apache.org>
wrote:
>>>
>>>       
>>>> Anyone who has tried to use one of these also has a cached copy that
>>>> will not be updated when the version on the mirror changes (maven
>>>> doesn't bother checking for modifications because officially-released
>>>> artifacts should never change).
>>>>
>>>> So I think the best thing to do here is to release
>>>> checksum-maven-plugin-1.0.1 etc, and put up a notice on your website
>>>> saying that 1.0 should not be used. As Carlos says, once it is out there
>>>> it really isn't easy to recall.
>>>>
>>>> It is also possible to set maven up so that a "release" deploys to a
>>>> temporary repository, then the artifact can be moved to the actual repo
>>>> (the mirror dir in this case) either manually (plain "cp" on
>>>> people.apache.org) or via the "stage" plugin. I haven't used the "stage"
>>>> plugin myself but I believe this is the approach that the maven
>>>> developers recommend.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>> Carlos Sanchez schrieb:
>>>>
>>>>         
>>>>> the problem is that they are already propagated to all mirrors, so
>>>>> changing them in one is not going to do any good
>>>>>
>>>>> On Mon, Oct 20, 2008 at 12:24 AM, Guillaume Nodet <gnodet@gmail.com>
wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> We have a problem with some artifacts having been deployed onto the
>>>>>> m2-ibiblio-rsync-repository.
>>>>>> These artifacts are:
>>>>>>  http://repo1.maven.org/maven2/org/apache/servicemix/tooling/checksum-maven-plugin/1.0/
>>>>>>  http://repo1.maven.org/maven2/org/apache/servicemix/tooling/features-maven-plugin/1.0/
>>>>>>  http://repo1.maven.org/maven2/org/apache/servicemix/tooling/xfire-maven-plugin/4.0/
>>>>>>  http://repo1.maven.org/maven2/org/apache/servicemix/tooling/res-maven-plugin/4.0/
>>>>>>
>>>>>> The problem comes from the fact that we are in the process of
>>>>>> releasing those artifacts and the trunks has been mistakenly changed
>>>>>> to a release number and were not changed back to a SNAPSHOT version
>>>>>> after the tag has been cut.  Our nightly deployment scripts has thus
>>>>>> deployed the released version of those artifacts instead of SNAPSHOTS
>>>>>> are they are supposed to do.
>>>>>>
>>>>>> Is there a way that those artifacts can be removed from the central
>>>>>> maven repo until the official vote is closed and artifacts correctly
>>>>>> uploaded ?
>>>>>>             
>>
>
>
>
>   


Mime
View raw message