Home » Archived » Tigerstripe » Doubts about the project
| Doubts about the project [message #2153] |
Sat, 24 November 2007 08:45  |
 Markus Voelter
Messages: 33
Registered: July 2009 |
Member |
|
|
Hi,
to get the discussion started: I am very sceptical about
this proposal for the following reasons:
* at its core, the proposed techniques seem to be
inferior to the stuff that's already available at
EMP
* in other areas it seems like a reinvention of the
wheels we already have (UML editor, Code Gen Engine).
We need fewer, better integrated modules, not more!
* I don't think there's any point of having a modeling
thing outside of EMP. What kind of message would that
send?? If there's a valuable contribution in it, make
it part of modeling. If not, don't put it on Eclipse.
That said, I would *love* to see a workbench-y kind of
thing, that takes all (or most) of the EMP components and
builds a nice workbench around it. That would be an integration
project on top of what we have.
Markus
--
Markus Völter
voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
|
| Re: Doubts about the project [message #2181 is a reply to message #2153] |
Sat, 24 November 2007 11:47  |
Eclipse User |
|
|
|
Originally posted by: sven.efftinge.de
Hi,
I totally agree with what Markus said.
If you think there is an aspect of your tool, which fits a niche in EMP,
then it would be very interested to hear about it.
regards,
Sven
Markus Voelter wrote:
> Hi,
>
> to get the discussion started: I am very sceptical about
> this proposal for the following reasons:
>
> * at its core, the proposed techniques seem to be
> inferior to the stuff that's already available at
> EMP
> * in other areas it seems like a reinvention of the
> wheels we already have (UML editor, Code Gen Engine).
> We need fewer, better integrated modules, not more!
> * I don't think there's any point of having a modeling
> thing outside of EMP. What kind of message would that
> send?? If there's a valuable contribution in it, make
> it part of modeling. If not, don't put it on Eclipse.
>
> That said, I would *love* to see a workbench-y kind of
> thing, that takes all (or most) of the EMP components and
> builds a nice workbench around it. That would be an integration
> project on top of what we have.
>
> Markus
>
> --Markus Völter
>
> voelter - ingenieurbüro für softwaretechnologie
> Grabenstrasse 4, 73033 Goeppingen, Germany
> Tel. +49 (0) 171 / 86 01 869
> Email: voelter@acm.org
>
> Web: http://www.voelter.de
> Blog: http://www.voelter.de/blog
> Podcast: http://www.se-radio.net
>
> PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
|
| Re: Doubts about the project [message #2210 is a reply to message #2153] |
Sat, 24 November 2007 13:37 |
| Eclipse User |
|
|
|
Originally posted by: peter.friese.gentleware.com
Hi,
I'd like to second what Markus said.
Since quite a number of companies are using model driven technologies,
especially from the EMP project, I suggest that we should rather try to
gather a community that starts building a best-of-breed modeling workbench
instead of having just another proprietary modeling workbench (i.e.
TigerStripe) under the Eclipse umbrella.
Peter
|
|
|
| Re: Doubts about the project [message #2238 is a reply to message #2153] |
Tue, 27 November 2007 01:30 |
Ed Warnicke
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Markus Voelter wrote:
> Hi,
> to get the discussion started: I am very sceptical about
> this proposal for the following reasons:
> * at its core, the proposed techniques seem to be
> inferior to the stuff that's already available at
> EMP
> * in other areas it seems like a reinvention of the
> wheels we already have (UML editor, Code Gen Engine).
> We need fewer, better integrated modules, not more!
Please note in the proposal, in the scope section, the paragraph which
reads:
"In addition, we intend to migrate existing parts of the software to the
latest frameworks supported by the Modeling top-level project. In
particular, we intend to use more of the EMF and UML2 frameworks where
applicable to complement the current technology in use, and allow easier
model sharing between users."
We intend to converge over time. We'd like to do it in the open. That
will mean over time
incorporating more of the Eclipse Modeling components, as well as feeding
contributions
back to those components.
> * I don't think there's any point of having a modeling
> thing outside of EMP. What kind of message would that
> send?? If there's a valuable contribution in it, make
> it part of modeling. If not, don't put it on Eclipse.
Technology provides us with a good place to incubate. If at a later time
moving to the Eclipse Modeling Project makes sense to the folks involved,
we can do that.
> That said, I would *love* to see a workbench-y kind of
> thing, that takes all (or most) of the EMP components and
> builds a nice workbench around it. That would be an integration
> project on top of what we have.
Thats kind of where we would like to go. Tigerstripe is, in many ways, a
workbench-y thing built on what Modeling had to offer in the past. Gaps
that existed then were filled, and some of filling those gaps brought in
features and functionality that are not yet be present in the current
Modeling components. Current Eclipse Modeling doesn't provide a drop in
replacement for what Tigerstripe allows it's current users to do, and
Tigerstripe certainly doesn't provide all of the functionality of the
Eclipse Modeling Projects with which it overlaps. Working through those
issues, while continuing to support Tigerstripe existing user base, is
part of what we hope to accomplish.
|
|
|
| Re: Doubts about the project [message #2265 is a reply to message #2238] |
Tue, 27 November 2007 09:18 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
wrote:
Hi all,
thanks for your feedback. I can see where you are coming from and
being a hardcore eclipse user myself, I fully agree with the need to
strenghthen the existing components rather than re-inventing the wheel
and duplicating them.
I like to think of Tigerstripe as an end-user environment or workbench
for Modeling+Scoping+Generation. We started building the application a
few years back when some of these components either didn't exist or
weren't fully stable yet. As a result, we did re-invent the wheel (as
stated above) as we were working through end-user requirements and
various issues.
So yes, some of the components in Tigerstripe are currently inferior
to the corresponding components from the modeling project. Yet, the
whole is a end-to-end workbench where end-users, i.e. modelers, can
get their job done.
Now, as stated in the proposal, we DO INTEND to migrate the non
standards components to the latest stable components from the modeling
project. In fact I am hoping that overtime we can become a model of
use for the Modeling components in complete solution. As we migrate, I
believe we can feed some of our experience to the appropriate modeling
components.
Hopefully, we can use Tigerstripe as the red-thread to assemble all
modeling components in an end-user workbench. Use the current version
as a starting point, and replace internal components one by one to
make it best of breed in the Open, outside of the modeling project for
now until we "ready" to be a proper subproject of the modeling
project.
By talking to our existing user community (see interested party in the
proposal), I believe the workbench as a whole already has a lot of
value. Migrating internal components to best of breed in the open
should only add more value to the Eclipse community as we feed their
requirements back to the community.
Eric
>Markus Voelter wrote:
>
>> Hi,
>
>> to get the discussion started: I am very sceptical about
>> this proposal for the following reasons:
>
>> * at its core, the proposed techniques seem to be
>> inferior to the stuff that's already available at
>> EMP
>> * in other areas it seems like a reinvention of the
>> wheels we already have (UML editor, Code Gen Engine).
>> We need fewer, better integrated modules, not more!
>Please note in the proposal, in the scope section, the paragraph which
>reads:
>
>"In addition, we intend to migrate existing parts of the software to the
>latest frameworks supported by the Modeling top-level project. In
>particular, we intend to use more of the EMF and UML2 frameworks where
>applicable to complement the current technology in use, and allow easier
>model sharing between users."
>
>We intend to converge over time. We'd like to do it in the open. That
>will mean over time
>incorporating more of the Eclipse Modeling components, as well as feeding
>contributions
>back to those components.
>
>> * I don't think there's any point of having a modeling
>> thing outside of EMP. What kind of message would that
>> send?? If there's a valuable contribution in it, make
>> it part of modeling. If not, don't put it on Eclipse.
>
>Technology provides us with a good place to incubate. If at a later time
>moving to the Eclipse Modeling Project makes sense to the folks involved,
>we can do that.
>
>> That said, I would *love* to see a workbench-y kind of
>> thing, that takes all (or most) of the EMP components and
>> builds a nice workbench around it. That would be an integration
>> project on top of what we have.
>
>Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>workbench-y thing built on what Modeling had to offer in the past. Gaps
>that existed then were filled, and some of filling those gaps brought in
>features and functionality that are not yet be present in the current
>Modeling components. Current Eclipse Modeling doesn't provide a drop in
>replacement for what Tigerstripe allows it's current users to do, and
>Tigerstripe certainly doesn't provide all of the functionality of the
>Eclipse Modeling Projects with which it overlaps. Working through those
>issues, while continuing to support Tigerstripe existing user base, is
>part of what we hope to accomplish.
>
|
|
|
| Re: Doubts about the project [message #2295 is a reply to message #2265] |
Tue, 27 November 2007 11:52 |
Bernd Kolb
Messages: 57
Registered: July 2009 |
Member |
|
|
Eric,
I can see your point but first of all, I do not see why you could not do
that in modeling. I cannot find a single sentence wrt. EMP toplevel
project in the Proposal.
The next thing when having a look to your proposal which came up to my
mind was that you seem to use technologies which have proven to be not
the best choice when doing MDSD (Just velocity as an example).
EMP already has the problem that it is not clear for the user which tool
to use in which cases. If you now start another project under another
toplevel project users will get confused even more! I agree that having
an integration project would really add a benefit EMP. But it has to be
an integration project from the beginning.
You are mentioning that you'd like to migrate to "standard components".
What do you consider to be a standard component?
So far I am not convinced :-)
Best regards
Bernd
Eric Dillon schrieb:
> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
> wrote:
>
> Hi all,
>
> thanks for your feedback. I can see where you are coming from and
> being a hardcore eclipse user myself, I fully agree with the need to
> strenghthen the existing components rather than re-inventing the wheel
> and duplicating them.
>
> I like to think of Tigerstripe as an end-user environment or workbench
> for Modeling+Scoping+Generation. We started building the application a
> few years back when some of these components either didn't exist or
> weren't fully stable yet. As a result, we did re-invent the wheel (as
> stated above) as we were working through end-user requirements and
> various issues.
>
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project. Yet, the
> whole is a end-to-end workbench where end-users, i.e. modelers, can
> get their job done.
>
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
>
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
>
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value. Migrating internal components to best of breed in the open
> should only add more value to the Eclipse community as we feed their
> requirements back to the community.
>
> Eric
>
>> Markus Voelter wrote:
>>
>>> Hi,
>>> to get the discussion started: I am very sceptical about
>>> this proposal for the following reasons:
>>> * at its core, the proposed techniques seem to be
>>> inferior to the stuff that's already available at
>>> EMP
>>> * in other areas it seems like a reinvention of the
>>> wheels we already have (UML editor, Code Gen Engine).
>>> We need fewer, better integrated modules, not more!
>> Please note in the proposal, in the scope section, the paragraph which
>> reads:
>>
>> "In addition, we intend to migrate existing parts of the software to the
>> latest frameworks supported by the Modeling top-level project. In
>> particular, we intend to use more of the EMF and UML2 frameworks where
>> applicable to complement the current technology in use, and allow easier
>> model sharing between users."
>>
>> We intend to converge over time. We'd like to do it in the open. That
>> will mean over time
>> incorporating more of the Eclipse Modeling components, as well as feeding
>> contributions
>> back to those components.
>>
>>> * I don't think there's any point of having a modeling
>>> thing outside of EMP. What kind of message would that
>>> send?? If there's a valuable contribution in it, make
>>> it part of modeling. If not, don't put it on Eclipse.
>> Technology provides us with a good place to incubate. If at a later time
>> moving to the Eclipse Modeling Project makes sense to the folks involved,
>> we can do that.
>>
>>> That said, I would *love* to see a workbench-y kind of
>>> thing, that takes all (or most) of the EMP components and
>>> builds a nice workbench around it. That would be an integration
>>> project on top of what we have.
>> Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>> workbench-y thing built on what Modeling had to offer in the past. Gaps
>> that existed then were filled, and some of filling those gaps brought in
>> features and functionality that are not yet be present in the current
>> Modeling components. Current Eclipse Modeling doesn't provide a drop in
>> replacement for what Tigerstripe allows it's current users to do, and
>> Tigerstripe certainly doesn't provide all of the functionality of the
>> Eclipse Modeling Projects with which it overlaps. Working through those
>> issues, while continuing to support Tigerstripe existing user base, is
>> part of what we hope to accomplish.
>>
|
|
|
| Re: Doubts about the project [message #2325 is a reply to message #2295] |
Tue, 27 November 2007 12:19 |
Markus Voelter
Messages: 33
Registered: July 2009 |
Member |
|
|
Bernd pretty clearly stated the same I
would have replied. So I don't repeat that.
I am also not convinced.
Why don't you rewrite the proposal to reflect
more explicitly what you say here?
Markus
> Eric,
>
> I can see your point but first of all, I do not see why you could not do
> that in modeling. I cannot find a single sentence wrt. EMP toplevel
> project in the Proposal.
>
> The next thing when having a look to your proposal which came up to my
> mind was that you seem to use technologies which have proven to be not
> the best choice when doing MDSD (Just velocity as an example).
>
> EMP already has the problem that it is not clear for the user which tool
> to use in which cases. If you now start another project under another
> toplevel project users will get confused even more! I agree that having
> an integration project would really add a benefit EMP. But it has to be
> an integration project from the beginning.
>
> You are mentioning that you'd like to migrate to "standard components".
> What do you consider to be a standard component?
>
>
> So far I am not convinced :-)
>
> Best regards
>
> Bernd
>
>
> Eric Dillon schrieb:
>> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
>> wrote:
>> Hi all,
>> thanks for your feedback. I can see where you are coming from and
>> being a hardcore eclipse user myself, I fully agree with the need to
>> strenghthen the existing components rather than re-inventing the wheel
>> and duplicating them.
>> I like to think of Tigerstripe as an end-user environment or workbench
>> for Modeling+Scoping+Generation. We started building the application a
>> few years back when some of these components either didn't exist or
>> weren't fully stable yet. As a result, we did re-invent the wheel (as
>> stated above) as we were working through end-user requirements and
>> various issues.
>> So yes, some of the components in Tigerstripe are currently inferior
>> to the corresponding components from the modeling project. Yet, the
>> whole is a end-to-end workbench where end-users, i.e. modelers, can
>> get their job done.
>> Now, as stated in the proposal, we DO INTEND to migrate the non
>> standards components to the latest stable components from the modeling
>> project. In fact I am hoping that overtime we can become a model of
>> use for the Modeling components in complete solution. As we migrate, I
>> believe we can feed some of our experience to the appropriate modeling
>> components.
>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>> modeling components in an end-user workbench. Use the current version
>> as a starting point, and replace internal components one by one to
>> make it best of breed in the Open, outside of the modeling project for
>> now until we "ready" to be a proper subproject of the modeling
>> project.
>> By talking to our existing user community (see interested party in the
>> proposal), I believe the workbench as a whole already has a lot of
>> value. Migrating internal components to best of breed in the open
>> should only add more value to the Eclipse community as we feed their
>> requirements back to the community.
>> Eric
>>
>>> Markus Voelter wrote:
>>>
>>>> Hi,
>>>> to get the discussion started: I am very sceptical about
>>>> this proposal for the following reasons:
>>>> * at its core, the proposed techniques seem to be
>>>> inferior to the stuff that's already available at
>>>> EMP
>>>> * in other areas it seems like a reinvention of the
>>>> wheels we already have (UML editor, Code Gen Engine).
>>>> We need fewer, better integrated modules, not more!
>>> Please note in the proposal, in the scope section, the paragraph which
>>> reads:
>>>
>>> "In addition, we intend to migrate existing parts of the software to
>>> the latest frameworks supported by the Modeling top-level project. In
>>> particular, we intend to use more of the EMF and UML2 frameworks where
>>> applicable to complement the current technology in use, and allow
>>> easier model sharing between users."
>>>
>>> We intend to converge over time. We'd like to do it in the open.
>>> That will mean over time
>>> incorporating more of the Eclipse Modeling components, as well as
>>> feeding contributions
>>> back to those components.
>>>
>>>> * I don't think there's any point of having a modeling
>>>> thing outside of EMP. What kind of message would that
>>>> send?? If there's a valuable contribution in it, make
>>>> it part of modeling. If not, don't put it on Eclipse.
>>> Technology provides us with a good place to incubate. If at a later
>>> time moving to the Eclipse Modeling Project makes sense to the folks
>>> involved, we can do that.
>>>
>>>> That said, I would *love* to see a workbench-y kind of
>>>> thing, that takes all (or most) of the EMP components and
>>>> builds a nice workbench around it. That would be an integration
>>>> project on top of what we have.
>>> Thats kind of where we would like to go. Tigerstripe is, in many
>>> ways, a workbench-y thing built on what Modeling had to offer in the
>>> past. Gaps that existed then were filled, and some of filling those
>>> gaps brought in features and functionality that are not yet be present
>>> in the current Modeling components. Current Eclipse Modeling doesn't
>>> provide a drop in replacement for what Tigerstripe allows it's current
>>> users to do, and Tigerstripe certainly doesn't provide all of the
>>> functionality of the Eclipse Modeling Projects with which it
>>> overlaps. Working through those issues, while continuing to support
>>> Tigerstripe existing user base, is part of what we hope to accomplish.
>>>
>
--
Markus Völter
voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
|
| Re: Doubts about the project [message #2355 is a reply to message #2265] |
Tue, 27 November 2007 12:38 |
| Eclipse User |
|
|
|
Originally posted by: sven.efftinge.de
Hi Eric,
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project.
Which are not?
I'm really interested to here about new ideas and technologies regarding
MDSD, but I couldn't see anything like that stated in the proposal.
If there are such things, you may want to come up with a more specific
proposal for that?
>
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
Yes, there is a need for such a project within EMP. But who should
decide what components should become part of a best-of-breed modeling
environment?
To be honest, I doubt that you should decide that, because Tigerstripe
seems to be some years behind of what IMHO is state of the art in this
field (sorry, don't take this personally).
IMHO such a project should be driven by the community, at least the
decisions on what is best-of-breed and what's not.
>
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
It's a bit strange, that you think incubating in EMT and then moving
over to EMP is a good idea. There are a lot of projects in an incubator
phase at EMP (Have a look at EMFT and GMT).
Maybe the real problem is that the focus doesn't fit with EMP?
>
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value.
I'm sure there are a lot of happy users.
That's really not the problem.
There are also a lot of other MDSD-workbenches with many users out
there. And none of them (oAW included ;-)) should become the
"Best-Of-Breed Eclipse Modeling Project".
kind regards,
Sven
|
|
|
| Re: Doubts about the project [message #2385 is a reply to message #2355] |
Tue, 27 November 2007 14:31 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Ok. It seems to me that we can't just discard users that quickly :-).
The focus of the modeling project is definitely frameworks. I think we may
even all agree that there are a lot of frameworks, and that it is sometimes
difficult to sort your way through them. However, the consumers of the
modeling project - its users - are mainly application developers, able to
assemble the frameworks together into a bigger whole - thus creating value
for end-users that are not interested or able to do so.
As you may have noticed the current user community of Tigerstripe is based
in the Telecom space. These guys are interested in modeling the latest
networking technology, network gear, etc... and in generating specs,
management interfaces, documentation, compliance test kits, and more. Most
of them - if not all of them - have no interest in stitching frameworks
together before they can get started on doing their job. In other words, the
consumers of Tigerstripe - its users - are VERY different from those of the
modeling project.
Now, we should also be careful when talking about an integration project for
EMP. What would be its intent? Show how to assemble frameworks? or provide
end-users with complete environment?
I think we need to address all user communities. It seems Tigerstripe
addresses a different user community than the modeling project. Our intent
to migrate to EMP components (that's what I called standard components, as
opposed to proprietary one :-)) should also serve the users of the Modeling
project.
Eric
"Sven Efftinge" <sven@efftinge.de> wrote in message
news:fih32c$n57$1@build.eclipse.org...
> Hi Eric,
>
>> So yes, some of the components in Tigerstripe are currently inferior
>> to the corresponding components from the modeling project.
>
> Which are not?
> I'm really interested to here about new ideas and technologies regarding
> MDSD, but I couldn't see anything like that stated in the proposal.
> If there are such things, you may want to come up with a more specific
> proposal for that?
>
>>
>> Now, as stated in the proposal, we DO INTEND to migrate the non
>> standards components to the latest stable components from the modeling
>> project. In fact I am hoping that overtime we can become a model of
>> use for the Modeling components in complete solution. As we migrate, I
>> believe we can feed some of our experience to the appropriate modeling
>> components.
>
> Yes, there is a need for such a project within EMP. But who should decide
> what components should become part of a best-of-breed modeling
> environment?
> To be honest, I doubt that you should decide that, because Tigerstripe
> seems to be some years behind of what IMHO is state of the art in this
> field (sorry, don't take this personally).
> IMHO such a project should be driven by the community, at least the
> decisions on what is best-of-breed and what's not.
>
>>
>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>> modeling components in an end-user workbench. Use the current version
>> as a starting point, and replace internal components one by one to
>> make it best of breed in the Open, outside of the modeling project for
>> now until we "ready" to be a proper subproject of the modeling
>> project.
>
> It's a bit strange, that you think incubating in EMT and then moving over
> to EMP is a good idea. There are a lot of projects in an incubator phase
> at EMP (Have a look at EMFT and GMT).
> Maybe the real problem is that the focus doesn't fit with EMP?
>
>>
>> By talking to our existing user community (see interested party in the
>> proposal), I believe the workbench as a whole already has a lot of
>> value.
>
> I'm sure there are a lot of happy users.
> That's really not the problem.
> There are also a lot of other MDSD-workbenches with many users out there.
> And none of them (oAW included ;-)) should become the "Best-Of-Breed
> Eclipse Modeling Project".
>
> kind regards,
> Sven
|
|
|
| Re: Doubts about the project [message #2446 is a reply to message #2385] |
Tue, 27 November 2007 17:17 |
| Eclipse User |
|
|
|
Originally posted by: Kenn.Hussey.embarcadero.com
Eric,
While the mature subprojects/components in Modeling happen to be
infrastructure-related, I disagree that the (only) focus of the Modeling
project is frameworks. Take the MDT subproject, for example - one of its
goals is to provide exemplary tools for building industry standard models.
One of the (other) questions that needs to be answered clearly for new
proposals is what the intended scope will be. The way the proposal is
currently written, it suggests that the scope is MDD in general. Here,
however, you have suggested that the intended consumers and user community
of Tigerstripe are fundamentally different from those of Modeling, i.e. they
are in the Telecom space; if that is the case, perhaps this should be made
more explicit in the proposal, and then this whole issue of overlap with the
Modeling project would be less of a concern...
Ultimately the proposal needs to make clear how the project will benefit the
Eclipse community and what falls inside (and outside) of the scope for the
project.
Kenn
"Eric Dillon" <erdillon@cisco.com> wrote in message
news:fih9os$k3o$1@build.eclipse.org...
> Ok. It seems to me that we can't just discard users that quickly :-).
>
> The focus of the modeling project is definitely frameworks. I think we may
> even all agree that there are a lot of frameworks, and that it is
> sometimes difficult to sort your way through them. However, the consumers
> of the modeling project - its users - are mainly application developers,
> able to assemble the frameworks together into a bigger whole - thus
> creating value for end-users that are not interested or able to do so.
>
> As you may have noticed the current user community of Tigerstripe is based
> in the Telecom space. These guys are interested in modeling the latest
> networking technology, network gear, etc... and in generating specs,
> management interfaces, documentation, compliance test kits, and more. Most
> of them - if not all of them - have no interest in stitching frameworks
> together before they can get started on doing their job. In other words,
> the consumers of Tigerstripe - its users - are VERY different from those
> of the modeling project.
>
> Now, we should also be careful when talking about an integration project
> for EMP. What would be its intent? Show how to assemble frameworks? or
> provide end-users with complete environment?
>
> I think we need to address all user communities. It seems Tigerstripe
> addresses a different user community than the modeling project. Our intent
> to migrate to EMP components (that's what I called standard components, as
> opposed to proprietary one :-)) should also serve the users of the
> Modeling project.
>
> Eric
>
>
> "Sven Efftinge" <sven@efftinge.de> wrote in message
> news:fih32c$n57$1@build.eclipse.org...
>> Hi Eric,
>>
>>> So yes, some of the components in Tigerstripe are currently inferior
>>> to the corresponding components from the modeling project.
>>
>> Which are not?
>> I'm really interested to here about new ideas and technologies regarding
>> MDSD, but I couldn't see anything like that stated in the proposal.
>> If there are such things, you may want to come up with a more specific
>> proposal for that?
>>
>>>
>>> Now, as stated in the proposal, we DO INTEND to migrate the non
>>> standards components to the latest stable components from the modeling
>>> project. In fact I am hoping that overtime we can become a model of
>>> use for the Modeling components in complete solution. As we migrate, I
>>> believe we can feed some of our experience to the appropriate modeling
>>> components.
>>
>> Yes, there is a need for such a project within EMP. But who should decide
>> what components should become part of a best-of-breed modeling
>> environment?
>> To be honest, I doubt that you should decide that, because Tigerstripe
>> seems to be some years behind of what IMHO is state of the art in this
>> field (sorry, don't take this personally).
>> IMHO such a project should be driven by the community, at least the
>> decisions on what is best-of-breed and what's not.
>>
>>>
>>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>>> modeling components in an end-user workbench. Use the current version
>>> as a starting point, and replace internal components one by one to
>>> make it best of breed in the Open, outside of the modeling project for
>>> now until we "ready" to be a proper subproject of the modeling
>>> project.
>>
>> It's a bit strange, that you think incubating in EMT and then moving over
>> to EMP is a good idea. There are a lot of projects in an incubator phase
>> at EMP (Have a look at EMFT and GMT).
>> Maybe the real problem is that the focus doesn't fit with EMP?
>>
>>>
>>> By talking to our existing user community (see interested party in the
>>> proposal), I believe the workbench as a whole already has a lot of
>>> value.
>>
>> I'm sure there are a lot of happy users.
>> That's really not the problem.
>> There are also a lot of other MDSD-workbenches with many users out there.
>> And none of them (oAW included ;-)) should become the "Best-Of-Breed
>> Eclipse Modeling Project".
>>
>> kind regards,
>> Sven
>
>
|
|
|
| Re: Doubts about the project [message #2505 is a reply to message #2238] |
Tue, 27 November 2007 20:29 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Ed,
Comments below.
Ed Warnicke wrote:
> Markus Voelter wrote:
>
>> Hi,
>
>> to get the discussion started: I am very sceptical about
>> this proposal for the following reasons:
>
>> * at its core, the proposed techniques seem to be
>> inferior to the stuff that's already available at
>> EMP
>> * in other areas it seems like a reinvention of the
>> wheels we already have (UML editor, Code Gen Engine).
>> We need fewer, better integrated modules, not more!
> Please note in the proposal, in the scope section, the paragraph which
> reads:
>
> "In addition, we intend to migrate existing parts of the software to
> the latest frameworks supported by the Modeling top-level project. In
> particular, we intend to use more of the EMF and UML2 frameworks where
> applicable to complement the current technology in use, and allow
> easier model sharing between users."
I'm trying to reconcile that intent with concept like 'facets' and
'binary' models mentioned by Steve in the next note chain. It almost
sounds like the model is both a super set and a subset. I think many
folks would be far more comfortable with reuse of existing components as
the starting point rather than an eventual end goal. Given the
development realities with which we are all faced, it's clear that good
intentions don't on their own produce the actual results. The three
folks working actively on the UML2 Tools could benefit from a growing
contributor base.
>
> We intend to converge over time. We'd like to do it in the open.
> That will mean over time
> incorporating more of the Eclipse Modeling components, as well as
> feeding contributions
> back to those components.
I get the sense that you will be migrating your user base at least twice
with this approach. I.e., won't the APIs against which folks are
generating artifacts change at least package names by virtue of moving
to Eclipse and then drastically a second time as a result of moving from
your current form to the UML2 APIs. This would also require migration
of the serialized artifacts use an interchangeable serialization format.
It also seems to me that whatever reason you had for not using UML2 in
the first place two years ago won't suddenly go away today. Could you
explain why you chose not to use UML2 but now expect to take a different
path at some point in the future?
>
>> * I don't think there's any point of having a modeling
>> thing outside of EMP. What kind of message would that
>> send?? If there's a valuable contribution in it, make
>> it part of modeling. If not, don't put it on Eclipse.
>
> Technology provides us with a good place to incubate. If at a later
> time moving to the Eclipse Modeling Project makes sense to the folks
> involved, we can do that.
I should point out that the modeling PMC's lead (Rich and I) didn't give
you folks a lot of choice. We weren't willing to accept the project in
its present form because of the duplication and overlap about which
other folks have expressed their concerns.
>
>> That said, I would *love* to see a workbench-y kind of
>> thing, that takes all (or most) of the EMP components and
>> builds a nice workbench around it. That would be an integration
>> project on top of what we have.
>
> Thats kind of where we would like to go. Tigerstripe is, in many
> ways, a workbench-y thing built on what Modeling had to offer in the
> past. Gaps that existed then were filled, and some of filling those
> gaps brought in features and functionality that are not yet be present
> in the current Modeling components. Current Eclipse Modeling doesn't
> provide a drop in replacement for what Tigerstripe allows it's current
> users to do, and Tigerstripe certainly doesn't provide all of the
> functionality of the Eclipse Modeling Projects with which it
> overlaps. Working through those issues, while continuing to support
> Tigerstripe existing user base, is part of what we hope to accomplish.
>
UML2 wasn't really a gap though and Ecore already existed as well.
Filling in the gaps via what's currently a divergent code base doesn't
solve any problems for the established modeling community at Eclipse.
It would seem better to support the existing user base via the existing
code base and start on a new path towards a single replacement based on
integration with the established infrastructure. Importers and
exporters could be used to migrate the users to the new base once it's
stable. This would certainly be what I'd prefer to see because two
modeling solutions at Eclipse just seems plain confusing, especially
when the modeling project is badly in need of a more unifying overview.
I'm sure the community would welcome an effort that clearly takes
immediate steps towards a common goal.
|
|
|
| Re: Doubts about the project [message #2535 is a reply to message #2265] |
Tue, 27 November 2007 20:41 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eric,
Comments below.
Eric Dillon wrote:
> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
> wrote:
>
> Hi all,
>
> thanks for your feedback. I can see where you are coming from and
> being a hardcore eclipse user myself, I fully agree with the need to
> strenghthen the existing components rather than re-inventing the wheel
> and duplicating them.
>
I really enjoyed the demos you have and would love to work more closely
with you.
> I like to think of Tigerstripe as an end-user environment or workbench
> for Modeling+Scoping+Generation. We started building the application a
> few years back when some of these components either didn't exist or
> weren't fully stable yet. As a result, we did re-invent the wheel (as
> stated above) as we were working through end-user requirements and
> various issues.
>
We of course like to think of the modeling project in this way as well
and would have welcomed your direct involvement years ago and will do so
now.
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project. Yet, the
> whole is a end-to-end workbench where end-users, i.e. modelers, can
> get their job done.
>
I could argue that EMF's tools could stand a significant amount of
polish, but as a whole has allowed folks to do amazing things despite
the warts. It's better if others make that point though. :-P
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
>
This is a key point that needs to be understood well. As I asked Ed,
what were the reasons for not using UML2 nor Ecore that will change in
the future? Both were available and there must be a good reason for not
having chosen them and likely that reason hasn't gone away.
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
>
I suppose I'd rather see that effort be the starting point rather than
good long term intentions. As I said to Ed, development reality often
throws good intentions by the wayside.
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value. Migrating internal components to best of breed in the open
> should only add more value to the Eclipse community as we feed their
> requirements back to the community.
>
I know from talking to you folks it's not your intent to insult the
established community at Eclipse. You're a great bunch of guys. It's
just that you need to keep in mind that your scope as you've outlined it
is almost identical to that of the modeling project, so there are
significant sensitivities here. I guess I'm hoping to convince you
folks to reconsider the current path since I think a path where we work
immediately towards integration will be a more successful one for
everyone involved. Just look at the numbers of committers involved in
the modeling project relative to the small tigerstripe base. It's hard
to compare the size of the communities, but I suspect that will be even
more slanted toward the established base at Eclipse. It seems you're
much more likely to achieve broad appeal by leveraging what we've been
working at for many years already...
> Eric
>
>
>> Markus Voelter wrote:
>>
>>
>>> Hi,
>>>
>>> to get the discussion started: I am very sceptical about
>>> this proposal for the following reasons:
>>>
>>> * at its core, the proposed techniques seem to be
>>> inferior to the stuff that's already available at
>>> EMP
>>> * in other areas it seems like a reinvention of the
>>> wheels we already have (UML editor, Code Gen Engine).
>>> We need fewer, better integrated modules, not more!
>>>
>> Please note in the proposal, in the scope section, the paragraph which
>> reads:
>>
>> "In addition, we intend to migrate existing parts of the software to the
>> latest frameworks supported by the Modeling top-level project. In
>> particular, we intend to use more of the EMF and UML2 frameworks where
>> applicable to complement the current technology in use, and allow easier
>> model sharing between users."
>>
>> We intend to converge over time. We'd like to do it in the open. That
>> will mean over time
>> incorporating more of the Eclipse Modeling components, as well as feeding
>> contributions
>> back to those components.
>>
>>
>>> * I don't think there's any point of having a modeling
>>> thing outside of EMP. What kind of message would that
>>> send?? If there's a valuable contribution in it, make
>>> it part of modeling. If not, don't put it on Eclipse.
>>>
>> Technology provides us with a good place to incubate. If at a later time
>> moving to the Eclipse Modeling Project makes sense to the folks involved,
>> we can do that.
>>
>>
>>> That said, I would *love* to see a workbench-y kind of
>>> thing, that takes all (or most) of the EMP components and
>>> builds a nice workbench around it. That would be an integration
>>> project on top of what we have.
>>>
>> Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>> workbench-y thing built on what Modeling had to offer in the past. Gaps
>> that existed then were filled, and some of filling those gaps brought in
>> features and functionality that are not yet be present in the current
>> Modeling components. Current Eclipse Modeling doesn't provide a drop in
>> replacement for what Tigerstripe allows it's current users to do, and
>> Tigerstripe certainly doesn't provide all of the functionality of the
>> Eclipse Modeling Projects with which it overlaps. Working through those
>> issues, while continuing to support Tigerstripe existing user base, is
>> part of what we hope to accomplish.
>>
>>
|
|
|
| Re: Doubts about the project [message #2567 is a reply to message #2385] |
Tue, 27 November 2007 20:49 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000907050702060801050001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eric,
Comments below.
Eric Dillon wrote:
> Ok. It seems to me that we can't just discard users that quickly :-).
>
> The focus of the modeling project is definitely frameworks. I think we may
> even all agree that there are a lot of frameworks, and that it is sometimes
> difficult to sort your way through them. However, the consumers of the
> modeling project - its users - are mainly application developers, able to
> assemble the frameworks together into a bigger whole - thus creating value
> for end-users that are not interested or able to do so.
>
I'm always a bit wary of how to carve up reality into different
compartments. Not that it's relevant here, but the whole tools verses
runtimes split often strikes me as totally artificial.
> As you may have noticed the current user community of Tigerstripe is based
> in the Telecom space. These guys are interested in modeling the latest
> networking technology, network gear, etc... and in generating specs,
> management interfaces, documentation, compliance test kits, and more. Most
> of them - if not all of them - have no interest in stitching frameworks
> together before they can get started on doing their job. In other words, the
> consumers of Tigerstripe - its users - are VERY different from those of the
> modeling project.
>
I'm not exactly sure what you mean by stitching frameworks together and
I'm not sure I understand at all the difference between the Tigerstripe
users base verses the modeling project's user base (as if we have only
one). It seems to me that the proposal presented a broad MDD vision
that's effectively identical to that of the modeling project but here
you suggest that the vision is narrower or the users addressed by it is
more restricted. I'm not sure I understand whether this is a general
MDD vision or an industry vertical version of it.
> Now, we should also be careful when talking about an integration project for
> EMP. What would be its intent? Show how to assemble frameworks? or provide
> end-users with complete environment?
>
It should do all of these things. And many of the end users are likely
building their own frameworks. Many Eclipse projects are using the EMP
infrastructure in order to build their own infrastructure...
> I think we need to address all user communities. It seems Tigerstripe
> addresses a different user community than the modeling project. Our intent
> to migrate to EMP components (that's what I called standard components, as
> opposed to proprietary one :-)) should also serve the users of the Modeling
> project.
>
I'd like to understand this difference a lot better. The proposal as it
is written isn't entirely clear that the user communities don't
coincide. I think folks like Kenn and others are trying to understand
the distinctions being drawn here is well...
> Eric
>
>
> "Sven Efftinge" <sven@efftinge.de> wrote in message
> news:fih32c$n57$1@build.eclipse.org...
>
>> Hi Eric,
>>
>>
>>> So yes, some of the components in Tigerstripe are currently inferior
>>> to the corresponding components from the modeling project.
>>>
>> Which are not?
>> I'm really interested to here about new ideas and technologies regarding
>> MDSD, but I couldn't see anything like that stated in the proposal.
>> If there are such things, you may want to come up with a more specific
>> proposal for that?
>>
>>
>>> Now, as stated in the proposal, we DO INTEND to migrate the non
>>> standards components to the latest stable components from the modeling
>>> project. In fact I am hoping that overtime we can become a model of
>>> use for the Modeling components in complete solution. As we migrate, I
>>> believe we can feed some of our experience to the appropriate modeling
>>> components.
>>>
>> Yes, there is a need for such a project within EMP. But who should decide
>> what components should become part of a best-of-breed modeling
>> environment?
>> To be honest, I doubt that you should decide that, because Tigerstripe
>> seems to be some years behind of what IMHO is state of the art in this
>> field (sorry, don't take this personally).
>> IMHO such a project should be driven by the community, at least the
>> decisions on what is best-of-breed and what's not.
>>
>>
>>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>>> modeling components in an end-user workbench. Use the current version
>>> as a starting point, and replace internal components one by one to
>>> make it best of breed in the Open, outside of the modeling project for
>>> now until we "ready" to be a proper subproject of the modeling
>>> project.
>>>
>> It's a bit strange, that you think incubating in EMT and then moving over
>> to EMP is a good idea. There are a lot of projects in an incubator phase
>> at EMP (Have a look at EMFT and GMT).
>> Maybe the real problem is that the focus doesn't fit with EMP?
>>
>>
>>> By talking to our existing user community (see interested party in the
>>> proposal), I believe the workbench as a whole already has a lot of
>>> value.
>>>
>> I'm sure there are a lot of happy users.
>> That's really not the problem.
>> There are also a lot of other MDSD-workbenches with many users out there.
>> And none of them (oAW included ;-)) should become the "Best-Of-Breed
>> Eclipse Modeling Project".
>>
>> kind regards,
>> Sven
>>
>
>
>
--------------000907050702060801050001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eric,<br>
<br>
Comments below.<br>
<br>
Eric Dillon wrote:
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">Ok. It seems to me that we can't just discard users that quickly :-).
The focus of the modeling project is definitely frameworks. I think we may
even all agree that there are a lot of frameworks, and that it is sometimes
difficult to sort your way through them. However, the consumers of the
modeling project - its users - are mainly application developers, able to
assemble the frameworks together into a bigger whole - thus creating value
for end-users that are not interested or able to do so.
</pre>
</blockquote>
I'm always a bit wary of how to carve up reality into different
compartments. Not that it's relevant here, but the whole tools verses
runtimes split often strikes me as totally artificial.<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
As you may have noticed the current user community of Tigerstripe is based
in the Telecom space. These guys are interested in modeling the latest
networking technology, network gear, etc... and in generating specs,
management interfaces, documentation, compliance test kits, and more. Most
of them - if not all of them - have no interest in stitching frameworks
together before they can get started on doing their job. In other words, the
consumers of Tigerstripe - its users - are VERY different from those of the
modeling project.
</pre>
</blockquote>
I'm not exactly sure what you mean by stitching frameworks together
and I'm not sure I understand at all the difference between the
Tigerstripe users base verses the modeling project's user base (as if
we have only one). It seems to me that the proposal presented a broad
MDD vision that's effectively identical to that of the modeling project
but here you suggest that the vision is narrower or the users addressed
by it is more restricted. I'm not sure I understand whether this is a
general MDD vision or an industry vertical version of it.<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
Now, we should also be careful when talking about an integration project for
EMP. What would be its intent? Show how to assemble frameworks? or provide
end-users with complete environment?
</pre>
</blockquote>
It should do all of these things. And many of the end users are likely
building their own frameworks. Many Eclipse projects are using the EMP
infrastructure in order to build their own infrastructure...<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
I think we need to address all user communities. It seems Tigerstripe
addresses a different user community than the modeling project. Our intent
to migrate to EMP components (that's what I called standard components, as
opposed to proprietary one :-)) should also serve the users of the Modeling
project.
</pre>
</blockquote>
I'd like to understand this difference a lot better. The proposal as
it is written isn't entirely clear that the user communities don't
coincide. I think folks like Kenn and others are trying to understand
the distinctions being drawn here is well...<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
Eric
"Sven Efftinge" <a class="moz-txt-link-rfc2396E" href="mailto:sven@efftinge.de"><sven@efftinge.de></a> wrote in message
<a class="moz-txt-link-freetext" href="news:fih32c$n57$1@build.eclipse.org">news:fih32c$n57$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi Eric,
</pre>
<blockquote type="cite">
<pre wrap="">So yes, some of the components in Tigerstripe are currently inferior
to the corresponding components from the modeling project.
</pre>
</blockquote>
<pre wrap="">Which are not?
I'm really interested to here about new ideas and technologies regarding
MDSD, but I couldn't see anything like that stated in the proposal.
If there are such things, you may want to come up with a more specific
proposal for that?
</pre>
<blockquote type="cite">
<pre wrap="">Now, as stated in the proposal, we DO INTEND to migrate the non
standards components to the latest stable components from the modeling
project. In fact I am hoping that overtime we can become a model of
use for the Modeling components in complete solution. As we migrate, I
believe we can feed some of our experience to the appropriate modeling
components.
</pre>
</blockquote>
<pre wrap="">Yes, there is a need for such a project within EMP. But who should decide
what components should become part of a best-of-breed modeling
environment?
To be honest, I doubt that you should decide that, because Tigerstripe
seems to be some years behind of what IMHO is state of the art in this
field (sorry, don't take this personally).
IMHO such a project should be driven by the community, at least the
decisions on what is best-of-breed and what's not.
</pre>
<blockquote type="cite">
<pre wrap="">Hopefully, we can use Tigerstripe as the red-thread to assemble all
modeling components in an end-user workbench. Use the current version
as a starting point, and replace internal components one by one to
make it best of breed in the Open, outside of the modeling project for
now until we "ready" to be a proper subproject of the modeling
project.
</pre>
</blockquote>
<pre wrap="">It's a bit strange, that you think incubating in EMT and then moving over
to EMP is a good idea. There are a lot of projects in an incubator phase
at EMP (Have a look at EMFT and GMT).
Maybe the real problem is that the focus doesn't fit with EMP?
</pre>
<blockquote type="cite">
<pre wrap="">By talking to our existing user community (see interested party in the
proposal), I believe the workbench as a whole already has a lot of
value.
</pre>
</blockquote>
<pre wrap="">I'm sure there are a lot of happy users.
That's really not the problem.
There are also a lot of other MDSD-workbenches with many users out there.
And none of them (oAW included ;-)) should become the "Best-Of-Breed
Eclipse Modeling Project".
kind regards,
Sven
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------000907050702060801050001--
|
|
|
| Re: Doubts about the project [message #2623 is a reply to message #2265] |
Wed, 28 November 2007 00:07 |
Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
Just to add my thoughts on this proposal and discussion:
Tigerstripe approached Modeling regarding the contribution of this code,
which Ed and I felt was not a good fit for many of the reasons already
raised here. We suggested Technology as an alternative where they could
incubate, grow a community, and potentially contribute to Modeling in the
future. This would be a challenging path, imho.
That said, I'm not sure I understand the point in contributing something,
refactoring it, and then possibly moving it (in part, or whole).
Personally, I don't think I'd start to use a technology if this were its
plan. I'd instead wait for the dust to settle, and in the meantime use the
pieces of EMP that let me do much of the same things, even if not
well-integrated (which brings me to the real point...).
Perhaps the best outcome of this proposal from the Modeling project's
perspective is that it introduces a competitive spark to help us do what
many of us have wanted to do for some time; that is, take the next step in
the Modeling project's evolution and focus on integrations and usability.
We've already started discussion on a packaging effort, capabilities
definition, etc. To me, the best way to get it done is within the scope of
a new project, which I've drafted a proposal for and hope to send out
shortly.
As for Tigerstripe, while I think the existence of this project will add to
the confusion about modeling solutions at Eclipse, I think the bigger
challenge will be for them to grow the 3 communities while undergoing such
change. My recommendation remains for them to narrow their focus, and even
consider returning to their original vertical-focused, SOA-centric roots.
Otherwise, as always, I welcome their contribution to some of our current
pain points in Modeling.
Best Regards,
Rich
On 11/27/07 4:18 AM, in article l7mnk311q2u2t1ker51atcbfu19njjd4go@4ax.com,
"Eric Dillon" <erdillon@cisco.com> wrote:
> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
> wrote:
>
> Hi all,
>
> thanks for your feedback. I can see where you are coming from and
> being a hardcore eclipse user myself, I fully agree with the need to
> strenghthen the existing components rather than re-inventing the wheel
> and duplicating them.
>
> I like to think of Tigerstripe as an end-user environment or workbench
> for Modeling+Scoping+Generation. We started building the application a
> few years back when some of these components either didn't exist or
> weren't fully stable yet. As a result, we did re-invent the wheel (as
> stated above) as we were working through end-user requirements and
> various issues.
>
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project. Yet, the
> whole is a end-to-end workbench where end-users, i.e. modelers, can
> get their job done.
>
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
>
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
>
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value. Migrating internal components to best of breed in the open
> should only add more value to the Eclipse community as we feed their
> requirements back to the community.
>
> Eric
>
>> Markus Voelter wrote:
>>
>>> Hi,
>>
>>> to get the discussion started: I am very sceptical about
>>> this proposal for the following reasons:
>>
>>> * at its core, the proposed techniques seem to be
>>> inferior to the stuff that's already available at
>>> EMP
>>> * in other areas it seems like a reinvention of the
>>> wheels we already have (UML editor, Code Gen Engine).
>>> We need fewer, better integrated modules, not more!
>> Please note in the proposal, in the scope section, the paragraph which
>> reads:
>>
>> "In addition, we intend to migrate existing parts of the software to the
>> latest frameworks supported by the Modeling top-level project. In
>> particular, we intend to use more of the EMF and UML2 frameworks where
>> applicable to complement the current technology in use, and allow easier
>> model sharing between users."
>>
>> We intend to converge over time. We'd like to do it in the open. That
>> will mean over time
>> incorporating more of the Eclipse Modeling components, as well as feeding
>> contributions
>> back to those components.
>>
>>> * I don't think there's any point of having a modeling
>>> thing outside of EMP. What kind of message would that
>>> send?? If there's a valuable contribution in it, make
>>> it part of modeling. If not, don't put it on Eclipse.
>>
>> Technology provides us with a good place to incubate. If at a later time
>> moving to the Eclipse Modeling Project makes sense to the folks involved,
>> we can do that.
>>
>>> That said, I would *love* to see a workbench-y kind of
>>> thing, that takes all (or most) of the EMP components and
>>> builds a nice workbench around it. That would be an integration
>>> project on top of what we have.
>>
>> Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>> workbench-y thing built on what Modeling had to offer in the past. Gaps
>> that existed then were filled, and some of filling those gaps brought in
>> features and functionality that are not yet be present in the current
>> Modeling components. Current Eclipse Modeling doesn't provide a drop in
>> replacement for what Tigerstripe allows it's current users to do, and
>> Tigerstripe certainly doesn't provide all of the functionality of the
>> Eclipse Modeling Projects with which it overlaps. Working through those
>> issues, while continuing to support Tigerstripe existing user base, is
>> part of what we hope to accomplish.
>>
|
|
|
| Re: Doubts about the project [message #2683 is a reply to message #2446] |
Wed, 28 November 2007 06:41 |
Markus Voelter
Messages: 33
Registered: July 2009 |
Member |
|
|
> Here however, you have suggested that the intended consumers and user
> community of Tigerstripe are fundamentally different from those of
> Modeling, i.e. they are in the Telecom space;
right (a bit like Topcased for the Aerospace world).
So *if* Tigerstripe is a collection of tools tairlored for
domain specific use, this is a different story. But again:
make it clear(er) in the proposal, and integrate EMP
projects.
Markus
if that is the case, perhaps this should be
> made
> more explicit in the proposal, and then this whole issue of overlap with
> the
> Modeling project would be less of a concern...
>
> Ultimately the proposal needs to make clear how the project will benefit
> the
> Eclipse community and what falls inside (and outside) of the scope for
> the
> project.
>
> Kenn
>
> "Eric Dillon" <erdillon@cisco.com> wrote in message
> news:fih9os$k3o$1@build.eclipse.org...
>> Ok. It seems to me that we can't just discard users that quickly :-).
>>
>> The focus of the modeling project is definitely frameworks. I think we
>> may
>> even all agree that there are a lot of frameworks, and that it is
>> sometimes difficult to sort your way through them. However, the
>> consumers
>> of the modeling project - its users - are mainly application developers,
>> able to assemble the frameworks together into a bigger whole - thus
>> creating value for end-users that are not interested or able to do so.
>>
>> As you may have noticed the current user community of Tigerstripe is
>> based
>> in the Telecom space. These guys are interested in modeling the latest
>> networking technology, network gear, etc... and in generating specs,
>> management interfaces, documentation, compliance test kits, and more.
>> Most
>> of them - if not all of them - have no interest in stitching frameworks
>> together before they can get started on doing their job. In other words,
>> the consumers of Tigerstripe - its users - are VERY different from those
>> of the modeling project.
>>
>> Now, we should also be careful when talking about an integration project
>> for EMP. What would be its intent? Show how to assemble frameworks? or
>> provide end-users with complete environment?
>>
>> I think we need to address all user communities. It seems Tigerstripe
>> addresses a different user community than the modeling project. Our
>> intent
>> to migrate to EMP components (that's what I called standard components,
>> as
>> opposed to proprietary one :-)) should also serve the users of the
>> Modeling project.
>>
>> Eric
>>
>>
>> "Sven Efftinge" <sven@efftinge.de> wrote in message
>> news:fih32c$n57$1@build.eclipse.org...
>>> Hi Eric,
>>>
>>>> So yes, some of the components in Tigerstripe are currently inferior
>>>> to the corresponding components from the modeling project.
>>>
>>> Which are not?
>>> I'm really interested to here about new ideas and technologies
>>> regarding
>>> MDSD, but I couldn't see anything like that stated in the proposal.
>>> If there are such things, you may want to come up with a more specific
>>> proposal for that?
>>>
>>>>
>>>> Now, as stated in the proposal, we DO INTEND to migrate the non
>>>> standards components to the latest stable components from the modeling
>>>> project. In fact I am hoping that overtime we can become a model of
>>>> use for the Modeling components in complete solution. As we migrate, I
>>>> believe we can feed some of our experience to the appropriate modeling
>>>> components.
>>>
>>> Yes, there is a need for such a project within EMP. But who should
>>> decide
>>> what components should become part of a best-of-breed modeling
>>> environment?
>>> To be honest, I doubt that you should decide that, because Tigerstripe
>>> seems to be some years behind of what IMHO is state of the art in this
>>> field (sorry, don't take this personally).
>>> IMHO such a project should be driven by the community, at least the
>>> decisions on what is best-of-breed and what's not.
>>>
>>>>
>>>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>>>> modeling components in an end-user workbench. Use the current version
>>>> as a starting point, and replace internal components one by one to
>>>> make it best of breed in the Open, outside of the modeling project for
>>>> now until we "ready" to be a proper subproject of the modeling
>>>> project.
>>>
>>> It's a bit strange, that you think incubating in EMT and then moving
>>> over
>>> to EMP is a good idea. There are a lot of projects in an incubator
>>> phase
>>> at EMP (Have a look at EMFT and GMT).
>>> Maybe the real problem is that the focus doesn't fit with EMP?
>>>
>>>>
>>>> By talking to our existing user community (see interested party in the
>>>> proposal), I believe the workbench as a whole already has a lot of
>>>> value.
>>>
>>> I'm sure there are a lot of happy users.
>>> That's really not the problem.
>>> There are also a lot of other MDSD-workbenches with many users out
>>> there.
>>> And none of them (oAW included ;-)) should become the "Best-Of-Breed
>>> Eclipse Modeling Project".
>>>
>>> kind regards,
>>> Sven
>>
>>
>
>
--
Markus Völter
voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
|
| Re: Doubts about the project [message #4113 is a reply to message #2153] |
Wed, 28 November 2007 10:44 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
Just my 2 cents to this debate.
As an Eclipse user I would really like a well integrated modeling
environment. There is lot of work to do on that side in the modeling
project, but also working together with other Eclipse projects.
For instance the "cartridge" things, by cartridge I mean model two text
transformations from a given type of model to a given set of framework. In
my opinion these cartridges should belong to the corresponding Eclipse
project. For instance if you generate JEE code, then you should be part of
the WTP project, if it's about Service Oriented Architecture, then STP is
here.. Then we can ensure the generated stuffs behave nicely with the
tooling provided with the project. This kind of co-operations is not in the
proposal.
Moreover, my opinion is that this proposal introduces yet another UML model,
yet another UML editor for that model, yet another template engine and all
this duplication is not even providing features we don't already have !
This opinion seems quite shared by the Eclipse commiters, I just wanted to
express the fact that the concerns about this project are pervasive.
Cédric
Markus Voelter wrote:
> Hi,
>
> to get the discussion started: I am very sceptical about
> this proposal for the following reasons:
>
> * at its core, the proposed techniques seem to be
> inferior to the stuff that's already available at
> EMP
> * in other areas it seems like a reinvention of the
> wheels we already have (UML editor, Code Gen Engine).
> We need fewer, better integrated modules, not more!
> * I don't think there's any point of having a modeling
> thing outside of EMP. What kind of message would that
> send?? If there's a valuable contribution in it, make
> it part of modeling. If not, don't put it on Eclipse.
>
> That said, I would *love* to see a workbench-y kind of
> thing, that takes all (or most) of the EMP components and
> builds a nice workbench around it. That would be an integration
> project on top of what we have.
>
> Markus
>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Doubts about the project [message #4253 is a reply to message #4113] |
Wed, 28 November 2007 16:01 |
| Eclipse User |
|
|
|
Originally posted by: dstrombo.cisco.com
I advocate that EF consider Tigerstripe as an extremely positive
contribution to Eclipse.
It's a market-tested modeling tool based on Eclipse with an active user
community among the largest telecommunications companies.
It demonstrates the use of several of the wonderful Eclipse modeling
frameworks.
It has a paradigm of UML2 modeling-to-code generation that is very
powerful.
I personally don't think there is a one-size-fits-all modeling approach,
so I don't understand your concerns about diversity of tooling. I think
the community needs a variety of tools.
I'm concerned that Eclipse appears to be prescriptive in terms of how to
do modeling. Telling a very advanced MDA user that he shouldn't use large
models is inappropriate.
Whether or not it belongs as a part of the core Eclipse Modeling Project
is a judgement call... probably not from your comments. But I'm sure
there are very practical uses of Tigerstripe within the Eclipse community.
Tigerstripe is not a threat to Eclipse Modeling frameworks. It is an
excellent example of how to apply them to real world issues.
I doubt my position will make me very popular. :)
Best Regards,
Doug
|
|
|
| Re: Doubts about the project [message #4323 is a reply to message #4253] |
Wed, 28 November 2007 17:20 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Doug,
Comments below.
Doug Strombom wrote:
> I advocate that EF consider Tigerstripe as an extremely positive
> contribution to Eclipse.
I'm sure it's intended to be a positive contribution and that the
Tigerstripe folks have nothing but good intentions in general.
>
> It's a market-tested modeling tool based on Eclipse with an active
> user community among the largest telecommunications companies.
Eclipse is also a commercial ecosystem so while this comment is great
for folks who like free beer, it's not necessarily so great for folks
selling beer. So in a sense this is both good and bad. Providing
frameworks that commercial vendors can extend to provide value-add is an
important principle at Eclipse.
>
> It demonstrates the use of several of the wonderful Eclipse modeling
> frameworks.
Now we're faltered. Hehehe.
>
> It has a paradigm of UML2 modeling-to-code generation that is very
> powerful.
I guess folks will want to understand how it compares to using UML2 or
Ecore directly with Xpand or JET? I.e., what makes it better? And how
can we reuse what makes it better to make more of the modeling project
infrastructure (for UML2 and Ecore) better?
>
> I personally don't think there is a one-size-fits-all modeling
> approach, so I don't understand your concerns about diversity of tooling.
The concern is about duplication. A great many folks have build
infrastructure that works directly with UML2 models or Ecore models so
they'd like to thing that their technology is applicable in the context
of Tigerstripe so if Tigerstripe is not using the UML2 model directly,
like the answer is it's not directly applicable.
> I think the community needs a variety of tools.
Certainly, but consider something like NetBeans verses Eclipse.
Probably no one needs both. It's more a case of one or the other. And
hence we'd all likely be better off if there weren't Eclipse and
NetBeans but just one that we all worked on together.
> I'm concerned that Eclipse appears to be prescriptive in terms of how
> to do modeling.
I don't think that's the case.
> Telling a very advanced MDA user that he shouldn't use large models is
> inappropriate.
A model will be as large as is required. The suggestion is merely that
it might be easier to maintain a larger number of smaller models than a
small number of large models. I.e., it's likely more conceptually
manageable. But in the end, a model must be as large as is needed to
capture what needs to be captured. Certainly the notion of "facets",
though I'm not quite clear on if that's a language construct of a
filtering in the UI, would be one way to deal with models that become so
large as to become conceptually unmanageable for the user.
> Whether or not it belongs as a part of the core Eclipse Modeling
> Project is a judgement call... probably not from your comments.
Actually, I think most folks will argue that it does belong in the
modeling project and that it should fit in well there. The issue is to
resolve the concerns about how well it fits. Obviously there have been
many concerns expressed about that.
> But I'm sure there are very practical uses of Tigerstripe within the
> Eclipse community.
I'm all in favor of growing the community, but you should take note of
the number of folks involved in the modeling project from various
companies and they don't typically name their community based on what's
currently a commercial brand.
>
> Tigerstripe is not a threat to Eclipse Modeling frameworks.
Unfortunately the fact that it's a brand name, which I know is an issue
you are looking to resolve, gives a threatening appearance.
> It is an excellent example of how to apply them to real world issues.
I'll need to read the proposed rewording of the proposal, but it
juxtapose much of what Tigerstripe is doing, i.e., MDD for the real
world, against precisely what many folks in the modeling project think
they are already doing today...
> I doubt my position will make me very popular. :)
Life's not a popularity contest. I've learned to stop worrying about
that. Speak your mind and who can really fault you for being honest...
>
> Best Regards,
> Doug
>
>
>
>
>
|
|
|
| Re: Doubts about the project [message #561218 is a reply to message #2153] |
Sat, 24 November 2007 11:47 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Hi,
I totally agree with what Markus said.
If you think there is an aspect of your tool, which fits a niche in EMP,
then it would be very interested to hear about it.
regards,
Sven
Markus Voelter wrote:
> Hi,
>
> to get the discussion started: I am very sceptical about
> this proposal for the following reasons:
>
> * at its core, the proposed techniques seem to be
> inferior to the stuff that's already available at
> EMP
> * in other areas it seems like a reinvention of the
> wheels we already have (UML editor, Code Gen Engine).
> We need fewer, better integrated modules, not more!
> * I don't think there's any point of having a modeling
> thing outside of EMP. What kind of message would that
> send?? If there's a valuable contribution in it, make
> it part of modeling. If not, don't put it on Eclipse.
>
> That said, I would *love* to see a workbench-y kind of
> thing, that takes all (or most) of the EMP components and
> builds a nice workbench around it. That would be an integration
> project on top of what we have.
>
> Markus
>
> --Markus Völter
>
> voelter - ingenieurbüro für softwaretechnologie
> Grabenstrasse 4, 73033 Goeppingen, Germany
> Tel. +49 (0) 171 / 86 01 869
> Email: voelter@acm.org
>
> Web: http://www.voelter.de
> Blog: http://www.voelter.de/blog
> Podcast: http://www.se-radio.net
>
> PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
| |
| Re: Doubts about the project [message #561245 is a reply to message #2153] |
Tue, 27 November 2007 01:30 |
Ed Warnicke
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
Markus Voelter wrote:
> Hi,
> to get the discussion started: I am very sceptical about
> this proposal for the following reasons:
> * at its core, the proposed techniques seem to be
> inferior to the stuff that's already available at
> EMP
> * in other areas it seems like a reinvention of the
> wheels we already have (UML editor, Code Gen Engine).
> We need fewer, better integrated modules, not more!
Please note in the proposal, in the scope section, the paragraph which
reads:
"In addition, we intend to migrate existing parts of the software to the
latest frameworks supported by the Modeling top-level project. In
particular, we intend to use more of the EMF and UML2 frameworks where
applicable to complement the current technology in use, and allow easier
model sharing between users."
We intend to converge over time. We'd like to do it in the open. That
will mean over time
incorporating more of the Eclipse Modeling components, as well as feeding
contributions
back to those components.
> * I don't think there's any point of having a modeling
> thing outside of EMP. What kind of message would that
> send?? If there's a valuable contribution in it, make
> it part of modeling. If not, don't put it on Eclipse.
Technology provides us with a good place to incubate. If at a later time
moving to the Eclipse Modeling Project makes sense to the folks involved,
we can do that.
> That said, I would *love* to see a workbench-y kind of
> thing, that takes all (or most) of the EMP components and
> builds a nice workbench around it. That would be an integration
> project on top of what we have.
Thats kind of where we would like to go. Tigerstripe is, in many ways, a
workbench-y thing built on what Modeling had to offer in the past. Gaps
that existed then were filled, and some of filling those gaps brought in
features and functionality that are not yet be present in the current
Modeling components. Current Eclipse Modeling doesn't provide a drop in
replacement for what Tigerstripe allows it's current users to do, and
Tigerstripe certainly doesn't provide all of the functionality of the
Eclipse Modeling Projects with which it overlaps. Working through those
issues, while continuing to support Tigerstripe existing user base, is
part of what we hope to accomplish.
|
|
|
| Re: Doubts about the project [message #561259 is a reply to message #2238] |
Tue, 27 November 2007 09:18 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
wrote:
Hi all,
thanks for your feedback. I can see where you are coming from and
being a hardcore eclipse user myself, I fully agree with the need to
strenghthen the existing components rather than re-inventing the wheel
and duplicating them.
I like to think of Tigerstripe as an end-user environment or workbench
for Modeling+Scoping+Generation. We started building the application a
few years back when some of these components either didn't exist or
weren't fully stable yet. As a result, we did re-invent the wheel (as
stated above) as we were working through end-user requirements and
various issues.
So yes, some of the components in Tigerstripe are currently inferior
to the corresponding components from the modeling project. Yet, the
whole is a end-to-end workbench where end-users, i.e. modelers, can
get their job done.
Now, as stated in the proposal, we DO INTEND to migrate the non
standards components to the latest stable components from the modeling
project. In fact I am hoping that overtime we can become a model of
use for the Modeling components in complete solution. As we migrate, I
believe we can feed some of our experience to the appropriate modeling
components.
Hopefully, we can use Tigerstripe as the red-thread to assemble all
modeling components in an end-user workbench. Use the current version
as a starting point, and replace internal components one by one to
make it best of breed in the Open, outside of the modeling project for
now until we "ready" to be a proper subproject of the modeling
project.
By talking to our existing user community (see interested party in the
proposal), I believe the workbench as a whole already has a lot of
value. Migrating internal components to best of breed in the open
should only add more value to the Eclipse community as we feed their
requirements back to the community.
Eric
>Markus Voelter wrote:
>
>> Hi,
>
>> to get the discussion started: I am very sceptical about
>> this proposal for the following reasons:
>
>> * at its core, the proposed techniques seem to be
>> inferior to the stuff that's already available at
>> EMP
>> * in other areas it seems like a reinvention of the
>> wheels we already have (UML editor, Code Gen Engine).
>> We need fewer, better integrated modules, not more!
>Please note in the proposal, in the scope section, the paragraph which
>reads:
>
>"In addition, we intend to migrate existing parts of the software to the
>latest frameworks supported by the Modeling top-level project. In
>particular, we intend to use more of the EMF and UML2 frameworks where
>applicable to complement the current technology in use, and allow easier
>model sharing between users."
>
>We intend to converge over time. We'd like to do it in the open. That
>will mean over time
>incorporating more of the Eclipse Modeling components, as well as feeding
>contributions
>back to those components.
>
>> * I don't think there's any point of having a modeling
>> thing outside of EMP. What kind of message would that
>> send?? If there's a valuable contribution in it, make
>> it part of modeling. If not, don't put it on Eclipse.
>
>Technology provides us with a good place to incubate. If at a later time
>moving to the Eclipse Modeling Project makes sense to the folks involved,
>we can do that.
>
>> That said, I would *love* to see a workbench-y kind of
>> thing, that takes all (or most) of the EMP components and
>> builds a nice workbench around it. That would be an integration
>> project on top of what we have.
>
>Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>workbench-y thing built on what Modeling had to offer in the past. Gaps
>that existed then were filled, and some of filling those gaps brought in
>features and functionality that are not yet be present in the current
>Modeling components. Current Eclipse Modeling doesn't provide a drop in
>replacement for what Tigerstripe allows it's current users to do, and
>Tigerstripe certainly doesn't provide all of the functionality of the
>Eclipse Modeling Projects with which it overlaps. Working through those
>issues, while continuing to support Tigerstripe existing user base, is
>part of what we hope to accomplish.
>
|
|
|
| Re: Doubts about the project [message #561276 is a reply to message #2265] |
Tue, 27 November 2007 11:52 |
Bernd Kolb
Messages: 57
Registered: July 2009 |
Member |
|
|
Eric,
I can see your point but first of all, I do not see why you could not do
that in modeling. I cannot find a single sentence wrt. EMP toplevel
project in the Proposal.
The next thing when having a look to your proposal which came up to my
mind was that you seem to use technologies which have proven to be not
the best choice when doing MDSD (Just velocity as an example).
EMP already has the problem that it is not clear for the user which tool
to use in which cases. If you now start another project under another
toplevel project users will get confused even more! I agree that having
an integration project would really add a benefit EMP. But it has to be
an integration project from the beginning.
You are mentioning that you'd like to migrate to "standard components".
What do you consider to be a standard component?
So far I am not convinced :-)
Best regards
Bernd
Eric Dillon schrieb:
> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
> wrote:
>
> Hi all,
>
> thanks for your feedback. I can see where you are coming from and
> being a hardcore eclipse user myself, I fully agree with the need to
> strenghthen the existing components rather than re-inventing the wheel
> and duplicating them.
>
> I like to think of Tigerstripe as an end-user environment or workbench
> for Modeling+Scoping+Generation. We started building the application a
> few years back when some of these components either didn't exist or
> weren't fully stable yet. As a result, we did re-invent the wheel (as
> stated above) as we were working through end-user requirements and
> various issues.
>
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project. Yet, the
> whole is a end-to-end workbench where end-users, i.e. modelers, can
> get their job done.
>
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
>
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
>
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value. Migrating internal components to best of breed in the open
> should only add more value to the Eclipse community as we feed their
> requirements back to the community.
>
> Eric
>
>> Markus Voelter wrote:
>>
>>> Hi,
>>> to get the discussion started: I am very sceptical about
>>> this proposal for the following reasons:
>>> * at its core, the proposed techniques seem to be
>>> inferior to the stuff that's already available at
>>> EMP
>>> * in other areas it seems like a reinvention of the
>>> wheels we already have (UML editor, Code Gen Engine).
>>> We need fewer, better integrated modules, not more!
>> Please note in the proposal, in the scope section, the paragraph which
>> reads:
>>
>> "In addition, we intend to migrate existing parts of the software to the
>> latest frameworks supported by the Modeling top-level project. In
>> particular, we intend to use more of the EMF and UML2 frameworks where
>> applicable to complement the current technology in use, and allow easier
>> model sharing between users."
>>
>> We intend to converge over time. We'd like to do it in the open. That
>> will mean over time
>> incorporating more of the Eclipse Modeling components, as well as feeding
>> contributions
>> back to those components.
>>
>>> * I don't think there's any point of having a modeling
>>> thing outside of EMP. What kind of message would that
>>> send?? If there's a valuable contribution in it, make
>>> it part of modeling. If not, don't put it on Eclipse.
>> Technology provides us with a good place to incubate. If at a later time
>> moving to the Eclipse Modeling Project makes sense to the folks involved,
>> we can do that.
>>
>>> That said, I would *love* to see a workbench-y kind of
>>> thing, that takes all (or most) of the EMP components and
>>> builds a nice workbench around it. That would be an integration
>>> project on top of what we have.
>> Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>> workbench-y thing built on what Modeling had to offer in the past. Gaps
>> that existed then were filled, and some of filling those gaps brought in
>> features and functionality that are not yet be present in the current
>> Modeling components. Current Eclipse Modeling doesn't provide a drop in
>> replacement for what Tigerstripe allows it's current users to do, and
>> Tigerstripe certainly doesn't provide all of the functionality of the
>> Eclipse Modeling Projects with which it overlaps. Working through those
>> issues, while continuing to support Tigerstripe existing user base, is
>> part of what we hope to accomplish.
>>
|
|
|
| Re: Doubts about the project [message #561290 is a reply to message #2295] |
Tue, 27 November 2007 12:19 |
Markus Voelter
Messages: 33
Registered: July 2009 |
Member |
|
|
Bernd pretty clearly stated the same I
would have replied. So I don't repeat that.
I am also not convinced.
Why don't you rewrite the proposal to reflect
more explicitly what you say here?
Markus
> Eric,
>
> I can see your point but first of all, I do not see why you could not do
> that in modeling. I cannot find a single sentence wrt. EMP toplevel
> project in the Proposal.
>
> The next thing when having a look to your proposal which came up to my
> mind was that you seem to use technologies which have proven to be not
> the best choice when doing MDSD (Just velocity as an example).
>
> EMP already has the problem that it is not clear for the user which tool
> to use in which cases. If you now start another project under another
> toplevel project users will get confused even more! I agree that having
> an integration project would really add a benefit EMP. But it has to be
> an integration project from the beginning.
>
> You are mentioning that you'd like to migrate to "standard components".
> What do you consider to be a standard component?
>
>
> So far I am not convinced :-)
>
> Best regards
>
> Bernd
>
>
> Eric Dillon schrieb:
>> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
>> wrote:
>> Hi all,
>> thanks for your feedback. I can see where you are coming from and
>> being a hardcore eclipse user myself, I fully agree with the need to
>> strenghthen the existing components rather than re-inventing the wheel
>> and duplicating them.
>> I like to think of Tigerstripe as an end-user environment or workbench
>> for Modeling+Scoping+Generation. We started building the application a
>> few years back when some of these components either didn't exist or
>> weren't fully stable yet. As a result, we did re-invent the wheel (as
>> stated above) as we were working through end-user requirements and
>> various issues.
>> So yes, some of the components in Tigerstripe are currently inferior
>> to the corresponding components from the modeling project. Yet, the
>> whole is a end-to-end workbench where end-users, i.e. modelers, can
>> get their job done.
>> Now, as stated in the proposal, we DO INTEND to migrate the non
>> standards components to the latest stable components from the modeling
>> project. In fact I am hoping that overtime we can become a model of
>> use for the Modeling components in complete solution. As we migrate, I
>> believe we can feed some of our experience to the appropriate modeling
>> components.
>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>> modeling components in an end-user workbench. Use the current version
>> as a starting point, and replace internal components one by one to
>> make it best of breed in the Open, outside of the modeling project for
>> now until we "ready" to be a proper subproject of the modeling
>> project.
>> By talking to our existing user community (see interested party in the
>> proposal), I believe the workbench as a whole already has a lot of
>> value. Migrating internal components to best of breed in the open
>> should only add more value to the Eclipse community as we feed their
>> requirements back to the community.
>> Eric
>>
>>> Markus Voelter wrote:
>>>
>>>> Hi,
>>>> to get the discussion started: I am very sceptical about
>>>> this proposal for the following reasons:
>>>> * at its core, the proposed techniques seem to be
>>>> inferior to the stuff that's already available at
>>>> EMP
>>>> * in other areas it seems like a reinvention of the
>>>> wheels we already have (UML editor, Code Gen Engine).
>>>> We need fewer, better integrated modules, not more!
>>> Please note in the proposal, in the scope section, the paragraph which
>>> reads:
>>>
>>> "In addition, we intend to migrate existing parts of the software to
>>> the latest frameworks supported by the Modeling top-level project. In
>>> particular, we intend to use more of the EMF and UML2 frameworks where
>>> applicable to complement the current technology in use, and allow
>>> easier model sharing between users."
>>>
>>> We intend to converge over time. We'd like to do it in the open.
>>> That will mean over time
>>> incorporating more of the Eclipse Modeling components, as well as
>>> feeding contributions
>>> back to those components.
>>>
>>>> * I don't think there's any point of having a modeling
>>>> thing outside of EMP. What kind of message would that
>>>> send?? If there's a valuable contribution in it, make
>>>> it part of modeling. If not, don't put it on Eclipse.
>>> Technology provides us with a good place to incubate. If at a later
>>> time moving to the Eclipse Modeling Project makes sense to the folks
>>> involved, we can do that.
>>>
>>>> That said, I would *love* to see a workbench-y kind of
>>>> thing, that takes all (or most) of the EMP components and
>>>> builds a nice workbench around it. That would be an integration
>>>> project on top of what we have.
>>> Thats kind of where we would like to go. Tigerstripe is, in many
>>> ways, a workbench-y thing built on what Modeling had to offer in the
>>> past. Gaps that existed then were filled, and some of filling those
>>> gaps brought in features and functionality that are not yet be present
>>> in the current Modeling components. Current Eclipse Modeling doesn't
>>> provide a drop in replacement for what Tigerstripe allows it's current
>>> users to do, and Tigerstripe certainly doesn't provide all of the
>>> functionality of the Eclipse Modeling Projects with which it
>>> overlaps. Working through those issues, while continuing to support
>>> Tigerstripe existing user base, is part of what we hope to accomplish.
>>>
>
--
Markus Völter
voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
|
| Re: Doubts about the project [message #561306 is a reply to message #2265] |
Tue, 27 November 2007 12:38 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Hi Eric,
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project.
Which are not?
I'm really interested to here about new ideas and technologies regarding
MDSD, but I couldn't see anything like that stated in the proposal.
If there are such things, you may want to come up with a more specific
proposal for that?
>
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
Yes, there is a need for such a project within EMP. But who should
decide what components should become part of a best-of-breed modeling
environment?
To be honest, I doubt that you should decide that, because Tigerstripe
seems to be some years behind of what IMHO is state of the art in this
field (sorry, don't take this personally).
IMHO such a project should be driven by the community, at least the
decisions on what is best-of-breed and what's not.
>
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
It's a bit strange, that you think incubating in EMT and then moving
over to EMP is a good idea. There are a lot of projects in an incubator
phase at EMP (Have a look at EMFT and GMT).
Maybe the real problem is that the focus doesn't fit with EMP?
>
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value.
I'm sure there are a lot of happy users.
That's really not the problem.
There are also a lot of other MDSD-workbenches with many users out
there. And none of them (oAW included ;-)) should become the
"Best-Of-Breed Eclipse Modeling Project".
kind regards,
Sven
|
|
|
| Re: Doubts about the project [message #561323 is a reply to message #2355] |
Tue, 27 November 2007 14:31 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Ok. It seems to me that we can't just discard users that quickly :-).
The focus of the modeling project is definitely frameworks. I think we may
even all agree that there are a lot of frameworks, and that it is sometimes
difficult to sort your way through them. However, the consumers of the
modeling project - its users - are mainly application developers, able to
assemble the frameworks together into a bigger whole - thus creating value
for end-users that are not interested or able to do so.
As you may have noticed the current user community of Tigerstripe is based
in the Telecom space. These guys are interested in modeling the latest
networking technology, network gear, etc... and in generating specs,
management interfaces, documentation, compliance test kits, and more. Most
of them - if not all of them - have no interest in stitching frameworks
together before they can get started on doing their job. In other words, the
consumers of Tigerstripe - its users - are VERY different from those of the
modeling project.
Now, we should also be careful when talking about an integration project for
EMP. What would be its intent? Show how to assemble frameworks? or provide
end-users with complete environment?
I think we need to address all user communities. It seems Tigerstripe
addresses a different user community than the modeling project. Our intent
to migrate to EMP components (that's what I called standard components, as
opposed to proprietary one :-)) should also serve the users of the Modeling
project.
Eric
"Sven Efftinge" <sven@efftinge.de> wrote in message
news:fih32c$n57$1@build.eclipse.org...
> Hi Eric,
>
>> So yes, some of the components in Tigerstripe are currently inferior
>> to the corresponding components from the modeling project.
>
> Which are not?
> I'm really interested to here about new ideas and technologies regarding
> MDSD, but I couldn't see anything like that stated in the proposal.
> If there are such things, you may want to come up with a more specific
> proposal for that?
>
>>
>> Now, as stated in the proposal, we DO INTEND to migrate the non
>> standards components to the latest stable components from the modeling
>> project. In fact I am hoping that overtime we can become a model of
>> use for the Modeling components in complete solution. As we migrate, I
>> believe we can feed some of our experience to the appropriate modeling
>> components.
>
> Yes, there is a need for such a project within EMP. But who should decide
> what components should become part of a best-of-breed modeling
> environment?
> To be honest, I doubt that you should decide that, because Tigerstripe
> seems to be some years behind of what IMHO is state of the art in this
> field (sorry, don't take this personally).
> IMHO such a project should be driven by the community, at least the
> decisions on what is best-of-breed and what's not.
>
>>
>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>> modeling components in an end-user workbench. Use the current version
>> as a starting point, and replace internal components one by one to
>> make it best of breed in the Open, outside of the modeling project for
>> now until we "ready" to be a proper subproject of the modeling
>> project.
>
> It's a bit strange, that you think incubating in EMT and then moving over
> to EMP is a good idea. There are a lot of projects in an incubator phase
> at EMP (Have a look at EMFT and GMT).
> Maybe the real problem is that the focus doesn't fit with EMP?
>
>>
>> By talking to our existing user community (see interested party in the
>> proposal), I believe the workbench as a whole already has a lot of
>> value.
>
> I'm sure there are a lot of happy users.
> That's really not the problem.
> There are also a lot of other MDSD-workbenches with many users out there.
> And none of them (oAW included ;-)) should become the "Best-Of-Breed
> Eclipse Modeling Project".
>
> kind regards,
> Sven
|
|
|
| Re: Doubts about the project [message #561361 is a reply to message #2385] |
Tue, 27 November 2007 17:17 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Eric,
While the mature subprojects/components in Modeling happen to be
infrastructure-related, I disagree that the (only) focus of the Modeling
project is frameworks. Take the MDT subproject, for example - one of its
goals is to provide exemplary tools for building industry standard models.
One of the (other) questions that needs to be answered clearly for new
proposals is what the intended scope will be. The way the proposal is
currently written, it suggests that the scope is MDD in general. Here,
however, you have suggested that the intended consumers and user community
of Tigerstripe are fundamentally different from those of Modeling, i.e. they
are in the Telecom space; if that is the case, perhaps this should be made
more explicit in the proposal, and then this whole issue of overlap with the
Modeling project would be less of a concern...
Ultimately the proposal needs to make clear how the project will benefit the
Eclipse community and what falls inside (and outside) of the scope for the
project.
Kenn
"Eric Dillon" <erdillon@cisco.com> wrote in message
news:fih9os$k3o$1@build.eclipse.org...
> Ok. It seems to me that we can't just discard users that quickly :-).
>
> The focus of the modeling project is definitely frameworks. I think we may
> even all agree that there are a lot of frameworks, and that it is
> sometimes difficult to sort your way through them. However, the consumers
> of the modeling project - its users - are mainly application developers,
> able to assemble the frameworks together into a bigger whole - thus
> creating value for end-users that are not interested or able to do so.
>
> As you may have noticed the current user community of Tigerstripe is based
> in the Telecom space. These guys are interested in modeling the latest
> networking technology, network gear, etc... and in generating specs,
> management interfaces, documentation, compliance test kits, and more. Most
> of them - if not all of them - have no interest in stitching frameworks
> together before they can get started on doing their job. In other words,
> the consumers of Tigerstripe - its users - are VERY different from those
> of the modeling project.
>
> Now, we should also be careful when talking about an integration project
> for EMP. What would be its intent? Show how to assemble frameworks? or
> provide end-users with complete environment?
>
> I think we need to address all user communities. It seems Tigerstripe
> addresses a different user community than the modeling project. Our intent
> to migrate to EMP components (that's what I called standard components, as
> opposed to proprietary one :-)) should also serve the users of the
> Modeling project.
>
> Eric
>
>
> "Sven Efftinge" <sven@efftinge.de> wrote in message
> news:fih32c$n57$1@build.eclipse.org...
>> Hi Eric,
>>
>>> So yes, some of the components in Tigerstripe are currently inferior
>>> to the corresponding components from the modeling project.
>>
>> Which are not?
>> I'm really interested to here about new ideas and technologies regarding
>> MDSD, but I couldn't see anything like that stated in the proposal.
>> If there are such things, you may want to come up with a more specific
>> proposal for that?
>>
>>>
>>> Now, as stated in the proposal, we DO INTEND to migrate the non
>>> standards components to the latest stable components from the modeling
>>> project. In fact I am hoping that overtime we can become a model of
>>> use for the Modeling components in complete solution. As we migrate, I
>>> believe we can feed some of our experience to the appropriate modeling
>>> components.
>>
>> Yes, there is a need for such a project within EMP. But who should decide
>> what components should become part of a best-of-breed modeling
>> environment?
>> To be honest, I doubt that you should decide that, because Tigerstripe
>> seems to be some years behind of what IMHO is state of the art in this
>> field (sorry, don't take this personally).
>> IMHO such a project should be driven by the community, at least the
>> decisions on what is best-of-breed and what's not.
>>
>>>
>>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>>> modeling components in an end-user workbench. Use the current version
>>> as a starting point, and replace internal components one by one to
>>> make it best of breed in the Open, outside of the modeling project for
>>> now until we "ready" to be a proper subproject of the modeling
>>> project.
>>
>> It's a bit strange, that you think incubating in EMT and then moving over
>> to EMP is a good idea. There are a lot of projects in an incubator phase
>> at EMP (Have a look at EMFT and GMT).
>> Maybe the real problem is that the focus doesn't fit with EMP?
>>
>>>
>>> By talking to our existing user community (see interested party in the
>>> proposal), I believe the workbench as a whole already has a lot of
>>> value.
>>
>> I'm sure there are a lot of happy users.
>> That's really not the problem.
>> There are also a lot of other MDSD-workbenches with many users out there.
>> And none of them (oAW included ;-)) should become the "Best-Of-Breed
>> Eclipse Modeling Project".
>>
>> kind regards,
>> Sven
>
>
|
|
|
| Re: Doubts about the project [message #561395 is a reply to message #2238] |
Tue, 27 November 2007 20:29 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Warnicke wrote:
> Markus Voelter wrote:
>
>> Hi,
>
>> to get the discussion started: I am very sceptical about
>> this proposal for the following reasons:
>
>> * at its core, the proposed techniques seem to be
>> inferior to the stuff that's already available at
>> EMP
>> * in other areas it seems like a reinvention of the
>> wheels we already have (UML editor, Code Gen Engine).
>> We need fewer, better integrated modules, not more!
> Please note in the proposal, in the scope section, the paragraph which
> reads:
>
> "In addition, we intend to migrate existing parts of the software to
> the latest frameworks supported by the Modeling top-level project. In
> particular, we intend to use more of the EMF and UML2 frameworks where
> applicable to complement the current technology in use, and allow
> easier model sharing between users."
I'm trying to reconcile that intent with concept like 'facets' and
'binary' models mentioned by Steve in the next note chain. It almost
sounds like the model is both a super set and a subset. I think many
folks would be far more comfortable with reuse of existing components as
the starting point rather than an eventual end goal. Given the
development realities with which we are all faced, it's clear that good
intentions don't on their own produce the actual results. The three
folks working actively on the UML2 Tools could benefit from a growing
contributor base.
>
> We intend to converge over time. We'd like to do it in the open.
> That will mean over time
> incorporating more of the Eclipse Modeling components, as well as
> feeding contributions
> back to those components.
I get the sense that you will be migrating your user base at least twice
with this approach. I.e., won't the APIs against which folks are
generating artifacts change at least package names by virtue of moving
to Eclipse and then drastically a second time as a result of moving from
your current form to the UML2 APIs. This would also require migration
of the serialized artifacts use an interchangeable serialization format.
It also seems to me that whatever reason you had for not using UML2 in
the first place two years ago won't suddenly go away today. Could you
explain why you chose not to use UML2 but now expect to take a different
path at some point in the future?
>
>> * I don't think there's any point of having a modeling
>> thing outside of EMP. What kind of message would that
>> send?? If there's a valuable contribution in it, make
>> it part of modeling. If not, don't put it on Eclipse.
>
> Technology provides us with a good place to incubate. If at a later
> time moving to the Eclipse Modeling Project makes sense to the folks
> involved, we can do that.
I should point out that the modeling PMC's lead (Rich and I) didn't give
you folks a lot of choice. We weren't willing to accept the project in
its present form because of the duplication and overlap about which
other folks have expressed their concerns.
>
>> That said, I would *love* to see a workbench-y kind of
>> thing, that takes all (or most) of the EMP components and
>> builds a nice workbench around it. That would be an integration
>> project on top of what we have.
>
> Thats kind of where we would like to go. Tigerstripe is, in many
> ways, a workbench-y thing built on what Modeling had to offer in the
> past. Gaps that existed then were filled, and some of filling those
> gaps brought in features and functionality that are not yet be present
> in the current Modeling components. Current Eclipse Modeling doesn't
> provide a drop in replacement for what Tigerstripe allows it's current
> users to do, and Tigerstripe certainly doesn't provide all of the
> functionality of the Eclipse Modeling Projects with which it
> overlaps. Working through those issues, while continuing to support
> Tigerstripe existing user base, is part of what we hope to accomplish.
>
UML2 wasn't really a gap though and Ecore already existed as well.
Filling in the gaps via what's currently a divergent code base doesn't
solve any problems for the established modeling community at Eclipse.
It would seem better to support the existing user base via the existing
code base and start on a new path towards a single replacement based on
integration with the established infrastructure. Importers and
exporters could be used to migrate the users to the new base once it's
stable. This would certainly be what I'd prefer to see because two
modeling solutions at Eclipse just seems plain confusing, especially
when the modeling project is badly in need of a more unifying overview.
I'm sure the community would welcome an effort that clearly takes
immediate steps towards a common goal.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Doubts about the project [message #561413 is a reply to message #2265] |
Tue, 27 November 2007 20:41 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Eric,
Comments below.
Eric Dillon wrote:
> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
> wrote:
>
> Hi all,
>
> thanks for your feedback. I can see where you are coming from and
> being a hardcore eclipse user myself, I fully agree with the need to
> strenghthen the existing components rather than re-inventing the wheel
> and duplicating them.
>
I really enjoyed the demos you have and would love to work more closely
with you.
> I like to think of Tigerstripe as an end-user environment or workbench
> for Modeling+Scoping+Generation. We started building the application a
> few years back when some of these components either didn't exist or
> weren't fully stable yet. As a result, we did re-invent the wheel (as
> stated above) as we were working through end-user requirements and
> various issues.
>
We of course like to think of the modeling project in this way as well
and would have welcomed your direct involvement years ago and will do so
now.
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project. Yet, the
> whole is a end-to-end workbench where end-users, i.e. modelers, can
> get their job done.
>
I could argue that EMF's tools could stand a significant amount of
polish, but as a whole has allowed folks to do amazing things despite
the warts. It's better if others make that point though. :-P
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
>
This is a key point that needs to be understood well. As I asked Ed,
what were the reasons for not using UML2 nor Ecore that will change in
the future? Both were available and there must be a good reason for not
having chosen them and likely that reason hasn't gone away.
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
>
I suppose I'd rather see that effort be the starting point rather than
good long term intentions. As I said to Ed, development reality often
throws good intentions by the wayside.
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value. Migrating internal components to best of breed in the open
> should only add more value to the Eclipse community as we feed their
> requirements back to the community.
>
I know from talking to you folks it's not your intent to insult the
established community at Eclipse. You're a great bunch of guys. It's
just that you need to keep in mind that your scope as you've outlined it
is almost identical to that of the modeling project, so there are
significant sensitivities here. I guess I'm hoping to convince you
folks to reconsider the current path since I think a path where we work
immediately towards integration will be a more successful one for
everyone involved. Just look at the numbers of committers involved in
the modeling project relative to the small tigerstripe base. It's hard
to compare the size of the communities, but I suspect that will be even
more slanted toward the established base at Eclipse. It seems you're
much more likely to achieve broad appeal by leveraging what we've been
working at for many years already...
> Eric
>
>
>> Markus Voelter wrote:
>>
>>
>>> Hi,
>>>
>>> to get the discussion started: I am very sceptical about
>>> this proposal for the following reasons:
>>>
>>> * at its core, the proposed techniques seem to be
>>> inferior to the stuff that's already available at
>>> EMP
>>> * in other areas it seems like a reinvention of the
>>> wheels we already have (UML editor, Code Gen Engine).
>>> We need fewer, better integrated modules, not more!
>>>
>> Please note in the proposal, in the scope section, the paragraph which
>> reads:
>>
>> "In addition, we intend to migrate existing parts of the software to the
>> latest frameworks supported by the Modeling top-level project. In
>> particular, we intend to use more of the EMF and UML2 frameworks where
>> applicable to complement the current technology in use, and allow easier
>> model sharing between users."
>>
>> We intend to converge over time. We'd like to do it in the open. That
>> will mean over time
>> incorporating more of the Eclipse Modeling components, as well as feeding
>> contributions
>> back to those components.
>>
>>
>>> * I don't think there's any point of having a modeling
>>> thing outside of EMP. What kind of message would that
>>> send?? If there's a valuable contribution in it, make
>>> it part of modeling. If not, don't put it on Eclipse.
>>>
>> Technology provides us with a good place to incubate. If at a later time
>> moving to the Eclipse Modeling Project makes sense to the folks involved,
>> we can do that.
>>
>>
>>> That said, I would *love* to see a workbench-y kind of
>>> thing, that takes all (or most) of the EMP components and
>>> builds a nice workbench around it. That would be an integration
>>> project on top of what we have.
>>>
>> Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>> workbench-y thing built on what Modeling had to offer in the past. Gaps
>> that existed then were filled, and some of filling those gaps brought in
>> features and functionality that are not yet be present in the current
>> Modeling components. Current Eclipse Modeling doesn't provide a drop in
>> replacement for what Tigerstripe allows it's current users to do, and
>> Tigerstripe certainly doesn't provide all of the functionality of the
>> Eclipse Modeling Projects with which it overlaps. Working through those
>> issues, while continuing to support Tigerstripe existing user base, is
>> part of what we hope to accomplish.
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Doubts about the project [message #561434 is a reply to message #2385] |
Tue, 27 November 2007 20:49 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000907050702060801050001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eric,
Comments below.
Eric Dillon wrote:
> Ok. It seems to me that we can't just discard users that quickly :-).
>
> The focus of the modeling project is definitely frameworks. I think we may
> even all agree that there are a lot of frameworks, and that it is sometimes
> difficult to sort your way through them. However, the consumers of the
> modeling project - its users - are mainly application developers, able to
> assemble the frameworks together into a bigger whole - thus creating value
> for end-users that are not interested or able to do so.
>
I'm always a bit wary of how to carve up reality into different
compartments. Not that it's relevant here, but the whole tools verses
runtimes split often strikes me as totally artificial.
> As you may have noticed the current user community of Tigerstripe is based
> in the Telecom space. These guys are interested in modeling the latest
> networking technology, network gear, etc... and in generating specs,
> management interfaces, documentation, compliance test kits, and more. Most
> of them - if not all of them - have no interest in stitching frameworks
> together before they can get started on doing their job. In other words, the
> consumers of Tigerstripe - its users - are VERY different from those of the
> modeling project.
>
I'm not exactly sure what you mean by stitching frameworks together and
I'm not sure I understand at all the difference between the Tigerstripe
users base verses the modeling project's user base (as if we have only
one). It seems to me that the proposal presented a broad MDD vision
that's effectively identical to that of the modeling project but here
you suggest that the vision is narrower or the users addressed by it is
more restricted. I'm not sure I understand whether this is a general
MDD vision or an industry vertical version of it.
> Now, we should also be careful when talking about an integration project for
> EMP. What would be its intent? Show how to assemble frameworks? or provide
> end-users with complete environment?
>
It should do all of these things. And many of the end users are likely
building their own frameworks. Many Eclipse projects are using the EMP
infrastructure in order to build their own infrastructure...
> I think we need to address all user communities. It seems Tigerstripe
> addresses a different user community than the modeling project. Our intent
> to migrate to EMP components (that's what I called standard components, as
> opposed to proprietary one :-)) should also serve the users of the Modeling
> project.
>
I'd like to understand this difference a lot better. The proposal as it
is written isn't entirely clear that the user communities don't
coincide. I think folks like Kenn and others are trying to understand
the distinctions being drawn here is well...
> Eric
>
>
> "Sven Efftinge" <sven@efftinge.de> wrote in message
> news:fih32c$n57$1@build.eclipse.org...
>
>> Hi Eric,
>>
>>
>>> So yes, some of the components in Tigerstripe are currently inferior
>>> to the corresponding components from the modeling project.
>>>
>> Which are not?
>> I'm really interested to here about new ideas and technologies regarding
>> MDSD, but I couldn't see anything like that stated in the proposal.
>> If there are such things, you may want to come up with a more specific
>> proposal for that?
>>
>>
>>> Now, as stated in the proposal, we DO INTEND to migrate the non
>>> standards components to the latest stable components from the modeling
>>> project. In fact I am hoping that overtime we can become a model of
>>> use for the Modeling components in complete solution. As we migrate, I
>>> believe we can feed some of our experience to the appropriate modeling
>>> components.
>>>
>> Yes, there is a need for such a project within EMP. But who should decide
>> what components should become part of a best-of-breed modeling
>> environment?
>> To be honest, I doubt that you should decide that, because Tigerstripe
>> seems to be some years behind of what IMHO is state of the art in this
>> field (sorry, don't take this personally).
>> IMHO such a project should be driven by the community, at least the
>> decisions on what is best-of-breed and what's not.
>>
>>
>>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>>> modeling components in an end-user workbench. Use the current version
>>> as a starting point, and replace internal components one by one to
>>> make it best of breed in the Open, outside of the modeling project for
>>> now until we "ready" to be a proper subproject of the modeling
>>> project.
>>>
>> It's a bit strange, that you think incubating in EMT and then moving over
>> to EMP is a good idea. There are a lot of projects in an incubator phase
>> at EMP (Have a look at EMFT and GMT).
>> Maybe the real problem is that the focus doesn't fit with EMP?
>>
>>
>>> By talking to our existing user community (see interested party in the
>>> proposal), I believe the workbench as a whole already has a lot of
>>> value.
>>>
>> I'm sure there are a lot of happy users.
>> That's really not the problem.
>> There are also a lot of other MDSD-workbenches with many users out there.
>> And none of them (oAW included ;-)) should become the "Best-Of-Breed
>> Eclipse Modeling Project".
>>
>> kind regards,
>> Sven
>>
>
>
>
--------------000907050702060801050001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eric,<br>
<br>
Comments below.<br>
<br>
Eric Dillon wrote:
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">Ok. It seems to me that we can't just discard users that quickly :-).
The focus of the modeling project is definitely frameworks. I think we may
even all agree that there are a lot of frameworks, and that it is sometimes
difficult to sort your way through them. However, the consumers of the
modeling project - its users - are mainly application developers, able to
assemble the frameworks together into a bigger whole - thus creating value
for end-users that are not interested or able to do so.
</pre>
</blockquote>
I'm always a bit wary of how to carve up reality into different
compartments. Not that it's relevant here, but the whole tools verses
runtimes split often strikes me as totally artificial.<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
As you may have noticed the current user community of Tigerstripe is based
in the Telecom space. These guys are interested in modeling the latest
networking technology, network gear, etc... and in generating specs,
management interfaces, documentation, compliance test kits, and more. Most
of them - if not all of them - have no interest in stitching frameworks
together before they can get started on doing their job. In other words, the
consumers of Tigerstripe - its users - are VERY different from those of the
modeling project.
</pre>
</blockquote>
I'm not exactly sure what you mean by stitching frameworks together
and I'm not sure I understand at all the difference between the
Tigerstripe users base verses the modeling project's user base (as if
we have only one). It seems to me that the proposal presented a broad
MDD vision that's effectively identical to that of the modeling project
but here you suggest that the vision is narrower or the users addressed
by it is more restricted. I'm not sure I understand whether this is a
general MDD vision or an industry vertical version of it.<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
Now, we should also be careful when talking about an integration project for
EMP. What would be its intent? Show how to assemble frameworks? or provide
end-users with complete environment?
</pre>
</blockquote>
It should do all of these things. And many of the end users are likely
building their own frameworks. Many Eclipse projects are using the EMP
infrastructure in order to build their own infrastructure...<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
I think we need to address all user communities. It seems Tigerstripe
addresses a different user community than the modeling project. Our intent
to migrate to EMP components (that's what I called standard components, as
opposed to proprietary one :-)) should also serve the users of the Modeling
project.
</pre>
</blockquote>
I'd like to understand this difference a lot better. The proposal as
it is written isn't entirely clear that the user communities don't
coincide. I think folks like Kenn and others are trying to understand
the distinctions being drawn here is well...<br>
<blockquote cite="mid:fih9os$k3o$1@build.eclipse.org" type="cite">
<pre wrap="">
Eric
"Sven Efftinge" <a class="moz-txt-link-rfc2396E" href="mailto:sven@efftinge.de"><sven@efftinge.de></a> wrote in message
<a class="moz-txt-link-freetext" href="news:fih32c$n57$1@build.eclipse.org">news:fih32c$n57$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi Eric,
</pre>
<blockquote type="cite">
<pre wrap="">So yes, some of the components in Tigerstripe are currently inferior
to the corresponding components from the modeling project.
</pre>
</blockquote>
<pre wrap="">Which are not?
I'm really interested to here about new ideas and technologies regarding
MDSD, but I couldn't see anything like that stated in the proposal.
If there are such things, you may want to come up with a more specific
proposal for that?
</pre>
<blockquote type="cite">
<pre wrap="">Now, as stated in the proposal, we DO INTEND to migrate the non
standards components to the latest stable components from the modeling
project. In fact I am hoping that overtime we can become a model of
use for the Modeling components in complete solution. As we migrate, I
believe we can feed some of our experience to the appropriate modeling
components.
</pre>
</blockquote>
<pre wrap="">Yes, there is a need for such a project within EMP. But who should decide
what components should become part of a best-of-breed modeling
environment?
To be honest, I doubt that you should decide that, because Tigerstripe
seems to be some years behind of what IMHO is state of the art in this
field (sorry, don't take this personally).
IMHO such a project should be driven by the community, at least the
decisions on what is best-of-breed and what's not.
</pre>
<blockquote type="cite">
<pre wrap="">Hopefully, we can use Tigerstripe as the red-thread to assemble all
modeling components in an end-user workbench. Use the current version
as a starting point, and replace internal components one by one to
make it best of breed in the Open, outside of the modeling project for
now until we "ready" to be a proper subproject of the modeling
project.
</pre>
</blockquote>
<pre wrap="">It's a bit strange, that you think incubating in EMT and then moving over
to EMP is a good idea. There are a lot of projects in an incubator phase
at EMP (Have a look at EMFT and GMT).
Maybe the real problem is that the focus doesn't fit with EMP?
</pre>
<blockquote type="cite">
<pre wrap="">By talking to our existing user community (see interested party in the
proposal), I believe the workbench as a whole already has a lot of
value.
</pre>
</blockquote>
<pre wrap="">I'm sure there are a lot of happy users.
That's really not the problem.
There are also a lot of other MDSD-workbenches with many users out there.
And none of them (oAW included ;-)) should become the "Best-Of-Breed
Eclipse Modeling Project".
kind regards,
Sven
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------000907050702060801050001--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Doubts about the project [message #561475 is a reply to message #2265] |
Wed, 28 November 2007 00:07 |
Richard Gronback
Messages: 605
Registered: July 2009 |
Senior Member |
|
|
Just to add my thoughts on this proposal and discussion:
Tigerstripe approached Modeling regarding the contribution of this code,
which Ed and I felt was not a good fit for many of the reasons already
raised here. We suggested Technology as an alternative where they could
incubate, grow a community, and potentially contribute to Modeling in the
future. This would be a challenging path, imho.
That said, I'm not sure I understand the point in contributing something,
refactoring it, and then possibly moving it (in part, or whole).
Personally, I don't think I'd start to use a technology if this were its
plan. I'd instead wait for the dust to settle, and in the meantime use the
pieces of EMP that let me do much of the same things, even if not
well-integrated (which brings me to the real point...).
Perhaps the best outcome of this proposal from the Modeling project's
perspective is that it introduces a competitive spark to help us do what
many of us have wanted to do for some time; that is, take the next step in
the Modeling project's evolution and focus on integrations and usability.
We've already started discussion on a packaging effort, capabilities
definition, etc. To me, the best way to get it done is within the scope of
a new project, which I've drafted a proposal for and hope to send out
shortly.
As for Tigerstripe, while I think the existence of this project will add to
the confusion about modeling solutions at Eclipse, I think the bigger
challenge will be for them to grow the 3 communities while undergoing such
change. My recommendation remains for them to narrow their focus, and even
consider returning to their original vertical-focused, SOA-centric roots.
Otherwise, as always, I welcome their contribution to some of our current
pain points in Modeling.
Best Regards,
Rich
On 11/27/07 4:18 AM, in article l7mnk311q2u2t1ker51atcbfu19njjd4go@4ax.com,
"Eric Dillon" <erdillon@cisco.com> wrote:
> On Tue, 27 Nov 2007 01:30:11 +0000 (UTC), eaw@cisco.com (Ed Warnicke)
> wrote:
>
> Hi all,
>
> thanks for your feedback. I can see where you are coming from and
> being a hardcore eclipse user myself, I fully agree with the need to
> strenghthen the existing components rather than re-inventing the wheel
> and duplicating them.
>
> I like to think of Tigerstripe as an end-user environment or workbench
> for Modeling+Scoping+Generation. We started building the application a
> few years back when some of these components either didn't exist or
> weren't fully stable yet. As a result, we did re-invent the wheel (as
> stated above) as we were working through end-user requirements and
> various issues.
>
> So yes, some of the components in Tigerstripe are currently inferior
> to the corresponding components from the modeling project. Yet, the
> whole is a end-to-end workbench where end-users, i.e. modelers, can
> get their job done.
>
> Now, as stated in the proposal, we DO INTEND to migrate the non
> standards components to the latest stable components from the modeling
> project. In fact I am hoping that overtime we can become a model of
> use for the Modeling components in complete solution. As we migrate, I
> believe we can feed some of our experience to the appropriate modeling
> components.
>
> Hopefully, we can use Tigerstripe as the red-thread to assemble all
> modeling components in an end-user workbench. Use the current version
> as a starting point, and replace internal components one by one to
> make it best of breed in the Open, outside of the modeling project for
> now until we "ready" to be a proper subproject of the modeling
> project.
>
> By talking to our existing user community (see interested party in the
> proposal), I believe the workbench as a whole already has a lot of
> value. Migrating internal components to best of breed in the open
> should only add more value to the Eclipse community as we feed their
> requirements back to the community.
>
> Eric
>
>> Markus Voelter wrote:
>>
>>> Hi,
>>
>>> to get the discussion started: I am very sceptical about
>>> this proposal for the following reasons:
>>
>>> * at its core, the proposed techniques seem to be
>>> inferior to the stuff that's already available at
>>> EMP
>>> * in other areas it seems like a reinvention of the
>>> wheels we already have (UML editor, Code Gen Engine).
>>> We need fewer, better integrated modules, not more!
>> Please note in the proposal, in the scope section, the paragraph which
>> reads:
>>
>> "In addition, we intend to migrate existing parts of the software to the
>> latest frameworks supported by the Modeling top-level project. In
>> particular, we intend to use more of the EMF and UML2 frameworks where
>> applicable to complement the current technology in use, and allow easier
>> model sharing between users."
>>
>> We intend to converge over time. We'd like to do it in the open. That
>> will mean over time
>> incorporating more of the Eclipse Modeling components, as well as feeding
>> contributions
>> back to those components.
>>
>>> * I don't think there's any point of having a modeling
>>> thing outside of EMP. What kind of message would that
>>> send?? If there's a valuable contribution in it, make
>>> it part of modeling. If not, don't put it on Eclipse.
>>
>> Technology provides us with a good place to incubate. If at a later time
>> moving to the Eclipse Modeling Project makes sense to the folks involved,
>> we can do that.
>>
>>> That said, I would *love* to see a workbench-y kind of
>>> thing, that takes all (or most) of the EMP components and
>>> builds a nice workbench around it. That would be an integration
>>> project on top of what we have.
>>
>> Thats kind of where we would like to go. Tigerstripe is, in many ways, a
>> workbench-y thing built on what Modeling had to offer in the past. Gaps
>> that existed then were filled, and some of filling those gaps brought in
>> features and functionality that are not yet be present in the current
>> Modeling components. Current Eclipse Modeling doesn't provide a drop in
>> replacement for what Tigerstripe allows it's current users to do, and
>> Tigerstripe certainly doesn't provide all of the functionality of the
>> Eclipse Modeling Projects with which it overlaps. Working through those
>> issues, while continuing to support Tigerstripe existing user base, is
>> part of what we hope to accomplish.
>>
|
|
|
| Re: Doubts about the project [message #561513 is a reply to message #2446] |
Wed, 28 November 2007 06:41 |
Markus Voelter
Messages: 33
Registered: July 2009 |
Member |
|
|
> Here however, you have suggested that the intended consumers and user
> community of Tigerstripe are fundamentally different from those of
> Modeling, i.e. they are in the Telecom space;
right (a bit like Topcased for the Aerospace world).
So *if* Tigerstripe is a collection of tools tairlored for
domain specific use, this is a different story. But again:
make it clear(er) in the proposal, and integrate EMP
projects.
Markus
if that is the case, perhaps this should be
> made
> more explicit in the proposal, and then this whole issue of overlap with
> the
> Modeling project would be less of a concern...
>
> Ultimately the proposal needs to make clear how the project will benefit
> the
> Eclipse community and what falls inside (and outside) of the scope for
> the
> project.
>
> Kenn
>
> "Eric Dillon" <erdillon@cisco.com> wrote in message
> news:fih9os$k3o$1@build.eclipse.org...
>> Ok. It seems to me that we can't just discard users that quickly :-).
>>
>> The focus of the modeling project is definitely frameworks. I think we
>> may
>> even all agree that there are a lot of frameworks, and that it is
>> sometimes difficult to sort your way through them. However, the
>> consumers
>> of the modeling project - its users - are mainly application developers,
>> able to assemble the frameworks together into a bigger whole - thus
>> creating value for end-users that are not interested or able to do so.
>>
>> As you may have noticed the current user community of Tigerstripe is
>> based
>> in the Telecom space. These guys are interested in modeling the latest
>> networking technology, network gear, etc... and in generating specs,
>> management interfaces, documentation, compliance test kits, and more.
>> Most
>> of them - if not all of them - have no interest in stitching frameworks
>> together before they can get started on doing their job. In other words,
>> the consumers of Tigerstripe - its users - are VERY different from those
>> of the modeling project.
>>
>> Now, we should also be careful when talking about an integration project
>> for EMP. What would be its intent? Show how to assemble frameworks? or
>> provide end-users with complete environment?
>>
>> I think we need to address all user communities. It seems Tigerstripe
>> addresses a different user community than the modeling project. Our
>> intent
>> to migrate to EMP components (that's what I called standard components,
>> as
>> opposed to proprietary one :-)) should also serve the users of the
>> Modeling project.
>>
>> Eric
>>
>>
>> "Sven Efftinge" <sven@efftinge.de> wrote in message
>> news:fih32c$n57$1@build.eclipse.org...
>>> Hi Eric,
>>>
>>>> So yes, some of the components in Tigerstripe are currently inferior
>>>> to the corresponding components from the modeling project.
>>>
>>> Which are not?
>>> I'm really interested to here about new ideas and technologies
>>> regarding
>>> MDSD, but I couldn't see anything like that stated in the proposal.
>>> If there are such things, you may want to come up with a more specific
>>> proposal for that?
>>>
>>>>
>>>> Now, as stated in the proposal, we DO INTEND to migrate the non
>>>> standards components to the latest stable components from the modeling
>>>> project. In fact I am hoping that overtime we can become a model of
>>>> use for the Modeling components in complete solution. As we migrate, I
>>>> believe we can feed some of our experience to the appropriate modeling
>>>> components.
>>>
>>> Yes, there is a need for such a project within EMP. But who should
>>> decide
>>> what components should become part of a best-of-breed modeling
>>> environment?
>>> To be honest, I doubt that you should decide that, because Tigerstripe
>>> seems to be some years behind of what IMHO is state of the art in this
>>> field (sorry, don't take this personally).
>>> IMHO such a project should be driven by the community, at least the
>>> decisions on what is best-of-breed and what's not.
>>>
>>>>
>>>> Hopefully, we can use Tigerstripe as the red-thread to assemble all
>>>> modeling components in an end-user workbench. Use the current version
>>>> as a starting point, and replace internal components one by one to
>>>> make it best of breed in the Open, outside of the modeling project for
>>>> now until we "ready" to be a proper subproject of the modeling
>>>> project.
>>>
>>> It's a bit strange, that you think incubating in EMT and then moving
>>> over
>>> to EMP is a good idea. There are a lot of projects in an incubator
>>> phase
>>> at EMP (Have a look at EMFT and GMT).
>>> Maybe the real problem is that the focus doesn't fit with EMP?
>>>
>>>>
>>>> By talking to our existing user community (see interested party in the
>>>> proposal), I believe the workbench as a whole already has a lot of
>>>> value.
>>>
>>> I'm sure there are a lot of happy users.
>>> That's really not the problem.
>>> There are also a lot of other MDSD-workbenches with many users out
>>> there.
>>> And none of them (oAW included ;-)) should become the "Best-Of-Breed
>>> Eclipse Modeling Project".
>>>
>>> kind regards,
>>> Sven
>>
>>
>
>
--
Markus Völter
voelter - ingenieurbüro für softwaretechnologie
Grabenstrasse 4, 73033 Goeppingen, Germany
Tel. +49 (0) 171 / 86 01 869
Email: voelter@acm.org
Web: http://www.voelter.de
Blog: http://www.voelter.de/blog
Podcast: http://www.se-radio.net
PGP Public Key: http://www.voelter.de/data/MarkusVoelter.gpg
|
|
|
| Re: Doubts about the project [message #561552 is a reply to message #2153] |
Wed, 28 November 2007 10:44 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
Just my 2 cents to this debate.
As an Eclipse user I would really like a well integrated modeling
environment. There is lot of work to do on that side in the modeling
project, but also working together with other Eclipse projects.
For instance the "cartridge" things, by cartridge I mean model two text
transformations from a given type of model to a given set of framework. In
my opinion these cartridges should belong to the corresponding Eclipse
project. For instance if you generate JEE code, then you should be part of
the WTP project, if it's about Service Oriented Architecture, then STP is
here.. Then we can ensure the generated stuffs behave nicely with the
tooling provided with the project. This kind of co-operations is not in the
proposal.
Moreover, my opinion is that this proposal introduces yet another UML model,
yet another UML editor for that model, yet another template engine and all
this duplication is not even providing features we don't already have !
This opinion seems quite shared by the Eclipse commiters, I just wanted to
express the fact that the concerns about this project are pervasive.
Cédric
Markus Voelter wrote:
> Hi,
>
> to get the discussion started: I am very sceptical about
> this proposal for the following reasons:
>
> * at its core, the proposed techniques seem to be
> inferior to the stuff that's already available at
> EMP
> * in other areas it seems like a reinvention of the
> wheels we already have (UML editor, Code Gen Engine).
> We need fewer, better integrated modules, not more!
> * I don't think there's any point of having a modeling
> thing outside of EMP. What kind of message would that
> send?? If there's a valuable contribution in it, make
> it part of modeling. If not, don't put it on Eclipse.
>
> That said, I would *love* to see a workbench-y kind of
> thing, that takes all (or most) of the EMP components and
> builds a nice workbench around it. That would be an integration
> project on top of what we have.
>
> Markus
>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Doubts about the project [message #561592 is a reply to message #4113] |
Wed, 28 November 2007 16:01 |
| Eclipse User |
|
|
|
Originally posted by: dstrombo.cisco.com
I advocate that EF consider Tigerstripe as an extremely positive
contribution to Eclipse.
It's a market-tested modeling tool based on Eclipse with an active user
community among the largest telecommunications companies.
It demonstrates the use of several of the wonderful Eclipse modeling
frameworks.
It has a paradigm of UML2 modeling-to-code generation that is very
powerful.
I personally don't think there is a one-size-fits-all modeling approach,
so I don't understand your concerns about diversity of tooling. I think
the community needs a variety of tools.
I'm concerned that Eclipse appears to be prescriptive in terms of how to
do modeling. Telling a very advanced MDA user that he shouldn't use large
models is inappropriate.
Whether or not it belongs as a part of the core Eclipse Modeling Project
is a judgement call... probably not from your comments. But I'm sure
there are very practical uses of Tigerstripe within the Eclipse community.
Tigerstripe is not a threat to Eclipse Modeling frameworks. It is an
excellent example of how to apply them to real world issues.
I doubt my position will make me very popular. :)
Best Regards,
Doug
|
|
|
| Re: Doubts about the project [message #561614 is a reply to message #4253] |
Wed, 28 November 2007 17:20 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Doug,
Comments below.
Doug Strombom wrote:
> I advocate that EF consider Tigerstripe as an extremely positive
> contribution to Eclipse.
I'm sure it's intended to be a positive contribution and that the
Tigerstripe folks have nothing but good intentions in general.
>
> It's a market-tested modeling tool based on Eclipse with an active
> user community among the largest telecommunications companies.
Eclipse is also a commercial ecosystem so while this comment is great
for folks who like free beer, it's not necessarily so great for folks
selling beer. So in a sense this is both good and bad. Providing
frameworks that commercial vendors can extend to provide value-add is an
important principle at Eclipse.
>
> It demonstrates the use of several of the wonderful Eclipse modeling
> frameworks.
Now we're faltered. Hehehe.
>
> It has a paradigm of UML2 modeling-to-code generation that is very
> powerful.
I guess folks will want to understand how it compares to using UML2 or
Ecore directly with Xpand or JET? I.e., what makes it better? And how
can we reuse what makes it better to make more of the modeling project
infrastructure (for UML2 and Ecore) better?
>
> I personally don't think there is a one-size-fits-all modeling
> approach, so I don't understand your concerns about diversity of tooling.
The concern is about duplication. A great many folks have build
infrastructure that works directly with UML2 models or Ecore models so
they'd like to thing that their technology is applicable in the context
of Tigerstripe so if Tigerstripe is not using the UML2 model directly,
like the answer is it's not directly applicable.
> I think the community needs a variety of tools.
Certainly, but consider something like NetBeans verses Eclipse.
Probably no one needs both. It's more a case of one or the other. And
hence we'd all likely be better off if there weren't Eclipse and
NetBeans but just one that we all worked on together.
> I'm concerned that Eclipse appears to be prescriptive in terms of how
> to do modeling.
I don't think that's the case.
> Telling a very advanced MDA user that he shouldn't use large models is
> inappropriate.
A model will be as large as is required. The suggestion is merely that
it might be easier to maintain a larger number of smaller models than a
small number of large models. I.e., it's likely more conceptually
manageable. But in the end, a model must be as large as is needed to
capture what needs to be captured. Certainly the notion of "facets",
though I'm not quite clear on if that's a language construct of a
filtering in the UI, would be one way to deal with models that become so
large as to become conceptually unmanageable for the user.
> Whether or not it belongs as a part of the core Eclipse Modeling
> Project is a judgement call... probably not from your comments.
Actually, I think most folks will argue that it does belong in the
modeling project and that it should fit in well there. The issue is to
resolve the concerns about how well it fits. Obviously there have been
many concerns expressed about that.
> But I'm sure there are very practical uses of Tigerstripe within the
> Eclipse community.
I'm all in favor of growing the community, but you should take note of
the number of folks involved in the modeling project from various
companies and they don't typically name their community based on what's
currently a commercial brand.
>
> Tigerstripe is not a threat to Eclipse Modeling frameworks.
Unfortunately the fact that it's a brand name, which I know is an issue
you are looking to resolve, gives a threatening appearance.
> It is an excellent example of how to apply them to real world issues.
I'll need to read the proposed rewording of the proposal, but it
juxtapose much of what Tigerstripe is doing, i.e., MDD for the real
world, against precisely what many folks in the modeling project think
they are already doing today...
> I doubt my position will make me very popular. :)
Life's not a popularity contest. I've learned to stop worrying about
that. Speak your mind and who can really fault you for being honest...
>
> Best Regards,
> Doug
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Nov 09 05:09:58 GMT 2024
Powered by FUDForum. Page generated in 0.07335 seconds |
] 
Search
Help
Register
Login
Home
