Hi Rich,
please find my comments inlined:
I don't have a problem with having components within Amalgam that
represent
specific workflows with corresponding download configurations.
For
example,
an oAW component that includes what you list below, or one that
covers GMF,
Xpand, and QVTO. However, the brand "oAW" seems to not be the
most
descriptive (it's quite vague).
Sure it's not descriptive.
I don't want to discuss it like that. I think it's clear what it is
about:
We've been developing under this brand for several years. At some
point we started to contribute all our technologies to Eclipse
Modeling. So now there's only the brand left as well as the
mentioned
integration code and some components wich of course would fit into
some of our projects (e.g. emft).
We put a lot of work into the brand and simply don't want to
throw it
away. Instead we want to contribute it to Eclipse Modeling as well.
It wouldn't be "our" (oAW guys) brand anymore but "ours" (Eclipse
Modeling Guys) ;-). And of course it won't just consist of the X-
Stuff
from oAW but instead would include GMF, EMF, most of the EMFT
components as well as UML2. So it's one possible "amalgamation"
named
oAW.
Of course, I can't think of anything more
descriptive than perhaps the "X Modeling" configuration (Xpand,
Xtend, Xtext
;). I know Ed is keen on seeing the oAW brand become an Eclipse
brand,
similar to what Tigerstripe did, afaiu. In that case, I'm fine
with
the
name within Amalgam.
I think Tigerstripe really is a product.
oAW is more like AspectJ which has also been an open-source project
before it came to Eclipse (if i remember correctly).
What I don't want are a bunch of contributions that live in
isolation and
are not consumable by an adopter, or easily separated. Amalgam is
not
delivering "products," but deliverables that can be consumed by an
adopter,
while also improving the experience of the end user community.
Of course, we don't want to see a bunch of contributions livinig in
isolation, too. The only code really would be the "amalgamation"-
code
already mentioned.
I don't know what you think what "product" exactly means to you,
but
if you don't want to provide a usable piece of software under
Eclipse
Modeling I'm a bit confused of what amalgamation is really about.
Understandably, I believe in supporting all 3 communities.
So, the approach I'd like to take with Amalgam is to first form
the
base,
allowing for extensions that form a set of preconfigured downloads
(oAW
being perhaps the first, as you guys are able/willing to
contribute).
Furthermore, inspired by the release train requirements list, if a
project
does not conform to the proper UI guidelines and make filtering by
way of
capabilities possible (for example), they won't be part of
Amalgam.
Again, we really want to provide a good eclipse-ish open-source
solution for MDD.
No extra oAW stuff, just a composition of proven Eclipse technology
and some glue code to improve the user's experience.
IMHO separate components in Amalgamation would be helpful, because
then we could have a lead, newsgroup, mailing-list and repository
for
each component. Of course you as the project lead should still keep
everything in sync, eclipse-ish and the way we all want it to be.
Sven
On 4/2/08 9:08 AM, "Sven Efftinge" <sven.efftinge@xxxxxxxxx>
wrote:
Hi Rich,
the code we're talking about is integration code like:
- an oAW perspective
- wizards covering several components at once
- cheat sheets and documentation covering the whole stack
Would it be possible to have such code in a CVS under
amalgamation?
Sven
As for the remaining glue code, I can't imagine there is much
here. I'd
like to see a base set of Modeling glue that can be used by
adopters, with
perhaps some specific code to accompany each distro. In the
case
of oAW,
how is it not just a general Modeling collection that favors
Xpand
over JET,
Xtend over ATL, Xtext over TCS, etc.? As discussed at
EclipseCon,
why not a
general solution that enables/disables capabilities to allow the
user to
select the tool collection they prefer? In this way, each
distro
may define
a set of defaults, and perhaps some minimal branding.
_______________________________________________
amalgam-dev mailing list
amalgam-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amalgam-dev
_______________________________________________
amalgam-dev mailing list
amalgam-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amalgam-dev
_______________________________________________
amalgam-dev mailing list
amalgam-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amalgam-dev
