| Re: [stp-newsgroup] SCA v0.95 EMF model contribution? [message #581150] |
Mon, 14 August 2006 20:44 |
 Daniel Berg
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
This is a multipart message in MIME format.
--=_alternative 0071ACD5852571CA_=
Content-Type: text/plain; charset="US-ASCII"
We do share a common model that is generated differently. The shared
model is in the form of standard XSDs. For Tuscany they generate one
model instance and for the tools we generate an EMF model instance. So
the level of sharing for the models stops at the formal contract.
In my time of building tools I have seen sharing between the runtime. At
first we (tools guys) created the models that would be used by
the tools and runtime. This was not so easy since the tools couldn't add
dependencies which they wanted because they were not
available in the runtime and the runtime complained because of the extra
baggage of the model to support interactive development.
I've also worked on projects that took the models from the runtime and
used them in the tools. These models were better within the runtime but
fell short in the tools and a large number of hacks were put in place to
allow overrides in the tools environment.
In the end it is best to share formal contracts and not actual binaries.
But this is only by 2 cents.
Regards,
Dan
Oisin Hurley <ohurley@iona.com>
Sent by: stp-newsgroup-bounces@eclipse.org
08/14/2006 08:59 AM
Please respond to
"Gateway between eclipse.stp and stp-newsgroup"
<stp-newsgroup@eclipse.org>
To
"Gateway between eclipse.stp and stp-newsgroup"
<stp-newsgroup@eclipse.org>
cc
Subject
Re: [stp-newsgroup] SCA v0.95 EMF model contribution?
> Yes there are plans to update the current stp.core.* plug-ins to be
> compliant with the latest specification level. We have been
> putting this off since the spec is still churning and no-one in STP
> was clamoring for the latest changes.
Keeping an implementation in line with a moving specification is always
a challenge as it can be easier to change words rather than change
code :)
This is an issue that the folk that are working on the Tuscany
project [0]
are also facing in their work on an SCA-supporting runtime. During
ApacheCon
EU earlier this year, I had a chat with Jim Marino and Jeremy Boynes
about
how STP and Tuscany could share information, technology, expertise or
whatever to allow both of us to move faster in our reactions to the
spec.
We kicked around some ideas, but nothing presented itself as being an
obvious contender - one of the reasons being that we're working from an
EMF model purposed to provision of a UI, whereas they are working from
a POJO model (which was once EMF), purposed to the provision of a
runtime.
I think however that as two open source projects with licenses that are
considered 'friendly', we should invest a little more time in seeing how
would could approach this challenge together. For example, is it
feasible
to construct a model that we could both share, based on EMF, but
generate
code differently?
Anyone got any opinions? :)
cheers
--oh
[0] http://incubator.apache.org/tuscany
_______________________________________________
stp-newsgroup mailing list
stp-newsgroup@eclipse.org
https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
--=_alternative 0071ACD5852571CA_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">We do share a common model that is generated
differently. The shared model is in the form of standard XSDs. For
Tuscany they generate one</font>
<br><font size=2 face="sans-serif">model instance and for the tools we
generate an EMF model instance. So the level of sharing for the models
stops at the formal contract.</font>
<br><font size=2 face="sans-serif">In my time of building tools I have
seen sharing between the runtime. At first we (tools guys) created
the models that would be used by </font>
<br><font size=2 face="sans-serif">the tools and runtime. This was
not so easy since the tools couldn't add dependencies which they wanted
because they were not</font>
<br><font size=2 face="sans-serif">available in the runtime and the runtime
complained because of the extra baggage of the model to support interactive
development.<br>
I've also worked on projects that took the models from the runtime and
used them in the tools. These models were better within the runtime
but</font>
<br><font size=2 face="sans-serif">fell short in the tools and a large
number of hacks were put in place to allow overrides in the tools environment.</font>
<br>
<br><font size=2 face="sans-serif">In the end it is best to share formal
contracts and not actual binaries. But this is only by 2 cents.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Dan<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Oisin Hurley <ohurley@iona.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: stp-newsgroup-bounces@eclipse.org</font>
<p><font size=1 face="sans-serif">08/14/2006 08:59 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
"Gateway between eclipse.stp and stp-newsgroup" <stp-newsgroup@eclipse.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"Gateway between eclipse.stp and
stp-newsgroup" <stp-newsgroup@eclipse.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [stp-newsgroup] SCA v0.95 EMF model
contribution?</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>> Yes there are plans to update the current stp.core.*
plug-ins to be <br>
> compliant with the latest specification level. We have been
<br>
> putting this off since the spec is still churning and no-one in STP
<br>
> was clamoring for the latest changes.<br>
<br>
Keeping an implementation in line with a moving specification is always<br>
a challenge as it can be easier to change words rather than change <br>
code :)<br>
<br>
This is an issue that the folk that are working on the Tuscany <br>
project [0]<br>
are also facing in their work on an SCA-supporting runtime. During <br>
ApacheCon<br>
EU earlier this year, I had a chat with Jim Marino and Jeremy Boynes <br>
about<br>
how STP and Tuscany could share information, technology, expertise or<br>
whatever to allow both of us to move faster in our reactions to the <br>
spec.<br>
<br>
We kicked around some ideas, but nothing presented itself as being an<br>
obvious contender - one of the reasons being that we're working from an<br>
EMF model purposed to provision of a UI, whereas they are working from<br>
a POJO model (which was once EMF), purposed to the provision of a <br>
runtime.<br>
<br>
I think however that as two open source projects with licenses that are<br>
considered 'friendly', we should invest a little more time in seeing how<br>
would could approach this challenge together. For example, is it <br>
feasible<br>
to construct a model that we could both share, based on EMF, but <br>
generate<br>
code differently?<br>
<br>
Anyone got any opinions? :)<br>
<br>
cheers<br>
--oh<br>
<br>
<br>
[0] http://incubator.apache.org/tuscany<br>
_______________________________________________<br>
stp-newsgroup mailing list<br>
stp-newsgroup@eclipse.org<br>
https://dev.eclipse.org/mailman/listinfo/stp-newsgroup<br>
</font></tt>
<br>
--=_alternative 0071ACD5852571CA_=--
|
|
|
Powered by
FUDForum. Page generated in 0.02730 seconds
] 
Search
Help
Register
Login
Home
