That's the best practice. Read about it if you don't believe me. Kalle
On Wed, Apr 14, 2010 at 2:32 PM, Justin Lee <[email protected]> wrote: > I thought about that (and I plan on moving all our deps to that -- the > current set up is a mess) but it seems a bit of an antipattern to have to > specify intra-project dependencies like that. Seems overly redundant. > > On Wed, Apr 14, 2010 at 5:30 PM, Kalle Korhonen > <[email protected]>wrote: > >> On Wed, Apr 14, 2010 at 2:06 PM, Justin Lee <[email protected]> wrote: >> > I'm working on making the grizzly deployments actually work with maven >> > [INFO] The version could not be updated: ${grizzly-version} >> > The problem, it seems, is that we use the property grizzly-version >> defined >> > in the root pom ( >> https://grizzly.dev.java.net/svn/grizzly/trunk/code/pom.xml) >> > to specify the intermodule dependencies. Now, I've seen poms that don't >> > specify the module versions in the deps but when I try that, the pom >> fails >> > to validate. So I guess I have two questions: >> > 1. Can we not use the property for the dependency version number like >> > that? Do we need to hard code the project version? >> > 2. How can we eliminate that version entry from the dependency >> > altogether? That'd be the simplest way, i think, if it works that way. >> >> Use dependency management section of the parent pom to specify >> versions for the child modules. Then don't explicitly specify versions >> when referring to any of your own dependencies. You don't have to >> hard-code versions in the parent pom for each separately, you can use >> properties. You should always use snapshot version when specifying >> version for your own modules in development. The release plugin >> handles updating the versions from snapshot to release and back. For >> example, see various other projects using Maven, such as >> http://svn.apache.org/repos/asf/incubator/shiro/trunk/pom.xml >> >> Kalle >> >> --------------------------------------------------------------------- >> 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]
