ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Dependent modules where shared code rarely changes
Date Mon, 30 Jul 2012 15:40:07 GMT
A good practice is to have the fact that a version can change, even if
rarely, be reflected in the version number itself. So you might have a
-SNAPSHOT or -dev suffix or a -_timestamp_ suffix.

Beyond that, it's a good idea to publish the module with a status that
indicates that it is an integration version. The out-of-the-box status for
this is "integration". See the documentation for ivy:deliver and
ivy:publish to see about setting the status. Once you've done this, if you
have all your potentially changing, i.e. integration, versions going into a
particular Ivy repository/directory, then you can tell the Ivy resolver
pointing at that repo to never trust the cache. Do something like:
changingPattern="*" changingMatcher="glob"
Or the regular expression equivalent...

If you don't have a separate repository or directory for integration
versions, then you need to make use of the suffix in the version itself to
indicate it could change. And then specify changingPattern accordingly. But
even if you do have a separate repo for integration versions, it's just
good practice to incorporate the changeability of the module into the
version. When you see a revision like 3.0.1, it's a good indication that
this is a release version.

On Mon, Jul 30, 2012 at 8:26 AM, Chris Rimmer <chrisr@we7.com> wrote:

> I am in the process of splitting up a large codebase and hoping to start
> using ivy to manage dependencies. As a first step, I have split it into two
> pieces, A and B. There is some shared code used by both A and B. This is
> held in a jar file which is an artifact of A and used by B. I don't
> anticipate this shared code changing very often, so I am quite happy to
> manage the versions manually. So the version number of module A is just
> held in a properties file checked into source control. The initial version
> (0.1) is published in a shared repository (the shared jar is the only
> artifact) and B has a dependency on v0.1.
>
> What I would like to do would for our continuous integration process to
> detect if the shared code has been changed, but the version number has not
> been incremented. So someone has probably forgotten to publish a new
> version of A having changed the shared code. While it is possible to find
> the latest version of a module using the <ivy:findrevision> ant task, it
> does not seem to be easy to compare what is built from version control with
> what it is in the shared repository.
>
> My question is, am I approaching this the wrong way and if so, what should
> I be doing to handle this differently?
>
> Thanks
>
> Chris
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message