Hi Patrik,

Thanks for your quick and helpful reply.  I'll respond using the same
numbering:

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.  

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?

3. Can you add some more info about 3a?  It looks like your sentence got
chopped off there with "I don't see"...

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.

Thanks!
--Polly




Patrik Nordwall wrote:
> 
> Hi Polly,
> 
> This is an area that I would very much like to help and improve Sculptor
> as much as possible. It is not very easy to support any type of
> customization without replacing some of the Sculptor jar files. I'm very
> interested in your suggestions and experience of customization.
> 
> Let us talk about a few concrete cases.
> 
> 1. DEFINE blocks in templates (.xpt) are rather easy to replace using AOP
> and separate xpt files. Xpt files are loaded from the classpath and it
> should be possible to assemble these customizations in a separate jar. If
> you have found any DEFINE blocks that should be changed to better support
> customization we would be happy to improve.
> 
> 2. Changes to metamodel. It is loaded from classpath and your changes must
> replace sculptor-metamodel.jar. Any other idea? It is not easy to have
> control of the order of the classpath when using maven. Could we do some
> adjustments to the fornax-oaw-m2-plugin to be able to define the
> dependency and its order. A better alternative might be that you replace
> sculptor-metamodel.jar with your jar (it is possible to exclude dependency
> in maven). 
> 
> 3. Changes to dsl and dsl.editor.
> a) dsl editor Eclipse plugin needs to be exported and installed by your
> developers. I don't see 
> b) dsl jar used by maven in the transformation/generation phase. Same
> issue as metamodel.
> 
> /Patrik
> 
> 
> amphoras wrote:
>> 
>> Hi,
>> 
>> I've been customizing Sculptor for a while now, and I find that it is
>> working well.  So far I've been hacking my changes inside the "dsl",
>> "metadata", and "generator" projects because my changes are more
>> extensive than can be accommodated by AOP.  However, mixing up my code
>> with Sculptor's code does not seem like a great strategy going forward. 
>> I'd prefer to keep Sculptor as is and put all my customizations
>> elsewhere. 
>> 
>> Is it possible to put additional templates in a separate plugin or
>> fragment instead of inside the Sculptor jars?  Some tools offer a
>> template extension point that allows other plugins to contribute
>> templates.  Fragments are targeted at one specific plugin and get merged
>> into that plugin as it is loaded.  Does Sculptor support this?  If not,
>> can I suggest it as a feature and perhaps contribute a patch?  
>> 
>> Thanks,
>> Polly
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-Sculptor--Template-modifications-in-a-separate-plugin-or-fragment--tp18935207s17564p18968357.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

Reply via email to