Community
Participate
Working Groups
Created attachment 172415 [details] Diagram Hi Guys, I was thinking last night about dependencies in Tigerstripe and why you needed to list all dependencies (including transitive ones) for generation to work properly... So.. with attached diagram... (and this will be the same with projects or modules I think) Without EhasD Module E will insist on Module C and B being in dependencies. This is because of the superclass hierarchy. (enforced by JDT) Adding EhasD will ‘need’ Module D listed as a dependency... but doesn’t insist that module A is added.... However generation of Module E will not work correctly if getOtherEnd() is needed.... What do we do about this? Steve
Steve? What is the status on this? I seem to remember you said this was triggered by something else and wasn't really a problem. If so, let's close this. Eric
There is something unstated going on here... "you needed to list all dependencies (including transitive ones) for generation to work properly" I don't think its a surprsise that you need all dependencies present for generation to work (by definition you are dependant on them). Is this just an issue when doing headless generation, that the headless build does not "assemble" the dependencies in the same way that you would normally have already done in your workspace? I don't think this would be an issue with Modules (provided that they are installed in the eclipse being used). I thnk we really need a much clearer statement of what the issue is, before we can start on this one.
I have recreated the example model in workspace projects. NOTE THAT my model "E" does not have a dependency on model "A" I created a test plugin that had a rule for the association that looks like this : $artifact.getAEnd() $artifact.getAEnd().getType().getName() $artifact.getAEnd().getOtherEnd().getType().getName() $artifact.getAEnd().getOtherEnd().getType().getArtifact().getExtendedArtifact().getName() And I got the following output org.eclipse.tigerstripe.workbench.internal.core.model.AssociationEnd@1d53ecf ClassE ClassD ClassA So I think this is the expected behaviour. (Now I will try with a few "modules" instead of local projects.
So I made Projects A B C and D into modules, and closed the local projects. The generation was still correct. So I don;t know what the issue is here. I can only guess that when doing a headless build, the requirted projects are not being correctly walked to get get their dependencies. But that is a guess, and without an example I will have to close this as "works for me"
No further information forthcoming, so I'm closing this.
Created attachment 178343 [details] Demonstate transitive dep issue.
See attachment. Hopefully a simple demonstration of the issue ... which occurs in multiple situations.
Re-assigning to Richard with the additional details.
I checked out these models as per the attachment.... The list of Enum Artifacts that is in the pdf includes (amongst others): AlarmSeverityEnum BusinessLifeCycleStateEnum These are not in the project, or the referneced module, but come from a modeul refernced by teh modeul (ie a transitive dependency) This would appear to be what you are asking for.....so I am closing this again.
