Re: [mylyn-context-dev] Juno SR1 MFT contribution

[Miles Parker <miles.parker@xxxxxxxxxxx>]

I should just move on and accept that :D because it really doesn't matter much at all but there is something nagging at me that I want to be sure is clear…but we may have had this same conversation earlier this year.

I think we may have a different sense for what an integrator and consumer are.

When I hear "Integrator" I think of someone who has a significant tool base that they are integrating with a common tool. This is typical for say someone doing a Mylyn connector for a Task tracking system.

Modeling projects don't work that way. Almost everyone who downloads a modelling tool is doing so to actively work on code generation and other projects that deal with artifacts. If you look at the modeling cagtegory almost all of the projects there are SDKs. Yes, they have runtime tooling, but the purpose of that is to support code that is built against the runtime APIs. So it's the reverse situation, where it would be very uncommon for someone to want to just get say the MWE SDK from the site if they weren't already developing code for it.

My point is that the population of users is much larger. I'd hate for someone to want to develop a simple connector and not be able to easily locate it.

But I don't feel that strongly about it so unless I hear back I'll leave it out.

On 2012-09-21, at 3:38 PM, Steffen Pingel <steffen.pingel@xxxxxxxxxxx> wrote:

> I'm -1 on that. If it's listed and not clearly marked as an Integrator
> / SDK feature users may install it with the reasonable expectation
> that it does something that adds value.
> 
> Integrators should look at the documentation anyways and obtain the
> tools from the MFT update site where I believe all features are
> categorized (or should be).
> 
> Steffen
> 
> 
> On Fri, Sep 21, 2012 at 3:31 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:
>> 
>> No, UML2 should work stand-alone, unless I'm really mistaken.
>> 
>> On 2012-09-21, at 2:27 PM, Steffen Pingel <steffen.pingel@xxxxxxxxxxx> wrote:
>> 
>>> Okay, that sounds reasonable. I had assumed you needed something on
>>> top of the UML2 bridge to actually make use of it but if there are
>>> tools out there that get focus just by installing the bridge (do you
>>> have an example?) I'm fine with listing it in a category.
>> 
>> Okay, I wish I could say that was the case. :) When we have codegen for the boilerplate it will be, but for now you have to do some boiler-plate work:
>> 
>> http://wiki.eclipse.org/Mylyn/Modeling_Bridge#Recipe
>> 
>> Again, I think this is not an atypical usage for a common consumer and would suit more than just integrators, and we don't want people to have to hunt for it if we want to drive consumer (in the GMF developer sense) adoption.
>> 
>> I'll got ahead and put that in for now.
>> 
>>> 
>>> We have always pointed integrators at the source for Mylyn and
>>> provided SDKs only for convenience but didn't encourage their use.
>>> That said, I'm okay with adding the SDK to a category since we have
>>> been getting regular requests for them in the past.
>>> 
>>> Steffen
>>> 
>>> 
>>> On Fri, Sep 21, 2012 at 11:30 AM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:
>>>> 
>>>> UML2 is a connector that Carsten put together to support the (non-Papyrus) UML2 so that's consumer oriented.
>>>> 
>>>> re: SDK, I'd argue for inclusion. It's positioned to be more of an end-user oriented SDK, like the EMF and GEF SDK, etc.. I don't want to make it too difficult for people who want to implement their own connector extensions.
>>>> 
>>>> BTW, I've created a bug for Modeling asking that they consider including the Mylyn Modeling connectors there as well. Would help drive more adoption I think.
>>>> 
>>>> BTW2, I've been using this -- especially the EcoreTools integration which provides the hierarchical editor support in the project explorer -- in the real world now for Reviews, and finding it actually useful. :)
>>>> 
>>>> On 2012-09-21, at 11:24 AM, Steffen Pingel <steffen.pingel@xxxxxxxxxxx> wrote:
>>>> 
>>>>> That sounds good and is how we handled categorization in the past. I
>>>>> agree that we should only categorize features that user may want to
>>>>> install such as the Papyrus or Ecoretools integration. Not sure that
>>>>> also applies to UML2?
>>>>> 
>>>>> In regard to the SDK feature I would prefer if it wasn't categorized
>>>>> since it's target at integrators rather then end users.
>>>>> 
>>>>> Steffen
>>>>> 
>>>>> 
>>>>> On Fri, Sep 21, 2012 at 11:09 AM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:
>>>>>> 
>>>>>> An embarrassed note that while I got the addition of Papyrus and UML2 support into Juno SR1, I neglected to add them to the collaboration category. By the time that change was tested, the train had left the station. So they can be consumed from there, and users can install, but only after unchecking the "Group Items by Category" box. I'm updating the Wiki to reflect that.
>>>>>> 
>>>>>> On the same note, I've put in the fix for that and will do Kepler next. I'm thinking that we really only want the consumer (e.g. Ecoretools, UML2 and Papyrus) and SDK features listed there and not the ones that are useless by themselves (EMF and GMF). Make sense to everyone?
>>>>>> 
>>>>>> -Miles
>>>>>> 
>>>>>> 
>>>>>> ______________________________
>>>>>> Miles T. Parker
>>>>>> Senior Solutions Architect
>>>>>> Tasktop
>>>>>> http://tasktop.com
>>>>>> Committer, Eclipse Mylyn and Virgo
>>>>>> Project Lead, Model Focussing Tools and AMP
>>>>>> http://milesparker.blogspot.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> mylyn-context-dev mailing list
>>>>>> mylyn-context-dev@xxxxxxxxxxx
>>>>>> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Steffen Pingel
>>>>> Principal Software Engineer, Eclipse Mylyn
>>>>> Mylyn Tasks Lead
>>>>> http://tasktop.com
>>>>> _______________________________________________
>>>>> mylyn-context-dev mailing list
>>>>> mylyn-context-dev@xxxxxxxxxxx
>>>>> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
>>>> 
>>>> _______________________________________________
>>>> mylyn-context-dev mailing list
>>>> mylyn-context-dev@xxxxxxxxxxx
>>>> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
>>> 
>>> 
>>> 
>>> --
>>> Steffen Pingel
>>> Principal Software Engineer, Eclipse Mylyn
>>> Mylyn Tasks Lead
>>> http://tasktop.com
>>> _______________________________________________
>>> mylyn-context-dev mailing list
>>> mylyn-context-dev@xxxxxxxxxxx
>>> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
>> 
>> _______________________________________________
>> mylyn-context-dev mailing list
>> mylyn-context-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev
> 
> 
> 
> -- 
> Steffen Pingel
> Principal Software Engineer, Eclipse Mylyn
> Mylyn Tasks Lead
> http://tasktop.com
> _______________________________________________
> mylyn-context-dev mailing list
> mylyn-context-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/mylyn-context-dev