Re: [cross-project-issues-dev] Fwd: [modeling-pmc] Ed Willink standing down from MMT, OCL, QVTd, QVTo
Hi, As for QVTo dependencies. As Ed mentioned QVTo utilizes only three plug-ins of Classic OCL: org.eclipse.ocl org.eclipse.ocl.common org.eclipse.ocl.ecore Being bundled along with QVTo will make the latter fully self-contained. So I believe repackaging Classic OCL this way looks like a rational solution. Regards, Sergey. On Wed, Apr 3, 2024 at 8:49 PM Edward Willink via cross-project-issues-dev < cross-project-issues-dev@eclipse.org> wrote: > Hi > > You are looking at minor dependencies for which the OCL aspect is > unwise/obsolete/irrelevant. > > The major dependencies are QVTo and Papyrus; other projects should wait > to see what these projects do. > > The constraint aspect of Papyrus is heavily dependent on the new Eclipse > OCL that exploits Xtext. This is unlikely to survive long before the > infrastructure needs an at least minor rebuild. The OCL usage of Xtext > uniquely avoids tight coupling but some Xtext evolutions tend to require > a compatibility tweak. > > QVTo is heavily dependent on the old Classic Eclipse OCL that is very > stable. However an infrastructure evolution will eventually break it. If > the remaining QVTo committer is enthusiastic, the classic OCL plugins > could be folded into QVTo and, if exported, could be used to satisfy the > minor dependencies. > > (QVTd is still an incubation project that has failed to popularize an > OMG standard. It has very few users. Not needed in SimRel.) > > Regards > > Ed Willink > > On 03/04/2024 18:06, Ed Merks via cross-project-issues-dev wrote: > > > > Thanks. Yes, I was already looking at EMF Services' dependencies > > > ___ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] QVTo participation in 2018-09
Hi, QVTo will participate in the 2018-09 SimRel with an offset of +2. Release record: https://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/2018-09-3.9.0 Cheers /Sergey ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] QVTo will participate in Photon
Hi, QVTo will be participating in Photon release train. The offset will be +2. Release record: https://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/3.8.0 Cheers /Sergey ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] QVTo participation in Oxygen
Hi, QVTo will be participating in Oxygen release train. The offset will be +2. Release record: https://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/3.7.0 Cheers /Sergey ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] QVTo participating in Mars release
Hi, QVTo will be participating in Mars. The offset will be +2. Release record: https://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/4.0.0 Sergey Boyko ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Luna M3 staging repository is complete
Hi David, I'm very sorry but QVTo has missed Luna M3 deadline. It's ready now. Is it possible to rebuild Luna M3 repository with it? Best Regards, Sergey. On Thu, Nov 14, 2013 at 2:26 AM, David M Williams david_willi...@us.ibm.com wrote: Here it is ... 5:00 PM on Wednesday (Eastern time), no jobs running, no requests for extensions, so I'm declaring the Luna M3 repository complete. Please test http://download.eclipse.org/releases/staging/ If no blockers reported, I'll add M3 to the composite .../releases/luna on Friday morning. Here is the state of disabled projects ... I think this matches what the many previous notes/replies said ... Contribution disabled: (indicating no commitment yet to join Luna) amp.b3aggrcon pdt.b3aggrcon soa-sca.b3aggrcon Repository disabled: (indicating plans to join Luna, just not quite ready) riena.b3aggrcon sphinx.b3aggrcon Feature disabled: (indicating issue with just one feature) dltk.b3aggrcon (long standing disabled feature: Bug 415535) I'll re-enable the runaggregator job on Friday after EPP builds are ready. Thanks! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] QVTO Participating in Luna
Hi, The QVTO project will be participating in the Luna simultaneous release. The release record can be found here [1]. QVTO has an offset of +2. [1] http://projects.eclipse.org/projects/modeling.mmt.qvt-oml/releases/3.4.0 Best regards, Sergey Boyko ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [epp-dev] CRLF in mmt-qvto.b3aggrcon
Hi Tomasz, It was my mistake. Thank you for fixing it. Regards, Sergey On Fri, Aug 23, 2013 at 6:18 PM, Tomasz Zarna tomasz.za...@tasktop.comwrote: Oops, sorry for spamming the wrong list. Fixed the line endings in http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=df27dbe578c5b54100c4faedb942fed014867183 Cheers On Fri, Aug 23, 2013 at 4:00 PM, Markus Knauer mkna...@eclipsesource.comwrote: Hi Tomasz, since you are going to take over the Simultaneous Release Train contribution role from Steffen, you should make sure that you get access to the org.eclipse.simrel.build Git repository yourself. And then... sometimes it's confusing which mailing list is the correct one... in this case it affects the Simultaneous Release (and not EPP itself) and cross-project-issues-dev@eclipse.org would be the right one. Thanks, Markus On Fri, Aug 23, 2013 at 3:34 PM, Tomasz Zarna tomasz.za...@tasktop.comwrote: Hi guys, mmt-qvto.b3aggrcon seems to be the only file with Windows line endings (CRLF), I guess this is by mistake [1]. Not a big deal but can someone fix this? Cheers, [1] https://github.com/eclipse/simrel.build/commit/bbcfa3b8f1dc97f3d4393ccb427f6b7b839111c4#mmt-qvto.b3aggrcon -- Tomasz Zarna Software Engineer, Tasktop Dev Committer, Mylyn/Review, EGit, Eclipse Platform/Resources, Orion http://tasktop.com ___ epp-dev mailing list epp-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/epp-dev ___ epp-dev mailing list epp-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/epp-dev -- Tomasz Zarna Software Engineer, Tasktop Dev Committer, Mylyn/Review, EGit, Eclipse Platform/Resources, Orion http://tasktop.com ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Luna M1
QVTo was re-enabled for Luna. Cheers... Sergey On Wed, Aug 21, 2013 at 8:00 AM, David M Williams david_willi...@us.ibm.com wrote: Doesn't look good. I'll admit there is one day left, but so far 50 projects have not even enabled their contribution to Luna (pasted below). ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [modeling-pmc] Notifcation to let QVTO contribute to Juno
Hi Nicolas, Webmaster had restored my access rights to development server and I published QVTo M4 build. I updated 'm2m-qvtoml.b3aggrcon' with this build for Juno and aggregation build was ok ( https://hudson.eclipse.org/hudson/job/juno.runAggregator/189/). So QVTo normally joined Juno sim.release train. In nearest days I'm going to take up other formal steps for Juno ( http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements). Regards, Sergey On Mon, Dec 19, 2011 at 8:11 PM, Rouquette, Nicolas F (313K) nicolas.f.rouque...@jpl.nasa.gov wrote: Sergey, The patch we discussed back in August is still waiting approval from JPL/Caltech lawyers; I've escalated this request recently. At the OMG, I officially represent NASA's interests in modeling specifications and in that capacity, I strongly support the excellent work Eclipse has done in implementing OMG's key modeling specifications in various Eclipse projects -- EMF core, EMF/XSD, OCL, UML, QVTO. Also at the OMG, I have pioneered using QVTO for producing the official, published machine-readable files for several specifications: SysML 1.2 -- http://www.omg.org/spec/SysML/1.2/ UML 2.4.1 -- http://www.omg.org/spec/UML/2.4/ SysML 1.3 -- not yet publicly available At JPL, we've developed a rigorous integration between MOF2 / OWL2 using QVTO, SPARQL and OWL2 reasoners. Whether it is for JPL or for NASA, it is clear to me that QVTO is a very important specification and the Eclipse QVTO is essential in making this specification practically useful. I hope this suffices to clearly indicate that there is a strong interest in QVTo participating in the Juno release train. On the commercial side, I'm aware of two vendors that use Eclipse QVTO in their products: - IBM's Rational Software Architect 8 is based on Eclipse Helios and specifically refers to Eclipse QVTO as a technology option for model transformation - NoMagic developed a JSR-233 script engine wrapper to use Eclipse QVTO in their flagship modeling tool, MagicDraw 17.0 As I mentioned before, I believe it would be useful to contact these vendors to promote the fact that they use Eclipse QVTO in their products and perhaps create additional revenue streams to support the ongoing development/improvement of Eclipse QVTO. At least, I've personally committed $1,000 specifically to support Eclipse QVTO; this means you and whoever else works as an unpaid committer on Eclipse QVTO. - Nicolas. On Dec 19, 2011, at 1:06 AM, Sergey Boyko wrote: Hi Philipp, Problem with QVTo participation on Juno release train comes from the fact that I didn't get clear response whether somebody requires that participation. When we discussed with Nicolas (in August) patch from NASA we decided that QVTo release for Indigo is the right target to merge the patch to (I prepared maintenance branch for that). I also expect some input from re-istablished GMF Tooling project but there was nothing. Without clear interest of QVTo participating in Juno realease train I didn't see the need to perform all the administrative steps to keep project on train. Regards, Sergey Boyko On Sat, Dec 17, 2011 at 4:55 PM, Philipp W. Kutter | Montages AG kut...@montages.com wrote: Perfect! I wish you all Happy Holidays! It is a great feeling that the OMG standards based projects are going strong and will all be on the Juno releasse train! If there is a doubt in the future that any of these projects will not be on the release train, simply because nobody is there to fulfill the formalities of the project or the details of the newest build project, we can always help. As Miles mentions, this may need to add some people of other modeling projects to the committer teams. Could the modeling PMC send out a mail and ask the modeling teams a) who sees a risk they will not be on the release train, simply because of lack to fulfill the formalities and the build project b) who would volunteer to help out for other projects. As well, it might be a good policy, to have a backup plan, if a component lead is either not available, or ill, or otherwise gone in the very moment he needs to promote the project. Immagine an important project, with lots of dependencies does not release, simply because the component lead is in-available. The costs can be huge. Thanks for the great work of the Eclipse Foundation, Philipp On 17.12.2011 01:44, Ed Willink wrote: Hi Miles There is no need to panic. In view of some delicacies, considerable correspondence has happened off-list. Nicolas Rouquette has now resolved both the problem and the delicacies by his open email to these lists that you must have missed. Thanks to Nicolas' generosity, QVTo will be available in Juno supported by the existing QVTo team. The only process exception that may be needed is tolerance of a one or two day tardiness in setting the contribution flag. I'm sure we all wish to thank
Re: [cross-project-issues-dev] [modeling-pmc] Notifcation to let QVTO contribute to Juno
Hi Philipp, Problem with QVTo participation on Juno release train comes from the fact that I didn't get clear response whether somebody requires that participation. When we discussed with Nicolas (in August) patch from NASA we decided that QVTo release for Indigo is the right target to merge the patch to (I prepared maintenance branch for that). I also expect some input from re-istablished GMF Tooling project but there was nothing. Without clear interest of QVTo participating in Juno realease train I didn't see the need to perform all the administrative steps to keep project on train. Regards, Sergey Boyko On Sat, Dec 17, 2011 at 4:55 PM, Philipp W. Kutter | Montages AG kut...@montages.com wrote: Perfect! I wish you all Happy Holidays! It is a great feeling that the OMG standards based projects are going strong and will all be on the Juno releasse train! If there is a doubt in the future that any of these projects will not be on the release train, simply because nobody is there to fulfill the formalities of the project or the details of the newest build project, we can always help. As Miles mentions, this may need to add some people of other modeling projects to the committer teams. Could the modeling PMC send out a mail and ask the modeling teams a) who sees a risk they will not be on the release train, simply because of lack to fulfill the formalities and the build project b) who would volunteer to help out for other projects. As well, it might be a good policy, to have a backup plan, if a component lead is either not available, or ill, or otherwise gone in the very moment he needs to promote the project. Immagine an important project, with lots of dependencies does not release, simply because the component lead is in-available. The costs can be huge. Thanks for the great work of the Eclipse Foundation, Philipp On 17.12.2011 01:44, Ed Willink wrote: Hi Miles There is no need to panic. In view of some delicacies, considerable correspondence has happened off-list. Nicolas Rouquette has now resolved both the problem and the delicacies by his open email to these lists that you must have missed. Thanks to Nicolas' generosity, QVTo will be available in Juno supported by the existing QVTo team. The only process exception that may be needed is tolerance of a one or two day tardiness in setting the contribution flag. I'm sure we all wish to thank Nicolas for being so helpful to Eclipse. Thank you Nicolas. Regards Ed Willink On 16/12/2011 23:57, Miles Parker wrote: Philipp, You should identify QVTO leadership, which means M2M nee MMT, so that they can make the change in their portal. (This of course would have to be in the middle of a project renaming!) That would require all of MMT to join train, I don't know if it's possible to do this more fine-grained than that. PMC can flip the bit for MMT, but I don't think we should do that unless/until we have support from project leadership or at least active committers if they exist. Comments? William, I'm cc'ing you because I note that you have contact with Frédéric Jouault who is project lead..? Perhaps you could pass on his email to Phillip. FWLIW, I'll support any process exception if needed/possible once that is sorted out. Phillip, thanks for taking the initiative on this. Why don't you report back to PMC list as you make progress? cheers, Miles On Dec 16, 2011, at 12:29 PM, Philipp W. Kutter | Montages AG wrote: Dear PMC. I would like to notify that QVTO should flip the bit for Juno. I hope this has already been done by the QVTO team itself. In the unexpected case, that the current QVTO team will not have time to trigger the newest ways of building the QVTO, I can guarantee development time from the GMF Tolling component lead Michael Golubev, who knows well the newest ways of building. As well, there is a cummulative patch from Nicolas Rouquette, which we would love to integrate in the new build, if the QVTO team has not yet done. The GMF Tooling project has a strong dependency on QVTO and would fail in their efforts to do their releases in the future, if QVTO build fails. As well, the sponsor of the 3 FTE working on GMF tooling requests that GMF Tooling as well as the project it depends on are remaining in Juno, so we have a multiyear 3 FTE sponsorship at risk, if this does not happen. We want to do all to support the current team to do the Juno builds. There is a budget from Nicolas Rouquette and us, which would offer $ 2000 to who ever in the QVTO team wants to do this. And we support with development time from the 3 FTE working on GMF Tooling, if needed. Please forward this message as well to the QVTO team, whom I do not know personally. Please assure them of our full support. I did not find a mailing list for them. And, as today is the deadline, please accept this notification, even if formally it comes from
