Thanks Marc, I would try Artifactory to see if it fits my case.
Jammy 2015-11-04 21:41 GMT+08:00 Marc De Boeck <mdeb...@gmail.com>: > 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... > > > > > >
