Skip to main content

[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


On Jan 19, 2010, at 11:10 AM, Cédric Brun wrote:
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.

That's what I meant. I like it.

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 :)

I agree. 

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.

I'm not only concerned about the size, but also about UI contributions.
I think if we have this nice and user friendly way to select what you need, we could simply use it for everything.
This would also avoid lengthy discussions about what feature to include and what not. ;-)

Sven


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

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


Back to the top