Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » Re: Doubts about the project
Re: Doubts about the project [message #602393] Wed, 28 November 2007 00:07
Richard Gronback is currently offline 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.
>>
Previous Topic:Ecore mapping of xsd:restriction
Next Topic:Re: Doubts about the project
Goto Forum:
  


Current Time: Thu Oct 30 15:11:33 GMT 2014

Powered by FUDForum. Page generated in 0.03496 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software