You can try to use <scope>system</scope> bug this is generally not
encouraged as it does not work as you might expect in all situations.
This would allow you to pull your artifacts from your current system,
put them in a /lib folder, and use them as part of your current Maven
build.

However, I think this is a bad idea -- system scope is not a long-term
solution, and not a great short-term solution either. Instead I would
build a little shell script that would analyze your pom, go out to
your proprietary repo and download the necessary files and then use
"mvn install:install-file -DgeneratePom=true -DcreateChecksum=true
..." to install each one into your local Maven repo cache.

Ideally once you got things working on your local environment, you
would use "mvn deploy" to deploy your code to a new Maven (corporate)
repo that you will set up that will function as your new artifact
repository. I would also write a script to run "mvn
deploy:deploy-file" similar to the "mvn install" script mentioned
above, so you will migrate not only the current app you're working on
but also all of its related support libraries etc.

Wayne

On 10/26/07, Guillaume Lederrey <[EMAIL PROTECTED]> wrote:
> On 26/10/2007, Graham Leggett <[EMAIL PROTECTED]> wrote:
> > 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.
>
>  That's our main problem !
>
>  For organizational / political reasons, the "bottom" of our
> dependency tree will not migrate anytime soon ... that's why we need
> some way to depend on projects NOT in the maven repository ...
>
>  I know, we're going to have a lot of fun !
>
> > 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]
> >
> >
>
>
> --
> 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]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to