Looks like we have a winner. ${grizzly-version} is redundant anyway.
Replacing it with ${project.version} achieves the same goal and works with
the release plugin. I'll run with that for now. Thanks, everyone.
On Wed, Apr 14, 2010 at 5:51 PM, Justin Lee <[email protected]> wrote:
> That's a good suggestion. I'll try that and see how that works.
>
>
> On Wed, Apr 14, 2010 at 5:44 PM, Benson Margulies
> <[email protected]>wrote:
>
>> Well, usually, all the related-by-aggregation submodules have the same
>> version, so ${project.version} works in the dependencies.
>>
>> On Wed, Apr 14, 2010 at 5:42 PM, Justin Lee <[email protected]> wrote:
>> > I don't doubt it. and for external deps, i'm all for it. but for
>> > intra-project dependencies, it's a huge deficiency regardless of best
>> > practice status or not. But if that's the best that maven can do right
>> now
>> > then that's what i'll have to deal with. I'd rather hard code those
>> version
>> > numbers throughout, though, and let the release plugin update them when
>> it
>> > runs. That beats maintaining a separate list of modules in the root
>> pom.
>> >
>> > On Wed, Apr 14, 2010 at 5:39 PM, Kalle Korhonen
>> > <[email protected]>wrote:
>> >
>> >> 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]
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
