Changing=true
kirby
-Original Message-
From: Mike Quilleash
Sent: Thursday, May 13, 2010 10:59 AM
To: ivy-user@ant.apache.org
Subject: Refreshing ivy cache after changing a published version
Hi all,
I have an Ivy repository where we store all our 3rd party libraries. One of
these
You could put all your DLLs in a zip and that becomes your artifact.
Everytime you change the contents of the zip, you just publish a new
version.
-Tim
From: Mike Quilleash
To: "ivy-user@ant.apache.org"
Date: 05/13/2010 11:00 AM
Subject:Refreshing ivy cache after ch
Hi folks,
I have a bit of a complex issue here, and I'm wondering if anybody has
recommendations about how I can solve it.
I will start out by describing what I want to do. I have several ivy
modules which contain javascript files. My build process produces a .war
file, and needs to concaten
One problem I ran into while using this mechanism is that if the dependency is
based on a "latest.integration" revision and the ivy.xml pattern for the
repository does not have the revision number somewhere in it, this mechanism
will fail.
The other possibility is that your test sequence may
Thanks. I tried doing the following to test..
- Cleaned out my ivy cache and cleaned my project build
- Removed one of the jar entries from one ivy.xml in my repository
- Did a build
- Dependencies were downloaded, build failed because of missing jar
- Edited the ivy.xml in the repository to put
Take a look at the Cache Management section on the main concepts page:
http://ant.apache.org/ivy/history/latest-milestone/concept.html
Specifically, look at the subsection entitled "Change Management".
Scott
-Original Message-
From: Mike Quilleash [mailto:mike.quille...@junifersystems.c
Personally, if I need to do this sort of thing, I delete the specific
module from the ivy cache (ie: rm
~/.ivy2/cache/[organization]/[name]/*). Then it's not as painful for
developers who are working over the VPN.
There's probably a better way to do this, though, that somebody else
will know
Hi all,
I have an Ivy repository where we store all our 3rd party libraries. One of
these is a large C# UI component library that comprises 100+ DLLs. In reality
we only need about 10-15 of those DLLs but we sometimes need additional ones
added as we use new functionality. This isn't a versi