I didnt think about that, but it sounds like a great solution ! Thanks ! I'll have a look on monday ...
On 27/10/2007, Wayne Fay <[EMAIL PROTECTED]> wrote: > On Windows, there is mavenrc_pre.bat and mavenrc_post.bat. Check the > mvn.bat file to see the reference to those files. > > And you can easily customize your mvn.bat or mvn.sh file for your > corporate environment if you want to do "special stuff" in addition to > the normal Maven commands. You just need to make sure that all your > developers then install and use your custom Maven distro rather than > the generic distro. > > Wayne > > On 10/26/07, Guillaume Lederrey <[EMAIL PROTECTED]> wrote: > > Wayne, Graham, thanks for your advices ! > > > > I will investigate a bit the <scope>system</scope> bug/feature (havent > > really heard of it yet). > > > > Is it possible to have maven run a script before dependency checking ? > > That would allow us to have a script (or maven-plugin, or ant task, > > or whatever) run as part of the build that would download our > > dependencies and install them locally. That would be mostly > > transparent to the developer, so it looks like a clean solution. > > > > Worst case, we can always have a separate script that the developer > > has to run prior to run maven, but it is not as clean ... > > > > I know, I should try it before asking the question ... but ... I'm a > > bit lazy, and it's already the weekend ... > > > > Thanks again ! > > > > MrG > > > > Our migration isnt only a large complex project, its dozen of them ! > > Each project generating many artifacts ... So yes, in the best world, > > if everything goes right, I think we can expect to complete the > > migration in a few years ;-) Every step to ease that pain will be > > welcomed. > > > > I will certainly have to write some documentation of our process, but > > in french (sorry). I will let you know if I am allowed to publish it > > ... > > > > On 26/10/2007, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > > > > > -- > > 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] > > -- 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]
