Rich,
Comments below.
Richard Gronback wrote:
Hi Peter,
See comments below...
In summary, given the existence of the DSL Toolkit download from
Amalgam and the history associated with the oAW “brand” at Eclipse, I’m
not inclined to see such a package created within the project.
Yes, it's kind of a case of once bitten twice shy. It's fully
understandable. So many of the promises of the past haven't been kept
and often the fallout of such problems tie up personal time that none
of us have to spare. I think the tone of your comment reflects
justifiable frustration.
Contributions to the DSL Toolkit are of
course welcome!
Thanks,
Rich
On 2/9/09 9:46 AM, "Peter Friese" <peter.friese@xxxxxxxxx> wrote:
Hi all,
I am writing this eMail on behalf of the oAW team. As you know, there
has been a lot of confusion lately around openArchitectureWare: will it
remain an Eclipse project, will it move out, or move back in?
[rcg] Yes, a very long intermittent thread with seemingly no end.
All good things must come to an end. :-P
We have been having lots of discussions recently and think it might be
the best idea for oAW to stay with Eclipse. As pretty much of the whole
code of oAW actually is contained in components that already are
Eclipse projects, it really doesn't make much sense to move away from
Eclipse. Essentially, oAW is a distro that is made up of Xpand, MWE,
Xtext and of course all the platform code we rely on such as EMF and
the Eclipse platform. In addition to all that, we only have some glue
code like the oAW perspective and the project wizards.
[rcg] I’m afraid it may have taken too long to come to this decision.
In the meantime, a DSL Toolkit package has been created in Amalgam
that has much the same makeup. In fact, I’ve already stated I’ll be
adding Xtext to this package. The DSL Toolkit has its own perspective,
project type/wizard, etc. So, I really don’t see the point in having
another package that is so closely aligned in purpose/content. I’ll
continue to reply where appropriate to the questions below...
What criteria will we use to determine which packages are appropriate
and which are not? I definitely agree that a proliferation of very
similar packages is problematic. But then, the rest of the modeling
project has similar such proliferation and we've not simply blocked
those things but rather allow them to co-exist. Of course in those
cases, we don't have a track record of non-delivery to overcome...
We have come to the conclusion to propose running oAW as an
Amalgamation package. Actually, oAW is being mentioned on the
Amalgamation wiki page (http://wiki.eclipse.org/ModelingAmalgam)
already :-)
[rcg] Yes, that was a very old reference. I actually removed it
yesterday, given my rethinking of the idea in the context of Amalgam
and its charter. Adding it nowadays would not serve the community
well; in fact, it would create more of the same problem we have already
have in Modeling with too much choice for everything.
I suppose, but as I said, how will we decide which are reasonable new
choices and which are unnacceptable? Do we know who the winners will
be ahead of time?
This would effectively mean we
- archive the oAW code in the SourceForge repository and stop
development there
- do all new development under the umbrella of Eclipse
- try to convince our users to use the Eclipse newsgroups for support
- redirect http://www.openarchitectureware.org
<http://www.openarchitectureware.org/>
to http://www.eclipse.org/modeling(amalagamation/oaw
[rcg] I suggest you keep this website operational if you intend to
continue using the oAW name, logo, etc.
I think the desire is to see things evolve in a way similar to Jetty,
which is currently not an Eclipse brand but presumably will be. Fully
assimilating oAW into Eclipse would see to be advantageous to avoid the
proliferation of communities, which in my opinion is worse than the
proliferation of packages. If the price for the merger is an extra
package in Amalgamation, even a somewhat duplicative one, I'd still
consider that a reasonable trade-off. Of course I fully understand
that intelligent people will differ on what's a reasonable trade-off,
but as an Amalgamation committer, I hope my opinions will be considered
as well. To me it's important to recognize that oAW is an important
visible brand in some geographies, not a commercial one but an open
source one, and that Eclipse modeling stands to benefit from
assimilating this brand as its own.
We compiled a list of questions that we couldn't answer by looking at
the Amalgamation project site and wiki and love to hear your answers.
Also, if you've got any questions, we'd be happy to answer them.
So without further ado, here is the list of questions:
1) will we be able to provide an oAW feature that users can install
into their existing Eclipse installation
I would hope so...
2) what will be the version identifier of
what we now call "oAW 5.0" ?
I'm not fond of such large version numbers given that Eclipse version
guidelines are quite specific about why they signify. Perhaps a new
naming scheme might be appropriate. E.g., oAW Galileo.
3) will we be able to have a landing page for
oAW Amalgamation?
The packages are quite poorly described right now. It would seem
better to have a page dedicated to the details of each one...
4) will be be allowed to place off-site links
on our landing-page?
Certainly there are a great many examples at Eclipse where this is
done. BIRT Exchange and Wascana are two that come to mind. I think it
needs to be very clear though when you're pointing off into the
community though...
5) will we be allowed to provide p2 update
site URLs, so that users can complement their Eclipse installation with
our external add-ons after installing oAW Amalgamation?
I'm not sure the policy about things like this. It's more of a legal
question and we'd have to consult with Janet.
6) will we be allowed redirect http://www.openarchitectureware.org
<http://www.openarchitectureware.org/>
to http://www.eclipse.org/modeling/amalgam/oaw
?
[rcg] I don’t think anyone can prevent an external URL from referencing
an Eclipse website.
This would be a good demonstration that oAW as a separate organization
has been assimilated.
7) will we be able to participate in the Galileo release train?
[rcg] Amalgam is not currently on the train.
It probably doesn't matter since you can release simultaneously with it
anyway.
8) how many committers may we suggest? (It
seems reasonable to have 2 or 3 committers to get the work done)
9) how will those committers be added to the Amalgamation project? Just
ask Rich?
[rcg] Adding committers to Amalgam or any Eclipse project requires the
same meritocratic process.
Definitely it's important to see concretely exactly what's going to be
added before making a decision. As a committer I can help review these
changes to reduce the impact on Rich's time.
10) will we be allowed to provide glue code like wizards, perspectives,
online help, PDF manuals to complement oAW Amalgamation?
[rcg] As already stated, these exist already, while contributions are
welcome to improve them.
That's the idea: to contribute to what's there and to do things similar
to, as extensions of, or some refactoring of common parts of DSL
Toolkit. I too will want to see exactly what's being done and why. It
seems there's much that can and should be reused.
11) what's the relation of oAW Amalgamation with the Amalmagation
Modeling Package? Will we re-use it? Will it re-use us?
Cheers,
Peter
_______________________________________________
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
|
