But then shouldn't you be building with what's available, not a
snapshot created at some other time,
On Mar 16, 2010, at 10:37 AM, Benson Margulies <[email protected]>
wrote:
Just for fun, I think it's worth explaining the environment.
We are relatively new adopters of Maven. Up until now, we've done
maven releases only for external product releases. Thus, there are
snapshot dependencies amongst our internal components for months on
end. To make my original scenario a trifle more concrete:
I'm plugging away at a set of changes. The changes are across several
aggregated components. I finish with one component, and I'm working on
the next.
The overall set isn't going to be done in a day, but they feel really
light for a branch. Meanwhile, one of my colleagues knocks off a small
fix in the component I've finished with. So, she checks in, hudson
builds, and produces a snapshot. Unless I go back and rebuild my copy
of that component, I get a surprise.
Say that we tried to address this by making internal releases and only
using snapshot dependencies 'locally,' to a build tree. Is there a
plugin that will auto-edit a tree, finding all dependencies on g/a/v
x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back
for checkin?
My fantasy continues to be that I could put a filter in my
settings.xml that turned off snapshot updates on a set of g/a/v
patterns.
On Tue, Mar 16, 2010 at 9:00 AM, Maven User <[email protected]>
wrote:
You could probably do a dependency:resolve and leverage the
includes/excludes - but that starts smelling hacky.
I'm in agreement with the earlier comment. If you're allowing any/
all devs
to deploy, it can't be a free-for-all.
Why not let ci be the bottleneck (which implicitly has some degree of
automated testing)? Devs have the option of deactivating tests
locally....
On Mar 16, 2010, at 8:52 AM, Stephen Connolly
<[email protected]> wrote:
I guess the issue is if you want to update some but not all of your
-SNAPSHOT dependencies. Maven does not provide filtering of update
checking
On 16 March 2010 12:46, Maven User <[email protected]> wrote:
Google maven updatepolicy - you (as a user) can choose how often
(or at
all) you take versions from a repository.
On Mar 16, 2010, at 8:18 AM, Benson Margulies <[email protected]
>
wrote:
Well, at least now we can see the disconnect. People don't want to
make a branch every time they are working on something for more
than a
day. (Default snapshot update is a day.) Making a branch is fairly
tiresome, especially given the difficulty of persuading
release:branch
to work. The 'person' who published the snapshot is hudson, just
doing
its job.
If the answer is, 'always make a branch,' then that's the
answer. It
is not a popular answer with the developers I'm supporting. I wish
there was some alternative involving controlling snapshot
updates per
g/a instead of per repository. --offline prevents unwanted
updates,
but it also prevents wanted updates of other, unmodified,
things, and
new dependencies.
On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly
<[email protected]> wrote:
On 16 March 2010 04:25, Ron Wheeler <[email protected]
>
wrote:
Benson Margulies wrote:
I have this feeling that I'm missing something terribly obvious.
1: grab a tree and make some changes.
2: mvn. Now you've got SNAPSHOT versions in your local
repository
3: someone else checks in a change and runs mvn deploy. Now the
snapshot repo has jars newer than the local repo.
4: run mvn and download those over top of the local mods.
Only if you have the update rule for your snapshot repos set
to check
every
time.
If you are working on a branch, then run maven in offline mode to
prevent
having to worry about picking up other versions that somebody
elese has
deployed
Without patching all the version numbers, is there a best
practice or
standard mechanism to stay out of this pickle?
What is the pickle? You have the latest version which is what
you
want
if
the person doing the deploy has done the deploy for a reason.
If the version deployed is not better than the version that
you have
locally, you beat the crap out of the guy who deployed a
version when
they
shouldn't have.
If people deploy crap into repositories, you will have a problem
eventually.
If you put your version into your source management, the other
person
would
have based his mods on yours or at least noticed the conflicts
before
he
deployed.
Collaborative software development has to be done
collaboratively.
Ron
---
---
---------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---
---
---------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---
------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---
------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
