On 3/12/07, Nascif Abousalh-Neto <[EMAIL PROTECTED]> wrote:
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.
But you can also automatically look at your reports. Ivy reports are xml based, and you can get their xml versions easily. So some xpath should be enough to break a build based on your reports. But that's just another idea than ConflictManager. - Xavier I like the idea of managing this at the conflict manager level, could be
useful too. -----Original Message----- From: Xavier Hanin [mailto:[EMAIL PROTECTED] Sent: Saturday, March 10, 2007 4:48 AM To: [email protected] Subject: Re: Eclipse integration On 3/9/07, Nascif Abousalh-Neto <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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> > >
