You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Borut Bolčina <bo...@gmail.com> on 2007/11/26 08:31:45 UTC
Version moving up fast
Hello maven users,
if one of our in-house jars (lets call it A.jar) is progressing fast in
terms of artifact version numbers (several times per week: 2.1 -> 2.2
-> 2.3-> ... - >
2.678 -> 2.679 -> ...), what is the best way for other artifacts which
depend on this "fast one" to always use the last one? All the artifacts
which depend on the A, would have to have their poms modified to
2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
trunk. This is error prone. I haven't looked into the release plugin yet,
but I don't think it addresses this issue.
One solution might be to name the A's version to something like 999-SNAPSHOT
and then all the other jars would have their dependencies to this version.
This smells like a dead fish in the sewer to me.
What do you say?
Re: Version moving up fast
Posted by Kalle Korhonen <ka...@gmail.com>.
Unfortunately what I suggested doesn't work because of
http://jira.codehaus.org/browse/MDEPLOY-44 - setting uniqueVersion from the
command line doesn't work together with deploy:deploy, only with
deploy:deploy-file - of course you could use the latter but it gets even
more cumbersome.
Kalle
On 11/26/07, Kalle Korhonen <ka...@gmail.com> wrote:
>
> If you are releasing something, I think it's wrong to force your clients
> to move onto the new versions. If the client modules using your module would
> be in control of what they use, they'd update versions in their own
> schedule, even skip some. I haven't tried, but I wonder if it'd work to use
> both unique and non-unique versions. If you "release" for archiving
> purposes, you could could just post a unique snapshot, otherwise you'd use
> non-unique snapshots. You'd need to check if dependency resolution works
> correctly in all cases with this approach.
>
> Kalle
>
>
> On 11/25/07, Borut Bolčina <bo...@gmail.com> wrote:
> >
> > Hello maven users,
> >
> > if one of our in-house jars (lets call it A.jar) is progressing fast in
> > terms of artifact version numbers (several times per week: 2.1 -> 2.2
> > -> 2.3-> ... - >
> > 2.678 -> 2.679 -> ...), what is the best way for other artifacts which
> > depend on this "fast one" to always use the last one? All the artifacts
> > which depend on the A, would have to have their poms modified to
> > 2.1-SNAPSHOT , 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
> > trunk. This is error prone. I haven't looked into the release plugin
> > yet,
> > but I don't think it addresses this issue.
> >
> > One solution might be to name the A's version to something like
> > 999-SNAPSHOT
> > and then all the other jars would have their dependencies to this
> > version.
> > This smells like a dead fish in the sewer to me.
> >
> > What do you say?
> >
>
>
Re: Version moving up fast
Posted by Kalle Korhonen <ka...@gmail.com>.
If you are releasing something, I think it's wrong to force your clients to
move onto the new versions. If the client modules using your module would be
in control of what they use, they'd update versions in their own schedule,
even skip some. I haven't tried, but I wonder if it'd work to use both
unique and non-unique versions. If you "release" for archiving purposes, you
could could just post a unique snapshot, otherwise you'd use non-unique
snapshots. You'd need to check if dependency resolution works correctly in
all cases with this approach.
Kalle
On 11/25/07, Borut Bolčina <bo...@gmail.com> wrote:
>
> Hello maven users,
>
> if one of our in-house jars (lets call it A.jar) is progressing fast in
> terms of artifact version numbers (several times per week: 2.1 -> 2.2
> -> 2.3-> ... - >
> 2.678 -> 2.679 -> ...), what is the best way for other artifacts which
> depend on this "fast one" to always use the last one? All the artifacts
> which depend on the A, would have to have their poms modified to
> 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
> trunk. This is error prone. I haven't looked into the release plugin yet,
> but I don't think it addresses this issue.
>
> One solution might be to name the A's version to something like
> 999-SNAPSHOT
> and then all the other jars would have their dependencies to this version.
> This smells like a dead fish in the sewer to me.
>
> What do you say?
>
Re: Version moving up fast
Posted by Tom Huybrechts <to...@gmail.com>.
that only works for plugins, not for compile dependencies...
I have the same problem, but I do my versioning slightly different.
When I release my 1.0.0-SNAPSHOT, I'll make the release version
1.0.0.v20071126, and keep the development version at 1.0.0-SNAPSHOT...
Tom
On Nov 26, 2007 5:32 PM, EJ Ciramella <ej...@upromise.com> wrote:
> I don't remember exactly (and my list of mvn bookmarks aren't working as well as they used to), but my recollection is if you put nothing for version number, it depends on the metadata stored in your internal repository (as long as that is kept up to date). Or was there a way to say "use the release version", again, relying on your metadata.xml file in your internal repository....
>
>
> -----Original Message-----
> From: Borut Bolčina [mailto:borut.bolcina@gmail.com]
> Sent: Monday, November 26, 2007 2:32 AM
> To: Maven
> Subject: Version moving up fast
>
> Hello maven users,
>
> if one of our in-house jars (lets call it A.jar) is progressing fast in
> terms of artifact version numbers (several times per week: 2.1 -> 2.2
> -> 2.3-> ... - >
> 2.678 -> 2.679 -> ...), what is the best way for other artifacts which
> depend on this "fast one" to always use the last one? All the artifacts
> which depend on the A, would have to have their poms modified to
> 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
> trunk. This is error prone. I haven't looked into the release plugin yet,
> but I don't think it addresses this issue.
>
> One solution might be to name the A's version to something like 999-SNAPSHOT
> and then all the other jars would have their dependencies to this version.
> This smells like a dead fish in the sewer to me.
>
> What do you say?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Version moving up fast
Posted by Borut Bolčina <bo...@gmail.com>.
Hello,
2007/11/27, Ronn.Chinowutthichai@toyota.com.au
<Ronn.Chinowutthichai@toyota.com.au
>:
>
> It sounds odd to have that many release version per day.
Yes indeed. Well, not per day, but per week. Nevertheless, it is odd.
Version range
> notation would be perfect for what you need..
The first thing we will try is to use ranges like [2.1,)
If I understand ranges correctly, then whenever we release this fast moving
artifact (the version moves up) all the clients will pick the latest release
version. Someone mentioned 2.0.7 has problems with ranges? Is there a JIRA
issue?
Cheers,
Borut
i.e.,
>
> [2.1, )
>
> Having said that I found a number of problems with using version range and
> I am stuck with 2.0.6 because 2.0.7 gives me NPE when it tries to resolve
> conflict between version ranges.
>
> Cheers,
> rOnn c.
>
>
>
>
>
> "Borut Bolčina" <bo...@gmail.com>
> 11/26/2007 06:31 PM
> Please respond to
> "Maven Users List" < users@maven.apache.org>
>
>
> To
> Maven <us...@maven.apache.org>
> cc
>
> Subject
> Version moving up fast
>
>
>
>
>
>
> Hello maven users,
>
> if one of our in-house jars (lets call it A.jar) is progressing fast in
> terms of artifact version numbers (several times per week: 2.1 -> 2.2
> -> 2.3-> ... - >
> 2.678 -> 2.679 -> ...), what is the best way for other artifacts which
> depend on this "fast one" to always use the last one? All the artifacts
> which depend on the A, would have to have their poms modified to
> 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
> trunk. This is error prone. I haven't looked into the release plugin yet,
> but I don't think it addresses this issue.
>
> One solution might be to name the A's version to something like
> 999-SNAPSHOT
> and then all the other jars would have their dependencies to this version.
> This smells like a dead fish in the sewer to me.
>
> What do you say?
>
>
> ######################################################################
> DISCLAIMER:
> This email and any attachment may contain confidential information.
> If you are not the intended recipient you are not authorized to copy
> or disclose all or any part of it without the prior written consent
> of Toyota.
>
> Opinions expressed in this email and any attachments are those of the
> sender and not necessarily the opinions of Toyota.
> Please scan this email and any attachment(s) for viruses.
> Toyota does not accept any responsibility for problems caused by
> viruses, whether it is Toyota's fault or not.
> ######################################################################
>
RE: Version moving up fast
Posted by EJ Ciramella <ej...@upromise.com>.
I don't remember exactly (and my list of mvn bookmarks aren't working as well as they used to), but my recollection is if you put nothing for version number, it depends on the metadata stored in your internal repository (as long as that is kept up to date). Or was there a way to say "use the release version", again, relying on your metadata.xml file in your internal repository....
-----Original Message-----
From: Borut Bolčina [mailto:borut.bolcina@gmail.com]
Sent: Monday, November 26, 2007 2:32 AM
To: Maven
Subject: Version moving up fast
Hello maven users,
if one of our in-house jars (lets call it A.jar) is progressing fast in
terms of artifact version numbers (several times per week: 2.1 -> 2.2
-> 2.3-> ... - >
2.678 -> 2.679 -> ...), what is the best way for other artifacts which
depend on this "fast one" to always use the last one? All the artifacts
which depend on the A, would have to have their poms modified to
2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
trunk. This is error prone. I haven't looked into the release plugin yet,
but I don't think it addresses this issue.
One solution might be to name the A's version to something like 999-SNAPSHOT
and then all the other jars would have their dependencies to this version.
This smells like a dead fish in the sewer to me.
What do you say?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Version moving up fast
Posted by Ro...@toyota.com.au.
It sounds odd to have that many release version per day. Version range
notation would be perfect for what you need..
i.e.,
[2.1, )
Having said that I found a number of problems with using version range and
I am stuck with 2.0.6 because 2.0.7 gives me NPE when it tries to resolve
conflict between version ranges.
Cheers,
rOnn c.
"Borut Bolčina" <bo...@gmail.com>
11/26/2007 06:31 PM
Please respond to
"Maven Users List" <us...@maven.apache.org>
To
Maven <us...@maven.apache.org>
cc
Subject
Version moving up fast
Hello maven users,
if one of our in-house jars (lets call it A.jar) is progressing fast in
terms of artifact version numbers (several times per week: 2.1 -> 2.2
-> 2.3-> ... - >
2.678 -> 2.679 -> ...), what is the best way for other artifacts which
depend on this "fast one" to always use the last one? All the artifacts
which depend on the A, would have to have their poms modified to
2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the
trunk. This is error prone. I haven't looked into the release plugin yet,
but I don't think it addresses this issue.
One solution might be to name the A's version to something like
999-SNAPSHOT
and then all the other jars would have their dependencies to this version.
This smells like a dead fish in the sewer to me.
What do you say?
######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
######################################################################