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 <rwhee...@artifact-
software.com>
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]
