Jason, William,

       Thanks for the clarifications.   The information will certainly help
in setting
up for the next release cycle.


cheers,

     mehul



On Tue, Jun 3, 2014 at 12:29 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:

> Mehul, this is the wrong pattern to use. It goes against the entire Maven
> dependency mechanism.
>
> Each GAV (aside from snapsghots) should represent a unique build.
>
> You should be creating new RC GAVs for each release candidate. eg
> groupX-artifactX-versionZ.rc1
>
> William
>
>
>
> On Tue, Jun 3, 2014 at 12:27 PM, Mehul Sanghvi <mehul.sang...@gmail.com>
> wrote:
>
> > We use SNAPSHOT during development, say 1.1.0-SNAPSHOT.  At code freeze,
> we
> > branch off from main line to a version specific branch and remove
> SNAPSHOT
> > from the version string, so it becomes 1.1.0.  Between code freeze and
> > release we have RC builds.  Its at that point that when a newer build of
> > the same artifact is uploaded, so the GAV is identical,
> > maven will not download the newest build.  So its the same JAR file being
> > uploaded, with the same version.  The only thing changing is the file
> size
> > and time stamp of the uploaded
> > artifact.
> >
> > So I have fubar-1.1.0.jar uploaded to Nexus.  The consumer picks up this
> > jar file and downloads to ~/.m2.  Now we find some problems with it, and
> > there is an update.  So a newer
> > fubar-1.1.0.jar is uploaded, over-writing the old one.  Then next time a
> > build of the consuming project is run, it does not download the newly
> built
> > fubar-1.1.0.jar.  Based on what
> > you're saying, this is a feature and the right way to do things, correct
> ?
> >
> >
> > Than, how do folks handle RC versions ?
> >
> >
> >
> > cheers,
> >
> >      mehul
> >
> >
> >
> >
> >
> > On Mon, Jun 2, 2014 at 6:54 PM, Jason van Zyl <ja...@takari.io> wrote:
> >
> > > Are you deploying different artifacts with the same version? Release
> > > versions are expected to be immutable and Maven will not try to
> download
> > a
> > > released artifact again because it's not expected to change. If you are
> > > deploying different artifacts using the same version you are using
> Maven
> > > incorrectly.
> > >
> > > On Jun 2, 2014, at 6:06 PM, mehul.sang...@gmail.com wrote:
> > >
> > > >
> > > > We have a Nexus server to which various projects upload artifacts.
> > > > The artifacts are uploaded to a release repository, not a snapshot
> > > repository.
> > > >
> > > > One project is just a consumer of the artifacts.  It does not upload
> > > anything.
> > > >
> > > > Even though we have an updated artifact available, the consuming
> > project
> > > does not download the artifacts from nexus until we clear out the local
> > > repo in ~/.m2.
> > > >
> > > > How does Nexus / Maven determine that a new artifact needs to be
> > > downloaded from the remote repo?  The timestamp reflects the time of
> > upload
> > > of the artifact.  So what am I missing ?
> > > >
> > > > The GAV is of the form:
> > > >
> > > >     group:artifact.id:group.artifact.id-11.1.0.jar
> > > >
> > > > When a new group.artifact.id-11.1.0.jar is uploaded, it won't get
> > > downloaded by the consuming project.
> > > >
> > > >
> > > > cheers,
> > > >
> > > >         mehul
> > > >
> > > > --
> > > > Sent from my "smart" phone
> > > >
> > > >
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder,  Apache Maven
> > > http://twitter.com/jvanzyl
> > > http://twitter.com/takari_io
> > > ---------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Mehul N. Sanghvi
> > email: mehul.sang...@gmail.com
> >
>



-- 
Mehul N. Sanghvi
email: mehul.sang...@gmail.com

Reply via email to