Also, I have used another method: start the Eclipse Installer, add the setup file to be tested to the <User> projects folder, and select those components for installation, to create a new workbench. I assume this would not conflict with the existing workbench. Is this correct?
That’s right. It’s just confusing that then there are two copies of everything: the “official” projects in the central catalogue and your local user projects. And trying to switch back and forth between these projects in a single workspace is awkward. But it works fine.
I've used this approach to install new workbenches with new workspaces, in order to recreate the scenario of a user that doesn't have the workbench already installed.
But considering the troubles that I've had, not just with m2e but also with my "Secure Storage" and the EMF code generation, I'm wondering if there might be something that might be causing conflicts between multiple installations. Perhaps issues with my .p2, .m2 or .eclipse folders. If I remove these, I should be in a clean slate right?
The nuclear option? It seemed to work for Asma. But, it removes a lot of goodness, such as Oomph’s download cache directory and the bundle pool. In fact, deleting that bundle pool yanks out all of the plug-ins from your Oomph-managed Eclipse installations, so you’ll have to delete all of those, too, because they won’t work any more. I can’t really see your secure storage and maven problems being caused by interference from other installations; Oomph and p2 keep this stuff pretty well isolated. But, I don’t actually know what’s happening in your environment, so I can’t advise one way or the other. Sorry.
I think we could just suppress the antrun in this lifecycle mappings preference file for now and remove the same from the POMs. That just leaves the three lifecycle errors in the feature POMs that I mentioned earlier, which we can then review. The nice thing about this is that by default, m2e doesn’t create this file in the preferences, so we can actually create it in the setup model and then the next time developers run the setup, they will get this file. That is, assuming they didn’t already create it for themselves. That’s the tricky bit: we get one chance at creating this file; Oomph will not replace it if we make changes (users would have to delete it and then let Oomph re-create it). BTW, the m2e connectors that we know we need are currently installed in my Eclipse from here: org.sonatype.tycho.repository - http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.8.0/N/LATEST/
So, we can just go with these for now in the setup model?
Done. I just pushed 72559 and added you as a reviewer. I put the features and these two repos under the "Core Development Tools" P2 director. Is that the appropriate place?
Yup, that’s a good place. We need them now to continue development on these sources (at least, with a minimum of red Xes showing), so they are “core tools”. Alternatively, we could create a new p2 task for them to highlight their different nature as high-maintenance installable units. I think I might rather prefer that. Maybe a p2 tasked labelled “Maven Connectors for m2e”.
I haven't tested it yet. I'm about to.
I’ll try it, too.
For the m2e buildhelper we still have only that very specific version, right?
It’s the only one I know of, and I seem to have had it installed a while now and more or less soak-tested it, so I’d say “yes.” |
