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 09:53:18 GMT
On 10/9/07, Andy Piper <andyp@bea.com> wrote:
>
> 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.


There is no local publish task. There is a local publish target in some
tutorials, which uses an incrementing version number as demonstration
purpose. But yes I think any time a version is published it should have a
different version as any other one. Using a build number or a timestamp may
fit this purpose.

For disk space management I'd say it depends on your environment and the
size of your artifacts. Some can't afford preserving more than one version,
others use a 1 week window, and others archive ALL versions. But you can
keep only one version even if you give it a new name each time. Deleting the
older version is usually pretty simple with ant. And at least when you have
a developer saying "it doesn't work on my box", you can better figure out if
something is wrong because of dependencies not or badly refreshed when you
know he has 2.0-b103423 rather than 2.0-SNAPSHOT.

But Ivy supports both, so depending on your requirements and feeling you can
choose the best strategy for you.

Xavier

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.0alpha
> > > 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.
>



-- 
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