|[amalgam-dev] Eclipse Modeling Package Mega Diet|
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 ....
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 ?
* Concrete Syntax Development*
XText, GMF Tooling, EEF
* Reverse Engineering*
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.
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.