I agree mostly with hkaiserl, but I'd like to add some extra thoughts. When we started using Ivy, we were also using ClearCase. Initially we decided to put 3rd party libraries etc also in ClearCase. Our own built artifacts were stored on a shared drive (not version controlled). This worked not so bad, but wasn't perfect. In the context of ClearCase it was actually not a strange idea to version binaries, because ClearCase is designed to store sources and binaries. ClearCase has also some unique features for build management system, e.g. in the area of build avoidance. On the other hand, when you use Ivy-dependencies to control the version, you have already your versioning via the Ivy revision numbers. So adding an additional versioning layer (ClearCase) on top of that, can generate strange effects when resolving these dependencies.
Later on, we moved to Git and to Artifactory. We chose Artifactory above Nexus, because we found that Nexus was too much focused on the maven eco-system. I am not sure if this is still the case. On the other, hand the GUI of Nexus seems to be more intuitive. Anyway, I am quite happy with the features and versatility of Artifactory. Initially we used the free OSS version, but since last year, we purchased the Pro version. Regards, Marc 2015-11-04 11:43 GMT+01:00 Jammy Chen <jamm...@gmail.com>: > Thanks for your response. > > In our project, we used some 3rd parties libraries which most of them > already be available in Maven repository, but also some private libraries > and libraries from the company like Oracle we cannot find them in > public Maven repository, indeed we cannot publish them to public, so I > believe this is must to build our enterprise level - shared repository. > > That's right we can put ivy.xml itself is again managed by clearcase, but > we also need set up place to put the share repository which all > team members can retrieve. I think thinking of perhaps a > shared HTTP-based file server could be option but this > adds additional hardware, maintain cost and complex in our system. > > This is why I thought we can check-in to clearcase as clearcase is already > a running service in our setup, we don't want each developers manually > update the share repository to local. Instead, implement own clearcase > resolver. But looks this is not easy or even not feasible as using Java to > retrieve clearcase files so I am asking is any better solution. looks nexus > could be one but I am not sure it is free or license. > > > > > > 2015-11-04 17:52 GMT+08:00 hkais...@googlemail.com <hkais...@gmail.com>: > > > > > Clearcase is in my eyes a *source* config management system. Jar files > are > > generated/compiled binaries from sources. > > So no source repository - also not clearcase - would be a good solution > > for managing binary configurations. > > > > Instead I would stick to a maven repository like sonatype nexus for the > > binaries. Ivy can handle any maven repository, also nexus. And your > ivy.xml > > is making for you the config management of the binaries. ivy.xml itself > is > > again managed by clearcase, so your config managment needs should be > > matched fully. > > > > If you still insist using clearcase - which I do not recommend - you can > > handle the ivy:retrieve by providing your own resolvers in IVY > > > http://ant.apache.org/ivy/history/latest-milestone/settings/resolvers.html > > > > I would spent my time better in setting up a nexus locally in the > > enterprise, instead of investing into a non standard resolver solution > > based on clearcase... > > >
