ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jammy Chen <jamm...@gmail.com>
Subject Re: IVY Clearcase integration
Date Thu, 05 Nov 2015 08:38:24 GMT
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 <mdeboec@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 <jammycc@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 hkaiserl@googlemail.com <hkaiserl@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...
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message