amphoras wrote: > > 1. Generator project: it sounds like the "generator" project is the easy > one to break up into the original Sculptor jar vs. our template jar, since > the templates are already loaded from the classpath. That is very > interesting. So I think maybe the template extension point idea doesn't > make sense. Because our architecture lead says says that the tool that he > has seen use the template extension point idea is Taylor MDA. He says: > "It defines an extension point allowing any plugin to contribute > templates. The generator plugin then access the templates by iterating > over all of the extensions (local and from other plugins.) In this tool > each and every template had to be called out by name as an extension > point. It was actually kind of unwieldy. I don't recall how the generator > was told which templates to run when." > > It sounds like oAW has already solved the problem with templates much more > elegantly. >
Yes, oAW AOP is great and the way to go for us regarding the templates. Now we also know how to use it for the extension functions, which will be utilized more. We will need to adjust the templates/extensions to improve the possibilities for customization. I would like to take advantage of your needs for doing this. Always better to have concrete examples and requests than trying to guess very to add flexibility. I have created a jira for this: http://www.fornax-platform.org/tracker/browse/CSC-225 I suggest that you do the changes you need to support your customization and send those changes as Eclipse patch files to me. I will review and commit. Alternatively you can become a member of the Sculptor team and commit yourself. I will still review though. amphoras wrote: > > 2. Metamodel project: yeah, this one is much harder to break up. For > example, the changes that I've made to the metamodel project are in-place. > I've simply added a few extra fields here and there to the Ecore diagram, > which generates the additional fields into existing classes. Right now > I'm replacing the sculptor-metamodel jar with my modified one. To create > two separate jars (original Sculptor vs. my changes), maybe I'd have to > use an inheritance relationship or something where we have your original > classes and my subclass that adds the fields. Would something like that > make sense? > Subclassing the metamodel classes is a good idea, that is worth trying. It is possible to create an ecore model that references another, i.e. your metamodel (with the subclasses) can import/reference to sculptor metamodel. We have used that mechanism in the sculptorguimetamodel. Let us know if you don't understand how to do it. If this doesn't work I suggest that you create and maintain your own version of the metamodel. I think you should have another maven artifactId for that and you need to add maven dependency to that and exclude dependency to the original sculptor metamodel. amphoras wrote: > > 3. Can you add some more info about 3a? It looks like your sentence got > chopped off there with "I don't see"... > I think the only way to go with the DSL changes is that you create and maintain your own variant of the dsl modules. Most of it is generated from the xtext grammar file and therefore I don't think it will be a big burden for you to merge future changes. amphoras wrote: > > Let to let you know--I'd like to investigate these ideas with some real > experimentation, but I've just received my updated priorities today.... > Unfortunately I do not have the time to invest in this right now. But > I'll keep this in the back of my mind and think about it. I will also let > you know whenever I come across code that does not lend itself to being > modified via AOP. > OK One more thing, if some of your customizations are improvements that you think are of interest for more people you are welcome to suggest them to be included in the core of Sculptor. /Patrik -- View this message in context: http://www.nabble.com/-Sculptor--Template-modifications-in-a-separate-plugin-or-fragment--tp18935207s17564p18970531.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fornax-developer
