It is the STS plugin for Eclipse, not the STS distro. Because m2e has updated faster than STS releases.
On Sat, Nov 3, 2012 at 8:07 PM, Ron Wheeler <rwhee...@artifact-software.com> wrote: > We never use anything outside Eclipse/STS and do not have any problems with > Maven. > > I don't understand why you have m2e installed with STS. > > Ron > > > On 03/11/2012 2:37 PM, Jeff Jensen wrote: >> >> Yes, that's what I uninstalled, the STS one. Funny there were no >> conflicts noticed prior. >> >> And it's weird behavior still - it works at Eclipse start but not on >> clean or incremental builds. Restarting Eclipse causes it to work but >> then it stops after one build. If I delete its dir and the dep >> plugin's markers dir and then force Eclipse incremental or clean >> build, I see the "Unpacking..." message in the Eclipse "Maven Console" >> view, but it doesn't do it. At least it works at Eclipse start, but >> requires running Maven build manually to make it happen again. >> >> On Sat, Nov 3, 2012 at 11:32 AM, Ron Wheeler >> <rwhee...@artifact-software.com> wrote: >>> >>> Did you have 2 m2e installations? >>> STS includes m2e. >>> >>> Ron >>> >>> >>> On 03/11/2012 10:40 AM, Jeff Jensen wrote: >>>> >>>> Fixed. >>>> >>>> We also use Spring STS, and, whatever its "Spring STS Maven Support" is, >>>> it >>>> was preventing m2e from executing it. >>>> Uninstalling just the STS Maven Support feature magically made it work. >>>> >>>> For future googlers, this is the page to read: >>>> http://wiki.eclipse.org/M2E_plugin_execution_not_covered >>>> >>>> >>>> >>>> On Fri, Nov 2, 2012 at 5:34 PM, Jeff Jensen < >>>> jeffjen...@upstairstechnology.com> wrote: >>>> >>>>> Thanks for the suggestions. >>>>> I tried the dependency plugin. Works great as a Maven goal. I have >>>>> not >>>>> found a m2e lifecycle mapping for unpack yet; finding some info, so >>>>> hope >>>>> to >>>>> make it work within the IDE. >>>>> Tried this [0] with <execute/> but only removed the warning of no >>>>> lifecycle mapped. Will continue trying to find the answer, as it >>>>> appears >>>>> to work for others... >>>>> >>>>> [0] >>>>> >>>>> >>>>> http://stackoverflow.com/questions/8706017/maven-dependency-plugin-goals-copy-dependencies-unpack-is-not-supported-b >>>>> >>>>> >>>>> On Fri, Nov 2, 2012 at 3:52 PM, Winsor, Daniel >>>>> <daniel.win...@etrade.com>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> If I understood correctly, what I'd do is make a dummy pom with a >>>>>> maven-dependency-plugin:unpack goal with output directory as the >>>>>> working >>>>>> directory, then just build that dummy project whenever you want. >>>>>> >>>>>> Another thing you can do is overlay the .war when building the test >>>>>> module, or vice versa, using the maven-war-plugin. >>>>>> >>>>>> I don't have problems running either of these plugins in Eclipse. >>>>>> >>>>>> Hope this helps, >>>>>> Daniel Winsor >>>>>> Associate, IT Architecture >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/2/12 1:07 PM, "Jeff Jensen" <jeffjen...@upstairstechnology.com> >>>>>> wrote: >>>>>> >>>>>>> We have some integration tests and prefer to use an embedded Tomcat >>>>>>> instance vs deploying to an external, running server (avoid external >>>>>>> dep >>>>>>> problem). The tests are in a separate module than the war module. >>>>>>> The >>>>>>> need is to retrieve the built war from the local repo and explode it >>>>>>> into >>>>>>> the working directory for the embedded instance. >>>>>>> >>>>>>> We're also trying to avoid using a Maven plugin to retrieve and >>>>>>> explode >>>>>>> the >>>>>>> war to prevent problems with running the tests in IDEs (Eclipse + m2e >>>>>>> and >>>>>>> IDEA). (However, possibly a Maven plugin wouldn't cause problems for >>>>>>> them?) >>>>>>> >>>>>>> I'm wondering if anyone has solved this in a simple manner. I've >>>>>>> been >>>>>>> googling, reading, and trying a few things and have not found an >>>>>>> answer >>>>>>> (perhaps I'm close but missing a final how-to). I've investigated >>>>>>> things >>>>>>> like Shrinkwrap, java.util.jar.JarFile, and bloggers' own >>>>>>> craptaculous >>>>>>> approaches on file manipulations, and now wondering if Aether is what >>>>>>> to >>>>>>> try next. What I've seen keeps looking like brute-force coding... >>>>>>> >>>>>>> I'm close to moving the ITs into the war module, as the packaged war >>>>>>> is >>>>>>> right there in target... >>>>>>> However, would be good to know a good way or two of solving retrieval >>>>>>> of >>>>>>> artifacts from the local repo. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>> >>>>>> >>> >>> -- >>> Ron Wheeler >>> President >>> Artifact Software Inc >>> email: rwhee...@artifact-software.com >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
