Isn't that what the dependency and/or the assembly plugins are for? On Sun, May 22, 2011 at 1:13 PM, Petr V. <[email protected]> wrote:
> Thanks Ron and Brian for your replies. > > We have our internal maven repository (mirrored) and we have very rigorous > release process. > > If all our dependencies are in one central location for all our existing > projects then how do we decide what jar files are actually needed to be > shipped for one particular product? > > We have very simple requirement i-e. all that needs to be shipped should be > in build output directory. Just give some one "build" output directory and > he has every thing that needs to be shipped, deployed and run. Nothing less, > nothing extra. > > I hope I have cleared my requirements. > > Right now, we are asking developers to pass -Dmaven.local.repo as part of > their maven command but we want developers not to worry about that. > > Thanks, > > > > > > > > > > --- On Sun, 5/22/11, Brian Topping <[email protected]> wrote: > > From: Brian Topping <[email protected]> > Subject: Re: How to define local repository path in settings.xml or > pom.xml? > To: "Maven Users List" <[email protected]> > Date: Sunday, May 22, 2011, 11:54 AM > > On May 21, 2011, at 10:41 PM, Ron Wheeler wrote: > > > On 20/05/2011 9:06 PM, Petr V. wrote: > >> Thanks Brian for your reply. > >> > >> Our developers work on several projects at same time using same machine. > What we want is that when they build the particular project then every thing > related to project goes to its own build directory (lot of output other than > jars) instead of putting every thing in central m2 location. > > I think that Brian is asking "Why do you want to do this?" > > Yes, that approximates what I was asking pretty well. :-) > > Petr, the only time I've ever had a mind to intentionally manipulate my > repository is when I want to make sure that a new build that I am committing > does not have any missing dependencies. In other words, a build might work > on my machine, but not on another machine because of a missing dependency. > > The path to that happening is (for instance) if I have built a version of > an artifact from source with 'mvn install', but that version does not exist > in a remote repository that the build is configured to look in. If someone > else were to try this new build without a copy of my local repository, their > build will fail. > > Note that this is the correct behavior! > > So by moving my repository aside and doing a build ("mv ~/.m2/respository > /tmp; mvn clean install"), I am forcing my machine to grab every dependency > (direct or transitive) and fail if one of those dependencies does not exist > in a configured remote repository. When it succeeds, I usually move my old > repository back ("rm -rf ~.m2/repository; mv /tmp/repository ~/.m2") because > the old one has a lot of dependencies from other projects that I work on but > don't want to download again. > > Also note that I am not saying "public repository" instead of "remote > repository". Some of the aforementioned dependencies that will be missing > by some people may be dependencies that they do not have source for, but are > not public dependencies either. Hypothetically, if my company has super > sekrit algorithms that we don't want the source floating around for, we > might only provide binaries to most developers. These binaries come from a > *private remote repository* such as Nexus (but could just be a writable > WebDAV directory) that lives *inside the firewall*. There are tens or > hundreds of thousands of these private repositories in use around the world. > > If I were to guess where you and Srinath might be having problems, it's > because you aren't running a private repository for your company's artifacts > like this. When I do a 'mvn install', my build only goes to my local > repository, which limits any brain-damaged code to my local machine. I do > this over and over until it's ready to share, and when it's ready, I do a > 'mvn deploy' to share it. For smaller companies with no QA resources, > everyone might have the credentials to deploy to a private repository, but > they don't do so until they have really done their homework and are sure the > artifacts are ready for their teammates to use. > > The other thing that might be happening is you aren't using the release > plugin. Teams of people need to make releases when milestones are > released. For a small company, a great milestone is "I want to push this > software out to customers". I never let snapshot builds reach a customer. > Never never never! But if all a team creates is 1.0-SNAPSHOT versions, > there's never any way to find those milestones over time. This would be a > reason to have multiple copies of a repository, but completely unnecessary > if a single repository is properly creating distinct releases in a single > repository. > > Versions are so important that I bake the version string into every build, > for instance into an admin screen. Bugs get filed against that version > string, and if there's no version in a bug, we assume it cannot be > reproduced without wasting time checking every version, so we reject it. > > I apologize for all the text, but maybe this helps you and Srinath see some > things you aren't doing. Please continue to ask questions until you get > your questions resolved! If we can help you, you'll eventually help > others! > > Cheers, Brian > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
