That flag is what I was looking for. Thanks! I'll give it a shot. On Tue, 2009-02-10 at 23:11 -0500, Jason van Zyl wrote:
> On 10-Feb-09, at 5:36 PM, Lincoln Baxter, III wrote: > > > > > > >> > >> The version must also match. If you refer to a project and the > >> version > >> doesn't match the version in your workspace then m2eclipse will use > >> normal Maven resolution which is checking your local and then remote > >> versions. > >> > > > > Yeah the versions match :) > > > >> > >> Maven is not m2eclipse. The Maven CLI is not going to be able to > >> build > >> anything if you don't have it installed. The CLI and m2eclipse's > >> operation inside Eclipse are two separate things. > > > > So when, in Eclipse, I do: > > > > > > Run As -> Maven Build > > > > > > Is that invoking the CLI or is m2eclipse doing the work? If it's > > actually invoking the CLI, then that's the reason, but if m2eclipse is > > doing the work, I would expect it to find my workspace dependencies > > during the build. (Which it's not) > > When you are executing a build the default is to use the embedder and > _not_ use artifacts in the workspace. You have to enable that in the > run configurations. There is a toggle for that. But whether the > embedded version of external version of Maven is used it's the CLI > code that is called. > > But this only affects Maven and Maven plugins that you are working on, > not your dependent projects. Maven executes as it normally would from > the command line. Maven itself cannot resolve artifacts in your > Eclipse workspace. > > > > > > > > Does that make sense? > > > > Thanks again, > > Lincoln > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more > examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
