Architecture Rules Forums › architecture-rules-dev

Classcyle

4 messages

Classcyle

Reply Threaded

Have we picked Classcycle as the tool to wrap for class dependencies?
--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

mikenereson

Re: Classcyle

Reply Threaded

Have we picked Classcycle as the tool to wrap for class dependencies?

Currently we are using JDepend to detect cyclic dependencies. JDepend is limited in that it can not detect static dependencies. That is, it only detects dependencies between one Object and another Object. It can not detect dependencies from on Object to a package. I'd like to reimplement the org.architecturerules.api.services.CyclicRedundancyService to use Classcycle in hopes of detecting dependencies that would otherwise have gone undetected with JDepend. Does that answer your question? We don't use Classcylce at all yet. In fact someone will really need to research the tool and ensure that it does actually preform above and beyond the current JDepend dependant implementation.

By the way, since you mentioned wrapping. I don't want to reexport any third party dependencies. So while we're reviewing old code and writing new code, lets keep an eye out for returns and parameters of Objects that are not from the JDK or our on domain when writing new API. This will allow us to change the tools we use and prevent our library from breaking when third parties change their APIs.

~ Mike Nereson

--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

mikenereson

Re: Classcyle

Reply Threaded

And another note in regard to Issue 59: "DependencyConstraintException should report the violating class." We should be able to utilize Classcycle to resolve this issue. I

~ Mike Nereson

On Mon, Sep 1, 2008 at 2:28 PM, Mike Nereson <[hidden email]> wrote:

Have we picked Classcycle as the tool to wrap for class dependencies?

Currently we are using JDepend to detect cyclic dependencies. JDepend is limited in that it can not detect static dependencies. That is, it only detects dependencies between one Object and another Object. It can not detect dependencies from on Object to a package. I'd like to reimplement the org.architecturerules.api.services.CyclicRedundancyService to use Classcycle in hopes of detecting dependencies that would otherwise have gone undetected with JDepend. Does that answer your question? We don't use Classcylce at all yet. In fact someone will really need to research the tool and ensure that it does actually preform above and beyond the current JDepend dependant implementation.

By the way, since you mentioned wrapping. I don't want to reexport any third party dependencies. So while we're reviewing old code and writing new code, lets keep an eye out for returns and parameters of Objects that are not from the JDK or our on domain when writing new API. This will allow us to change the tools we use and prevent our library from breaking when third parties change their APIs.

~ Mike Nereson

Chris Dempsey

Re: Classcyle

Reply Threaded

Yeah. I was looking at that issue and was just making sure Classycle was on the short list of choices so I could spend some time getting familiar with it.

On Mon, Sep 1, 2008 at 1:30 PM, Mike Nereson <[hidden email]> wrote:

And another note in regard to Issue 59: "DependencyConstraintException should report the violating class." We should be able to utilize Classcycle to resolve this issue. I

~ Mike Nereson

On Mon, Sep 1, 2008 at 2:28 PM, Mike Nereson <[hidden email]> wrote:

Have we picked Classcycle as the tool to wrap for class dependencies?

Currently we are using JDepend to detect cyclic dependencies. JDepend is limited in that it can not detect static dependencies. That is, it only detects dependencies between one Object and another Object. It can not detect dependencies from on Object to a package. I'd like to reimplement the org.architecturerules.api.services.CyclicRedundancyService to use Classcycle in hopes of detecting dependencies that would otherwise have gone undetected with JDepend. Does that answer your question? We don't use Classcylce at all yet. In fact someone will really need to research the tool and ensure that it does actually preform above and beyond the current JDepend dependant implementation.

By the way, since you mentioned wrapping. I don't want to reexport any third party dependencies. So while we're reviewing old code and writing new code, lets keep an eye out for returns and parameters of Objects that are not from the JDK or our on domain when writing new API. This will allow us to change the tools we use and prevent our library from breaking when third parties change their APIs.

~ Mike Nereson

--~--~---------~--~----~------------~-------~--~----~
~~ http://architecturerules.googlecode.com/svn/docs/index.html
~~You received this message because you are subscribed to the Google Groups "architecture-rules-dev" group.
~~To post to this group, send email to [hidden email]
~~To unsubscribe from this group, send email to [hidden email]
~~For more options, visit this group at http://groups.google.com/group/architecture-rules-dev?hl=en
-~----------~----~----~----~------~----~------~--~---