That is a consideration, but I am more worried about something like commons that depends on _everything_.In a single chain of dependencies, we would get the error on compilation, so that is not something I worry about.
On Wed, Aug 19, 2009 at 10:00 AM, Bart Reyserhove <[email protected] > wrote: > We could use horn to ease the dependency pain. I used it for our internal > framework and it definitely makes things easier. > Wouldn't it make things even more complex if each project has its own > dependencies and you want to use different of those projects in your > application? You could have a situation that "rhino commons" depends on > version 1 of Windsor and "rhino security" depends on version 2 of Windsor > for example. > > > On Wed, Aug 19, 2009 at 8:49 AM, Ayende Rahien <[email protected]> wrote: > >> Right now, Rhino Tools has dependencies for just about everything.I would >> like to upgrade the code to NH 2.1 and Windsor 2.0, but I am running into >> issues with the number of dependencies that we have and the number of >> _inter_ dependencies between them. >> >> I am severely tempted to start removing dependencies and simplifying >> things overall. >> In practice, what this means is that I would like to deprecate the entire >> Rhino Commons, and structure the project so each sub project host its own >> dependencies. >> We are still going to have inter dependencies (for example, DHT depends on >> PHT), but I think that this would significantly reduce them. >> >> Thoughts? Votes? >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
