www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Problems with unwanted published artifacts
Date Tue, 21 Oct 2008 11:51:40 GMT

Guillaume,

I think the point Simon is trying to recommend is to change your pom to point 
your release repository to something like "file:/tmp/stage" or something 
OTHER than the apache synced repository.   Thus, in the future, if it happens 
again, it won't get deployed to the sync location.

Dan



On Tuesday 21 October 2008 7:44:00 am Guillaume Nodet wrote:
> 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-mav
> >>>>>en-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 ?
> >>>>>
> >>>>> --
> >>>>> Cheers,
> >>>>> Guillaume Nodet
> >>>>> ------------------------
> >>>>> Blog: http://gnodet.blogspot.com/
> >>>>> ------------------------
> >>>>> Open Source SOA
> >>>>> http://fusesource.com
> >>>
> >>> --
> >>> -- Emails in "mixed" posting style will be ignored
> >>> -- (http://en.wikipedia.org/wiki/Posting_style)
> >
> > --
> > -- Emails in "mixed" posting style will be ignored
> > -- (http://en.wikipedia.org/wiki/Posting_style)



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message