Hi Patrik,
Thank you for helping me look into this. I really appreciate you fixing the
NullPointerException, because I was not about to figure that one out, and it
was giving me problems in my experiments.
After much banging on this, I am still not able to get the nested design
files to import. I keep getting weird Ambiguous exception something or
other. However, I did hack a solution to the other problem about keeping
the "common" objects separate. I dislike hacks a lot, but I have a
deadline, and it's more urgent that I separate out the "common" objects.
Maybe you'd be interested in helping me clean up the solution. :)
Here's what I did to keep the "common" objects separate:
1. In the metamodel, I added a new List to Application to keep track of
other Applications that the main one is "using".
2. In the xtxt definition, I added a keyword "use" like this:
DslUse :
'use' model=URI;
3. In common.model, my "main-model.design" actually imports
"a-model.design" and "b-model.design", but since I was not able to get
nested imports to work, my "app" design file says:
use
"platform:/resource/com.foo.common.model/src/main/resources/main-model.design"
use
"platform:/resource/com.foo.common.model/src/main/resources/a-model.design"
use
"platform:/resource/com.foo.common.model/src/main/resources/b-model.design"
This is annoying but will have to do for now. Since "use" really works the
same as "import" under the covers in GenExtensions.ext, the DSL editor is
able to resolve the objects with no problems.
4. Then in the transformation, I really wanted to make it so that I could
load "main-model.design" as an Application and load the other two as Modules
inside that Application, because the Application defines the basePackage.
However, try as I might, I could not get the syntax right. So In the
DslTransformation, I copied the syntax for "import":
create sculptormetamodel::Application this transform(DslModel dslModel) :
...
uses.addAll(dslModel.uses.model().typeSelect(DslModel).transform());
5. This transformation makes it so that Module "a" and "b" are floating
about and not related to their Application defined in "main-design". So I
hacked it by making these modules define their own "basePackage".
6. My "common" objects use a different "domain package" property than my
"app" objects, so then I had to change
GenerationHelper.getDomainPackage(Module). I hard-coded the logic so that
if the Module is "external", then just use its basePackage as is (without
adding the domain package property). Obviously this is not always a valid
assumption but works for now.
7. To figure out if the Module is "external" is a hack. Since the Module's
Application is not being populated correctly, it is null. However, the
eContainer() method returns an Application. So I test to see if the Module
has two nested eContainers. Having an eContainer.eContainer means that its
parent is an Application inside of another Application.
Whew! After all that, I was able to test. And it does work. :D The
"common" classes are not generated inside my project, and my classes have
the correct package imports for all references. Yay! I like having a
different place inside the metamodel to hold the external objects because
there's no need to tag them and no need to complicate the templates with
code to ignore them. However, it would be really nice to:
* figure out how to load Module "a" and "b" into their Application so I can
remove all the hard-coding around package names.
* figure out the syntax for nested imports in Extensions.ext (so we can
duplicate it for this external import usage too).
If you have any insights or inspiration, please let me know. I'd greatly
appreciate it.
Thanks!
--Polly
Patrik Nordwall wrote:
>
> I have tried this and I think we are on the right track.
> I found a bug in the DslTransformation which caused the NPE in circular
> dependency check. Fixed in trunk.
>
> The suggested solution from oawforum is difficult to follow and it
> actually doesn't solve the cyclic imports problem. I will post something
> there.
>
> One way, which also has the cyclic imports problem, is to overwrite the
> model() function.
>
> List[emf::EObject] model(DslImport this) :
> let loaded = model==null?{}:model.load().flatten() :
> let loaded2 = loaded.typeSelect(DslModel).imports.model().flatten() :
> loaded.union(loaded2);
>
> We don't allow cyclic dependencies between Modules (imports) anyway, but
> it would be nice to avoid this problem, since it might cause an infinite
> loop.
>
> You are right that we can add another import keyword to load project
> external models ("common") and mark those with a flag that we propagate
> through the transformation all the way to Module so we can skip those
> modules in the generation phase.
>
> /Patrik
>
>
>
--
View this message in context:
http://www.nabble.com/-Sculptor--importing-nested-design-files-tp20269181s17564p20277451.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
