Re: IVY Clearcase integration

[Marc De Boeck]

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 :

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

Re: IVY retrieve best use practice?

[Jammy Chen]

Thanks Marc.


Anybody else have suggest?

Jammy


2015-11-04 15:59 GMT+08:00 Marc De Boeck :

> We are using the second approach: use Ivy classpath to compile.
> For me it is the most efficient and elegant way to work with Ivy and the
> Ivy-cache.
>
> Regards,
> Marc
>
>
>
> 2015-11-04 7:46 GMT+01:00 Jammy Chen :
>
> > Hello IVY users/developers,
> >
> > I am now immigrating my project to with IVY libraries dependency
> > management,  I have built our shared repository, in regarding of how to
> > retrieve the libs from shared repository and put into use, I have below
> two
> > approaches I am just asking you guys experts what's the best practice and
> > make sense more in generic.
> >
> > 1. Use ivy retrieve task to make a copy of libs into project folder from
> > repository, in Ant build script, we will use these libs as classpath to
> > compile, re-org them and finally package as war/ear
> > this will leads less dependency with IVY once we retrieved the libs, but
> we
> > will have several copy of these libs e.g. in cache, project folder and
> > shared repository.
> >
> > 2. Use IVY cachepath as for compile target, once compiled then use ivy
> > retrieve task to retrieve the lib to package as war/ear, this sounds that
> > compile and distribute will be in different term, but need more changes
> in
> > build xml that more depends IVY cachepath.
> >
> > What the best practice should be?
> >
> > Thanks.
> >
>

IVY Clearcase integration

[Jammy Chen]

Dear IVY users, developers,

My project are source controlled with Clearcase, I built the shared
repository, do anybody have  suggest where the shared repository should be
allocate?

I thought I can check-in to clearcase and user should not manually donwload
this folder, in IVY we have customized clearcase resolver to
resolve/retrieve from the shared repository, is anyone have done similar
thing or good example how to implement custom clearcase IVY resolver?

Thanks very much
Jammy

Re: IVY retrieve best use practice?

[hkais...@googlemail.com]

On 04.11.2015 07:46, Jammy Chen wrote:
We have used ivy:cachepath for our compiles, test-runtime, but since we 
had a lot of troubles on IVY 2.3.x and also with the IvyDE we decided to 
switch to a folder based ivy:retrieve.
Also we are using a very simplistic eclipse plugin to reference all libs 
from folders and have given up to work with IvyDE. We use instead:

https://github.com/dpalic/EclipseFolderClasspath

So now ivy retrieves all dependencies into folders named by 
ivy-configuration names, and we only reference them in ANT and in 
Eclipse (with the previous plugin).
So the behaviour is always the same and we have no possible missmatch in 
ivy:cachepath (retrieved on every run of Ivy) vs. one ivy:retrieve for 
multiple runs (build, test, runtime, packaging, ...)


ivy:cachepath is still used by us, but only for basic dependency-lookups 
in the ANT-build. E.g. for building up a dependency-tree for PMD, 
findbugs integration into ANT.


To your disk usage, yes the ivy:retrieve will bloat your disk usage, but 
it will also provide you a clear overview of the files which you handle.
We have used ivy:report to generate a html report to see which lib and 
version was retrieved, but it is still easier to glance through some 
folders and to see which files are finally in my target folder.


So there is no clear recommendation. It depends on your complexity of 
your projects. For higher complexity I would still prefer to use the 
retrieve into ivy-config folders. For quick wins and for small projects 
I would stick to ivy:cachepath.

Re: IVY retrieve best use practice?

[Marc De Boeck]

We are using the second approach: use Ivy classpath to compile.
For me it is the most efficient and elegant way to work with Ivy and the
Ivy-cache.

Regards,
Marc



2015-11-04 7:46 GMT+01:00 Jammy Chen :

> Hello IVY users/developers,
>
> I am now immigrating my project to with IVY libraries dependency
> management,  I have built our shared repository, in regarding of how to
> retrieve the libs from shared repository and put into use, I have below two
> approaches I am just asking you guys experts what's the best practice and
> make sense more in generic.
>
> 1. Use ivy retrieve task to make a copy of libs into project folder from
> repository, in Ant build script, we will use these libs as classpath to
> compile, re-org them and finally package as war/ear
> this will leads less dependency with IVY once we retrieved the libs, but we
> will have several copy of these libs e.g. in cache, project folder and
> shared repository.
>
> 2. Use IVY cachepath as for compile target, once compiled then use ivy
> retrieve task to retrieve the lib to package as war/ear, this sounds that
> compile and distribute will be in different term, but need more changes in
> build xml that more depends IVY cachepath.
>
> What the best practice should be?
>
> Thanks.
>

Re: IVY Clearcase integration

[hkais...@googlemail.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...