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]
>
>

Reply via email to