ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nascif Abousalh-Neto" <Nascif.AbousalhN...@sas.com>
Subject RE: Eclipse integration
Date Mon, 12 Mar 2007 14:56:50 GMT
Reports are great and definitely a step in the right direction; but the larger the scope of
your build, the larger the chance that someone won't look at them close enough. So it is safer
to have automated safeguards, like IDE-based notification and build failures.

I like the idea of managing this at the conflict manager level, could be useful too.

-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com] 
Sent: Saturday, March 10, 2007 4:48 AM
To: ivy-user@incubator.apache.org
Subject: Re: Eclipse integration

On 3/9/07, Nascif Abousalh-Neto <Nascif.AbousalhNeto@sas.com> wrote:
>
> Sorry I was not clear. Here is the scenario: in a large corporation, 
> you have the concept of a major release. At that milestone, you want 
> to ship hundreds of jars in dozens of products. Many of those jars are 
> common dependencies accross projects, OK?
>
> The scenario is: you don't want to ship different versions of those 
> shared dependencies - you want only the latest version of each one. So 
> while you can allow some flexibility during the development phase 
> (different projects using different versions), as you get closer to 
> the release you want to enforce some "convergence" so that X weeks 
> before launching everbody is on the same page.
>
> This is what I meant by "failing the resolve task if ivy.xml has more 
> then X% old dependencies..."
>
> But perhaps the right answer is to just make sure everybody is 
> building against the integration version at that point.


Even if there's nothing automated to do what you want, I think that using reports can be useful:
You can for example create an ivy file for your major release, declaring dependencies on all
your products. Then if you resolve the dependencies you will see in the report how many conflicts
you have. You can even define your own conflict manager to make the build fail if you have
too many conflicts. Or parse the xml report to create a warning if dependencies are not aligned.
Is it the kind of thing you were thinking about?

- Xavier

Thanks,
>   Nascif
>
> -----Original Message-----
> From: Dmitriy Korobskiy [mailto:dk.root@verizon.net]
> Sent: Wednesday, March 07, 2007 9:53 PM
> To: Nascif Abousalh-Neto
> Subject: Re: Eclipse integration
>
> Hi, Nascif
> Re: your e-mail from Wednesday, March 7, 2007 5:47 PM
>
> NAN> Another newbie question - does Ivy provide any support to alert 
> NAN> the user that it is time to update the dependency versions in ivy.xml?
>
> NAN> For example, an IDE view of the repository with decorators 
> NAN> showing
> which dependencies are "out-of-date"?
>
> NAN> One of the most common fears I encounter when "evangelizing" the 
> NAN> dependency management approach is that developers will stay too 
> NAN> long on their "island of code" while their dependencies drift 
> NAN> away to newer and newer versions. I am trying to think of ways 
> NAN> that would make it easier to enforce some kind of motility - and 
> NAN> a visual indication that your dependencies are getting old would 
> NAN> be a
> great help.
>
> NAN> Perhaps some way of failing the resolve task if ivy.xml has more 
> NAN> then
> X% old dependencies...
>
> NAN> Does anybody has a similar use case?
>
> If you are simply trying to "get the latest version" you can use 
> dynamic revisions in your Ivy files (for example, <dependency name="commons-logging"
> rev="latest.integration" conf="default"/>
>
> Perhaps, I am not quite understanding what you are trying to achieve.
>
> Dmitriy <1-127-441 @ICQ, DKroot @Skype, DKroot1 @AIM, 
> dkroot1_at_gmail_dot_com @Google Talk>
>
>

Mime
View raw message