Hi Chris,
I just noticed that the ivy pattern for your internal repo does not distinguish
between different revisions-this means that, while you might have multiple
revisions of an artifact, you will only have a corresponding ivy.xml file for
one of them (probably either the newest or the oldest one). When I replicated
this situation (multiple jars, one ivy file), I was able to reproduce your
issue.
The easiest solution is to change your repository layout to include the
[revision] tag for ivy.xml (e.g. the ivy pattern could become
"${repository.dir}/[organisation]/[module]/ivy-[revision].xml"). Another
solution would be to change the layout to include the revision number as a
directory (e.g.
"${repository.dir}/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
for the artifact pattern and
"${repository.dir}/[organisation]/[module]/[revision]/ivy.xml" for the ivy
pattern).
Doug Glidden
Software Engineer
The Boeing Company
[email protected]
-----Original Message-----
From: Nappin, Chris (IT Services) [mailto:[email protected]]
Sent: Wednesday, October 21, 2009 11:51
To: [email protected]
Subject: RE: How to use dynamic revisions
Hi,
Thanks for the suggestions, I've tried these out and still no joy ;-(
Here are my current settings in full, my repository is hand-built and an
example module descriptor is on my previous post. I'm using Ivy 2.0, is this an
issue fixed in 2.1? If anyone can shed any light on this I'd be very grateful,
otherwise I'm not sure ivy is going to be of quite the benefit I hoped it would
be:
<ivysettings>
<!-- the local repository -->
<property name="repository.dir" value="${basedir}/ivy-repo"/>
<!-- prevents copying artifacts from local repository to cache -->
<caches useOrigin="true"/>
<!-- only use the local repository -->
<settings defaultResolver="internal" validate="true"/>
<resolvers>
<!-- only use the local repository, never use ibiblio over the internet
etc... -->
<filesystem name="internal" local="true" validate="true"
checkmodified="true" changingPattern="*">
<ivy
pattern="${repository.dir}/[organisation]/[module]/ivy.xml" />
<artifact
pattern="${repository.dir}/[organisation]/[module]/[artifact]-[revision]
.[ext]" />
</filesystem>
</resolvers>
</ivysettings>
Best Regards,
Chris Nappin
Technical Architect, Application Services
Mob: 07824 473044
-----Original Message-----
From: Glidden, Douglass A [mailto:[email protected]]
Sent: 21 October 2009 14:10
To: [email protected]
Subject: RE: How to use dynamic revisions
Chris,
My practice is to never explicitly use the revConstraint
attribute-dynamic revision requirements can be put in the rev attribute,
and in the default resolve mode, the revConstraint attribute is ignored;
on the other hand, if the revConstraint attribute is not specified, it
defaults to being the same as the rev attribute, so if you use the
dynamic resolve mode, it should still work fine if only the rev
attribute is specified. So I would replace the spring dependency in
your ivy file with this:
<dependency org="spring" name="context" rev="2.0.+" conf="compile" />
In my experience, that has always worked fine, so I would say that if
you're having problems with it, it's probably an issue in your ivy
settings or the repository rather than with the ivy file itself. I
would start by removing defaultResolveMode="dynamic" from your
ivysettings.xml file-the dynamic resolve mode can cause problems with
build reproducibility, and from your description of what you're trying
to do, I'm pretty sure you do not need to use it.
Doug Glidden
Software Engineer
The Boeing Company
[email protected]
-----Original Message-----
From: Nappin, Chris (IT Services) [mailto:[email protected]]
Sent: Wednesday, October 21, 2009 04:34
To: [email protected]
Subject: RE: How to use dynamic revisions
Hi,
My project's ivy.xml file is as follows:
<ivy-module version="2.0">
<info organisation="example" module="example"/>
<configurations>
<conf name="compile" description="Libs used at compilation
time"/>
<conf name="runtime " description="Libs used at runtime"/>
<conf name="test" description="Libs used to compile and run
tests"/>
</configurations>
<dependencies>
<dependency org="spring" name="context" rev="2.0.8"
revConstraint="2.0.+" conf="compile"/>
..etc..
</dependencies>
</ivy-module>
And the module descriptor for this dependency is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="1.0" xmlns:m="http://ant.apache.org/ivy/maven";>
<info organisation="spring" module="context" revision="2.0.8"/>
<configurations>
<conf name="compile"/>
<conf name="runtime"/>
</configurations>
<publications>
<artifact name="spring-context" type="jar" ext="jar"/>
</publications>
<dependencies>
..etc..
</dependencies>
</ivy-module>
I was following the documentation
(http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.h
tml#revision) which I read to mean exact version numbers must go in
"rev" attributes, and dynamic ones in "revConstraint" attributes.
Anyway, I've tried both "rev" and "revConstraint" and they both fail
with the same message. If I use an exact number (e.g. 2.0.8) then it
works fine.
Best Regards,
Chris Nappin
Technical Architect, Application Services
Mob: 07824 473044
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Joshua Tharp
Sent: 20 October 2009 17:21
To: [email protected]
Subject: Re: How to use dynamic revisions
Where are you putting revConstraint="2.0.+"? To use dynamic versions, I
put
rev="2.0.+" in my ivy.xml file.
On Tue, Oct 20, 2009 at 8:53 AM, Nappin, Chris (IT Services) <
[email protected]> wrote:
> Hi,
>
> I have a very simple ivy setup working (using exact version numbers
> for everything). I'm now trying to move to dynamic revision
resolution,
> but it isn't working.
>
> My ivy-settings.xml contains the following:
>
> <settings defaultResolver="internal" defaultResolveMode="dynamic"
> validate="true"/>
>
> My ant build.xml contains the following:
>
> <ivy:retrieve pattern="${libs}/[conf]/[artifact]-[revision].[ext]" />
>
> My local repository contains artifacts such as "spring" (org)
"context"
> (module) "2.0.8" (revision).
>
> When I reference this dependency using rev="2.0.8", it is found. When
I
> use revConstraint="2.0.+" it fails as follows:
>
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve] :::: WARNINGS
> [ivy:retrieve] module not found: spring#context;2.0.+
> [ivy:retrieve] ==== internal: tried
> [ivy:retrieve]
> C:\limaloa-svn\code\trunk/ivy-repo/spring/context/ivy.xml
> [ivy:retrieve] [work...@internal]
> [ivy:retrieve] -- artifact spring#context;2.0.+!context.jar:
> [ivy:retrieve]
> C:\limaloa-svn\code\trunk/ivy-repo/spring/context/context-[rev
> ision].jar
> [ivy:retrieve] ::::::::::::::::::::::::::::::::::::::::::::::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::::::::::::::::::::::::::::::::::::::::::::::
> [ivy:retrieve] :: spring#context;2.0.+: not found
> [ivy:retrieve] ::::::::::::::::::::::::::::::::::::::::::::::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
>
> Best Regards,
>
> Chris Nappin
> Technical Architect, Application Services
> OPSERV - IT Services
> Mob: 07824 473044
> Part of the Capita Group plc www.capita.co.uk
<http://www.capita.co.uk/>
> www.capita-its.co.uk <http://www.capita.co.uk/>
>
> 'Evolving a great Operational IT Service through OPSERV'
>
>
>
> This email and any attachment are intended solely for the addressee,
are
> strictly confidential and may be legally privileged. If you are not
the
> intended recipient any reading, dissemination, copying or any other
use or
> reliance is prohibited. If you have received this email in error
please
> notify the sender immediately by email and then permanently delete the
> email. Copyright reserved.
>
> All communications, incoming and outgoing, may be recorded and are
> monitored for legitimate business purposes.
>
> The security and reliability of email transmission cannot be
guaranteed. It
> is the recipient's responsibility to scan this e-mail and any
attachment for
> the presence of viruses.
>
> The Capita Group plc and its subsidiaries ("Capita") exclude all
liability
> for any loss or damage whatsoever arising or resulting from the
receipt, use
> or transmission of this email.
>
> Any views or opinions expressed in this email are those of the author
only.
This email has been scanned for all viruses by the MessageLabs SkyScan
service.
This email and any attachment are intended solely for the addressee, are
strictly confidential and may be legally privileged. If you are not the
intended recipient any reading, dissemination, copying or any other use
or reliance is prohibited. If you have received this email in error
please notify the sender immediately by email and then permanently
delete the email. Copyright reserved.
All communications, incoming and outgoing, may be recorded and are
monitored for legitimate business purposes.
The security and reliability of email transmission cannot be guaranteed.
It is the recipient?s responsibility to scan this e-mail and any
attachment for the presence of viruses.
The Capita Group plc and its subsidiaries ("Capita") exclude all
liability for any loss or damage whatsoever arising or resulting from
the receipt, use or transmission of this email.
Any views or opinions expressed in this email are those of the author
only.
This email has been scanned for all viruses by the MessageLabs SkyScan
service.
This email and any attachment are intended solely for the addressee, are
strictly confidential and may be legally privileged. If you are not the
intended recipient any reading, dissemination, copying or any other use or
reliance is prohibited. If you have received this email in error please notify
the sender immediately by email and then permanently delete the email.
Copyright reserved.
All communications, incoming and outgoing, may be recorded and are monitored
for legitimate business purposes.
The security and reliability of email transmission cannot be guaranteed. It is
the recipient?s responsibility to scan this e-mail and any attachment for the
presence of viruses.
The Capita Group plc and its subsidiaries ("Capita") exclude all liability for
any loss or damage whatsoever arising or resulting from the receipt, use or
transmission of this email.
Any views or opinions expressed in this email are those of the author only.
