Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component propo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)

From: Oleksandr Boyko <Oleksandr_Boyko@xxxxxxxxxx>
Date: Thu, 28 Aug 2008 12:06:09 -0400
Delivered-to: gmf-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/gmf-dev>
List-help: <mailto:gmf-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/gmf-dev>, <mailto:gmf-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/gmf-dev>, <mailto:gmf-dev-request@eclipse.org?subject=unsubscribe>

Rich,

Are we allowed to commit code into 2.0 maintenance stream? Since 2.0.1 and 2.0.2 were already released, isn't the stream considred as closed now?
Thanks.

Cheers,
Alex

Mariot Chauvin <mariot.chauvin@xxxxxxx>

Mariot Chauvin <mariot.chauvin@xxxxxxx>

Sent by: gmf-dev-bounces@xxxxxxxxxxx

08/28/2008 06:23 AM

Please respond to
"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc	gmf-dev-bounces@xxxxxxxxxxx, PMC members mailing list <modeling-pmc@xxxxxxxxxxx>
Subject	Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)

Please replace "2.0.1 version" with "2.0.2 version" (which is not an archived version :)) Sorry for the mix up, Cheers, Mariot Mariot Chauvin a écrit : > Hi all, > > Alex, Thanks for taking care of theses patches. > > For 242283 and 244297 both (2.1.2 and 2.2) will be great. > > For 243888, if you could add the 2.0.1 version, even if it's an archived > version, as this version is used in one of our project where we can not > easily upgrade. > > I will have a look to the 215179 today. > > Cheers, > > Mariot > > Oleksandr Boyko a écrit : >> Hi all, >> >> Since Anthony is away this week I'll be taking care of these patches >> till he's back. >> Jonathan, could you please specify which GMF version you'd like the >> fixes to be comiitted for? (2.1.2 and 2.2 or 2.2 only is sufficient) >> >> Now, Linda will commit the fix for 242283 >> >> I'll look into committing the rest. >> 215179 - you guys need to reevaluate this defect, since the related >> code has changed significantly. >> >> Cheers, >> Alex >> >> Inactive hide details for Richard Gronback >> <richard.gronback@xxxxxxxxxxx>Richard Gronback >> <richard.gronback@xxxxxxxxxxx> >> >> >> *Richard Gronback <richard.gronback@xxxxxxxxxxx>* >> Sent by: gmf-dev-bounces@xxxxxxxxxxx >> >> 27/08/2008 09:56 AM >> Please respond to >> "GMF Project developer discussions." >> <gmf-dev@xxxxxxxxxxx> >> >> >> >> To >> >> <gmf-dev@xxxxxxxxxxx> >> >> cc >> >> PMC members mailing list <modeling-pmc@xxxxxxxxxxx> >> >> Subject >> >> Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component >> proposal (code migration) >> >> >> >> >> Thanks for this, Jonathan. It’s exactly what I’d expect and encourage >> folks to do when it seems like their bugs aren’t getting the attention >> they should. >> >> As they are all runtime bugs, I’m certain Anthony will take a look. >> Regarding 215179, if it’s a blocker, why not set the severity >> accordingly? Severity is a user field, btw. >> >> Thanks again, >> Rich >> >> >> On 8/27/08 9:42 AM, "Jonathan MUSSET" <_jonathan.musset@obeo.fr_> wrote: >> >> Rich, >> >> Sorry for the wrong number... They were about 10 in my mind >> : perhaps 3 bugs + 4 patches == 10 with a french calculator >> (Human shortcut) >> I'm confused. I'll verify exactly my information the next >> time ;-) >> 2 of them are from january and march... >> But, I know the rules, and I can understand your reaction >> I totally agree that there are many things to consider when >> accepting patches but some of the following patches are >> trivial >> Here are more information : >> >> patch for a bug opened by someone of IBM : >> >> 242283 : NullPointerException from >> ViewUtil#getSourceConnectionsConnectingVisibleViews_ >> __https://bugs.eclipse.org/bugs/show_bug.cgi?id=242283_ >> patch : >> _https://bugs.eclipse.org/bugs/attachment.cgi?id=110084_ >> >> bugs opened by someone of Obeo >> >> 243888 : [Code Style] some methods in >> >> org.eclipse.gmf.runtime.diagram.ui.providers.internal.DefaultProvider >> do not follow java code guidelines_ >> __https://bugs.eclipse.org/bugs/show_bug.cgi?id=243888_ >> A patch has been joined : >> _https://bugs.eclipse.org/bugs/attachment.cgi?id=109789_ >> >> 244297 : ScaledGraphics should allow one to set background >> and foregroud patterns_ >> __https://bugs.eclipse.org/bugs/show_bug.cgi?id=244297_ >> A patch has been joined : >> _https://bugs.eclipse.org/bugs/attachment.cgi?id=110091_ >> >> 215179 : The way >> DiagramGenerator#findConnectionsToPaint(...) gets the view >> connections source will cause the image export to fail_ >> __https://bugs.eclipse.org/bugs/show_bug.cgi?id=215179_ >> A patch has been joined : >> _https://bugs.eclipse.org/bugs/attachment.cgi?id=91333_ >> >> 215179 is a trivial patch and it is a blocker point for us >> 244297 is very usefull for the SCA designer >> >> Thanks, >> >> Jonathan >> >> >> >> Richard Gronback a écrit : >> Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] >> Xpand OCL component proposal (code migration) >> Stephane, >> >> This is a topic that is as old as the Platform >> project, where similar issues have been dealt >> with for years. What I need to know are the >> exact bugs that are contentious. When I hear “10 >> bugs with patches have been ignored for over a >> year” and then I search and find 3 bugs that are >> relatively new, I shrug my shoulders and tend >> not to take the claim, and therefore the person >> making the claim, too seriously. And I’m sure >> it’s the same on the other side of the >> discussion, where a few bugs are submitted, >> seemingly ignored, and then combined with the >> claims of others, leading to an impression that >> a project is not taking contributions seriously >> (which may be true, but which may also be >> false). Human nature, I suppose. >> >> Anyway, there are many things to consider when >> accepting patches, as I’m sure you know. When it >> comes to the runtime component, I defer to >> Anthony and team to evaluate each patch or >> feature, as there are a LOT of clients using the >> runtime. Beyond the obvious need to maintain >> APIs, there are feature additions that may seem >> perfectly sensible to the contributor, but that >> don’t fit into the vision for the project from >> the perspective of those who built/maintain it. >> The outline view discussion comes to mind. What >> to do in cases like this? In my opinion, the >> “owner” of the code wins, as they have the >> long-term stake in the code base. >> >> On the tooling side, we are very interested in >> providing extensibility through the generator. >> We’re in the process now of incorporating some >> extensions done by UML2 Tools back into GMF. As >> I’ve said many times before, this is the >> approach that is preferred and will contribute >> to the long-term success of GMF. What I don’t >> see are too many that are interested in putting >> forth the extra effort to understand our code >> generation templates and contribute patches of >> this variety. The nature of MDSD, I suppose. The >> point here is that while it’s relatively easy to >> develop some new feature on top of the runtime >> or by modifying the generated code, what we >> really need are contributions that are at the >> level of template modification, or suggested >> improvements in the tooling models. We’ve >> received a few contributions of this nature, but >> they are certainly rare. >> >> So, there are bugs and there are features. Bugs >> that have quality patches and unit tests applied >> are certainly to be taken seriously and dealt >> with quickly. If they are not, then raise the >> issue in the newsgroup, mailing list, or even >> the PMC. If it’s a feature and there is a degree >> of subjectivity involved, well then it’s up to >> the component owner to decide, ultimately. If >> there are cases where it’s perhaps not that >> subjective, the issue is ignored, or there is >> some form of unsubstantiated refusal, then >> public escalation is appropriate. I’d encourage >> more public attention to these matters, actually. >> >> With respect to gaining Committer rights on the >> project, we stick to the Platform example of >> maintaining a high bar. We need to see several >> quality patches and contributions from an >> individual before considering nomination to >> Committer status. We see a lot of “drive by” >> patches and bugs, where it’s clear the person is >> implementing something using GMF, but will soon >> likely leave the space and isn’t therefore >> able/willing to invest the long-term commitment >> of contributing and maintaining code in the >> project. Again, this is not only a GMF issue, >> but one that is found in most Eclipse projects. >> Some projects lend themselves better to adding >> what I’d call “casual committers,” where >> part-time attention is sufficient. In my >> opinion, GMF is not a project that falls into >> this category. >> >> I hope this helps, and welcome further >> discussion on this topic. Mostly, it’s my >> impression that contributors often don’t >> consider the full responsibility that comes with >> contribution (features, not bugs). One way that >> the Platform tried to obtain more committers >> from outside (non-IBM) organizations was to >> offer a sort of intern program. This seemed >> sensible to me, and would certainly work for >> GMF. What it involved was a company to sponsor a >> full-time developer to work on the project under >> the guidance of one or more Committers. This >> contributor would be expected to commit to a >> long-term stint on the project and gain >> Committer rights during the initial phase. >> Certainly, the backing of a Strategic Developer >> would help the acceptance of such an approach. >> Would Obeo be interested in something like this? >> >> Best Regards, >> Rich >> >> >> >> >> On 8/27/08 2:53 AM, "Stéphane LACRAMPE" >> <_stephane.lacrampe@obeo.fr_> wrote: >> >> (adding the GMF mailing list in cc) >> Rich, >> >> Going back to the GMF patches, >> indeed Jonathan had the wrong >> numbers in mind, sorry for that. >> Beyond that, I get the feedback from >> people from my teams that it takes >> quite long to have patches accepted >> under GMF, not necessarily the ones >> from Obeo. I do not want to be >> aggressive at all on that and we may >> have false impression. >> >> But the thing is that we are working >> quite a lot with the GMF technology >> at Obeo for several customers as >> well as for Papyrus and Topcased, >> and because of this impression that >> it's difficult to get patches >> accepted, people tend to develop >> stuff to improve GMF without trying >> to raise a bug and submit a patch, >> which is definitely not a good habit. >> What's your view on that ? >> >> Anyway, because of all the work we >> are doing under GMF, I am trying to >> push people to get back on the right >> track and to provide more and more >> patches to GMF when it makes sense. >> We would then also be quite >> interested to get a GMF committer at >> some point, we could help to >> integrate patches as well as >> developing new features, do you >> think that it would be possible ? >> >> Regards >> Stephane LACRAMPE >> Obeo CEO >> Eclipse board member >> >> Jonathan MUSSET a écrit : >> Rich, >> >> One of the Obeo guys >> sent me an email to say >> that 4 bugs were >> submitted and not 10 ;-) >> For MTL and QVTO, You're >> right... It isn't >> available at the moment >> But, We need a small >> part of QVTO >> (Functions)... It isn't >> a blocker point. We can >> already define queries. >> We have made a lot of >> work since the beginning >> of the year... The >> documentations are >> coming soon. >> MTL is not ready for >> your needs. Xpand is >> ready. Let's us create >> our community. The first >> version will be >> available in September. >> I hope that your >> contribution will be >> integrated into Xpand, >> as an alternative of the >> navigation syntax... >> >> Cheers, >> >> Jonathan >> >> >> Richard Gronback a >> écrit : >> >> (narrowing >> list, as I'm >> sure the EMO >> and Bjorn >> have little >> interest in >> this...) >> >> Hi Jonathan, >> >> I'm really >> interested >> to >> understand >> what you see >> as easier in >> >> Xpand/Xtend/_expression_-language >> as compared >> to OCL + >> QVTO. I >> get the >> & nbsp; impression >> that few >> have looked >> at QVTO >> recently to >> see what it >> can offer >> beyond the >> OCL in this >> context. I >> don't >> believe MTL >> actually >> uses QVTO, >> does it? >> Either way, >> I feel the >> combination >> of Xpand >> with >> OCL/QVTO >> provides >> the best >> overall M2T >> solution. >> Hopefully, >> I'm not >> alone ;) >> Maybe we just >> need to let >> Alex & Artem >> finish their >> work and >> then provide >> a >> demonstration? >> >> Also, I'd >> appreciate >> some help >> identifying >> the >> outstanding >> GMF >> patches you >> mention. I'm >> assuming >> "we" is >> Obeo? In >> that case, I >> see 3 bugs: >> one with a >> patch >> submitted in >> January; one >> with a patch >> re: code >> style >> submitted 2 >> weeks ago; >> the third >> patch was >> submitted on >> the 15th of >> this >> month. Note >> that I only >> searched for >> bugs >> submitted >> that >> included >> 'obeo' in >> the ID. >> >> Thanks, >> Rich >> >> >> On 8/26/08 >> 12:26 PM, >> "Jonathan >> MUSSET" >> >> <_jonathan.musset@obeo.fr_> >> >> <_mailto:jonathan.musset@obeo.fr_> >> wrote: >> >> >> >> >> >> Rich, >> >> Sven, >> >> I >> >> agree >> >> with >> >> Sven >> >> in >> a >> >> sens >> >> that >> I >> >> think >> >> it >> >> is >> >> not >> a >> >> good >> >> idea >> >> to >> >> create >> a >> >> new >> >> component >> >> in >> >> M2T. >> >> >> At >> >> the >> >> moment, >> >> it >> >> is >> >> difficult >> >> to >> >> understand >> >> the >> >> difference >> >> between >> >> JET, >> >> Xpand, >> >> and >> >> MTL. >> >> But, >> >> we >> >> can >> >> argue >> : >> >> -JET >> : >> a >> >> Java/Xpath >> >> way, >> >> you >> >> don't >> >> need >> >> EMF, >> >> it >> >> is >> >> better >> >> if >> >> you >> >> don't >> >> have >> >> any >> >> model >> >> -XPand >> : >> >> easier >> >> to >> >> use >> >> because >> >> without >> >> OCL >> >> -MTL >> : >> >> the >> >> standard, >> a >> >> little
>> >> bit >> >> more >> >> difficult >> >> because >> >> of >> >> OCL >> >> I >> >> would >> >> not >> >> understand >> >> why >> >> there >> >> should >> >> be >> >> another >> >> Xpand >> >> OCL >> >> or >> >> another >> >> name >> >> when >> >> there >> >> is >> >> MTL >> >> component >> >> that >> >> is >> >> there >> >> to >> >> do >> >> the >> >> trick. >> >> The >> >> same >> >> was >> >> argued >> >> with >> >> us >> >> several >> >> times >> >> when >> >> we >> >> proposed >> >> to >> >> contribute >> >> the >> >> Acceleo >> >> code >> >> and >> >> its >> >> community >> >> to >> >> the >> >> M2T >> >> project >> : >> >> Acceleo >> >> was >> >> not >> >> enough >> >> "different" >> >> from >> >> what >> >> Xpand >> >> offers >> >> in >> >> M2T. >> >> FYI, >> >> we >> >> are >> >> working >> >> on >> >> MTL, >> >> and >> a >> >> version >> >> will >> >> be >> >> available >> >> in >> >> September >> >> with >> >> the >> >> target >> >> to >> >> provide >> a >> >> stable >> >> one >> >> for >> >> the >> >> next >> >> simultaneous >> >> release >> >> of >> >> Eclipse. >> >> >> On >> >> the >> >> contrary, >> I >> >> hope >> >> that >> >> you'll >> >> find >> a >> >> way >> >> to >> >> work >> >> with >> >> the >> >> XPand >> >> guys >> >> to >> >> have >> >> your >> >> contribution >> >> integrated >> >> into >> >> Xpand. >> >> >> Another >> >> subject >> >> is >> >> about >> >> the >> >> complexity >> >> of >> >> OCL. >> >> It >> >> is >> a >> >> real >> >> concern >> >> and >> >> this >> >> is >> >> one >> >> of >> >> the >> >> reasons >> >> why >> >> you >> >> find >> >> such >> a >> >> variety >> >> of >> >> modeling >> >> tools >> >> having >> >> their >> >> own >> >> navigation >> >> language >> >> (ATL, >> >> QVT, >> >> MTL, >> >> Xpand, >> >> Acceleo, >> >> JET...). >> I >> >> think >> >> we >> >> should >> >> discuss >> ; >> this >> >> with >> >> the >> >> OMG >> >> since >> >> some >> >> discussions >> >> have >> >> started >> >> between >> >> Eclipse >> >> and >> >> the >> >> OMG >> >> and >> >> we >> >> should >> >> carry >> >> on >> >> the >> >> work >> >> already >> >> made >> >> in >> >> MDT >> >> OCL >> >> to >> >> make >> >> OCL >> >> easier. >> >> It >> >> could >> >> be >> a >> >> good >> >> subject >> >> for >> >> the >> >> Eclipse >> >> summit >> >> as >> >> well. >> >> >> Regards, >> >> Jonathan >> >> Musset >> >> MTL >> >> leader >> >> >> PS >> : >> >> BTW, >> >> you >> >> argued >> >> about >> >> the >> >> fact >> >> that >> >> OAW >> >> did >> >> not >> >> considered >> >> your >> >> contributions, >> >> would >> >> it >> >> be >> >> possible >> >> for >> >> you >> >> to >> >> check >> >> at >> >> the >> >> different >> >> patches >> >> we >> >> submitted >> >> to >> >> the >> >> GMF >> >> team, >> >> there >> >> are >> >> about >> >> 10, >> >> some >> >> of >> >> them >> >> waiting >> >> for >> >> more >> >> than >> a >> >> year... >> >> >> >> Sven >> >> Efftinge >> a >> >> écrit >> : >> >> >> >> >> Rich, >> >> >> surely, >> >> I >> >> should >> >> have >> >> raised >> >> this >> >> discussion >> >> earlier. >> >> >> Naming >> >> the >> >> component >> >> differently >> >> is >> >> a >> >> good >> >> idea >> >> and >> >> should >> >> avoid >> >> confusion. >> >> >> thanks, >> >> Sven >> >> >> P.S.: >> >> As >> >> most >> >> of >> >> the >> >> discussion >> >> is >> >> not >> >> directly >> >> related >> >> to >> >> this >> >> component >> >> proposal >> >> but
>> >> still >> >> interesting, >> >> I'll >> >> respond >> >> in >> >> more >> >> detail >> >> in >> >> a >> &nbs p; >> separate >> >> mail, >> >> which >> >> I'll >> >> send >> >> to >> >> pmc >> >> mailing >> >> list >> >> only. >> >> >> >> On >> >> Aug >> >> 25, >> >> 2008, >> >> at >> >> 7:08 >> >> PM, >> >> Richard >> >> Gronback >> >> wrote: >> >> >> >> >> Sven, >> >> See inserts below... >> >> Thanks, >> Rich >> >> >> On 8/25/08 10:57 AM, "Sven Efftinge" <_sven@efftinge.de_> >> <_mailto:sven@efftinge.de_> wrote: >> >> >> >> >> >> Rich, >> >> sorry I originally wanted to write this mail before you propose the >> component. Hopefully you still welcome a discussion on this. >> >> >> >> >> It was my interpretation that we ended the call in agreement that a new >> component in M2T was the way to go. For those not interested in what >> is a >> Modeling project conversation to follow, feel free to ignore the rest of >> this reply. >> >> >> >> >> >> As said during the PMC call, I really understand your need to remove >> the "Xpand variant" from GMF and I also know that it has been promised >> by committers of the M2T/Xpand component to provide a working Xpand >> within the ganymede release. >> >> >> >> >> Right, and since there has not been a published build from Xpand since >> January, very little activity in CVS, the newsgroup, and in the mailing >> list, I'm inclined to request a Termination Review for this component. >> >> >> >> >> >> It's really a painful situation having >> this dialect within GMF, especially when people use the real Xpand and >> the modified version shipped with GMF at once. This is the case for >> all GMF users doing code generation with oAW (and AFAIK there are a >> lot). Unfortunately having an "official" Xpand dialect in addition >> would further worsen the situation. >> >> >> >> >> I'd characterize it as unfortunate, more so than painful. Let's not >> forget >> that the original variation was produced in order to leverage LPG, as >> Xpand >> was using a non-EPL friendly ANTLR version which took a very long >> time to >> resolve in the original. IOW, waiting a year for the ANTLR update >> and now a >> year for GMF changes to be incorporated into the "real" Xpand, with a >> follow >> up of "please wait for us to re-implement it all on a new (unproven) >> underlying foundation" does not seem too appealing. >> >> >> >> >> >> So, I see and understand your need for a solution, but I doubt that >> it's a good idea to come up with yet another template language. >> We already have three languages in M2T: >> >> - JET (the orginal solution from EMF) >> - MTL (the implementation of the OMG standard, which uses OCL and Op- >> QVT) >> - Xpand (a practice proven solution) >> >> >> >> >> This argument can be made for other Eclipse projects with overlap, and >> certainly within Modeling itself (e.g. M2M: ATL and QVT). >> Realistically, >> the 3 M2T solutions we have will never merge into one, and as long as >> all >> have vibrant communities, why does it matter if there are 3? This was a >> challenge we realized when creating Modeling, as it was a unification of >> many separate projects, each with teams/communities that were >> unlikely to >> give up their identity. >> >> >> >> >> >> Besides that you need a template language now, because you want to get >> rid of the "Xpand variant" (I fully understand that), I don't see how >> an "Xpand OCL" would add any value. I think there are already >> solutions for everybody: If you like standards and want to be conform >> go for MTL, if you like pragmatic solutions go for Xpand, if you like >> Xpath go and use JET. >> >> >> >> >> We think it adds value as it eliminates an entire _expression_ and >> transformation language (Xtend, which from your previous argument >> should not >> exist in the presence of M2M QVT and ATL). By using MDT OCL and M2M >> QVTO, >> we are promoting reuse from other Modeling projects, which seems >> better than >> continuing to develop and maintain Xtend and the _expression_ language >> currently used in Xpand. As I understand it, the only reason OCL wasn't >> used in the first place was because there was no MDT OCL at the time. >> >> The way I see it, we're providing a nice migration for Xpand and >> improving >> its capabilities. From the original, we now add OCL and QVTO support, >> thereby allowing users to know fewer languages, and not have to deal >> with >> the minor differences that currently exist. From here, I'd expect >> that a >> future Xpand based on Xtext could also use OCL/QVTO in its >> implementation, >> providing the next major version of the project. >> >> So, Xpand/Xtend -> Xpand/OCL/QVTO -> Xpand/OCL/QVTO based on Xtext >> >> Or, are you saying you reject the inclusions of standards in Xpand >> and see >> the two as mutually exclusive? I don't see the "if you like >> standards, use >> this..." argument as valid. Or if you like, we'll say "If you'd like >> some >> standards in your Xpand, use this one." >> >> >> >> >> >> In case you want to migrate to the real Xpand language you can do so >> by the end of this year. >> >> >> >> >> Based on the past and given the complete lack of visibility into how >> this >> work is progressing, how can we be sure that we will really be able >> to adopt >> the new Xpand by the end of this year? I don't have a "warm and fuzzy" >> about it, to be honest. >> >> >> >> >> >> As the current GMF generator is already implemented in Xpand it >> shouldn't be too hard to migrate and to have everything working and >> tested for the galileo release. >> >> >> >> >> Another argument would be, if we have a migration utility that can >> ease the >> conversion of existing Xpand templates ("original" and GMF), why not use >> this as a path toward making Xpand more "standard"? Have you queried >> your >> clients to see if OCL would be an acceptable alternative? I suspect >> as OCL >> is used so pervasively in modeling technologies, it would be a welcomed >> change. >> >> >> >> >> >> Note, that there is a huge user base (we've up to 70 messages a day in >> our forums) and all these users will be able to use, understand and >> enhance the generator shipped with GMF. >> >> >> >> >> By "our forums" which do you mean? The only ones we really should be >> considering in this discussion are Eclipse forums. Again, as an Eclipse >> project, we all need to openly and transparently develop and interact >> with >> the Eclipse community. If you mean oAW forums, that's an old >> discussion we >> thought had been concluded with the termination of the oAW component >> within >> GMT and the migration of several technologies, Xpand included, to other >> Modeling projects. The health of an Eclipse project is measured by its >> activity on Eclipse forums only, so you're only hurting your >> project/component by continuing to use external forums. >> >> >> >> >> >> Note that TMF/Xtext's (textual equivalent to GMF) generator is also >> implemented in Xpand, and we are working on combination and >> integration of GMF and Xtext editors. It will be helpful if there are >> not two many different technologies for the same purposes. >> >> >> >> >> And I'm sure the ATL/TCS folks would have their own opinion and >> similar set >> of technologies. >> >> >> >> >> >> All in all I'ld like to see GMF migrating to M2T/Xpand. We can of >> course talk about opening up Xpand so that it would be possible to use >> Operational-QVT functions like Xtend functions (that really would be a >> good thing!). >> >> >> >> >> Again, the past indicates that "opening up" is not something the >> Xpand team >> takes too seriously, or has not enough development bandwidth to properly >> support. On the other hand, we've been using Xpand for years in GMF, >> provided valuable input and the implementation to improve the >> original, but >> have been largely ignored. What would you do? >> >> >> >> >> >> But it's not possible for us to just change the _expression_ language to >> OCL, because this heavily breaks API contracts. >> (Don't you also have API contracts in GMF? AFAIK the current modified >> Xpand shipped with GMF uses the original _expression_ language. Doesn't >> the OCL migration mean that all the templates of the users will be >> broken?) >> >> >> >> >> As was already stated, we will provide a migration utility. The >> codebase >> itself is within internal packages, so there are no API breakage >> issues (we >> know better than to expose as API a technology that for all intents and >> purposes shouldn't be in GMF anyway). That said, we currently >> support UML2 >> Tools and our commercial development efforts with the GMF variant, so we >> clearly understand the implications of this move. In the long run, >> how can >> you argue it would be better to develop and maintain a "proprietary" >> Xtend >> and _expression_ language rather than leverage suitable and quite similar >> standard-based implementations available within Modeling? >> >> >> >> >> >> Hopefully you don't get me wrong. I definitely see your point but >> coming up with an "Xpand OCL" component IMHO will definitely hurt the >> acceptance of Xpand *and GMF*. And will make it more difficult to >> understand and combine the different solutions. >> Especially in EMP we should work on reuse and consolidation rather >> than on inventing new things when there are already solutions. That >> clearly means making compromises, but I'm pretty sure they are worth >> it. >> >> >> >> >> Your "reuse and consolidation" argument doesn't make any sense to me, >> actually. By leveraging OCL and QVTO, we're certainly moving toward >> this >> goal in GMF's Xpand and would like to make it more readily available >> to the >> rest of the community by moving to M2T. If you'd like, we can rename it >> entirely, so as to avoid further confusion. >> >> I'll respectfully disagree that using OCL within the context of Xpand >> will >> hurt GMF. >> >> >> >> >> >> regards, >> Sven >> >> On Aug 25, 2008, at 3:55 PM, Richard Gronback wrote: >> >> >> >> >> >> Hello, >> >> As discussed on the last PMC call [1], we'd like >> to finally get the >> Xpand >> variant out of GMF and into M2T where it >> belongs. Given the current >> migration of the current Xpand to an Xtext-based >> foundation, and >> given the >> desire to continue using Xtend and underlying >> _expression_ language by >> the >> current Xpand team, we'd like to create a new >> 'Xpand OCL' component >> in M2T. >> >> This version of Xpand will use OCL and QVTO for >> the query/_expression_ >> language, and include the enhancements made to >> Xpand for GMF's needs >> [2], >> but which were never fully implemented in the >> original Xpand. Also >> provided >> will be a migration utility that converts the >> use of Xtend to OCL/ >> QVTO. The >> initial committers for this component will be >> Artem Tikhomirov >> (lead) and >> Alexander Shatalin (both GMF committers already). >> >> Copying the GMF and M2T dev mailing lists to get >> approval for code >> migration. >> >> Copying the Modeling PMC to get PMC approval >> (obviously, my vote is >> +1). >> >> Copying the EMO to serve as indication that the >> obligatory community >> announcement needs to be made for this new >> component. Actually, as >> it's not >> really 'new' but just relocating, is this >> necessary? It can't hurt, I >> suppose. >> >> Copying the IP team for confirmation to get >> clarification on what >> moving >> code from one project to another will entail, >> from an IP perspective. >> Anything? A CQ for tracking purposes? Maybe we >> could use a cartoon >> for >> moving code between projects? ;) >> >> Copying Bjorn as the "master of process" to help >> identify any >> complications >> the newly approved development process changes >> may present in this >> move. I >> didn't see anything specifically on this under >> /dev_process, but >> suppose >> this topic could be the first under the "I am a >> PMC Member..." on [3]. >> >> Thanks, >> Rich >> >> [1] >> >> _http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2008-08-19_ >> [2] >> >> _https://bugs.eclipse.org/bugs/show_bug.cgi?id=202813_ >> [3] >> >> _http://www.eclipse.org/projects/dev_process/index.php_ >> >> >> _______________________________________________ >> m2t-dev mailing list >> _m2t-dev@eclipse.org_ >> >> _https://dev.eclipse.org/mailman/listinfo/m2t-dev_ >> >> >> >> >> _______________________________________________ >> modeling-pmc mailing list >> _modeling-pmc@eclipse.org_ >> _https://dev.eclipse.org/mailman/listinfo/modeling-pmc_ >> >> >> >> >> >> _______________________________________________ >> gmf-dev mailing list >> _gmf-dev@eclipse.org_ >> _https://dev.eclipse.org/mailman/listinfo/gmf-dev_ >> >> >> >> >> _______________________________________________ >> >> m2t-dev >> >> mailing >> >> list >> >> _m2t-dev@eclipse.org_ >> >> _https://dev.eclipse.org/mailman/listinfo/m2t-dev_ >> >> >> >> >> >> _______________________________________________ >> >> m2t-dev >> >> mailing >> >> list >> >> _m2t-dev@eclipse.org_ >> >> _https://dev.eclipse.org/mailman/listinfo/m2t-dev_ >> >> >> >> >> >> >> _______________________________________________ >> m2t-dev >> mailing list >> >> _m2t-dev@eclipse.org_ >> >> _https://dev.eclipse.org/mailman/listinfo/m2t-dev_ >> >> >> >> >> >> >> _______________________________________________ >> m2t-dev mailing list >> _m2t-dev@eclipse.org_ >> >> _https://dev.eclipse.org/mailman/listinfo/m2t-dev_ >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> modeling-pmc mailing list >> _modeling-pmc@eclipse.org_ >> >> _https://dev.eclipse.org/mailman/listinfo/modeling-pmc_ >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> modeling-pmc mailing list_ >> __modeling-pmc@eclipse.org__ >> >> __https://dev.eclipse.org/mailman/listinfo/modeling-pmc_ >> >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ >> modeling-pmc mailing list_ >> __modeling-pmc@eclipse.org__ >> >> __https://dev.eclipse.org/mailman/listinfo/modeling-pmc________________________________________________ >> >> gmf-dev mailing list >> gmf-dev@xxxxxxxxxxx >> https://dev.eclipse.org/mailman/listinfo/gmf-dev>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> gmf-dev mailing list >> gmf-dev@xxxxxxxxxxx >>https://dev.eclipse.org/mailman/listinfo/gmf-dev(See attached file: mariot_chauvin.vcf)_______________________________________________ gmf-dev mailing list gmf-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/gmf-dev

Attachment: mariot_chauvin.vcf
Description: Binary data

Follow-Ups:
- Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
  - From: Richard Gronback

References:
- Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
  - From: Mariot Chauvin

Prev by Date: Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
Next by Date: Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
Previous by thread: Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
Next by thread: Re: [gmf-dev] Re: [modeling-pmc] Re: [m2t-dev] Xpand OCL component proposal (code migration)
Index(es):
- Date
- Thread

Breadcrumbs