Home » Modeling » M2T (model-to-text transformation) » AMP Proposal, Potential XPAND ui collaborations
| AMP Proposal, Potential XPAND ui collaborations [message #59159] |
Thu, 02 April 2009 20:39  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi all,
Just wanted to ask the XPAND team (and anyone else) to take a quick
look at the project proposal for and Agent Modeling Platform:
http://eclipse.org/proposals/amp
Ed Merks and Sven Efftinge have graciously agreed to mentor.
The reason I bring it up here is that I was just going through some
work in preperation for a release of MetaABM (one of the proposed AMP
donor components) and I realized that there might be some pieces that
fit into or at least provide some inspiration for M2T / MWE effort.
I've posted a reply over on MWE and am waiting to hear back, but I'm
actually not sure which it would fall under. There are a few pieces
here.
1. Eclipse logging and marker support for XPand generation and checks
-- could be made to work for arbitrary workflows. Markers are
integrated with EMF editor, so if a check fails, it shows up in problem
view and you can double-click to get to problem EObject. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=269992 for a more
detailed description.
2. Generalized builders and handlers for model instance / workflow
combos. (See above bug response.)
3. A bunch of JUnit testing support for generating XPand to Java (could
obviously be expanded to non-Java targets) against models using above
builders, checking that the .java generation and compilation occurs
properly, and running actual tests against the generated code. This one
would need a bit more work to be useful outside current context.
I think some of this might have already been accomplished -- I rolled
it all quite a while ago and haven't seen a need to replace it -- but
let me know if anything looks promising / useful. In all cases they
would need to be generalized.
Its already quite simple to setup a new target template / model type
instance, but one thing I'd really like to have offered at some point
is a set of extension points so that plugin developers can easily
integrate arbitrary XPand generation and other workflows. Has anyone
given any thought to this? The plumbing can be supported by above.
Ideally the modeler could provide an XPand template reference, an EMF
model extension an ID and optionaly an icon, and the plugin would make
available at runtime a builder, a "Generate:" menu item. But it might
be more appropriate to keep this more modular.
thanks,
Miles
|
|
|
| Re: AMP Proposal, Potential XPAND ui collaborations [message #59356 is a reply to message #59159] |
Tue, 07 April 2009 08:45  |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Hi Miles,
Miles Parker schrieb:
> 1. Eclipse logging and marker support for XPand generation and checks --
> could be made to work for arbitrary workflows. Markers are integrated
> with EMF editor, so if a check fails, it shows up in problem view and
> you can double-click to get to problem EObject. See
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269992 for a more detailed
> description.
We usually have the validation in the editor.
For generation I'ld prefer to have hyperlinks in the console which
navigate to/ open up the repsective EObject.
This is because the workflow engine so far is a runtime thing (no UI
dependency).
I think what you describe is not so much MWE or Xpand related, but could
be generalized so that we have a common builder, which listenes on model
changes and passes the loaded model into "something".
This something could than be an EValidator (but I still would like to
have this in the editor ;-)) a generator, transformation or a complete
workflow. The interface should just be something like
void doStuff(IResource res, Resource emfResource)
I would like to see soemthing like that in Xtext, so that code
generation takes place when you save a file.
> 2. Generalized builders and handlers for model instance / workflow
> combos. (See above bug response.)
Yes, that's how I understood the bug. :-)
>
> 3. A bunch of JUnit testing support for generating XPand to Java (could
> obviously be expanded to non-Java targets) against models using above
> builders, checking that the .java generation and compilation occurs
> properly, and running actual tests against the generated code. This one
> would need a bit more work to be useful outside current context.
I don't think I got it.
What exactly are you testing here?
Cheers,
Sven
|
|
|
| Re: AMP Proposal, Potential XPAND ui collaborations [message #59381 is a reply to message #59356] |
Tue, 07 April 2009 16:24 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
On 2009-04-07 01:45:22 -0700, Sven Efftinge <sven.efftinge@itemis.de> said:
> Hi Miles,
>
> Miles Parker schrieb:
>> 1. Eclipse logging and marker support for XPand generation and checks
>> -- could be made to work for arbitrary workflows. Markers are
>> integrated with EMF editor, so if a check fails, it shows up in problem
>> view and you can double-click to get to problem EObject. See
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269992 for a more
>> detailed description.
>
> We usually have the validation in the editor.
> For generation I'ld prefer to have hyperlinks in the console which
> navigate to/ open up the repsective EObject.
>
> This is because the workflow engine so far is a runtime thing (no UI
> dependency).
>
> I think what you describe is not so much MWE or Xpand related, but
> could be generalized so that we have a common builder, which listenes
> on model changes and passes the loaded model into "something".
That's exactly right. So really its a kind of xpand.ui. The problems
view approach is really nice because it puts all of the issues in the
same place. i.e. all other build related issues go there. So case goes
like a) user saves b) user is notified that some check fails (or just
logged warning) c) editor gets marker and when user navigates to
problem view and double-clicks, that opens the EMF editor to the
respective EObject.
> This something could than be an EValidator (but I still would like to
> have this in the editor ;-)) a generator, transformation or a complete
> workflow. The interface should just be something like
Yes, but validator also creates problem view entries, but these entries
work for the hierarchical editor.
>
> void doStuff(IResource res, Resource emfResource)
Yes, again that's right. Except that you could define the res (workflow
file) at design time as part of an extension point and/or as a simple
builder implementation with just the workflow id.
>
> I would like to see soemthing like that in Xtext, so that code
> generation takes place when you save a file.
Yeah -- I have that working actually! In fact, I have a setup where the
user saves the xText, an Ecore model is created, and the the java code
is generated from that - smpletely seemless form the user point of
view. This is actually pretty easy because I've defined a builder for
the ecore file. So when you save the xtext file, that saves the
transformed ecore model, which triggeres the xpand build, which
triggers the java build.. Isn't Eclipse great?
>> 2. Generalized builders and handlers for model instance / workflow
>> combos. (See above bug response.)
>
> Yes, that's how I understood the bug. :-)
Good, from the response I got I wasn't sure.
>> 3. A bunch of JUnit testing support for generating XPand to Java (could
>> obviously be expanded to non-Java targets) against models using above
>> builders, checking that the .java generation and compilation occurs
>> properly, and running actual tests against the generated code. This one
>> would need a bit more work to be useful outside current context.
>
> I don't think I got it.
> What exactly are you testing here?
OK, this one was a bit more exploratory and I'm not sure how well it
can be generalized. The basic issue is that developers really need to
test that there *generated* artifacts actually work as intended. So we
need to generate the code and then run the tests against it to make
sure that our *tempaltes* as well as the target API are working
correctly. (I think that EMF does this but I haven't looked at it
closely.)
You have to have a model that is XPand'ing to some sort of Java class
artifact to begin with. And unless / until there is some sort of
generalization for that it really isn't broadly useful. But in the
case of the Agent Modeling stuff I *do* have a fairly general purpose
meta-model -- like ecore -- and all of the scaffolding to generate Java
classes against various apis. So what I'm doing is
a) Remove all generated java and class files from test project.
b) Generate code as normal, but adding @Test , etc..
Developers of models for XPand tests can then insert Java asserts into
code using the meta-model facilities for that, or use protected regions
within the generated code. (Both aproaches have value for testability.)
c) check that the new java code and classes actually *were* generated
and no errors occurred.
d) Then execute the test suties against the newly created unit tests.
This actually isn't trivial, especially because JUnit is so brain-dead.
because JUnit wants you to specify actual .class at design time, if you
don't "pre-generate" the classes, then you can't launch the tests that
depend on them -- and this creates a bootstrapping and dependency
problem. I'd like to use TestNG for this because it is much nicer at
handling all of this, but its looking like that will not fit in with
current Eclipse build process.
But again, I don't think process can really be generalized that well..
|
|
|
| Re: AMP Proposal, Potential XPAND ui collaborations [message #59406 is a reply to message #59381] |
Wed, 08 April 2009 15:22 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Miles Parker schrieb:
>
> Yes, but validator also creates problem view entries, but these entries
> work for the hierarchical editor.
You mean you want to be able to add markers to the resource, right?
That would be straightforward as long as you get the corresponding
resource passed in.
>>
>> void doStuff(IResource res, Resource emfResource)
>
> Yes, again that's right. Except that you could define the res (workflow
> file) at design time as part of an extension point and/or as a simple
> builder implementation with just the workflow id.
I'ld like to have the primary hook MWE independent.
We could of course have MWE adapters, which allow to declare a workflow
file in the extensions file.
>> I would like to see soemthing like that in Xtext, so that code
>> generation takes place when you save a file.
>
> Yeah -- I have that working actually! In fact, I have a setup where the
> user saves the xText, an Ecore model is created, and the the java code
> is generated from that - smpletely seemless form the user point of view.
> This is actually pretty easy because I've defined a builder for the
> ecore file. So when you save the xtext file, that saves the transformed
> ecore model, which triggeres the xpand build, which triggers the java
> build.. Isn't Eclipse great?
This definitely makes sense for fast running generators.
Yes, Eclipse is great :-)
>>> 3. A bunch of JUnit testing support for generating XPand to Java
>>> (could obviously be expanded to non-Java targets) against models
>>> using above builders, checking that the .java generation and
>>> compilation occurs properly, and running actual tests against the
>>> generated code. This one would need a bit more work to be useful
>>> outside current context.
>>
>> I don't think I got it.
>> What exactly are you testing here?
>
> OK, this one was a bit more exploratory and I'm not sure how well it can
> be generalized. The basic issue is that developers really need to test
> that there *generated* artifacts actually work as intended. So we need
> to generate the code and then run the tests against it to make sure that
> our *tempaltes* as well as the target API are working correctly. (I
> think that EMF does this but I haven't looked at it closely.)
>
> You have to have a model that is XPand'ing to some sort of Java class
> artifact to begin with. And unless / until there is some sort of
> generalization for that it really isn't broadly useful. But in the case
> of the Agent Modeling stuff I *do* have a fairly general purpose
> meta-model -- like ecore -- and all of the scaffolding to generate Java
> classes against various apis. So what I'm doing is
>
> a) Remove all generated java and class files from test project.
> b) Generate code as normal, but adding @Test , etc..
> Developers of models for XPand tests can then insert Java asserts
> into code using the meta-model facilities for that, or use protected
> regions within the generated code. (Both aproaches have value for
> testability.)
> c) check that the new java code and classes actually *were* generated
> and no errors occurred.
> d) Then execute the test suties against the newly created unit tests.
>
> This actually isn't trivial, especially because JUnit is so brain-dead.
> because JUnit wants you to specify actual .class at design time, if you
> don't "pre-generate" the classes, then you can't launch the tests that
> depend on them -- and this creates a bootstrapping and dependency
> problem. I'd like to use TestNG for this because it is much nicer at
> handling all of this, but its looking like that will not fit in with
> current Eclipse build process.
>
> But again, I don't think process can really be generalized that well..
>
Ok, I got it and agree that it might not be generalizable that well (or
might not be that helpful in other contexts)
Cheers,
Sven
|
|
|
| Re: AMP Proposal, Potential XPAND ui collaborations [message #59457 is a reply to message #59406] |
Wed, 08 April 2009 20:18 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
On 2009-04-08 08:22:04 -0700, Sven Efftinge <sven.efftinge@itemis.de> said:
You mean you want to be able to add markers to the resource, right?
> That would be straightforward as long as you get the corresponding
> resource passed in.
Yep, and this marker support works now..as I mentioned in the bug you
just need to make a small modification to the generated Ecore editor.
>>> void doStuff(IResource res, Resource emfResource)
>>
>> Yes, again that's right. Except that you could define the res (workflow
>> file) at design time as part of an extension point and/or as a simple
>> builder implementation with just the workflow id.
>
> I'ld like to have the primary hook MWE independent.
> We could of course have MWE adapters, which allow to declare a workflow
> file in the extensions file.
Hmmm..how would the build be triggered otherwise? I agree that it
shouldn't be part of MWE if that's what you mean.
In any case, this fuctionality will at the very least be in AMP because
I need it -- so if you don't have a more immediate need, I'll try to
generalize it somewhat and then you guys can let me know if you want to
factor into one of the other components. I hate duplicated effort :) so
if anyone is headed down this road get in touch with me please.
>
>>> I would like to see soemthing like that in Xtext, so that code
>>> generation takes place when you save a file.
>>
>> Yeah -- I have that working actually! In fact, I have a setup where the
>> user saves the xText, an Ecore model is created, and the the java code
>> is generated from that - smpletely seemless form the user point of
>> view. This is actually pretty easy because I've defined a builder for
>> the ecore file. So when you save the xtext file, that saves the
>> transformed ecore model, which triggeres the xpand build, which
>> triggers the java build.. Isn't Eclipse great?
>
> This definitely makes sense for fast running generators.
Yeah, its actually well within a lot of typical use cases, and I think
this kind of seemelsss intergration that it is the way that people
should begin to think about usages for their tools. Yes there is a
place for generaating lot's of customizable framework code ala EMF, but
also for complete round-trip real-time support for end-user oriented
tools. ABM being a perfect example of that letter. For my XPand
templates based on experimentation, some performance tips from Karsten,
and improvements you've all made thorugh oAW 4.3.1 I'm currently
building 20,000-30,000 lines of (mostly biolerplate, e.g. getters and
setters, but a lot of text) in under 15 seconds on my dual xeon mac.
And it works unobstrusivly on my old MacBook Pro as well.
[Testing]
> Ok, I got it and agree that it might not be generalizable that well (or
> might not be that helpful in other contexts)
Agreed..if anyone comes across this thread and wants further
information, please ask.
Miles
|
|
|
| Re: AMP Proposal, Potential XPAND ui collaborations [message #59481 is a reply to message #59356] |
Thu, 09 April 2009 19:26 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
btw, this might be a bit clearer in a screencast I've just uploaded..see:
http://metascapeabm.com/presentations/MetaABMModelDemo.mov
The problem view stuff is a little over 2/3 of the way through.
On 2009-04-07 01:45:22 -0700, Sven Efftinge <sven.efftinge@itemis.de> said:
> Hi Miles,
>
> Miles Parker schrieb:
>> 1. Eclipse logging and marker support for XPand generation and checks
>> -- could be made to work for arbitrary workflows. Markers are
>> integrated with EMF editor, so if a check fails, it shows up in problem
>> view and you can double-click to get to problem EObject. See
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=269992 for a more
>> detailed description.
>
> We usually have the validation in the editor.
> For generation I'ld prefer to have hyperlinks in the console which
> navigate to/ open up the repsective EObject.
>
> This is because the workflow engine so far is a runtime thing (no UI
> dependency).
>
> I think what you describe is not so much MWE or Xpand related, but
> could be generalized so that we have a common builder, which listenes
> on model changes and passes the loaded model into "something".
> This something could than be an EValidator (but I still would like to
> have this in the editor ;-)) a generator, transformation or a complete
> workflow. The interface should just be something like
>
> void doStuff(IResource res, Resource emfResource)
>
> I would like to see soemthing like that in Xtext, so that code
> generation takes place when you save a file.
>
>
>> 2. Generalized builders and handlers for model instance / workflow
>> combos. (See above bug response.)
>
> Yes, that's how I understood the bug. :-)
>
>>
>> 3. A bunch of JUnit testing support for generating XPand to Java (could
>> obviously be expanded to non-Java targets) against models using above
>> builders, checking that the .java generation and compilation occurs
>> properly, and running actual tests against the generated code. This one
>> would need a bit more work to be useful outside current context.
>
> I don't think I got it.
> What exactly are you testing here?
>
> Cheers,
> Sven
|
|
|
Goto Forum:
Current Time: Sat Apr 20 04:17:29 GMT 2024
Powered by FUDForum. Page generated in 0.03645 seconds |
] 
Search
Help
Register
Login
Home
