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]
