Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of waynefay@gmail.com designates
 209.85.146.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gC0E98nJkQqM948PtyHflv5ZGO7hVQJZHMH2e75VkT0K68ZOy1Wt0aPVq3XDLPTYcACp/voo41upF2ztewiRlzHriUZSL73lLpnKo+KGyst71iMIiK4MiLkNCGMK4rNsu9NQFTOh9s3m4idDlQrUGGr8oisSU18M4Ekat6Z7RL0=
Message-ID: <52bab8690710261735if0ae8b9kc701feefe6665073@mail.gmail.com>
Date: Fri, 26 Oct 2007 19:35:01 -0500
From: "Wayne Fay" <waynefay@gmail.com>
To: "Maven Users List" <users@maven.apache.org>
Subject: Re: dependencies outside maven
In-Reply-To: <78712c260710261525jbb5f7cfta117eb7996e720e2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <78712c260710260520n9853484y3f363f841402dd5d@mail.gmail.com>
	 <56899.84.233.182.145.1193401804.squirrel@www.sharp.fm>
	 <78712c260710260701t64c5d19bjb3810391a897641@mail.gmail.com>
	 <19018.84.233.182.145.1193408178.squirrel@www.sharp.fm>
	 <78712c260710260747j24044a94r48021b4631dcefd0@mail.gmail.com>
	 <52bab8690710260823g40f21e50j242681894b675712@mail.gmail.com>
	 <78712c260710261525jbb5f7cfta117eb7996e720e2@mail.gmail.com>

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 <guillaume.lederrey@gmail.com> 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 <waynefay@gmail.com> 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 <guillaume.lederrey@gmail.com> wrote:
> > > On 26/10/2007, Graham Leggett <minfrin@sharp.fm> 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: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Jabber : gehel@amessage.ch
> > > Skype : Guillaume.Lederrey
> > > Projects :
> > > * http://rwanda.wordpress.com/
> > > * http://rwandatech.wordpress.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org