ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Piper <an...@bea.com>
Subject Re: Problems with cache resolution
Date Tue, 09 Oct 2007 09:04:58 GMT
Incidentally, I'm guessing this is why the "local" publish task uses 
an incrementing version number? If so how do you avoid the issue of 
your disk filling up with old artifacts.

andy

At 06:28 09/10/2007, Xavier Hanin wrote:
>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/


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.

Mime
View raw message