Community
Participate
Working Groups
There is a new problem with qvto: https://download.eclipse.org/oomph/archive/simrel/qvto.aggrcon/index.html Specifically this feature and its associated "Developer Resources" source feature https://download.eclipse.org/oomph/archive/simrel/qvto.aggrcon/index/org.eclipse.m2m.qvt.oml.editor.feature.group_3.10.2.v20200414-0956.html I suspect this is caused by some type of merge problem that corrupted the XML. https://git.eclipse.org/c/mmt/org.eclipse.qvto.git/tree/features/org.eclipse.m2m.qvt.oml.editor.feature/feature.xml I.e., it contains content like this: version="3.10.2.qualifier">>>>>>> 4e2d158 [releng] Bump build/features by +0.0.1 for 3.10.2 It came from this commit: https://git.eclipse.org/c/mmt/org.eclipse.qvto.git/commit/features/org.eclipse.m2m.qvt.oml.editor.feature/feature.xml?id=d492f3cf2610a70794364ed90ab787bb3099ad60
Ouch! Yes. Thanks. Obviously there was a merge problem that I cleaned up manually, but only 90% successfully. Is the failure to validate trailing text on a String a PDE or EMF/XSD bug? What tool were you using that alerted you to the problem?
New Gerrit change created: https://git.eclipse.org/r/161033
Gerrit change https://git.eclipse.org/r/161033 was merged to [master]. Commit: http://git.eclipse.org/c/mmt/org.eclipse.qvto.git/commit/?id=541f5a7abea9fcee8aff6dfc84e5ff69817a5af6
(In reply to Ed Willink from comment #1) > Ouch! Yes. Thanks. Fix pushed to master for 3.10.2M2 > What tool were you using that alerted you to the problem? Presumably OOMPH tooling which uses an EMF reader, so EMF doesn't validate suffixed strings or OOMPH doesn't check all the Resource.errors/warnings. Do you know if the lack of warning in the MANIFEST.MF feature.xml tab is PDE or EMF or ...?
(In reply to Ed Merks from comment #0) > There is a new problem with qvto: > > https://download.eclipse.org/oomph/archive/simrel/qvto.aggrcon/index.html Can you live with the bad license diagnostic till M2, or is an M1a build needed?
PDE doesn't seem to complain about such a corrupted feature.xml, not even in the editor which still shows a full outline. But if I look at the Version tool we're using, it's clear that some of the underlying PDE frameworks are effectively truncating the XML such that only the attributes before the >>>> are "visible". I notice the problem because I look at the report that's updated/generated daily: https://download.eclipse.org/oomph/archive/simrel/ Unfortunately there ware still three projects with minor easy-to-fixed problems that have not gotten their act together to fix it, so finding/noticing new problems is hampered by the fact that we've never gotten the repo into a problem free state. In any case, this one has a new problem: https://download.eclipse.org/oomph/archive/simrel/qvto.aggrcon/index.html I also look at this which is also updated/generated daily: https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2020-06/index.html In both cases, the reports tell me what I can expect will be problems in the upcoming M*, RC* or R. The staging report gives me an overview of everything on the train and the simrel report let's me track down where the bad things come from.
(In reply to Ed Willink from comment #4) > (In reply to Ed Willink from comment #1) > > Ouch! Yes. Thanks. > > Fix pushed to master for 3.10.2M2 > > > What tool were you using that alerted you to the problem? > > Presumably OOMPH tooling which uses an EMF reader, so EMF doesn't validate > suffixed strings or OOMPH doesn't check all the Resource.errors/warnings. > I only notice because of the bad results in the p2 repositories. > Do you know if the lack of warning in the MANIFEST.MF feature.xml tab is PDE > or EMF or ...? I'm not sure why you are bring up EMF at all? Clearly PDE is responsible for all the tooling.
(In reply to Ed Willink from comment #5) > (In reply to Ed Merks from comment #0) > > There is a new problem with qvto: > > > > https://download.eclipse.org/oomph/archive/simrel/qvto.aggrcon/index.html > > Can you live with the bad license diagnostic till M2, or is an M1a build > needed? I don't think it's worth it to ask for a respin; that's too much work and it's only M1...
(In reply to Ed Merks from comment #7) > I'm not sure why you are bring up EMF at all? Because I, wrongly, assumed that OOMPH was using EMF. > Clearly PDE is responsible for all the tooling. Bug 562197 raised.
