our Corp pom is is
http://foo/common/trunk/pom.xml
project foo is in
http://foo/foo/trunk/
project bar is in
http://foo/bar/trunk
project bar depends on foo
normally bar only references the last release of foo
if I'm doing bleeding edge integration work trying to fix a bug that
is at the interface of foo and bar, I need to make changes to both,
so I check them both out locally, do mvn install in foo, change bar to
depend on the snapshot version of foo that i've built locally
once I've got everything working, I check foo back in and either wait
for or push the release of foo before releasing bar
Sent from my iPod
On 26 Dec 2008, at 07:01, nodje <[email protected]> wrote:
hey, thanks for sharing Stephen, it's probably a hard work typin all
this on
an ipod!
It's very interesting to be able to share that since it's choices
I've made
on my own.
We use a corporate pom for our application and they arein fact part
of the
same scm. I'm not sure by what you mean as 'can be released in one
go'. We
don't release them a the same time.
When we release one, we have to produce a release version of the
corporate
parent pom and all the dependencies the app depends on that are
SNAPSHOT.
As I recently introduce the corporate pom, I very often modify it,
so using
release version would increment it's version quickly. That seems
doable
though, and it's a viable option I reckon. It's a pain for
developers to
have to manually install the parent pom each time a new SNAPSHOT is
deployed
(which not use in fact.) but it's even more painful to remember to
update
the build server's version of the parent pom.
I'd argue that using versions:update-parent is not much different
from doing
a 'svn up' & 'mvn install' on the parent pom though. It's still not
automatic.
I'm not too sure I understand what you mean by 'for integration
development,
we check both projects out locally and install the. snapshots by
doing a
local build'.
Do you mean locally check out both corporate pom and dependant
application?
What snapshot?
Stephen Connolly-2 wrote:
if you have a corporate pom as your parent, you should be depending
on
a released version of that pom, or else your build is not fully
reproducible
my rule of thumb is that if the projects are all part of the same scm
tree and can be releasedin one go, then snapshots are valid,
otherwise
releases only
for integration development, we check both projects out locally and
install the. snapshots by doing a local build
we have abbandonded deploying non-snapshots as it only causes pain,
and after all the release early, release often strategy works well
for
us. we had over 163 releases of one project in a 9 month period
Sent from my iPod
On 24 Dec 2008, at 14:45, Stephen Connolly
<[email protected]
wrote:
if the parent is only being downloaded from the maven repo, and you
have not checked it out of scm locally, you should really be using a
released version and not a snapshot.
if you're using a release version then update-parent will do what
you want
Sent from my iPod
On 24 Dec 2008, at 01:59, nodje <[email protected]> wrote:
alas, -U doesn't work for parent pom, only for dependencies!
thanks fo the plugin anyway!
Stephen Connolly-2 wrote:
2008/12/23 nodje <[email protected]>
yep, it works with -DallowSnapshots=true, thanks.
I got mistaken because of one example that was using
-DallowSnapshots=false,
I thought true was the default value.
I get it for the parent problem. I've been redirected to the
version
plugin
by Maven folks about the automatic parent pom upgrade. We still
have to
wait
for it to be fixed I guess.
I've tried to deploy a new 3-SNAPSHOT version of my parent pom to
the
local
repository.
However, other machines wouldn't get the latest, just deployed
version,
with
a <mvn versions:update-parent -DallowSnapshots=true>.
It would only upgrade the pom with the latest found parent
version, but
not
find out there's a newer SNAPSHOT in the repository, isn't it?
If you're looking at 3-SNAPSHOT vs 3-SNAPSHOT, that's not what
versions-maven-plugin is for.
versions-maven-plugin is to change the version numbers.... so 3-
SNAPSHOT
->
3.1-SNAPSHOT
If you just want to pick up the latest snapshot, just run mvn with
-U
cheers
Stephen Connolly-2 wrote:
2008/12/22 nodje <[email protected]>
How would you configure the plugin so that it executes at each
mvn
execution? Or better, follow the regular Maven once-a-day
update
policy
applied to the dependencies.
That cannot ever work...
Maven reads the pom when it starts... versions-maven-plugin
changes the
pom... the pom on disk will not be the same as the pom that
maven read
in
before running versions-maven-plugin.
You *always* have to run versions-maven-plugin on its own...
e.g.
mvn versions:update-parent -DallowSnapshots=true
mvn clean install
Binding it to a phase will not do what you think it should do!
--
View this message in context:
http://www.nabble.com/Versions%3Aupdate-parent-usage-tp21125090p21139080.html
Sent from the mojo - user mailing list archive at Nabble.com.
---
---
---------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
View this message in context:
http://www.nabble.com/Versions%3Aupdate-parent-usage-tp21125090p21154214.html
Sent from the mojo - user mailing list archive at Nabble.com.
---
------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
View this message in context:
http://www.nabble.com/Versions%3Aupdate-parent-usage-tp21125090p21172314.html
Sent from the mojo - user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
