If you really want to get fancy, this is also possible. Only this
requires a little more hacking.
Take a look at [1] which checks the dependencies, especially line 171 to
174.
prompter.showMessage(
"This project relies on a SNA
I think it is very simple and also easy to keep up to date.
Start with checking out the Release Manager and the plugin:
svn co http://svn.apache.org/repos/asf/maven/release/trunk release
Change the file
maven-release-manager/src/main/resources/META-INF/plexus/components.xml
to reflect the pha
Wow. Thanks for the very insightful approach. It's kind of a very invasive
one in changing "code", but one that I may very well need to use if I keep
having to cut a release of our project that depends on these SNAPSHOTs.
-Matthew
nick_stolwijk wrote:
>
> Another solution is to check out the
Thanks for the workaround. You are right -- that could get really tedious in
following the thread of SNAPSHOTs. I will give it a try. But I really wish
there were an option to flat out "override" the release plugin to
acknowledge "I'm doing something really dangerous but let me do it
anyway"...
Another solution is to check out the release manager and remove that
phase from the components.xml and release an own version of the release
manager and release plugin. It is not a nice way, though.
Hth,
Nick Stolwijk
Steven Rowe wrote:
Hi Matthew,
I have gotten around this problem by deplo
Hi Matthew,
I have gotten around this problem by deploying the SNAPSHOT projects in
question to an internal repository, after first renaming their versions
from X.X.X-SNAPSHOT to X.X.X-myco-X (or something similar). This can
get messy, since SNAPSHOTs sometimes depend on other SNAPSHOTs, and
thos
Mavenites,
I have a project in which we depend on SNAPSHOTs. Unfortunately, three of
them are not actively being developed at the moment, however we still have
to use them. I realize it is a very bad practice to depend on these since
you never know what is going to be changed. However, is ther
