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... >
