[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [pmf-dev] Basic rules of PMF and eclipse talks

>I don't see any significant problem with hosting the Wazaabi technology in PMF.   If the transformation engine turns out to be generally useful, it can be moved to M2M later.
Neither do I. Before your joining this discussion, we have made such arrangement with Olivier.

 

Best regards

Yves YANG

From: pmf-dev-bounces@xxxxxxxxxxx [mailto:pmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
Sent: Friday, December 18, 2009 2:35 PM
To: PMF Development team
Cc: 'Kenn Hussey'
Subject: Re: [pmf-dev] Basic rules of PMF and eclipse talks

 

Comments below.

yves (yingmin) yang wrote:

ED,
 
  
I've always imagined and expected PMF to be an umbrella project to explore
    
interesting UI modeling technologies.
 
It is what I'm doing exactly. I think the situation is clear for everyone
that PMF should be in neutral position regarding all runtime engines.

I'm still not sure what exactly a runtime engine is nor is it clear to me why PMF should be neutral.  I expect a strong focus on Eclipse but not to the exclusion anything else.

 As you
said, each technology engine should stay in their category such M2M, M2T,
and "the specialized uses of these types of things" (for me, it is the same
as "integration with PMF") is part of PMF. 
  

M2M is certainly for general model transformation, but if there's transformation technology specifically focused on UI models, that should be fine to exist in PMF.

 
I declare here: I don't exclude one or some technologies. I exclude NONE
from PMF Project. Or I exclude EVERYONE (including me) from the PMF Core.
For two reasons,
  1. It is the key to make this project successful, Otherwise, PMF will
become a battle field of all technologies. 
  

My sense is that the declaration not to be a battle field is what's making it a battle field.

     I met already this situation during the project preparation phase.
  2. It is defined in the project scope.
     If we need to extend the cope to bundle other technologies, I think we
should follow the eclipse project rule by passing "project review". 
  

I really don't think anyone is going to complain about scope encroachment within the modeling project.  I'd only be concerned about encroaching on the scope of other top level projects not within modeling.

 
I think there is only a hosting problem of the technologies, which are not
yet part of either M2T or M2T. Can PMF host them? Or can we incubate them?
  

So are you suggesting that some parts of Wazaabi are really a general purpose model-to-model transformation technology?  One might argue that EMF Tiger should have been in M2M but much of what's in M2M is focused on transforming one model into another, not on transforming/modifying a existing instance. 

 
The hosting means, they can stay in the PMF, but it is not part of the PMF
core. It is no need to pass by "project review".
 
The incubation is different, they have to pass by PMC. 
  

I don't see any significant problem with hosting the Wazaabi technology in PMF.   If the transformation engine turns out to be generally useful, it can be moved to M2M later.

 
Best regards
Yves YANG
-----Original Message-----
From: pmf-dev-bounces@xxxxxxxxxxx [mailto:pmf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ed Merks
Sent: Friday, December 18, 2009 12:14 PM
To: Hallvard Trætteberg
Cc: PMF Development team; 'Kenn Hussey'
Subject: Re: [pmf-dev] Basic rules of PMF and eclipse talks
 
Guys,
 
What Hallvard describes seems pretty simple. I've always imagined and 
expected PMF to be an umbrella project to explore interesting UI 
modeling technologies.  I'm not happy seeing arguments about excluding 
specific things that appear highly relevant and useful and also don't 
appear to have an obvious home elsewhere in the modeling stack.   If 
folks have difficulty collaborating I'm inclined to partition the 
project to make room for different approaches so I'd suggest focusing on 
finding a way to be inclusive rather than finding reasons to exclude 
interesting technologies.
 
Regards,
Ed
 
 
Hallvard Trætteberg wrote:
  
yves (yingmin) yang wrote:
    
I'm having a hard time following this conversation.  It's sounding 
like some technology Olivier says is needed to provide a complete 
solution is being excluded from the scope of PMF.  I'm not sure 
exactly what's being excluded or why though.  Certainly a general 
purpose template engine should be part of M2T and a general purpose 
transformation engine should be part of M2M, but specialized uses of 
these types of things I would expect to be part of PMF.
        
Yes, it is what I called “integration part”.
      
I don't know the details of this myself, but here's how I understand it:
- Olivier wants to contribute Wazaabi, since it is a good example of a 
model-based UI runtime and clearly relevant in an M2M approach 
(whether live or batch-oriented).
- Yves argues for excluding Wazaabi, since it is a runtime target and 
not the kind of higher-level model that PMF is meant to be.
- In between there is what Yves calls "integration part", which 
provides the necessary integration between PMF and a runtime target.
- There are three questions for which a "yes" means including Wazaabi 
in PMF: 1) Wazaabi is not a runtime target, but a higher-level model 
(at least high enough). 2) Can Wazaabi be considered integration 
between PMF and the targets Wazaabi supports (SWT, JSF, ...). If yes, 
it's should be part of PMF. 3) If Wazaabi is a runtime target it could 
still be part of PMF, if it demonstrates a particularly interesting case.
 
I'm not sure about question 1, since Wazaabi is lower-level than PMF 
(in my understanding). On the other hand, I would answer "yes" for 
both the other two questions.
 
Hallvard
 
 
    
*From:* Ed Merks [mailto:ed.merks@xxxxxxxxx]
*Sent:* Thursday, December 17, 2009 12:00 PM
*To:* yves (yingmin) yang
*Cc:* 'PMF Development team'; 'Kenn Hussey'
*Subject:* Re: [pmf-dev] Basic rules of PMF and eclipse talks
 
Guys,
 
I'm having a hard time following this conversation.  It's sounding 
like some technology Olivier says is needed to provide a complete 
solution is being excluded from the scope of PMF.  I'm not sure 
exactly what's being excluded or why though.  Certainly a general 
purpose template engine should be part of M2T and a general purpose 
transformation engine should be part of M2M, but specialized uses of 
these types of things I would expect to be part of PMF.
 
What exactly is a runtime engine and why would they be excluded given 
that they appear to be an integral part of an end-to-end solution? If 
they're out of the scope of PMF which project would the fall into the 
scope of?  I imagine a dynamic two way mapping between a rendering 
technology and the model of what's to be rendered will be an 
important part of certain types of solutions.
 
 
Cheers,
Ed
 
 
yves (yingmin) yang wrote:
 
 >Please, let me bring addition (compatible with contribution in 
several points) :
Welcome!
 
 
 >PMF stands for Presentation Modeling Framework and, in my opinion, 
a modeling framework contains metamodels, documentation, conventions 
AND tools.
 
 
Exactly
 
 
 >Obviously, PMF must be vendor or platform agnostic.
 
 
I don’t know this religious word. If you mean, vendor or platform 
independent, it is exactly what I proposed. 
 
 
 >For this reason, I believe that the purpose of PMF is to provide, 
at least, abstract metamodels whose concrete metamodel could easily 
inherits.
 >An obvious (and easy) way to verify the indépendance of an abstract 
metamodel is just trying to inherit from it. If it is not possible, 
that means that the metamodel is simply not abstract :-) .
 
 
Absolutely abstract doesn’t make sense for me. Some classes may be 
concrete, which can be inherited.
 
 
 
Of course, the extensibility is one of the mandatory criteria of the 
design.
 
 
 >Regarding the content of PMF bundle, you are making a difference 
between model transformation mechanisms.
 >Code generation is a way to achieve a such transformation, 
rendering (live transformation) is another one.
 >Why excluding one and keeping another ?
I cannot capture your purpose.
 
 
 
One important point is that PMF can be tested and demonstrated using 
some “non polemic” solutions such as Java, SWT/JFace, e4 workbench, 
Jet for the public demonstration. Each technology can do it-self in 
its integration activities or events.  If you think some elements I 
have listed may rise a polemic, we can discuss.
 
 
 
If you try limit by category, you can say SWT is UI solution.
 
 
 >Here is what I propose (according to our Eclipse Summit meeting) :
 >PMF
 > +Core Abstract Metamodels (org.eclipse.pmf.model.core.xxx)
 >    + Concrete Metamodels (org.eclipse.pmf.model.xxx)
 > + SILOS
 >    + templates
 >    + integration
 >    + tools
 >    + etc, ....
I cannot get your purpose here.
 
 
 >I propose also that all of this works could be hosted in our CVS 
and of course provided as update site and/or downloadable matter.
I cannot answer this question, I think PMC must be involved.
 
 
 
Anyway, all runtime engines outside the lists of PMF standard 
components cannot pretend to be part of PMF.
 
 
 >Last point, I spent lot of time chatting with Jim. He's 
experiencing email problems, everything will be fixed tomorrow.
 
 
Thanks for this information.
 
 
 
Best regards
 
Yves YANG
      
Regards,
 
Olivier Moïses
        
 
 
 
 
 
 
*From:* pmf-dev-bounces@xxxxxxxxxxx 
<mailto:pmf-dev-bounces@xxxxxxxxxxx> 
[mailto:pmf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Olivier Moïses
*Sent:* Monday, December 14, 2009 10:20 PM
*To:* PMF Development team
*Cc:* Ed Merks; Kenn Hussey
*Subject:* Re: [pmf-dev] Basic rules of PMF and eclipse talks
 
 
 
Hi Yves,
 
Thanks for this.
 
Please, let me bring addition (compatible with contribution in 
several points) :
 
PMF stands for Presentation Modeling Framework and, in my opinion, a 
modeling framework contains metamodels, documentation, conventions 
AND tools.
 
Obviously, PMF must be vendor or platform agnostic.
For this reason, I believe that the purpose of PMF is to provide, at 
least, abstract metamodels whose concrete metamodel could easily 
inherits.
An obvious (and easy) way to verify the indépendance of an abstract 
metamodel is just trying to inherit from it. If it is not possible, 
that means that the metamodel is simply not abstract :-) .
 
Regarding the content of PMF bundle, you are making a difference 
between model transformation mechanisms.
 
Code generation is a way to achieve a such transformation, rendering 
(live transformation) is another one.
 
Why excluding one and keeping another ?
 
Here is what I propose (according to our Eclipse Summit meeting) :
 
PMF
 +Core Abstract Metamodels (org.eclipse.pmf.model.core.xxx)
    + Concrete Metamodels (org.eclipse.pmf.model.xxx)
 + SILOS
    + templates
    + integration
    + tools
    + etc, ....
 
I propose also that all of this works could be hosted in our CVS and 
of course provided as update site and/or downloadable matter.
 
Last point, I spent lot of time chatting with Jim. He's experiencing 
email problems, everything will be fixed tomorrow.
 
Regards,
 
Olivier Moïses
 
 
 
 
2009/12/12 yves (yingmin) yang <yves.yang@xxxxxxxxxxx 
<mailto:yves.yang@xxxxxxxxxxx>>
 
Hi All,
 
 
 
Recently, I have noticed there is some confusions in terms of Project 
content and how to contribute this project. It is important to make 
it clear before going forward since it is the key of success.
 
 
 
Here are mainly three questions:
 
 
 
1.       What will the content be in PMF’s bundle?
 
2.       How to contribute this project and promote each specific 
solution?
 
3.       Public  events
 
 
 
Please feel free to add other questions. I remind you our goal is to 
guarantee PMF to be really successful.
 
 
 
Here is my proposal. 
 
 
1.       What ‘s the content in PMF’s bundle ?
 
 
 
This question is more relative to the scope of this project. Here is 
my understanding about the content and scope. PMF may interconnect 
with several components in eclipse such as UI engine, M2M, M2T, 
Visual development tools, etc. Through the initial proposal of this 
project, PMF should not contains any specific runtimes of the 
existing engines. It provides the common infrastructure to connect 
them. PMF should keep a neutral position regarding all other solutions.
 
 
 
As for the bundle of the Project, I think there will be one PMF core 
feature and a list of integration bundles (but not runtime engines). 
The integration plugins are the plugins of the connection of PMF core 
with a specific technology.
 
 
 
2.       How to contribute this project and how promote each specific 
solution?
 
 
 
The success of Open source project relies on the contribution of the 
community. We should create a positive environment to enable everyone 
contribute on this project, and in the same time, the project should 
promote and help as much as possible the contributors to develop 
his/her business. There are several possibilities:
 
-          Create a web page in PMF project home about “Integrated 
Solutions”
 
This page may contain more detail integrations of each components. 
And they should be classified in categories: UI, Code transformation, 
Visual Tools,
 
-          Embed the integration bundles for each technology in the 
offline zip file or update site
 
-          List the existing integrations during the project talk
 
-          Etc..
 
 
 
3.        Public  events
 
Following the same principle, in each public event like EclipseCon, 
ESE, EclipseDay, CodeCamp, one project talk should be submitted. This 
talk deals with only project core issues. If we need to make a 
demonstration, we should use a neutral solutions (i.e, eclipse 
standard project, which doesn’t rise any polemic). For example:
 
      UI -> SWT/JFace
 
      Template -> JET
 
or with the agreement of all others. This talk is open for all 
committers to be a speaker.
 
 
 
Please feel free to make your proposal.
 
 
 
Best regards
 
Yves YANG
 
 
 
 
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx <mailto:pmf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/pmf-dev
 
 
 
Internal Virus Database is out of date.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 
08/16/09 06:09:00
 
Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 
08/16/09 06:09:00
 
 
------------------------------------------------------------------------
 
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev
      
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev
Internal Virus Database is out of date.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 08/16/09
06:09:00
 
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev
  

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 08/16/09 06:09:00