sorry, I accidentally sent that last email before finished. I'll create an issue and attach a demo project.
We can carry on discussions from there. Thanks Bob On 18 December 2014 at 21:44, Bob Tarling <bob.tarl...@gmail.com> wrote: > > Hi Thomas > > Looks good from within the same package. > > Can this be adapted to create the dependencies across package? > > I can't currently see what is preventing this. > > Bob > > On 18 December 2014 at 20:37, Thomas Neustupny <th...@gmx.de> wrote: >> >> Hi Bob, hi Tom, >> >> thanks for sharing the knowledge about these tools, there're for sure >> worth a look when cyclic dependencies need to be analyzed. >> >> To answer your question, Bob: The parser will only create a dependency if >> there is still none for the given client/supplier combination, or, if a >> stereotype name is provided, if there is no such dependency with that >> stereotype name. See the implementation of the private buildDependency(...) >> method in the Modeller class. >> >> Regards, >> Thomas >> >> >> Gesendet: Donnerstag, 18. Dezember 2014 um 20:25 Uhr >> Von: "Bob Tarling" <bob.tarl...@gmail.com> >> An: dev@argouml.tigris.org >> Betreff: Re: [argouml-dev] Some observations on java reverse engineering >> >> Cool, thanks Tom. >> IntelliJ may be the direction for us at work some time soon anyway, I'll >> start of looking at classcycle for now though.. >> I'd still like to tackle this for Argo as well, I'll go take a look at >> Thomas's work as soon as I can. >> >> Cheers >> >> Bob >> >> >> On 18 December 2014 at 18:38, Tom Morris <tfmor...@gmail.com> wrote: >> >> On Thu, Dec 18, 2014 at 5:29 AM, Bob Tarling <bob.tarl...@gmail.com[ >> bob.tarl...@gmail.com]> wrote: >> >> 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. >> >> The tool I used to do this analysis for ArgoUML itself (although we never >> tackled removing the package cycles) was Classycle: >> http://classycle.sourceforge.net/[http://classycle.sourceforge.net/] It >> is available as an Eclipse plugin as well as standalone tool. One nice >> addition since the last time I used it is support for Dependency Definition >> Files. This allows you to describe allowable dependencies (e.g. your >> architectural layers) and it will check for violations. >> http://classycle.sourceforge.net/ddf.html[http://classycle.sourceforge.net/ddf.html] >> Looking at >> http://argouml.tigris.org/source/browse/argouml/trunk/tools/classycle/[http://argouml.tigris.org/source/browse/argouml/trunk/tools/classycle/] >> it looks like it's been 7-8 years since I used it for ArgoUML. >> >> IntelliJ's dependency analysis looks pretty powerful too (although I >> haven't used it): >> https://www.jetbrains.com/idea/features/dependency_analysis.html[https://www.jetbrains.com/idea/features/dependency_analysis.html] >> >> While adding dependencies to the Java reverse engineering may be useful >> for other stuff, it's not how I'd recommend finding package cycles. A tool >> designed for that purpose will do a better job. >> >> Tom >> >> >> >> ------------------------------------------------------ >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3093000 >> >> To unsubscribe from this discussion, e-mail: [ >> dev-unsubscr...@argouml.tigris.org]. >> To be allowed to post to the list contact the mailing list moderator, >> email: [li...@tigris.org] >> > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3093004 To unsubscribe from this discussion, e-mail: [dev-unsubscr...@argouml.tigris.org]. To be allowed to post to the list contact the mailing list moderator, email: [li...@tigris.org]
