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]
