Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [amalgam-dev] Re: oAW in Amalgam

Hi Sven,

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

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

Make sense?

- Rich


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



Back to the top