ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Problems with cache resolution
Date Tue, 09 Oct 2007 05:28:38 GMT
I'm in favor of considering one version as sealed, and this is the default
in Ivy. But Ivy also supports two kinds of change in a version:
- change of the module metadata (an updated ivy file), to deal with that you
have to use checkModified="true"
- change of module artifacts (this is what you want), this is what is called
a changing revision in Ivy, and you need to tell it to Ivy in one of the two
options for that:
  + use changing="true" when you declare your dependency on the module
  + use a changingPattern on your resolver in which the module is published.
If all your revisions are changing, you can use changingPattern="*"
Note that before considering an artifact might have changed Ivy first checks
if the module publication date has changed, so it's important to publish a
new ivy file with at least the publication date changed.

Could you tweak your settings or your publishing strategy accordingly and
tell us if you still have a problem?

Xavier

On 10/9/07, John Gill <llignhoj@gmail.com> wrote:
>
> It is because you are publishing "another" version of 2.0.0.0. Try
> publishing using a build number or publication date as the version, that
> way
> the cache won't think you already have that version in the cache.
>
> In my book, a version is a version and there cannot be more than one
> release
> of it.
>
> On 10/9/07, Andy Piper <andyp@bea.com> wrote:
> >
> > Ok, here's an example:
> >
> > I have a module cluster.evs4j that depends on cluster.api.gcp. I have
> > built the latter and published it to my shared repository so that I see:
> >
> > eagle Andrew Piper> ls -l
> > ../../../target/repository/product/com.bea.wlevs.clus
> > ter.api.gcp_2.0.0.0.jar
> > -rwxrwxrwx 1 Andrew Piper None 8890 Oct  8 17:09
> > ../../../target/repository/prod
> > uct/com.bea.wlevs.cluster.api.gcp_2.0.0.0.jar
> >
> > All well and good. However, if I look in the cache I see this:
> >
> > eagle Andrew Piper> ls -l /windows/Documents\ and\ Settings/Andrew\
> > Piper/.ivy2
> > /cache/com.bea.wlevs/cluster.api.gcp/jars/cluster.api.gcp-2.0.0.0.jar
> > -rwx------+ 1 Andrew Piper None 8861 Sep 27 11:48 /windows/Documents
> > and Setting
> > s/Andrew
> > Piper/.ivy2/cache/com.bea.wlevs/cluster.api.gcp/jars/cluster.api.gcp-2.
> > 0.0.0.jar
> >
> > Ok, fine publish does not update the cache. But if I then try and
> > build cluster.evs4j it *only* consults the cache and *always* gets
> > the wrong version until I remove it from the cache. This seems like
> > pretty basic operation to me.
> >
> > I realize that I may just be making some configuration faux pas here,
> > which is why I have not raised a JIRA issue as yet. Is there
> > something obvious I am doing wrong? Should my publish step somehow
> > update the cache?
> >
> > If it matters ivy.resolver.default.check.modified = true
> > has no effect.
> > Thanks!
> >
> > andy
> >
> > At 07:53 08/10/2007, Xavier Hanin wrote:
> > >On 10/6/07, Andy Piper <andyp@bea.com> wrote:
> > > >
> > > > Hi Guys,
> > > >
> > > > We are having problems with ivy picking up jars from the cache when
> > > > they don't exist or when they are older than the jars being built.
> > > > Our only option seems to be to blow away the cache and start again.
> > > > Are there known problems in this area (I know about the flag for
> > > > checking for updates to the ivy files)? We have tried useOrigin but
> > > > that causes other failures. Are there known issues with useOrigin?
> > >
> > >
> > >I have had some issues when using changing revisions with 2.0.0 alpha
> 2,
> > but
> > >haven't isolated them for the moment. This may be related to what
> happens
> > to
> > >you. But in my case it isn't systematic. For the useOrigin feature, I'm
> > not
> > >aware of any problem with 2.0.0 alpha 2 in this area, but maybe others
> > could
> > >comment? Or maybe you could raise an issue in JIRA with some more
> > details?
> > >Same for bad jars picked up from the cache, describe your situation and
> > your
> > >ivy settings, and we'll see how this issue can be fixed.
> > >
> > >Xavier
> > >
> > >ivy 2.0 alpha2
> > > >
> > > > andy
> > > >
> > > >
> > > > Notice:  This email message, together with any attachments, may
> > contain
> > > > information  of  BEA Systems,  Inc.,  its
> > subsidiaries  and  affiliated
> > > > entities,  that may be
> > confidential,  proprietary,  copyrighted  and/or
> > > > legally privileged, and is intended solely for the use of the
> > individual or
> > > > entity named in this message. If you are not the intended recipient,
> > and
> > > > have received this message in error, please immediately return
> > > this by email
> > > > and then delete it.
> > > >
> > >
> > >
> > >
> > >--
> > >Xavier Hanin - Independent Java Consultant
> > >http://xhab.blogspot.com/
> > >http://incubator.apache.org/ivy/
> > >http://www.xoocode.org/
> >
> >
> > Notice:  This email message, together with any attachments, may contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> > entities,  that may be confidential,  proprietary,  copyrighted  and/or
> > legally privileged, and is intended solely for the use of the individual
> or
> > entity named in this message. If you are not the intended recipient, and
> > have received this message in error, please immediately return this by
> email
> > and then delete it.
> >
>
>
>
> --
> Regards,
> John Gill
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

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