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

there is no such code yet.
It is planned to have Xtext and Xpand reworked and polished under Eclipse late summer.
The oAW distribution of EMP is also planned for september / october.
Today we just want to make sure that we can finally contribute the oAW brand to Eclipse and are allowed to have oAW releases (beeing one particular view on EMP) in future.

atb,
Sven

On Apr 3, 2008, at 12:59 , Richard Gronback wrote:
Hi Sven,

I guess the next steps are to do whatever is required to resolve the
branding issue, and to provide a patch through Bugzilla for the UI elements
that would be included in the oAW download.

This week I'm looking into build and packaging options, and would also like
to install all of the modeling components and take a close look at the
current state of all our UI elements.

Best,
Rich


On 4/3/08 3:48 AM, "Sven Efftinge" <sven.efftinge@xxxxxxxxx> wrote:

Hi Rich,
Great!
oAW has always been highly extensible. It is for example shipped as
part of MID's Innovator.
Other product vendors are also working on integrating it. (Ultimately,
we'ld love to see every development product on this planet having oAW
integrated :-))

So, do we agree on making oAW an eclipse brand and creating a
corresponding component (or subproject) under Amalgamation?
What could be the next step to push this forward?

atb,
Sven

On Apr 2, 2008, at 17:57 , Richard Gronback wrote:
Hi Sven,

It seems we are not disagreeing.  I understand the history of the
oAW brand
issue, and if it becomes an Eclipse brand, we're all set.
Otherwise, we
return to an old discussion about marketing value, commercial vs.
non-commercial, vs. academic, etc. that I'd like to avoid
altogether.  Most
contributions at Eclipse have shed their previous branding/identity,
by the
way.

Components is the way to go, or whatever we call them based on the
ongoing
discussion of project, subproject, component, etc.  What I'm saying
mostly
is that they will depend on a common core, from the start.

Regarding product vs. project, if what is used by the end user
community is
not built upon an extensible framework that is consumable by the
adopter
community, you're not truly living up to the responsibility of being
an
Eclipse project. We're not here to simply give away tooling, but to
support
the three defined communities.

Best,
Rich


On 4/2/08 11:31 AM, "Sven Efftinge" <sven.efftinge@xxxxxxxxx> wrote:

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

_______________________________________________
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



Back to the top