Mark Lundquist wrote:
no, of course not... nevertheless, SNAPSHOT is only meaningful in
relation to a remote repository, right?
I don't really understand why you'd say that. It indicates that this is
an unreleased version. Whether it is in your local repository or a
remote repository doesn't change that. It only changes whether the
artifact is shared with others.
If you have a local repository for each subproject this should get
you what you need.
Really, a local repository for each subproject? I'm not seeing how
that would work, sorry... can you elaborate?
In maven 1 I often export MAVEN_HOME_LOCAL to a .maven subdirectory at
the root of my project. It then contains only the artifacts (and their
versions) for this specific project. Our CM folks use this technique
when building a project to insure it doesn't try to use anything it
isn't supposed to.
Suppose we are working on a big project P, which aggregates a whole
bunch of subprojects. I check this all out from Subversion trunk, and
suppose that all the poms already specify SNAPSHOT, because we are
working on the next release in trunk. Let's say all the poms have
version 1.0-SNAPSHOT. Okay, then...
Situation 1: Now, I want to build the project, right out of the box
from my clean trunk checkout. I don't have to tell Maven anything
special, that this is "my build", or anything else. I just say "mvn
install" and Maven does what it's supposed to do.
Situation 2: Now suppose I go on to make some code changes. Forget
SNAPSHOT, OK! :-) They are *already* SNAPSHOT versions. If they
weren't already, I would make them so as you pointed out, because I
intend for my changes to be committed — but that would be for the sake
of the project, it would not be necessary just for my local build to
work! So once again, I just type "mvn install".
For the purposes of the rest of this example, the two salient aspects
of this situation are:
(a) Just like in Situtation 1, there is still no special "-s ..." or
any other voodoo that I have to get right each time I want to build.
It's just "mvn install";
(b) all of my local changes are committable! There is no change
(e.g. to a pom) that I would have to revert before I can commit.
Moving along...
Situtation 3: I decide to work in parallel on some unrelated changes
to project P. So, I check out trunk again into directory P2. I go
into P2 and start making my changes, and all is still as it should
be... or so it seems. I type "mvn install" to build, and everything
works. No special invocation voodoo, and no uncommittable changes!
But then...
Bad idea. you should have used settings to have a local repository just
for this sandbox so that it would not intermingle with your pristine
(i.e. already committed) stuff.
Situation 4: I go back to directory P to resume my work there, and I
find that all is no longer right with the world, because working area
P1 has installed its own artifacts with the same name+version into my
local repository "out from under" the build encapsulated by "P". I
might now make some changes in one subproject and install it, and then
do something in another subproject that depends on it (e.g. "mvn
package" or running the program), but this will not take the artfacts
from P's build, instead it will take the current artifacts from the
local repo, which are the ones from P2's build!
See above. You screwed yourself.
---
This Situtation 1-4 scenario happened to me, and it was a surprise.
At first I didn't know what was going on, and then I figured it out.
I realize now that to somebody who understands Maven, it's expected
behavior... not surprising at all. But that's really not the point!
I wouldn't mind at all if there were some reasonable way to solve the
problem. But every suggestion I have heard violates properties (a)
and/or (b) above; they either depend on invocation details, e.g. "mvn
-s ...", which is error-prone; and/or they require me to make
uncommittable changes, so that I am left with an admixture of
commit-bound and uncommittable changes in my working area.
I admit, I prefer Maven 1's way of exporting MAVEN_HOME_LOCAL over
having to use a settings file. It is easy to do echo $MAVEN_HOME_LOCAL
before I type maven .... to verify what I am about to do. However, in
looking through the Maven 2 code it seems that
DefaultMavenSettingsBuilder will look at the system property named
maven.repo.local, if it is defined, to determine where the local
repository is - which is exactly what Maven 1 does. So the main
difference is that the Maven 2 script does not set the -D for
maven.repo.local as the Maven 1 script does. This is easily
accomplished by just doing
export MAVEN_OPTS=-Dmaven.repo.local=$PWD/.mvn
So my argument is that my expectation that builds would be
self-contained was reasonable. And in fact, separate builds on
separate machines *are* (by default) self-contained! I am arguing
that it *should* make no difference if two or more builds are on the
same machine; they should be self-contained by default just as they
would be if each build was on its own machine. It appears that Maven
doesn't work that way. My question really is, if Maven could be made
to work that way, wouldn't that be a good and useful thing?
But it does. I just told you how.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
