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]
