Home » Modeling » EMF » EMF Builder
| EMF Builder [message #512505] |
Fri, 05 February 2010 10:05  |
 Hasan Ceylan
Messages: 198
Registered: July 2009 |
Senior Member |
|
|
Hello Eike,
Sure...
But I couldn't have much change with the buckminster.
Therefore, I'll do it blindly...
Would you like this to be fully automatic or a prompt to the user 'The last
build was on XXX version would you like reegenration kind of'?
Also currently the state information of the builder is not persisted in
between the Workbench sessions. I see that this is an issue with teneo where
Martin has 500+ models (uhh), which takes about 40 secs on my laptop to scan
the dependencies, although this does not block as the dependency resolution
happens in the background as a job, it postpones the build process for that
long.
Hasan
Eike Stepper wrote:
> Hi Hasan,
>
> I was just working through my 28 models again and I have a first feature
> reuest for you ;-)
>
> Could you record the EMF version (including qualifier) used for
> generation and trigger a full regeneration if a new version is discovered?
>
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
> Am 01.02.2010 06:59, schrieb Hasan Ceylan:
>> The PDF has been attached...
>>
>>
>>> Hello,
>>>
>>> Attached is the PDF version of the forementioned EMF Build Manager
>>> Project Proposal.
>>>
>>> I kindly ask EMF community members and EMF (and subprojects) committers
>>> to review the document and forward their thoughts.
>>>
>>> I am also looking for mentors for the proposal.
>>>
>>> Below is the extraction of "Background" of the project. Please remember
>>> to review the attached PDF for full proposal draft.
>>>
>>> I apoligize for crossposting...
>>>
>>> ============================================================ =
>>> BACKGROUND
>>>
>>> EMF has been around for a long time. But the fact is that it lacked the
>>> necessary IDE Build Manager integration ever since.
>>> We think, the current code generation and validation toolset is below
>>> eclipse UI quality standards and fell behind similar facility provisions
>>> from the other projects.
>>>
>>> For instance, given the current infrastructure, if a developer is
>>> working with two ecore models that are dependent each other along with
>>> their respective genmodel, when developer makes a change in the base
>>> model that requires a change in the dependent ecore model, will need
>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>> executions along with several clicks to locate the action and run them.
>>>
>>> Also during the generation process, the UI is blocked and having
>>> finished the change on the base ecore, the developer cannot continue
>>> working on the second ecore before the base model generation finishes.
>>> Further more there is also need to switch to genmodels twice and
>>> initiate generation delibarately.
>>>
>>> In addition to this, if developer would like to validate the model in
>>> between the unit of the works, that will require clicks to locate the
>>> validation action, click to run the action and click to dismiss the
>>> feedback.
>>>
>>> It is also in our experience that the genmodel editors are kept open
>>> just for triggering code genration. Furthermore, this not only clutters
>>> the editor folder with unneeded editors, but also breaks the 'editor'
>>> description for genmodel, as usualy once genmodels are set up, they very
>>> seldom change, but needed to be open for code generation.
>>> When used on large workspaces with more than a few model, problem
>>> becomes a real burden.
>>>
>>> This is where EBM steps in and delegates much of the work to background
>>> build manager and prevents user distrubition with using the instruments
>>> like
>>> auto build on resource save, Marker and Problem View instrumentation to
>>> provide feedback.
>>> ============================================================ =
>>>
>>> Regards,
>>>
>>>
>>
|
|
|
| Re: EMF Builder [message #512507 is a reply to message #512505] |
Fri, 05 February 2010 10:15  |
|
Am 05.02.2010 11:05, schrieb Hasan Ceylan:
> Hello Eike,
>
> Sure...
>
> But I couldn't have much change with the buckminster.
> Therefore, I'll do it blindly...
>
Maybe you could "drop-in" an old EMF feature?
> Would you like this to be fully automatic or a prompt to the user 'The last
> build was on XXX version would you like reegenration kind of'?
>
I guess a question dialog for this particular case would be nice.
> Also currently the state information of the builder is not persisted in
> between the Workbench sessions. I see that this is an issue with teneo where
> Martin has 500+ models (uhh), which takes about 40 secs on my laptop to scan
> the dependencies, although this does not block as the dependency resolution
> happens in the background as a job, it postpones the build process for that
> long.
>
Yes, caching the build state between sessions makes sense ;-)
Cheers
/Eike
> Hasan
>
> Eike Stepper wrote:
>
>
>> Hi Hasan,
>>
>> I was just working through my 28 models again and I have a first feature
>> reuest for you ;-)
>>
>> Could you record the EMF version (including qualifier) used for
>> generation and trigger a full regeneration if a new version is discovered?
>>
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>
>> Am 01.02.2010 06:59, schrieb Hasan Ceylan:
>>
>>> The PDF has been attached...
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>> Attached is the PDF version of the forementioned EMF Build Manager
>>>> Project Proposal.
>>>>
>>>> I kindly ask EMF community members and EMF (and subprojects) committers
>>>> to review the document and forward their thoughts.
>>>>
>>>> I am also looking for mentors for the proposal.
>>>>
>>>> Below is the extraction of "Background" of the project. Please remember
>>>> to review the attached PDF for full proposal draft.
>>>>
>>>> I apoligize for crossposting...
>>>>
>>>> ============================================================ =
>>>> BACKGROUND
>>>>
>>>> EMF has been around for a long time. But the fact is that it lacked the
>>>> necessary IDE Build Manager integration ever since.
>>>> We think, the current code generation and validation toolset is below
>>>> eclipse UI quality standards and fell behind similar facility provisions
>>>> from the other projects.
>>>>
>>>> For instance, given the current infrastructure, if a developer is
>>>> working with two ecore models that are dependent each other along with
>>>> their respective genmodel, when developer makes a change in the base
>>>> model that requires a change in the dependent ecore model, will need
>>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>>> executions along with several clicks to locate the action and run them.
>>>>
>>>> Also during the generation process, the UI is blocked and having
>>>> finished the change on the base ecore, the developer cannot continue
>>>> working on the second ecore before the base model generation finishes.
>>>> Further more there is also need to switch to genmodels twice and
>>>> initiate generation delibarately.
>>>>
>>>> In addition to this, if developer would like to validate the model in
>>>> between the unit of the works, that will require clicks to locate the
>>>> validation action, click to run the action and click to dismiss the
>>>> feedback.
>>>>
>>>> It is also in our experience that the genmodel editors are kept open
>>>> just for triggering code genration. Furthermore, this not only clutters
>>>> the editor folder with unneeded editors, but also breaks the 'editor'
>>>> description for genmodel, as usualy once genmodels are set up, they very
>>>> seldom change, but needed to be open for code generation.
>>>> When used on large workspaces with more than a few model, problem
>>>> becomes a real burden.
>>>>
>>>> This is where EBM steps in and delegates much of the work to background
>>>> build manager and prevents user distrubition with using the instruments
>>>> like
>>>> auto build on resource save, Marker and Problem View instrumentation to
>>>> provide feedback.
>>>> ============================================================ =
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF Builder [message #512544 is a reply to message #512507] |
Fri, 05 February 2010 12:41 |
Hasan Ceylan
Messages: 198
Registered: July 2009 |
Senior Member |
|
|
Hello Eike,
Of what plugin(s ?) should I check the version change?
Hasan
Eike Stepper wrote:
> Am 05.02.2010 11:05, schrieb Hasan Ceylan:
>> Hello Eike,
>>
>> Sure...
>>
>> But I couldn't have much change with the buckminster.
>> Therefore, I'll do it blindly...
>>
> Maybe you could "drop-in" an old EMF feature?
>
>> Would you like this to be fully automatic or a prompt to the user 'The
>> last build was on XXX version would you like reegenration kind of'?
>>
> I guess a question dialog for this particular case would be nice.
>
>> Also currently the state information of the builder is not persisted in
>> between the Workbench sessions. I see that this is an issue with teneo
>> where Martin has 500+ models (uhh), which takes about 40 secs on my
>> laptop to scan the dependencies, although this does not block as the
>> dependency resolution happens in the background as a job, it postpones
>> the build process for that long.
>>
> Yes, caching the build state between sessions makes sense ;-)
>
> Cheers
> /Eike
>
>
>> Hasan
>>
>> Eike Stepper wrote:
>>
>>
>>> Hi Hasan,
>>>
>>> I was just working through my 28 models again and I have a first feature
>>> reuest for you ;-)
>>>
>>> Could you record the EMF version (including qualifier) used for
>>> generation and trigger a full regeneration if a new version is
>>> discovered?
>>>
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>>
>>> Am 01.02.2010 06:59, schrieb Hasan Ceylan:
>>>
>>>> The PDF has been attached...
>>>>
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> Attached is the PDF version of the forementioned EMF Build Manager
>>>>> Project Proposal.
>>>>>
>>>>> I kindly ask EMF community members and EMF (and subprojects)
>>>>> committers to review the document and forward their thoughts.
>>>>>
>>>>> I am also looking for mentors for the proposal.
>>>>>
>>>>> Below is the extraction of "Background" of the project. Please
>>>>> remember to review the attached PDF for full proposal draft.
>>>>>
>>>>> I apoligize for crossposting...
>>>>>
>>>>> ============================================================ =
>>>>> BACKGROUND
>>>>>
>>>>> EMF has been around for a long time. But the fact is that it lacked
>>>>> the necessary IDE Build Manager integration ever since.
>>>>> We think, the current code generation and validation toolset is below
>>>>> eclipse UI quality standards and fell behind similar facility
>>>>> provisions from the other projects.
>>>>>
>>>>> For instance, given the current infrastructure, if a developer is
>>>>> working with two ecore models that are dependent each other along with
>>>>> their respective genmodel, when developer makes a change in the base
>>>>> model that requires a change in the dependent ecore model, will need
>>>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>>>> executions along with several clicks to locate the action and run
>>>>> them.
>>>>>
>>>>> Also during the generation process, the UI is blocked and having
>>>>> finished the change on the base ecore, the developer cannot continue
>>>>> working on the second ecore before the base model generation finishes.
>>>>> Further more there is also need to switch to genmodels twice and
>>>>> initiate generation delibarately.
>>>>>
>>>>> In addition to this, if developer would like to validate the model in
>>>>> between the unit of the works, that will require clicks to locate the
>>>>> validation action, click to run the action and click to dismiss the
>>>>> feedback.
>>>>>
>>>>> It is also in our experience that the genmodel editors are kept open
>>>>> just for triggering code genration. Furthermore, this not only
>>>>> clutters the editor folder with unneeded editors, but also breaks the
>>>>> 'editor' description for genmodel, as usualy once genmodels are set
>>>>> up, they very seldom change, but needed to be open for code
>>>>> generation. When used on large workspaces with more than a few model,
>>>>> problem becomes a real burden.
>>>>>
>>>>> This is where EBM steps in and delegates much of the work to
>>>>> background build manager and prevents user distrubition with using the
>>>>> instruments like
>>>>> auto build on resource save, Marker and Problem View instrumentation
>>>>> to provide feedback.
>>>>> ============================================================ =
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>
>>
--
Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647
From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."
--
|
|
|
| Re: EMF Builder [message #512551 is a reply to message #512544] |
Fri, 05 February 2010 08:16 |
|
Am 05.02.2010 13:41, schrieb Hasan Ceylan:
> Hello Eike,
>
> Of what plugin(s ?) should I check the version change?
>
Hmm, I think what really makes the difference is the content of the
templates. That would make org.eclipse.emf.codegen.ecore a good choice.
Cheers
/Eike
> Hasan
>
> Eike Stepper wrote:
>
>
>> Am 05.02.2010 11:05, schrieb Hasan Ceylan:
>>
>>> Hello Eike,
>>>
>>> Sure...
>>>
>>> But I couldn't have much change with the buckminster.
>>> Therefore, I'll do it blindly...
>>>
>>>
>> Maybe you could "drop-in" an old EMF feature?
>>
>>
>>> Would you like this to be fully automatic or a prompt to the user 'The
>>> last build was on XXX version would you like reegenration kind of'?
>>>
>>>
>> I guess a question dialog for this particular case would be nice.
>>
>>
>>> Also currently the state information of the builder is not persisted in
>>> between the Workbench sessions. I see that this is an issue with teneo
>>> where Martin has 500+ models (uhh), which takes about 40 secs on my
>>> laptop to scan the dependencies, although this does not block as the
>>> dependency resolution happens in the background as a job, it postpones
>>> the build process for that long.
>>>
>>>
>> Yes, caching the build state between sessions makes sense ;-)
>>
>> Cheers
>> /Eike
>>
>>
>>
>>> Hasan
>>>
>>> Eike Stepper wrote:
>>>
>>>
>>>
>>>> Hi Hasan,
>>>>
>>>> I was just working through my 28 models again and I have a first feature
>>>> reuest for you ;-)
>>>>
>>>> Could you record the EMF version (including qualifier) used for
>>>> generation and trigger a full regeneration if a new version is
>>>> discovered?
>>>>
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>>
>>>> Am 01.02.2010 06:59, schrieb Hasan Ceylan:
>>>>
>>>>
>>>>> The PDF has been attached...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Attached is the PDF version of the forementioned EMF Build Manager
>>>>>> Project Proposal.
>>>>>>
>>>>>> I kindly ask EMF community members and EMF (and subprojects)
>>>>>> committers to review the document and forward their thoughts.
>>>>>>
>>>>>> I am also looking for mentors for the proposal.
>>>>>>
>>>>>> Below is the extraction of "Background" of the project. Please
>>>>>> remember to review the attached PDF for full proposal draft.
>>>>>>
>>>>>> I apoligize for crossposting...
>>>>>>
>>>>>> ============================================================ =
>>>>>> BACKGROUND
>>>>>>
>>>>>> EMF has been around for a long time. But the fact is that it lacked
>>>>>> the necessary IDE Build Manager integration ever since.
>>>>>> We think, the current code generation and validation toolset is below
>>>>>> eclipse UI quality standards and fell behind similar facility
>>>>>> provisions from the other projects.
>>>>>>
>>>>>> For instance, given the current infrastructure, if a developer is
>>>>>> working with two ecore models that are dependent each other along with
>>>>>> their respective genmodel, when developer makes a change in the base
>>>>>> model that requires a change in the dependent ecore model, will need
>>>>>> quite a lot of clicks and at least 4 editor switches, 2 actions
>>>>>> executions along with several clicks to locate the action and run
>>>>>> them.
>>>>>>
>>>>>> Also during the generation process, the UI is blocked and having
>>>>>> finished the change on the base ecore, the developer cannot continue
>>>>>> working on the second ecore before the base model generation finishes.
>>>>>> Further more there is also need to switch to genmodels twice and
>>>>>> initiate generation delibarately.
>>>>>>
>>>>>> In addition to this, if developer would like to validate the model in
>>>>>> between the unit of the works, that will require clicks to locate the
>>>>>> validation action, click to run the action and click to dismiss the
>>>>>> feedback.
>>>>>>
>>>>>> It is also in our experience that the genmodel editors are kept open
>>>>>> just for triggering code genration. Furthermore, this not only
>>>>>> clutters the editor folder with unneeded editors, but also breaks the
>>>>>> 'editor' description for genmodel, as usualy once genmodels are set
>>>>>> up, they very seldom change, but needed to be open for code
>>>>>> generation. When used on large workspaces with more than a few model,
>>>>>> problem becomes a real burden.
>>>>>>
>>>>>> This is where EBM steps in and delegates much of the work to
>>>>>> background build manager and prevents user distrubition with using the
>>>>>> instruments like
>>>>>> auto build on resource save, Marker and Problem View instrumentation
>>>>>> to provide feedback.
>>>>>> ============================================================ =
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: EMF Builder [message #512559 is a reply to message #512551] |
Fri, 05 February 2010 13:37 |
Hasan Ceylan
Messages: 198
Registered: July 2009 |
Senior Member |
|
|
Same logic here...
While awaiting for your answer, I picked that to start with.
I implemented it with an array of bundle names though.. So could be ecore +
codegen...
ecore might be important for validation...
If a model cannot pass the validation, it is not generated...
Eike Stepper wrote:
> Am 05.02.2010 13:41, schrieb Hasan Ceylan:
>> Hello Eike,
>>
>> Of what plugin(s ?) should I check the version change?
>>
> Hmm, I think what really makes the difference is the content of the
> templates. That would make org.eclipse.emf.codegen.ecore a good choice.
>
> Cheers
> /Eike
>
>
>> Hasan
>>
>> Eike Stepper wrote:
>>
>>
>>> Am 05.02.2010 11:05, schrieb Hasan Ceylan:
>>>
>>>> Hello Eike,
>>>>
>>>> Sure...
>>>>
>>>> But I couldn't have much change with the buckminster.
>>>> Therefore, I'll do it blindly...
>>>>
>>>>
>>> Maybe you could "drop-in" an old EMF feature?
>>>
>>>
>>>> Would you like this to be fully automatic or a prompt to the user 'The
>>>> last build was on XXX version would you like reegenration kind of'?
>>>>
>>>>
>>> I guess a question dialog for this particular case would be nice.
>>>
>>>
>>>> Also currently the state information of the builder is not persisted in
>>>> between the Workbench sessions. I see that this is an issue with teneo
>>>> where Martin has 500+ models (uhh), which takes about 40 secs on my
>>>> laptop to scan the dependencies, although this does not block as the
>>>> dependency resolution happens in the background as a job, it postpones
>>>> the build process for that long.
>>>>
>>>>
>>> Yes, caching the build state between sessions makes sense ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>>> Hasan
>>>>
>>>> Eike Stepper wrote:
>>>>
>>>>
>>>>
>>>>> Hi Hasan,
>>>>>
>>>>> I was just working through my 28 models again and I have a first
>>>>> feature reuest for you ;-)
>>>>>
>>>>> Could you record the EMF version (including qualifier) used for
>>>>> generation and trigger a full regeneration if a new version is
>>>>> discovered?
>>>>>
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 01.02.2010 06:59, schrieb Hasan Ceylan:
>>>>>
>>>>>
>>>>>> The PDF has been attached...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Attached is the PDF version of the forementioned EMF Build Manager
>>>>>>> Project Proposal.
>>>>>>>
>>>>>>> I kindly ask EMF community members and EMF (and subprojects)
>>>>>>> committers to review the document and forward their thoughts.
>>>>>>>
>>>>>>> I am also looking for mentors for the proposal.
>>>>>>>
>>>>>>> Below is the extraction of "Background" of the project. Please
>>>>>>> remember to review the attached PDF for full proposal draft.
>>>>>>>
>>>>>>> I apoligize for crossposting...
>>>>>>>
>>>>>>> ============================================================ =
>>>>>>> BACKGROUND
>>>>>>>
>>>>>>> EMF has been around for a long time. But the fact is that it lacked
>>>>>>> the necessary IDE Build Manager integration ever since.
>>>>>>> We think, the current code generation and validation toolset is
>>>>>>> below eclipse UI quality standards and fell behind similar facility
>>>>>>> provisions from the other projects.
>>>>>>>
>>>>>>> For instance, given the current infrastructure, if a developer is
>>>>>>> working with two ecore models that are dependent each other along
>>>>>>> with their respective genmodel, when developer makes a change in the
>>>>>>> base model that requires a change in the dependent ecore model, will
>>>>>>> need quite a lot of clicks and at least 4 editor switches, 2 actions
>>>>>>> executions along with several clicks to locate the action and run
>>>>>>> them.
>>>>>>>
>>>>>>> Also during the generation process, the UI is blocked and having
>>>>>>> finished the change on the base ecore, the developer cannot continue
>>>>>>> working on the second ecore before the base model generation
>>>>>>> finishes. Further more there is also need to switch to genmodels
>>>>>>> twice and initiate generation delibarately.
>>>>>>>
>>>>>>> In addition to this, if developer would like to validate the model
>>>>>>> in between the unit of the works, that will require clicks to locate
>>>>>>> the validation action, click to run the action and click to dismiss
>>>>>>> the feedback.
>>>>>>>
>>>>>>> It is also in our experience that the genmodel editors are kept open
>>>>>>> just for triggering code genration. Furthermore, this not only
>>>>>>> clutters the editor folder with unneeded editors, but also breaks
>>>>>>> the 'editor' description for genmodel, as usualy once genmodels are
>>>>>>> set up, they very seldom change, but needed to be open for code
>>>>>>> generation. When used on large workspaces with more than a few
>>>>>>> model, problem becomes a real burden.
>>>>>>>
>>>>>>> This is where EBM steps in and delegates much of the work to
>>>>>>> background build manager and prevents user distrubition with using
>>>>>>> the instruments like
>>>>>>> auto build on resource save, Marker and Problem View instrumentation
>>>>>>> to provide feedback.
>>>>>>> ============================================================ =
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
--
Hasan Ceylan
hceylan@batoo.org
+90 (532) 713-5384
+90 (216) 332-5647
From Thomas Gray's poem, Ode on a Distant Prospect of Eton College (1742):
"Where ignorance is bliss, 'tis folly to be wise."
--
|
|
|
Goto Forum:
Current Time: Thu May 09 19:50:59 GMT 2024
Powered by FUDForum. Page generated in 0.03955 seconds |
] 
Search
Help
Register
Login
Home
