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:56:09 GMT
On 10/9/07, Andy Piper <andyp@bea.com> wrote:
>
> Another question. Does the "status" field for publish have any
> special meaning to ivy (i.e. does it take any alternative action for
> some statuses) or is it just a means of distinguishing different
> types of published artifact.


The status field is used for two purposes:
- know if a version is an integration version or not, which is used by the
deliver task to do recusrive delivery (deliver all modules I depend upon
which are in integration status). This might be improved to recursive
delivery based on status compatiblity rather than this binary approach, but
this is how it works now.
- if you use latest.milestone or latest.release version constraints, then
Ivy will check the status in the ivy files of the dependency to find a
compatible one.

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