Brian, the changes in 2.2 were in the copy goal. the copy-dependencies goal is the one being used by Reinhart
Reinhart, are you sure this is a change between 2.2 and 2.1, and nite some side-effect of having run the install phase on your dependencies locally? if the artifact is resolved from the reactor or the local repo it will be -snapshot if resolved from a remote repo which has unique versions true, or maven 3 was used to deploy, it will be the timestamp. if the filename is critical to you use the copy goal instead as, since 2.2 that now resolves from the reactor and so can be used in all cases too (whereas prior to 2.2 if it was a dependency on a reactor module you would have had to use copy-dependencies) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 16 Jul 2011 00:59, "Brian Fox" <[email protected]> wrote: > If the snapshot was resolved from a repo then it will be timestamped, > if it came from the reactor or local repo, then it will be -SNAPSHOT. > The plugin calls into the maven resolution logic so this is core maven > behavior. > > In 2.2, resolution from the reactor was introduced for these goals, > previously they would always go to the repository, this could be why > you see a change in the new version. > > > On Fri, Jul 15, 2011 at 5:28 AM, Reinhard Nägele > <[email protected]> wrote: >> Hi all, >> >> We use the dependency plugin's goal "copy-dependencies" in several projects. >> For snapshot dependencies, it would copy unique snapshot jars until version >> 2.1. Since version 2.2, the behavior has changed in that now timestamped >> snapshots are copied. >> >> I could not find this change anywhere in the release notes. In fact, it is >> not documented at all, what the correct behavior is supposed to be. Is >> anyone aware of this change? Has it happened on purpose or by accident? >> Anyway, I'd really like to get the old behavior back. I think this should be >> configurable. >> >> Any opinions or insights? >> >> Thanks, >> Reinhard >> >> >> >> >> --------------------------------------------------------------------- >> 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] >
