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
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
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,
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
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.