| Summary: | ParExportTestCase.testExportOperation is failing with a PackageNotFoundException | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Leo Dos Santos <leo.dos.santos> |
| Component: | tooling | Assignee: | Miles Parker <milesparker> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, glyn.normington, milesparker, mlippert |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Leo Dos Santos
I'm wondering if the EMF model backing the par tooling needs to be updated to accommodate for bundle & package name changes due to the Eclipse.org migration? Miles, I know EMF is one of your strengths, maybe you'd like to look at this one? OK, this fixes it. (It also doesn't include history of other bad commit.) I needed to manually change a file in the workspace test. We should probably be generating that with SWTBOT instead of relying on a prior creed project but that's not biggie. Note that this change also removes inaccurate attributions from code comments. https://github.com/MilesParker/Virgo-Tooling/commit/1efc87bc57d7214860b52923a50980c4d49db7ad 1) I wrote all of the code. 2) I have authorization from my employer, Tasktop. Thanks for looking at this Myles. I have one concern before applying it and I want to pull Glyn into the conversation to get his feedback. This patch will fix the export test case, at the expense of breaking the par editor for existing pars with the old namespace in *.par.xml. There are migration instructions at http://wiki.eclipse.org/Virgo/Tooling but they will need to be updated yet again to document the EMF tooling URI change. With us dropping support for the dm Server in the near term (https://bugs.eclipse.org/bugs/show_bug.cgi?id=341911) we could make a clean break, or we could also try to provide some in-tool migration mechanism. But right now some people might be using the first Virgo IDE milestone with an expectation of what the par tooling provides, and we will likely break them with this change. Glyn, what are your thoughts on backwards compatibility and the Virgo tools? As I mentioned to Leo, we could come up with a way to read the files in and deal with the exception when the wrong URI is in an older file. But then we have to create tests for it, etc.. It seems to me that we're going to be breaking a lot of other stuff as we're going to be ripping out library dependencies, changing the names of builders, classpaths, etc., etc. Perhaps we should put this on hold and revisit the issue of OOTB backward compatibility (for existing projects, older servers would be supported in any case) when we have a better sense of the overall scope of changes that will be required to current projects. (In reply to comment #3) > Glyn, what are your thoughts on backwards compatibility and the Virgo tools? If we had infinite resource, Virgo tooling would understand dm Server projects and automagically migrate them. But we have limited resource, this is probably tricky to get right and cover in automated regression tests. Since there will hopefully be a one-time impact as users migrate from the dm Server tooling to the Virgo tooling, I think it's fine not to be backward compatible provided we are very careful to document in the migration guide the incompatibilities *and* the necessary steps that users need to take. I think that's reasonable Glyn. I've opened a bug to document the change before releasing the tools: 369458: Document the par.ecore URI change in the Migration wiki https://bugs.eclipse.org/bugs/show_bug.cgi?id=369458 Myles, I've applied your change, which can be seen here: http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?id=01abe8dab25cbf4125bb16f244363d855d1dddc0 I had to make a modification to the generated model so that we could continue to build against the Helios update site: http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?id=94c692a447f2c78653e81018c43c9d0ef2eee837 This test case is passing now. Thanks Myles. |