Re: Ivy shared repository tracking
There is no need to remove old versions unless you are low on space. In my case, I always leave the old versions in my internal repository and just update my projects to use the new versions. If I have to switch to developing on an old branch that depended on old versions of libraries, then they are still available and everything still builds. New development depends on the new versions and everything works very will in that way. However, for 3rd party or open source libraries I always specify an explicit release version. For internal libraries I usually just leave it as latest.integration except when making a production release where I will switch it to a specific release version of the internal libraries as well. Regards, -Roberto On Wed, Jan 13, 2016 at 01:07:28PM +0800, Jammy Chen wrote: > Hello > > I have question need your guys help. for example, for my product previous > release, we used 3rd party lib A version 1.0 and it store in the > repository, but for current or next release, we may uptake to 3rd party lib > A version 2.0 or replace to another open source, in this case we need > remove 3rd party lib A version 1.0 from the repository? > > if Yes, the previous release build will not work as 1.0 is not available. > If no, how do I track the libs in repository and is they are being used? > > Thanks -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Difficult with concurrent builds
I have a project using Ivy which is built via Jenkins. I have two
branches for this project (a stable branch and a current development
branch, which is the master branch in Git).
In Jenkins I have one build configured for each branch (I don't want to
mix the build histories). I have a post-commit hook in my Git
repository which checks for the branch(es) of the commit and then uses
to wget to retrieve the URL that triggers the build that corresponds to
the branch of the commit.
The problem that I am experiencing has to do with making changes in
quick succession on the two branches. My Ant build.xml does the normal
build routine and at the end publishes the artifacts into my own local
Ivy repository. When the builds run concurrently (because, for example,
I make a commit one branch and then immediately cherry-pick the commit
to the other branch, the build that finshes last uses the ivy.xml
desriptor from the build that finishes first. This is very frustrating
as it breaks all sorts of things. I can go into Jenkins and force a
rebuild of the one that finished last and everything turns out
correctly, with the correct descriptor being published the second time.
I looked through the Ivy source code and found a reference to a delivery
list file that looks in ${java.io.tmpdir}/delivery.properties. I tried
explicitly setting the ivy.delivery.list.file using Ant's tempfile/
task to ensure that concurrent builds won't accidentally touch the same
file. I was able to confirm that instead of /tmp/delivery.properties
that the Ivy publish task was using the randomly generated file name Ant
put into the ivy.delivery.list.file property.
Even with that, though, I am still seeing the buggy behavior. That is,
the build that finishes last uses the same descriptor as the build that
finishes first (line for line identical except for the revision and
publication attributes of the info tag.
Any help on this would be appreciated.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
