Hi Ralph,
Ralph Goers wrote:
Mark Lundquist wrote:
IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
repositories. That's not in view here.
Huh? SNAPSHOT identifies an artifact as not-released. There is no
requirement that it ever be published to a remote repository.
no, of course not... nevertheless, SNAPSHOT is only meaningful in
relation to a remote repository, right?
In our
environment we have our own private remote repository and after a change
has been made we do deploy the snapshot to that repository just so
others can use it.
Yes, and it has to be a SNAPSHOT so that it will get updated to the rest
of the team.
Of course, the snapshot is never deployed until the
corresponding source is committed.
Right.
I think what you are referring to is that maven "knows" that snapshots
change and it determines whether it needs to update the copy in your
local repository.
Yes, that's what I'm referring to.
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?
[..snip]
I don't understand "If those changes in and of themselves entail a
change to the pom". You don't change the pom version only when data in
the pom itself changes. If you changed a project or subproject in any
way and the pom is not already a snapshot then you need to submit a
snapshot pom with your change. This is because the next formal release
MUST have a new version number, no matter how small the change.
Yes, I understand and agree. Please let me try again with another
example :-)...
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...
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!
---
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.
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?
cheers,
âmlâ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
