Re: [modeling-pmc] [mylyn-dev] modeling bridge project

[Miles Parker <miles.parker@xxxxxxxxxxx>]

Hi all,

I also think the third option is a great idea. cc'ing modeling PMC as well, because it occurs to me that there is actually a lot of potential for overlap in terms of project packaging issues and strategy, and having it a separate sub-project would enable clearer lines of communication across the top-level projects. Just as an off the cuff example, if the modeling project decides to push collaborative modeling as an explicit project/package then there would need to be release coordination within Modeling PMC as well as Mylyn. Since all of the graphics work is also in Modeling -- even the stuff that isn't "only" for modeling, that would cover alignment with both modeling technologies and general graphic approaches.

I'd vote no *against* any kind of split, mostly out of fear of the extra admin thrashing. But on the other hand, I do think we need some way of separating out what bridges are currently pretty well supported and what bridges we're less confident about. Right now, I'd put ecore tools in the first category and papyrus in the second, but that is a function of the relative maturity of EcoreTools more than anything else. But all of this will be a moving target, especially as we see lots of changes coming to GMF tooling, more work on Graphiti, all of the exciting text stuff, etc. So it seems that it would be helpful to have like two maturity buckets -- something more formal than "I wouldn't rely on that particular bridge, but nearly everything else works well" and less than having a formal incubator. I don't know if any other projects have found a good way to handle this? Here's one simple way to slice this though: EcoreTools is 1.0+ and Papyrus isn't yet, so perhaps we could simply have a policy that we'll support incubation projects at incubation quality and release projects at release quality?

WRT to less strict policies for conformance, I really like that idea. :) As most of the modeling stuff is pretty bleeding edge, it would be extremely helpful to be able to make use of more up to date dependencies where necessary. Still, I know that at least one person is working on modeling bridge implementations for 3.6 tooling, so it wouldn't be a bad idea to start out with the same requirements to begin with.

Steffen and I also discussed that there are a number of build dependency issues that it would be good to isolate the Mylyn Context mainstream from. As Mylyn and many of the Modeling technologies are already at +3, mixing modeling into Mylyn main build dependencies could create lots of unnecessary build week drama.

cheers,

Miles

On Sep 21, 2011, at 3:06 AM, Cédric Brun wrote:

> Hi Steffen,
> 
> I would vote for a new  Mylyn Context Modeling project if it's not too much a burden creating it :
> - as you said it would put less pressure than Mylyn Context regarding compatibility
> - other bridges are likely to appear, Graphiti and Xtext are coming directly into mind
> - the scope is clear compared to the Incubator.
> 
> Le 21/09/2011 11:41, Steffen Pingel a écrit :
>> The Modeling Bridge project that Miles Parker has been working on (bug
>> 352032) has made very good progress and as discussed on the call last
>> Thursday it's getting close to point where we would like to bring it
>> to Eclipse.org. The project currently has four bridges that integrate
>> with the following modeling technologies:
>> 
>>  * EMF
>>  * GMF
>>  * ECore Tools
>>  * Papyrus
>> 
>> We already had some discussions around the best place for the code in
>> Mylyn. These were the options we discussed:
>> 
>>  * Mylyn Incubator
>>  * Mylyn Context
>>  * Mylyn Context Modeling (a new project under Mylyn Context)
>> 
>> We could also consider a combination of these if we split the current
>> code across multiple Mylyn projects, e.g. put the EMF/GMF bridge into
>> Mylyn Context and the other components that are more experimental into
>> the Incubator with the option to mature them later.
>> 
>> Since there has already been quite a bit of interest in these new
>> components I am wondering if the community around the modeling
>> integration is already big enough to justify creating a new sub-sub
>> project under Mylyn Context? This would enable interested parties to
>> drive evolution of the project independently and more rapidly than
>> what is feasible directly under Mylyn Context. A separate project
>> would provide a better focus than the Mylyn Incubator, support proper
>> releases, participation in Juno and could have less strict policies
>> than Mylyn Context (e.g. no support for Eclipse 3.6).
>> 
>> I'd be interested in hearing other's opinions or alternative
>> suggestions for hosting the modeling bridge.
>> 
>> Thanks,
>> 
>> Steffen
>> 
> 
> _______________________________________________
> mylyn-dev mailing list
> mylyn-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-dev