On 10/9/07, Andy Piper <[EMAIL PROTECTED]> 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
On 10/9/07, Andy Piper <[EMAIL PROTECTED]> 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 targ
On 10/9/07, Andy Piper <[EMAIL PROTECTED]> 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),
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 consi
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 def
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"
>- ch
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 wan
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
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
On 10/6/07, Andy Piper <[EMAIL PROTECTED]> 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 problem
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 upda
11 matches
Mail list logo
