Brilliant, thanks Thomas I'll take a look as soon as I can. My end goal is actually to determine package dependencies. I have a large application that I'm sure has cyclic dependencies between packages and I'd like to demonstrate that problem to the team I work with before we tackle how to resolve it and split the app to smaller jars.
With class dependencies in place I should be able to use that info to build the package dependencies. I'll do that work and provide it on top of your own. Going back to my previous comments.... Personally I'd like to see the creation of Components as being a checkbox option, for me that is a lot of extra elemernts that I don't see as useful in my model Others may view my new requirements similarly, they may prefer to have creation of dependencies turned off so this could also be a checkbox. A question - do you always create a dependency even if some other relationship already exists such as an association? Again for me personally I would only consider adding a dependency of no other relationship exists - this could be an option if others don't share my view. Cheers Bob On 17 December 2014 at 22:14, Thomas Neustupny <[email protected]> wrote: > > Hi Bob, > > here is a first attempt. First, a method call has to be added in the > parser java.g, here: > > localVariableDeclaration > : variableModifiers t=type > { > // simple dependency algorithm: if t is found in the model, > // then build a dependency, otherwise ignore > if (parserMode == MODE_IMPORT_PASS2) { > getModeller().addClassifierDependency(t); > } > } > variableDeclarators["", (short)0, null] > ; > > Then, the method in Modeller.java has to be added, here is a first working > version: > > /** > * Called from the parser to add a dependency to a classifier. > * > * @param name The name of the classifier candidate. > */ > void addClassifierDependency(String name) { > String classifierName = stripVarargAndGenerics(name); > Object clientObj = parseState.getClassifier(); > if (clientObj == null) { > return; > } > Object supplierObj = null; > > // first try: lookup classifierName in same namespace > Object ns = Model.getFacade().getNamespace(clientObj); > if (ns != null) { > supplierObj = Model.getFacade().lookupIn(ns, classifierName); > } > > // second try: lookup in imports > if (supplierObj == null) { > String packageName = getPackageName(name); > // ... > } > > // third try: resolve fully qualified classifier (xxx.yyy.Zzz) > String packageName = getPackageName(name); > if (supplierObj == null && packageName.length() > 0) { > classifierName = this.getClassifierName(name); > // ... > } > > // finally build the dependency > if (supplierObj != null) { > buildDependency(supplierObj, clientObj, null); > } > } > > I've committed it to the Java module code, feel free to test&experiment. > Your example already works with that provided both classes are in the same > package. > > Regards, > Thomas > > > Gesendet: Montag, 15. Dezember 2014 um 21:32 Uhr > Von: "Thomas Neustupny" <[email protected]> > An: [email protected] > Betreff: Aw: [argouml-dev] Some observations on java reverse engineering > [Sorry for accidently sending in hmtl format, I'm resending it in plain > text format] > > > Hi Bob, > > this is no malfunction, just a missing feature. The method bodies are > completely parsed, but the information in there is not used yet. I want > this feature, too, and can assist. I've just set up my dev environment > (eclipse Luna, Java 1.8, it works well so far). > > The component is not generated for each class, but for each compilation > unit (.java file), because a file can host more than one class. Also, the > imports do not belong to the class, but to the component instance for > obvious reasons. It's a great feature (not by me, I forgot who deserves > the honor for that!). > > I suggest to identify the lines in java.g, where the type identifier for > the associated class/interface can be found and discuss how to process > them. The parser has two passes, so we could search the already identified > types from the first pass during the second phase. > > Regards, > Thomas > > > 14 um 18:07 Uhr<br/> > <b>Von:</b> "Bob Tarling" <[email protected] > ><br/> > <b>An:</b> [email protected]<br/> > <b>Betreff:</b> [argouml-dev] Some observations on java reverse > engineering</div> > > <div name="quoted-content"> > <div> > <div>I'm trying to generate some diagrams from an existing code base > at work and I see some issues with the model generated.<br/> > </div> > A simple example is this. > > <div><br/> > public class UseTestUtil {<br/> > <br/> > private void test() {<br/> > TestUtil tu = new TestUtil();<br/> > tu.test();<br/> > }<br/> > }<br/> > </div> > > <div>I'd expect to see a dependency relationship from UseTestUtil to > TestUtil but nothing is generated. Is there some complication with our > parser not being able to manage this or is this just an outstanding > enhancement.<br/> > </div> > > <div>I also notice a component eing generated for every class. WHy is > this?<br/> > </div> > > <div>Regards<br/> > </div> > > <div>Bob<br/> > </div> > > <div><br/> > </div> > </div> > </div> > </div> > </div> > </div></div></body></html> > > ------------------------------------------------------ > > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3092752 > > To unsubscribe from this discussion, e-mail: [ > [email protected]]. > To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] > > ------------------------------------------------------ > > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3092754[http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3092754] > > To unsubscribe from this discussion, e-mail: [ > [email protected]]. > To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] > > ------------------------------------------------------ > > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3092933 > > To unsubscribe from this discussion, e-mail: [ > [email protected]]. > To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3092964 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
