Grokbase Groups Maven users May 2003
FAQ
I am looking for an explanation of the versioning functionality, and the
intended use cases.

Here is the scenario I am struggling with...

With regard to our internally developed components, we want to depend on the
most recent minor release. For example, we have a 1.4 release. Next week we
have a point release to fix a bug -- 1.4.1 (possibly 1.4.2, 1.4.3, ... in
the future). We want our components to depend on release 1.4, and use the
most recent point release of the 1.4 component.

Any suggestions or comments?

Search Discussions

  • Taft, Jason at May 15, 2003 at 11:50 am
    Anyone...

    -----Original Message-----
    From: Taft, Jason
    Sent: Wednesday, May 14, 2003 9:13 AM
    To: Maven Users List
    Subject: component versioning and usage rationale


    I am looking for an explanation of the versioning functionality, and the
    intended use cases.

    Here is the scenario I am struggling with...

    With regard to our internally developed components, we want to depend on the
    most recent minor release. For example, we have a 1.4 release. Next week we
    have a point release to fix a bug -- 1.4.1 (possibly 1.4.2, 1.4.3, ... in
    the future). We want our components to depend on release 1.4, and use the
    most recent point release of the 1.4 component.

    Any suggestions or comments?
  • Brian Ewins at May 15, 2003 at 2:17 pm
    There are a few ways to handle this. First off, if you have related
    projects, POM inheritance may well be a good way to go; it allows you to
    specify dependencies like this once only.

    Another approach (which seems to be used by the maven devs) is to use
    SNAPSHOT builds and 'flip' them to timestamped dependencies when you
    want to do a release. I dunno what the state of the release plugin is,
    you might want to try it out.

    A third approach if this is a team issue would be to work with SNAPSHOTS
    more during development. Your component might be eg 1.4.3, but the
    'main projects' would depend on 1.4-SNAPSHOT (ie the latest 1.4) until
    release time, when you'd manually change it to
    1.4.somethingmorerepeatable. This is possible with jars on ibiblio
    because I understand there's stuff up there maintaining links to
    snapshot versions - can anybody clarify this? However unless you have
    something which 'acts like' ibiblio you can't do this for your
    proprietary jars.

    So..... I've updated my repository webapp (attached maven project) to
    respond to requests for 'somejar-9.3-SNAPSHOT.jar' (for example) with
    the most recently modified file matching the regexp
    somejar-9\.3.*\.jar (or the 'real' SNAPSHOT jar if it exists). This
    isn't ideal - it will get things wrong if eg you upload "1.4.1" after
    "1.4.2" - and wont play well with branches being developed
    simultaneously. However, it does let you specify a SNAPSHOT dependency
    without actually having a SNAP on the corporate repo.

    Instructions for the webapp were posted a coupla weeks back, but theres
    only 5 classes, its easy to figure out.

    Hope this helps.
    -Baz

    Taft, Jason wrote:
    Anyone...

    -----Original Message-----
    From: Taft, Jason
    Sent: Wednesday, May 14, 2003 9:13 AM
    To: Maven Users List
    Subject: component versioning and usage rationale


    I am looking for an explanation of the versioning functionality, and the
    intended use cases.

    Here is the scenario I am struggling with...

    With regard to our internally developed components, we want to depend on the
    most recent minor release. For example, we have a 1.4 release. Next week we
    have a point release to fix a bug -- 1.4.1 (possibly 1.4.2, 1.4.3, ... in
    the future). We want our components to depend on release 1.4, and use the
    most recent point release of the 1.4 component.

    Any suggestions or comments?



  • Mark H. Wilkinson at May 15, 2003 at 2:20 pm

    On Thu, 2003-05-15 at 12:48, Taft, Jason wrote:
    With regard to our internally developed components, we want to depend on the
    most recent minor release. For example, we have a 1.4 release. Next week we
    have a point release to fix a bug -- 1.4.1 (possibly 1.4.2, 1.4.3, ... in
    the future). We want our components to depend on release 1.4, and use the
    most recent point release of the 1.4 component.

    Any suggestions or comments?
    As I understand it, you need to include the explicit version in the
    dependencies of the project. So, when you release a point release of a
    component (say 1.4.3) you would need to update project.xml for each
    project that depends on it.

    In a loosely coupled environment no other semantics would really be
    workable. If you could specify that you depend on version 1.4.x of a
    package (for any value of x), new minor releases of the package could
    quite easily break your project without you being aware of it. You might
    be (inadvertently) relying on some behaviour which the project owner
    thinks is actually a bug, and when they fix the bug your code will
    break.

    People have discussed a couple of approaches to factoring out
    dependencies shared by a number of projects. The options seem to be:

    * POM inheritance - use an <extend> element in project.xml to
    import dependencies from a fragment shared by a number of
    projects.
    * POM interpolation - use <version>${someProperty}</version> in
    project.xml and define the value of 'someProperty' in a property
    file shared by your projects.

    Both these approaches can allow you to update the dependencies of a
    number of projects by altering the version number in a single place.

    You might also want to read about SNAPSHOT dependencies, although they
    are intended to track the latest development version of an artifact
    rather than the latest released version of an artifact.

    -Mark.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Taft, Jason at May 15, 2003 at 2:34 pm

    In a loosely coupled environment no other semantics would really be
    workable. If you could specify that you depend on version 1.4.x of a
    package (for any value of x), new minor releases of the package could
    quite easily break your project without you being aware of it. You might
    be (inadvertently) relying on some behaviour which the project owner
    thinks is actually a bug, and when they fix the bug your code will
    break.
    This "breaking" is exactly what I'm looking for with regard to our
    internally developed dependencies -- Continuous Integration.

    I think SNAPSHOT dependencies will provide what I need (as long as I don't
    update 1.4.1 after 1.4.2). The only issue I have is that SNAPSHOTs are
    always downloaded from the repository whether the file is newer or not.

    thanks for the info.
  • Mark H. Wilkinson at May 15, 2003 at 3:08 pm

    On Thu, 2003-05-15 at 15:33, Taft, Jason wrote:
    In a loosely coupled environment no other semantics would really be
    workable. If you could specify that you depend on version 1.4.x of a
    package (for any value of x), new minor releases of the package could
    quite easily break your project without you being aware of it. You might
    be (inadvertently) relying on some behaviour which the project owner
    thinks is actually a bug, and when they fix the bug your code will
    break.
    This "breaking" is exactly what I'm looking for with regard to our
    internally developed dependencies -- Continuous Integration.
    Ahh; then snapshots will probably do what you're after. When you
    mentioned formal point releases I was thinking of something where you
    wanted a bit more control.
    I think SNAPSHOT dependencies will provide what I need (as long as I don't
    update 1.4.1 after 1.4.2). The only issue I have is that SNAPSHOTs are
    always downloaded from the repository whether the file is newer or not.
    The code in CVS has a fix for that bug, if you don't mind building maven
    yourself.

    -Mark.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Taft, Jason at May 15, 2003 at 7:45 pm
    Mark, somewhat related question...

    I've noticed that if a dependency exists in the local repository, the remote
    repositories will not be checked (or the JARs aren't downloaded if they are
    checked). Is this expected/unchanging behavior, or will newer versions of
    the JAR be pulled from the remote repositories in future releases (not
    SNAPSHOT dependencies).

    thanks again for all the info.

    -----Original Message-----
    From: Mark H. Wilkinson
    Sent: Thursday, May 15, 2003 11:08 AM
    To: Maven Users List
    Subject: RE: component versioning and usage rationale

    On Thu, 2003-05-15 at 15:33, Taft, Jason wrote:
    In a loosely coupled environment no other semantics would really be
    workable. If you could specify that you depend on version 1.4.x of a
    package (for any value of x), new minor releases of the package could
    quite easily break your project without you being aware of it. You might
    be (inadvertently) relying on some behaviour which the project owner
    thinks is actually a bug, and when they fix the bug your code will
    break.
    This "breaking" is exactly what I'm looking for with regard to our
    internally developed dependencies -- Continuous Integration.
    Ahh; then snapshots will probably do what you're after. When you
    mentioned formal point releases I was thinking of something where you
    wanted a bit more control.
    I think SNAPSHOT dependencies will provide what I need (as long as I don't
    update 1.4.1 after 1.4.2). The only issue I have is that SNAPSHOTs are
    always downloaded from the repository whether the file is newer or not.
    The code in CVS has a fix for that bug, if you don't mind building maven
    yourself.

    -Mark.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
  • Jason van Zyl at May 15, 2003 at 9:12 pm

    On Thu, 2003-05-15 at 15:44, Taft, Jason wrote:
    Mark, somewhat related question...

    I've noticed that if a dependency exists in the local repository, the remote
    repositories will not be checked (or the JARs aren't downloaded if they are
    checked). Is this expected/unchanging behavior, or will newer versions of
    the JAR be pulled from the remote repositories in future releases (not
    SNAPSHOT dependencies).
    Only SNAPSHOTs are downloaded if there is a newer version. Internally
    Maven considers a SNAPSHOT a failed dependency so a newer version will
    always be saught after.

    Otherwise Maven does what you tell it to. You must change your POM in
    order to get newer released versions of dependencies. It would make no
    sense for Maven to download 1.1 of foo when in your POM you have stated
    a dependency on 1.0 of foo.

    Maven does not automatically download newer released versions. It is the
    responsibility of those maintaining the POM to update the dependencies.
    Now there could be a tool to request updating the POM to the latest
    released version of foo i.e. to assist with an easy transition if you
    don't happen to know what the latest released version is but Maven does
    what it's told as far as retrieving dependencies.
    thanks again for all the info.

    -----Original Message-----
    From: Mark H. Wilkinson
    Sent: Thursday, May 15, 2003 11:08 AM
    To: Maven Users List
    Subject: RE: component versioning and usage rationale

    On Thu, 2003-05-15 at 15:33, Taft, Jason wrote:
    In a loosely coupled environment no other semantics would really be
    workable. If you could specify that you depend on version 1.4.x of a
    package (for any value of x), new minor releases of the package could
    quite easily break your project without you being aware of it. You might
    be (inadvertently) relying on some behaviour which the project owner
    thinks is actually a bug, and when they fix the bug your code will
    break.
    This "breaking" is exactly what I'm looking for with regard to our
    internally developed dependencies -- Continuous Integration.
    Ahh; then snapshots will probably do what you're after. When you
    mentioned formal point releases I was thinking of something where you
    wanted a bit more control.
    I think SNAPSHOT dependencies will provide what I need (as long as I don't
    update 1.4.1 after 1.4.2). The only issue I have is that SNAPSHOTs are
    always downloaded from the repository whether the file is newer or not.
    The code in CVS has a fix for that bug, if you don't mind building maven
    yourself.

    -Mark.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org
    --
    jvz.

    Jason van Zyl
    jason@zenplex.com
    http://tambora.zenplex.org

    In short, man creates for himself a new religion of a rational
    and technical order to justify his work and to be justified in it.

    -- Jacques Ellul, The Technological Society


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
    For additional commands, e-mail: users-help@maven.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmaven
postedMay 14, '03 at 1:14p
activeMay 15, '03 at 9:12p
posts8
users4
websitemaven.apache.org
irc#maven

People

Translate

site design / logo © 2019 Grokbase