You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Mehul Sanghvi <me...@gmail.com> on 2014/06/03 04:27:33 UTC
Re: Nexus / Maven repository artifact handling
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.sanghvi@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.sanghvi@gmail.com
Re: Nexus / Maven repository artifact handling
Posted by Mehul Sanghvi <me...@gmail.com>.
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.ferguson@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 <me...@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.sanghvi@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.sanghvi@gmail.com
> >
>
--
Mehul N. Sanghvi
email: mehul.sanghvi@gmail.com
Re: Nexus / Maven repository artifact handling
Posted by William Ferguson <wi...@xandar.com.au>.
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 <me...@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.sanghvi@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.sanghvi@gmail.com
>