Thank you for your answer ! There is a few points still unclear to me : see below
On 26/10/2007, Graham Leggett <[EMAIL PROTECTED]> wrote: > On Fri, October 26, 2007 2:20 pm, Guillaume Lederrey wrote: > > > I'm working in a large organization, thinking of moving to maven. We > > have lots of projects, having lots of dependencies between them. For > > the moment, those projects are deployed in a central, proprietary > > repository. We have ant scripts taking care of downloading the jars > > needed by a project. > > > > We need to be able to transition to maven one project after another > > (we cant just stop working for one month ;-). So we need to be able to > > still refer to our "old" proprietary repository if we move a project > > to maven but not all its dependencies are managed by maven. > > It is a pretty standard problem to have to support a "bridged" solution > while you move from one system to another. > > We had to move off of a hacked together local repository hosted on a > windows share, to a proper maven repo hosted on a webserver. > > Initially we started with an empty maven repo, and then manually imported > all the jars that were needed for each project from the existing > proprietry repo as we needed them. > > What we did find is that the vast majority of jars being hosted in the old > repo were jars that were already available in the maven repos at > http://repo1.maven.org. In these cases, no import was done at all - we > just configured the pom files to use the correct versions of these > external jars, and let maven handle the downloads automatically. 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. Does it make sense ? > There were a few jars left over that were no publically availalbe, and so > those jars were uploaded to our project-private in house repository. > > At all times both the old ant based way, and the new maven way, worked for > those projects that had been converted. This way we eased off the old, and > eventually switched it off. > > Regards, > Graham > -- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jabber : [EMAIL PROTECTED] Skype : Guillaume.Lederrey Projects : * http://rwanda.wordpress.com/ * http://rwandatech.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
