[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [amalgam-dev] Re: [modeling-pmc] Eclipse Modeling Package Mega Diet

All,

I like Cédric's idea. Having a minimal footprint modeling distro with a nice update mechanism will help to further adoption of modeling technologies.

I also think it's a good idea to have a voting for the Amalgamation lead.

Cheers,
Peter

On 19.01.2010, at 20:18, Ed Merks wrote:

Cédric,

This sounds like a very good approach.  I think the components you've identified are the right core set.

I'd like to suggest that the Amalgmation committers vote to make you the lead given you're by far the most active.  The EMO has been waiting for a leader to be designated so let's find closure as soon as possible.

Cheers,
Ed


Cédric Brun wrote:
Hi Ed,

I don't think thats an issue about component being in incubation or not, sometimes we're making mistakes, whether we're incubating or not.

My point is we can tackle the consistency and the style conformity starting from the core components and then notifying other components about what could be changed and it's part of my commitment to the amalgam project to do so just like Rich started to do so at some point.

And yes, most components providing concrete syntax definition tooling should be split in a small runtime versus tooling and editors so that we can include some concrete syntax without including the generic tooling.  That's the case for GMF, I don't know if that's the case for XText too.

AFAIK GMF runtime do not depend in any way on QVTo  and that's why I was thinking about including EcoreTools , if that means including too much of the other components then we can move into the direction Sven pointed at : keeping EMF and installing all the other components through the discovery ui.

Concerning the 280598 bug, we can only avoid those by testing the package and that's why I would like to focus on just "one package" and not severals like the Amalgam project used to provide.

I see a few reasons explaining why nobody cares to test :
 - project leads are not "pinged" to have a try on the package RC's
 - as a project lead you don' t easily get feedback about your component integration
 - we don't "market" the package to the community at large
 - the commiters are not using the package themselves



Cédric


Le 19/01/2010 12:46, Ed Willink a écrit :
Hi Cédric

This is a really sensible, but difficult, initiative.

As soon as you go beyond EMF, you are in danger of hitting unavoidable incestuous problems with modelling tools using modelling tools.

Ecore Tools uses GMF uses QVTo (almost uses QVTd) uses OCL uses LPG2, UML2.

At some point, after Helios, OCL UI will use IMP, EMFq, EMFt, EMFv too. For Helios these will just be in OCL Examples.

Therefore you must either have just EMF, or perhaps a much reduced Runtime-SDK to which the full SDK is added on demand.

As a purely hypothetical example, suppose EMF's code generation templates were rewritten in QVTo, even EMF might need a QVTo runtime, so perhaps we need all core projects to provide a minimal runtime (not SDK) comprising just the functionality necessary for fully developed tools to exploit.

It would be good to divert the JDT no-source-for-class pop-up to automatically load and install associated source.

-----

It would also be good to achieve some style conformity with a style guide.

e.g.

All Natures are added in Configure->...

All Examples Files/Projects are in Modeling-><Project>->...

Use of new top-level menu entries is strongly discouraged.

-----

I regret to say that the reason I don't use the Galileo Modelling package is that no one else used it, and consequently no one fixed EMF-Index's accident at RC4 (Bug 280598) that clutters the Console Log with warning messages. Such accidents are perhaps quite probable with Incubation projects and underlines the benefit of optional loading of non-core projects.

    Regards

        Ed Willink

On 19/01/2010 10:10, Cédric Brun wrote:
Hi Sven,

that's not exactly an update-site manager replacement as it is featureless compared to it, it's just a list of components categorized in a sexy ui with nice icons and descriptions, you can install them and P2 is called behind the scene.
It looks like that :
http://tasktop.com/blog/wp-content/uploads/2009/06/connector-discovery-small.png

It's definitely more friendly for end users :)

As for the EMF only package, here I'm mostly proposing EMF + EcoreTools because I think people are expecting to get *modelers*  from a *modeling* package. Let's see what size it would be then and if it's too big we can consider moving more components to the discovery ui.

Cédric

Le 19/01/2010 10:54, Sven Efftinge a écrit :
Hi Cédric,

thanks for the initiative. Sounds good :-)

Is this discovery thing meant to be a more user friendly replacement for the update site manager?

I'ld like to see the core package as slim as possible. While most people might need EMF, I'ld suggest to leave everything else 
out so it can be installed through the update sites.

Cheers,
Sven

On Jan 19, 2010, at 10:36 AM, Cédric Brun wrote:

Hi Modelistos ;)

Here are a few though about the current status of the modeling package and what is the direction I'm would like to take, let's start with the current status :

The Eclipse Ganymede release of the package had fairly good downloads though not even near of what I would expect considering the great technologies we're building ;) , the Galileo one
was a clear failure in providing a usable package and the downloads are quite poor. Number of downloads are one metric among other but let's start with ourselves, would you use the modeling package ?
I don't for a number of reasons:
 1. It's huge, more than 360Mb is just insane.
 2. It's cluttered, every Modeling project is there and provides his own UI elements, there is no consistency between them
 3. Installing anything else in it is close to impossible.
 4. I'm better off starting with an Eclipse SDK or even runtime and installing what I need, I get a faster, smaller installation - basically there is little if no added value using this package.

That said, the packages are - should be at least - a showcase of our technologies as many people tend to use this form of distribution as a "starter".

Once I said that you probably already see which path I want to take : Let's apply Occam's razor on the package and focus on good integration on core components.
What might be not so obvious is that I think having several packages would be a big mistake, having a unique and good starting point everybody can market would help the adoption,  and we can't possibly test several packages, we already have a hard time with one and all the supported platforms.

That leads to the second point :  easing the discovery and installation of all the good technologies we're building in the numerous Eclipse Modeling project (incubating or not !) within the package.
I had a pretty good feedback at ESE for such a feature and implemented it based on the discovery tooling Mylyn is providing.  The user would get more information about the technologies we're providing, their level of maturity, license, and install them.

I would expect features targeting the widest audience and with the lowest possible UI impact as part of the core package  - a bit like the "modelers" amalgam distribution:
 EMF Core - we can't do much without it anyway ;)
 EMF Compare Core- it's  tiny and perfectly silent
 Mint - here again it's a perfectly silent component.
 Ecore tools (and its runtime deps,  GMF runtime, Transactions, Validation...)
 OCL, UML2, XSD


Then using the discovery UI for :

 * Model Transformations*
     ATL, QVTO, Jet, Xpand, Acceleo ....

 * Tools*
     Papyrus (which I would easily see in the core distribution as soon as it graduated )
     MWE (I'm not even sure we need it in the UI as it's going to be installed as a required dependency for many components)

 * Runtimes* (can't figure a better name - any hint here ?)
    CDO :  If there is a minimal feature only providing the base framework I think it might make sense to include it in the bundle and keep all the backends and specific editors as an add-on, what is your opinion Eike ?
   Teneo

 * Concrete Syntax Development*
    XText, GMF Tooling, EEF

* Reverse Engineering*
   Modisco


What are the implications  ? first, many components already in the modeling package would be moved to the discovery UI.
Second, I'll need logo icons, summary and screenshots from the projects to feed the discovery UI.

As it would be affecting the Modeling Project as a whole I would be happy to have your opinion, I think doing so would help in getting a distro with a sane size and nicely integrated core components, then we can start from that to work on the discovered components integration. I would also love to be able, from such a UI, to install "learning materials" with samples DSL's, generators and such..

I'm adding this point to the PMC meeting so that we can discuss about it.

Cheers,

ps : If you want to get an idea the discovery UI is exactly like Mylyn's connectors one http://tasktop.com/blog/eclipse/mylyn-connector-discovery , the code is in the amalgam repository.

Cédric


_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc

_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/modeling-pmc

_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/modeling-pmc
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.730 / Virus Database: 270.14.149/2631 - Release Date: 01/18/10 16:56:00

_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/modeling-pmc


_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
amalgam-dev mailing list
amalgam-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amalgam-dev