You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Iliev, Alexander" <Al...@gs.com> on 2007/09/25 17:07:44 UTC
Logging too verbose
I find the logging produced by the ivy:resolve ant task to be too much -
it makes up the considerable majority of my ant output. This is at the
default logging level. Is there any way to make resolve more quiet,
without changing any other ant settings, ie. so that other tasks remain
at their default logging level?
I'm using Ivy 1.4.1 with ant 1.7
Thanks!
alex
Re: Problems with cache resolution
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/9/07, Andy Piper <an...@bea.com> wrote:
>
> 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
>
> Where does this go? I can find zero documentation on this attribute
On the dependency declaration:
<dependency org="foo" name="bar" rev="2.0" changing="true" />
See http://incubator.apache.org/ivy/history/trunk/ivyfile/dependency.html
> + use a changingPattern on your resolver in which the module is
> published.
> >If all your revisions are changing, you can use changingPattern="*"
>
> Ok so using this seems to work! Do you have an example, its not clear
> from the docs how exactly it is trying to match a "revision".
It works in pair with changingMatcher (documented just below changingPattern
in
http://incubator.apache.org/ivy/history/trunk/configuration/resolvers.html).
The matcher concept is documented here:
http://incubator.apache.org/ivy/history/trunk/concept.html#matcher
>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.
>
> Ok, looks like this happens by default
Yes, if you use the publish task :-) If you copy artifacts by hand you may
wonder why Ivy don't pick them up.
>Could you tweak your settings or your publishing strategy accordingly and
> >tell us if you still have a problem?
>
> Looks good.
>
> Incidentally I am happy to augment the documentation with editorial
> content if it would help.
Sure it would help! Documentation contribution is always welcome!
The docs are better than maven (not
> particularly hard), but still missing a lot of important detail.
Agreed. IMO the reference doc is not too bad even though it lacks some
details and cross references, the worst part is introduction and tutorials
which haven't really evolved to reflect some features introduced in recent
Ivy versions.
Xavier
Thanks!
>
> 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/
Re: Problems with cache resolution
Posted by Andy Piper <an...@bea.com>.
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
Where does this go? I can find zero documentation on this attribute
> + use a changingPattern on your resolver in which the module is published.
>If all your revisions are changing, you can use changingPattern="*"
Ok so using this seems to work! Do you have an example, its not clear
from the docs how exactly it is trying to match a "revision".
>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.
Ok, looks like this happens by default
>Could you tweak your settings or your publishing strategy accordingly and
>tell us if you still have a problem?
Looks good.
Incidentally I am happy to augment the documentation with editorial
content if it would help. The docs are better than maven (not
particularly hard), but still missing a lot of important detail.
Thanks!
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.
Re: Problems with cache resolution
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/9/07, Andy Piper <an...@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 <ll...@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 <an...@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 <an...@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/
Re: Problems with cache resolution
Posted by Andy Piper <an...@bea.com>.
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 <ll...@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 <an...@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 <an...@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.
Re: Problems with cache resolution
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/9/07, Andy Piper <an...@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 <ll...@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 <an...@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 <an...@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/
Re: Problems with cache resolution
Posted by Andy Piper <an...@bea.com>.
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.
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 <ll...@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 <an...@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 <an...@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.
Re: Problems with cache resolution
Posted by Xavier Hanin <xa...@gmail.com>.
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 <ll...@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 <an...@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 <an...@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/
Re: Problems with cache resolution
Posted by John Gill <ll...@gmail.com>.
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 <an...@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 <an...@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
Re: Problems with cache resolution
Posted by Andy Piper <an...@bea.com>.
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 <an...@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.
Re: Problems with cache resolution
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/6/07, Andy Piper <an...@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/
Problems with cache resolution
Posted by Andy Piper <an...@bea.com>.
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?
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.
Re: Logging too verbose
Posted by Xavier Hanin <xa...@gmail.com>.
Try settings these properties:
ivy.log.modules.in.use=false
ivy.log.module.when.found=false
ivy.log.resolved.revision=false
Xavier
On 9/25/07, Iliev, Alexander <Al...@gs.com> wrote:
>
> I find the logging produced by the ivy:resolve ant task to be too much -
> it makes up the considerable majority of my ant output. This is at the
> default logging level. Is there any way to make resolve more quiet,
> without changing any other ant settings, ie. so that other tasks remain
> at their default logging level?
>
> I'm using Ivy 1.4.1 with ant 1.7
>
> Thanks!
>
> alex
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/