On Fri, October 26, 2007 4:01 pm, Guillaume Lederrey wrote: > The dependencies on "standard" jars is not really a problem for us. As > you say, most of them are available already, and they tend not to > change to often. > > Our problem comes from dependencies on internally produced jars. For > example, we have a team working on a Swing Framework used by most of > our projects, or many teams working on components / services reused by > other internal projects. Those artifacts are deployed fairly often in > our proprietary repository, and we have to be able to depend on them. > > It is not an option to build a dependency graph and migrate first the > projects on which other projects depends. And it would be pretty heavy > to manually update our maven repository to include new versions of our > framework every time they do a release. > > For example, we need to be able to keep the framework deployed to our > proprietary repo, but have dependencies to this framework from > projects already migrating to maven.
You need to start at the "bottom" of your dependency tree, with those dependencies that do not depend on other internal dependencies. Get these bottom-most dependencies to the point where they are built by and deployed by maven to an internal maven repository set up for your project. When you make a release of these "bottom" dependencies, go through the formal maven release procedure (use the release plugin for this to make it easy), and as a final step, copy the artifact from the maven repository into your prorietry repo. Eventually, over time, more of the code will start life in the maven repo, until eventually you phase the proprietry repo out entirely. You can do this as quickly or as slowly as you feel comfortable with. Regards, Graham -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
