Home » Eclipse Projects » Technology Project and PMC » [ANN] metrics plugin updated and moved to a new home
| [ANN] metrics plugin updated and moved to a new home [message #39752] |
Fri, 27 December 2002 23:09  |
 Frank Sauer
Messages: 36
Registered: July 2009 |
Member |
|
|
A new release (1.0.1) is now available at the following location:
http://www.sourceforge.net/projects/metrics
This version uses the jdt.core.dom AST mechanism to actually parse the
compilation units in order to calculate more complex metrics such as the
McCabe cyclomatic complexity, also known as V(G). This also allowed
for a more meaningful count of blocks; it now measures maximum nested block
depth for each method, instead of simply all blocks.
As a side effect of the above, lines of code now counts comments *within*
method bodies. I have not found an easy way to strip those, since the AST's
MethodDeclaration does not expose the real source, only source without
linebreaks and the offset/length for the entire method body. I now use the
latter
to calculate the number of lines.
Because using the ASTs slowed the calculations down a lot, the values are
now
stored as persistent properties on the underlying resource and are only
recalculated when either the resource was changed since the last
calculation,
or a new version of the metrics plugin was installed (which could contain
new metrics
not currently cached)
Using this has not changed; simply open the properties for a project,
package root,
package fragment or compilation unit and look at the Metrics page.
Please let me know if you find any problems, or want to suggest other
metrics
to calculate. I'm thinking about how to make the metrics pluggable using the
standard extension mechanism.
Enjoy,
Frank Sauer
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #40001 is a reply to message #39752] |
Mon, 30 December 2002 18:08  |
Max Rydahl Andersen
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
It seems like the metrics are not calculated recursively for e.g. an
package.
While running it on cirrus.hibernate package in Hibernate it reported
the project only contained 21 classes, and that is definitely not true :)
Is that expected behavior ?
/max
"Frank Sauer" <sauerf@yahoo.com> wrote in message
news:auim5e$e49$1@rogue.oti.com...
> A new release (1.0.1) is now available at the following location:
>
> http://www.sourceforge.net/projects/metrics
>
> This version uses the jdt.core.dom AST mechanism to actually parse the
> compilation units in order to calculate more complex metrics such as the
> McCabe cyclomatic complexity, also known as V(G). This also allowed
> for a more meaningful count of blocks; it now measures maximum nested
block
> depth for each method, instead of simply all blocks.
>
> As a side effect of the above, lines of code now counts comments *within*
> method bodies. I have not found an easy way to strip those, since the
AST's
> MethodDeclaration does not expose the real source, only source without
> linebreaks and the offset/length for the entire method body. I now use the
> latter
> to calculate the number of lines.
>
> Because using the ASTs slowed the calculations down a lot, the values are
> now
> stored as persistent properties on the underlying resource and are only
> recalculated when either the resource was changed since the last
> calculation,
> or a new version of the metrics plugin was installed (which could contain
> new metrics
> not currently cached)
>
> Using this has not changed; simply open the properties for a project,
> package root,
> package fragment or compilation unit and look at the Metrics page.
>
> Please let me know if you find any problems, or want to suggest other
> metrics
> to calculate. I'm thinking about how to make the metrics pluggable using
the
> standard extension mechanism.
>
> Enjoy,
>
> Frank Sauer
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #40125 is a reply to message #40001] |
Mon, 30 December 2002 19:55 |
Frank Sauer
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
I'll look into that. It should.
I was under the impression that an IPackageFragment only contained
ICompilationUnits,
not nested package fragments (since they are flattened out by Eclipse) but
perhaps I'm wrong here.
So far I've seen only correct class counts. Did you try a source folder
(IPackageFragmentRoot) or
an entire project?
"Max Rydahl Andersen" <max@eos.dk> wrote in message
news:auq1de$v0i$1@rogue.oti.com...
>
> It seems like the metrics are not calculated recursively for e.g. an
> package.
> While running it on cirrus.hibernate package in Hibernate it reported
> the project only contained 21 classes, and that is definitely not true :)
> Is that expected behavior ?
>
> /max
>
> "Frank Sauer" <sauerf@yahoo.com> wrote in message
> news:auim5e$e49$1@rogue.oti.com...
> > A new release (1.0.1) is now available at the following location:
> >
> > http://www.sourceforge.net/projects/metrics
> >
> > This version uses the jdt.core.dom AST mechanism to actually parse the
> > compilation units in order to calculate more complex metrics such as the
> > McCabe cyclomatic complexity, also known as V(G). This also allowed
> > for a more meaningful count of blocks; it now measures maximum nested
> block
> > depth for each method, instead of simply all blocks.
> >
> > As a side effect of the above, lines of code now counts comments
*within*
> > method bodies. I have not found an easy way to strip those, since the
> AST's
> > MethodDeclaration does not expose the real source, only source without
> > linebreaks and the offset/length for the entire method body. I now use
the
> > latter
> > to calculate the number of lines.
> >
> > Because using the ASTs slowed the calculations down a lot, the values
are
> > now
> > stored as persistent properties on the underlying resource and are only
> > recalculated when either the resource was changed since the last
> > calculation,
> > or a new version of the metrics plugin was installed (which could
contain
> > new metrics
> > not currently cached)
> >
> > Using this has not changed; simply open the properties for a project,
> > package root,
> > package fragment or compilation unit and look at the Metrics page.
> >
> > Please let me know if you find any problems, or want to suggest other
> > metrics
> > to calculate. I'm thinking about how to make the metrics pluggable using
> the
> > standard extension mechanism.
> >
> > Enjoy,
> >
> > Frank Sauer
> >
> >
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #40423 is a reply to message #40125] |
Wed, 01 January 2003 19:25 |
Max Rydahl Andersen
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
> I'll look into that. It should.
> I was under the impression that an IPackageFragment only contained
> ICompilationUnits,
> not nested package fragments (since they are flattened out by Eclipse) but
> perhaps I'm wrong here.
> So far I've seen only correct class counts. Did you try a source folder
> (IPackageFragmentRoot) or
> an entire project?
I've got hibernate loaded (hibernate.sf.net) as an project and select the
cirrus.hibernate package and it shows a class count 21.
If I then choose cirrus.hibernate.map (a sub-package) then the class count
is 27 - how can that be ?
(I would expect that cirrus.hibernate also included (at least as an option)
the totals of cirrus.hibernate.map and other sub-packages)
Notice that im looking at the package explorer with layout set to
hiearichial, instead of just flatten.
/max
> "Max Rydahl Andersen" <max@eos.dk> wrote in message
> news:auq1de$v0i$1@rogue.oti.com...
> >
> > It seems like the metrics are not calculated recursively for e.g. an
> > package.
> > While running it on cirrus.hibernate package in Hibernate it reported
> > the project only contained 21 classes, and that is definitely not true
:)
> > Is that expected behavior ?
> >
> > /max
> >
> > "Frank Sauer" <sauerf@yahoo.com> wrote in message
> > news:auim5e$e49$1@rogue.oti.com...
> > > A new release (1.0.1) is now available at the following location:
> > >
> > > http://www.sourceforge.net/projects/metrics
> > >
> > > This version uses the jdt.core.dom AST mechanism to actually parse the
> > > compilation units in order to calculate more complex metrics such as
the
> > > McCabe cyclomatic complexity, also known as V(G). This also allowed
> > > for a more meaningful count of blocks; it now measures maximum nested
> > block
> > > depth for each method, instead of simply all blocks.
> > >
> > > As a side effect of the above, lines of code now counts comments
> *within*
> > > method bodies. I have not found an easy way to strip those, since the
> > AST's
> > > MethodDeclaration does not expose the real source, only source without
> > > linebreaks and the offset/length for the entire method body. I now use
> the
> > > latter
> > > to calculate the number of lines.
> > >
> > > Because using the ASTs slowed the calculations down a lot, the values
> are
> > > now
> > > stored as persistent properties on the underlying resource and are
only
> > > recalculated when either the resource was changed since the last
> > > calculation,
> > > or a new version of the metrics plugin was installed (which could
> contain
> > > new metrics
> > > not currently cached)
> > >
> > > Using this has not changed; simply open the properties for a project,
> > > package root,
> > > package fragment or compilation unit and look at the Metrics page.
> > >
> > > Please let me know if you find any problems, or want to suggest other
> > > metrics
> > > to calculate. I'm thinking about how to make the metrics pluggable
using
> > the
> > > standard extension mechanism.
> > >
> > > Enjoy,
> > >
> > > Frank Sauer
> > >
> > >
> >
> >
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #40518 is a reply to message #40423] |
Thu, 02 January 2003 04:26 |
Frank Sauer
Messages: 36
Registered: July 2009 |
Member |
|
|
I follow the same hierarchy as Eclipse does:
IJavaProject
IPackageFragmentRoot
IPackageFragment
ICompilationUnit
IType
IMethod and others
The documentation states clearly that a IPackageFragment *only* contains
ICompilationUnits, no other IPackageFragments.
If you want to get all classes, you need to select the source folder
(a IPackageFragmentRoot) and calculate the metrics at that level.
That should give you a correct class count.
Frank
"Max Rydahl Andersen" <max@eos.dk> wrote in message
news:auvel2$rqc$1@rogue.oti.com...
> > I'll look into that. It should.
> > I was under the impression that an IPackageFragment only contained
> > ICompilationUnits,
> > not nested package fragments (since they are flattened out by Eclipse)
but
> > perhaps I'm wrong here.
> > So far I've seen only correct class counts. Did you try a source folder
> > (IPackageFragmentRoot) or
> > an entire project?
>
> I've got hibernate loaded (hibernate.sf.net) as an project and select the
> cirrus.hibernate package and it shows a class count 21.
> If I then choose cirrus.hibernate.map (a sub-package) then the class count
> is 27 - how can that be ?
> (I would expect that cirrus.hibernate also included (at least as an
option)
> the totals of cirrus.hibernate.map and other sub-packages)
>
> Notice that im looking at the package explorer with layout set to
> hiearichial, instead of just flatten.
>
> /max
>
> > "Max Rydahl Andersen" <max@eos.dk> wrote in message
> > news:auq1de$v0i$1@rogue.oti.com...
> > >
> > > It seems like the metrics are not calculated recursively for e.g. an
> > > package.
> > > While running it on cirrus.hibernate package in Hibernate it reported
> > > the project only contained 21 classes, and that is definitely not true
> :)
> > > Is that expected behavior ?
> > >
> > > /max
> > >
> > > "Frank Sauer" <sauerf@yahoo.com> wrote in message
> > > news:auim5e$e49$1@rogue.oti.com...
> > > > A new release (1.0.1) is now available at the following location:
> > > >
> > > > http://www.sourceforge.net/projects/metrics
> > > >
> > > > This version uses the jdt.core.dom AST mechanism to actually parse
the
> > > > compilation units in order to calculate more complex metrics such as
> the
> > > > McCabe cyclomatic complexity, also known as V(G). This also allowed
> > > > for a more meaningful count of blocks; it now measures maximum
nested
> > > block
> > > > depth for each method, instead of simply all blocks.
> > > >
> > > > As a side effect of the above, lines of code now counts comments
> > *within*
> > > > method bodies. I have not found an easy way to strip those, since
the
> > > AST's
> > > > MethodDeclaration does not expose the real source, only source
without
> > > > linebreaks and the offset/length for the entire method body. I now
use
> > the
> > > > latter
> > > > to calculate the number of lines.
> > > >
> > > > Because using the ASTs slowed the calculations down a lot, the
values
> > are
> > > > now
> > > > stored as persistent properties on the underlying resource and are
> only
> > > > recalculated when either the resource was changed since the last
> > > > calculation,
> > > > or a new version of the metrics plugin was installed (which could
> > contain
> > > > new metrics
> > > > not currently cached)
> > > >
> > > > Using this has not changed; simply open the properties for a
project,
> > > > package root,
> > > > package fragment or compilation unit and look at the Metrics page.
> > > >
> > > > Please let me know if you find any problems, or want to suggest
other
> > > > metrics
> > > > to calculate. I'm thinking about how to make the metrics pluggable
> using
> > > the
> > > > standard extension mechanism.
> > > >
> > > > Enjoy,
> > > >
> > > > Frank Sauer
> > > >
> > > >
> > >
> > >
> >
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #40550 is a reply to message #40518] |
Thu, 02 January 2003 10:32 |
Max Rydahl Andersen
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
ok - that would let me do it at the project/src level...would still like the
option of not being limited by the physical layout of projects - I like the
logical one :)
/max
"Frank Sauer" <sauerf@yahoo.com> wrote in message
news:av0ehb$5mk$1@rogue.oti.com...
> I follow the same hierarchy as Eclipse does:
>
> IJavaProject
> IPackageFragmentRoot
> IPackageFragment
> ICompilationUnit
> IType
> IMethod and others
>
> The documentation states clearly that a IPackageFragment *only* contains
> ICompilationUnits, no other IPackageFragments.
>
> If you want to get all classes, you need to select the source folder
> (a IPackageFragmentRoot) and calculate the metrics at that level.
> That should give you a correct class count.
>
> Frank
>
> "Max Rydahl Andersen" <max@eos.dk> wrote in message
> news:auvel2$rqc$1@rogue.oti.com...
> > > I'll look into that. It should.
> > > I was under the impression that an IPackageFragment only contained
> > > ICompilationUnits,
> > > not nested package fragments (since they are flattened out by Eclipse)
> but
> > > perhaps I'm wrong here.
> > > So far I've seen only correct class counts. Did you try a source
folder
> > > (IPackageFragmentRoot) or
> > > an entire project?
> >
> > I've got hibernate loaded (hibernate.sf.net) as an project and select
the
> > cirrus.hibernate package and it shows a class count 21.
> > If I then choose cirrus.hibernate.map (a sub-package) then the class
count
> > is 27 - how can that be ?
> > (I would expect that cirrus.hibernate also included (at least as an
> option)
> > the totals of cirrus.hibernate.map and other sub-packages)
> >
> > Notice that im looking at the package explorer with layout set to
> > hiearichial, instead of just flatten.
> >
> > /max
> >
> > > "Max Rydahl Andersen" <max@eos.dk> wrote in message
> > > news:auq1de$v0i$1@rogue.oti.com...
> > > >
> > > > It seems like the metrics are not calculated recursively for e.g. an
> > > > package.
> > > > While running it on cirrus.hibernate package in Hibernate it
reported
> > > > the project only contained 21 classes, and that is definitely not
true
> > :)
> > > > Is that expected behavior ?
> > > >
> > > > /max
> > > >
> > > > "Frank Sauer" <sauerf@yahoo.com> wrote in message
> > > > news:auim5e$e49$1@rogue.oti.com...
> > > > > A new release (1.0.1) is now available at the following location:
> > > > >
> > > > > http://www.sourceforge.net/projects/metrics
> > > > >
> > > > > This version uses the jdt.core.dom AST mechanism to actually parse
> the
> > > > > compilation units in order to calculate more complex metrics such
as
> > the
> > > > > McCabe cyclomatic complexity, also known as V(G). This also
allowed
> > > > > for a more meaningful count of blocks; it now measures maximum
> nested
> > > > block
> > > > > depth for each method, instead of simply all blocks.
> > > > >
> > > > > As a side effect of the above, lines of code now counts comments
> > > *within*
> > > > > method bodies. I have not found an easy way to strip those, since
> the
> > > > AST's
> > > > > MethodDeclaration does not expose the real source, only source
> without
> > > > > linebreaks and the offset/length for the entire method body. I now
> use
> > > the
> > > > > latter
> > > > > to calculate the number of lines.
> > > > >
> > > > > Because using the ASTs slowed the calculations down a lot, the
> values
> > > are
> > > > > now
> > > > > stored as persistent properties on the underlying resource and are
> > only
> > > > > recalculated when either the resource was changed since the last
> > > > > calculation,
> > > > > or a new version of the metrics plugin was installed (which could
> > > contain
> > > > > new metrics
> > > > > not currently cached)
> > > > >
> > > > > Using this has not changed; simply open the properties for a
> project,
> > > > > package root,
> > > > > package fragment or compilation unit and look at the Metrics page.
> > > > >
> > > > > Please let me know if you find any problems, or want to suggest
> other
> > > > > metrics
> > > > > to calculate. I'm thinking about how to make the metrics pluggable
> > using
> > > > the
> > > > > standard extension mechanism.
> > > > >
> > > > > Enjoy,
> > > > >
> > > > > Frank Sauer
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #588168 is a reply to message #39752] |
Mon, 30 December 2002 18:08 |
Max Rydahl Andersen
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
It seems like the metrics are not calculated recursively for e.g. an
package.
While running it on cirrus.hibernate package in Hibernate it reported
the project only contained 21 classes, and that is definitely not true :)
Is that expected behavior ?
/max
"Frank Sauer" <sauerf@yahoo.com> wrote in message
news:auim5e$e49$1@rogue.oti.com...
> A new release (1.0.1) is now available at the following location:
>
> http://www.sourceforge.net/projects/metrics
>
> This version uses the jdt.core.dom AST mechanism to actually parse the
> compilation units in order to calculate more complex metrics such as the
> McCabe cyclomatic complexity, also known as V(G). This also allowed
> for a more meaningful count of blocks; it now measures maximum nested
block
> depth for each method, instead of simply all blocks.
>
> As a side effect of the above, lines of code now counts comments *within*
> method bodies. I have not found an easy way to strip those, since the
AST's
> MethodDeclaration does not expose the real source, only source without
> linebreaks and the offset/length for the entire method body. I now use the
> latter
> to calculate the number of lines.
>
> Because using the ASTs slowed the calculations down a lot, the values are
> now
> stored as persistent properties on the underlying resource and are only
> recalculated when either the resource was changed since the last
> calculation,
> or a new version of the metrics plugin was installed (which could contain
> new metrics
> not currently cached)
>
> Using this has not changed; simply open the properties for a project,
> package root,
> package fragment or compilation unit and look at the Metrics page.
>
> Please let me know if you find any problems, or want to suggest other
> metrics
> to calculate. I'm thinking about how to make the metrics pluggable using
the
> standard extension mechanism.
>
> Enjoy,
>
> Frank Sauer
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #588207 is a reply to message #40001] |
Mon, 30 December 2002 19:55 |
Frank Sauer
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
I'll look into that. It should.
I was under the impression that an IPackageFragment only contained
ICompilationUnits,
not nested package fragments (since they are flattened out by Eclipse) but
perhaps I'm wrong here.
So far I've seen only correct class counts. Did you try a source folder
(IPackageFragmentRoot) or
an entire project?
"Max Rydahl Andersen" <max@eos.dk> wrote in message
news:auq1de$v0i$1@rogue.oti.com...
>
> It seems like the metrics are not calculated recursively for e.g. an
> package.
> While running it on cirrus.hibernate package in Hibernate it reported
> the project only contained 21 classes, and that is definitely not true :)
> Is that expected behavior ?
>
> /max
>
> "Frank Sauer" <sauerf@yahoo.com> wrote in message
> news:auim5e$e49$1@rogue.oti.com...
> > A new release (1.0.1) is now available at the following location:
> >
> > http://www.sourceforge.net/projects/metrics
> >
> > This version uses the jdt.core.dom AST mechanism to actually parse the
> > compilation units in order to calculate more complex metrics such as the
> > McCabe cyclomatic complexity, also known as V(G). This also allowed
> > for a more meaningful count of blocks; it now measures maximum nested
> block
> > depth for each method, instead of simply all blocks.
> >
> > As a side effect of the above, lines of code now counts comments
*within*
> > method bodies. I have not found an easy way to strip those, since the
> AST's
> > MethodDeclaration does not expose the real source, only source without
> > linebreaks and the offset/length for the entire method body. I now use
the
> > latter
> > to calculate the number of lines.
> >
> > Because using the ASTs slowed the calculations down a lot, the values
are
> > now
> > stored as persistent properties on the underlying resource and are only
> > recalculated when either the resource was changed since the last
> > calculation,
> > or a new version of the metrics plugin was installed (which could
contain
> > new metrics
> > not currently cached)
> >
> > Using this has not changed; simply open the properties for a project,
> > package root,
> > package fragment or compilation unit and look at the Metrics page.
> >
> > Please let me know if you find any problems, or want to suggest other
> > metrics
> > to calculate. I'm thinking about how to make the metrics pluggable using
> the
> > standard extension mechanism.
> >
> > Enjoy,
> >
> > Frank Sauer
> >
> >
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #588278 is a reply to message #40125] |
Wed, 01 January 2003 19:25 |
Max Rydahl Andersen
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
> I'll look into that. It should.
> I was under the impression that an IPackageFragment only contained
> ICompilationUnits,
> not nested package fragments (since they are flattened out by Eclipse) but
> perhaps I'm wrong here.
> So far I've seen only correct class counts. Did you try a source folder
> (IPackageFragmentRoot) or
> an entire project?
I've got hibernate loaded (hibernate.sf.net) as an project and select the
cirrus.hibernate package and it shows a class count 21.
If I then choose cirrus.hibernate.map (a sub-package) then the class count
is 27 - how can that be ?
(I would expect that cirrus.hibernate also included (at least as an option)
the totals of cirrus.hibernate.map and other sub-packages)
Notice that im looking at the package explorer with layout set to
hiearichial, instead of just flatten.
/max
> "Max Rydahl Andersen" <max@eos.dk> wrote in message
> news:auq1de$v0i$1@rogue.oti.com...
> >
> > It seems like the metrics are not calculated recursively for e.g. an
> > package.
> > While running it on cirrus.hibernate package in Hibernate it reported
> > the project only contained 21 classes, and that is definitely not true
:)
> > Is that expected behavior ?
> >
> > /max
> >
> > "Frank Sauer" <sauerf@yahoo.com> wrote in message
> > news:auim5e$e49$1@rogue.oti.com...
> > > A new release (1.0.1) is now available at the following location:
> > >
> > > http://www.sourceforge.net/projects/metrics
> > >
> > > This version uses the jdt.core.dom AST mechanism to actually parse the
> > > compilation units in order to calculate more complex metrics such as
the
> > > McCabe cyclomatic complexity, also known as V(G). This also allowed
> > > for a more meaningful count of blocks; it now measures maximum nested
> > block
> > > depth for each method, instead of simply all blocks.
> > >
> > > As a side effect of the above, lines of code now counts comments
> *within*
> > > method bodies. I have not found an easy way to strip those, since the
> > AST's
> > > MethodDeclaration does not expose the real source, only source without
> > > linebreaks and the offset/length for the entire method body. I now use
> the
> > > latter
> > > to calculate the number of lines.
> > >
> > > Because using the ASTs slowed the calculations down a lot, the values
> are
> > > now
> > > stored as persistent properties on the underlying resource and are
only
> > > recalculated when either the resource was changed since the last
> > > calculation,
> > > or a new version of the metrics plugin was installed (which could
> contain
> > > new metrics
> > > not currently cached)
> > >
> > > Using this has not changed; simply open the properties for a project,
> > > package root,
> > > package fragment or compilation unit and look at the Metrics page.
> > >
> > > Please let me know if you find any problems, or want to suggest other
> > > metrics
> > > to calculate. I'm thinking about how to make the metrics pluggable
using
> > the
> > > standard extension mechanism.
> > >
> > > Enjoy,
> > >
> > > Frank Sauer
> > >
> > >
> >
> >
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #588303 is a reply to message #40423] |
Thu, 02 January 2003 04:26 |
Frank Sauer
Messages: 36
Registered: July 2009 |
Member |
|
|
I follow the same hierarchy as Eclipse does:
IJavaProject
IPackageFragmentRoot
IPackageFragment
ICompilationUnit
IType
IMethod and others
The documentation states clearly that a IPackageFragment *only* contains
ICompilationUnits, no other IPackageFragments.
If you want to get all classes, you need to select the source folder
(a IPackageFragmentRoot) and calculate the metrics at that level.
That should give you a correct class count.
Frank
"Max Rydahl Andersen" <max@eos.dk> wrote in message
news:auvel2$rqc$1@rogue.oti.com...
> > I'll look into that. It should.
> > I was under the impression that an IPackageFragment only contained
> > ICompilationUnits,
> > not nested package fragments (since they are flattened out by Eclipse)
but
> > perhaps I'm wrong here.
> > So far I've seen only correct class counts. Did you try a source folder
> > (IPackageFragmentRoot) or
> > an entire project?
>
> I've got hibernate loaded (hibernate.sf.net) as an project and select the
> cirrus.hibernate package and it shows a class count 21.
> If I then choose cirrus.hibernate.map (a sub-package) then the class count
> is 27 - how can that be ?
> (I would expect that cirrus.hibernate also included (at least as an
option)
> the totals of cirrus.hibernate.map and other sub-packages)
>
> Notice that im looking at the package explorer with layout set to
> hiearichial, instead of just flatten.
>
> /max
>
> > "Max Rydahl Andersen" <max@eos.dk> wrote in message
> > news:auq1de$v0i$1@rogue.oti.com...
> > >
> > > It seems like the metrics are not calculated recursively for e.g. an
> > > package.
> > > While running it on cirrus.hibernate package in Hibernate it reported
> > > the project only contained 21 classes, and that is definitely not true
> :)
> > > Is that expected behavior ?
> > >
> > > /max
> > >
> > > "Frank Sauer" <sauerf@yahoo.com> wrote in message
> > > news:auim5e$e49$1@rogue.oti.com...
> > > > A new release (1.0.1) is now available at the following location:
> > > >
> > > > http://www.sourceforge.net/projects/metrics
> > > >
> > > > This version uses the jdt.core.dom AST mechanism to actually parse
the
> > > > compilation units in order to calculate more complex metrics such as
> the
> > > > McCabe cyclomatic complexity, also known as V(G). This also allowed
> > > > for a more meaningful count of blocks; it now measures maximum
nested
> > > block
> > > > depth for each method, instead of simply all blocks.
> > > >
> > > > As a side effect of the above, lines of code now counts comments
> > *within*
> > > > method bodies. I have not found an easy way to strip those, since
the
> > > AST's
> > > > MethodDeclaration does not expose the real source, only source
without
> > > > linebreaks and the offset/length for the entire method body. I now
use
> > the
> > > > latter
> > > > to calculate the number of lines.
> > > >
> > > > Because using the ASTs slowed the calculations down a lot, the
values
> > are
> > > > now
> > > > stored as persistent properties on the underlying resource and are
> only
> > > > recalculated when either the resource was changed since the last
> > > > calculation,
> > > > or a new version of the metrics plugin was installed (which could
> > contain
> > > > new metrics
> > > > not currently cached)
> > > >
> > > > Using this has not changed; simply open the properties for a
project,
> > > > package root,
> > > > package fragment or compilation unit and look at the Metrics page.
> > > >
> > > > Please let me know if you find any problems, or want to suggest
other
> > > > metrics
> > > > to calculate. I'm thinking about how to make the metrics pluggable
> using
> > > the
> > > > standard extension mechanism.
> > > >
> > > > Enjoy,
> > > >
> > > > Frank Sauer
> > > >
> > > >
> > >
> > >
> >
>
>
|
|
|
| Re: [ANN] metrics plugin updated and moved to a new home [message #588313 is a reply to message #40518] |
Thu, 02 January 2003 10:32 |
Max Rydahl Andersen
Messages: 23
Registered: July 2009 |
Junior Member |
|
|
ok - that would let me do it at the project/src level...would still like the
option of not being limited by the physical layout of projects - I like the
logical one :)
/max
"Frank Sauer" <sauerf@yahoo.com> wrote in message
news:av0ehb$5mk$1@rogue.oti.com...
> I follow the same hierarchy as Eclipse does:
>
> IJavaProject
> IPackageFragmentRoot
> IPackageFragment
> ICompilationUnit
> IType
> IMethod and others
>
> The documentation states clearly that a IPackageFragment *only* contains
> ICompilationUnits, no other IPackageFragments.
>
> If you want to get all classes, you need to select the source folder
> (a IPackageFragmentRoot) and calculate the metrics at that level.
> That should give you a correct class count.
>
> Frank
>
> "Max Rydahl Andersen" <max@eos.dk> wrote in message
> news:auvel2$rqc$1@rogue.oti.com...
> > > I'll look into that. It should.
> > > I was under the impression that an IPackageFragment only contained
> > > ICompilationUnits,
> > > not nested package fragments (since they are flattened out by Eclipse)
> but
> > > perhaps I'm wrong here.
> > > So far I've seen only correct class counts. Did you try a source
folder
> > > (IPackageFragmentRoot) or
> > > an entire project?
> >
> > I've got hibernate loaded (hibernate.sf.net) as an project and select
the
> > cirrus.hibernate package and it shows a class count 21.
> > If I then choose cirrus.hibernate.map (a sub-package) then the class
count
> > is 27 - how can that be ?
> > (I would expect that cirrus.hibernate also included (at least as an
> option)
> > the totals of cirrus.hibernate.map and other sub-packages)
> >
> > Notice that im looking at the package explorer with layout set to
> > hiearichial, instead of just flatten.
> >
> > /max
> >
> > > "Max Rydahl Andersen" <max@eos.dk> wrote in message
> > > news:auq1de$v0i$1@rogue.oti.com...
> > > >
> > > > It seems like the metrics are not calculated recursively for e.g. an
> > > > package.
> > > > While running it on cirrus.hibernate package in Hibernate it
reported
> > > > the project only contained 21 classes, and that is definitely not
true
> > :)
> > > > Is that expected behavior ?
> > > >
> > > > /max
> > > >
> > > > "Frank Sauer" <sauerf@yahoo.com> wrote in message
> > > > news:auim5e$e49$1@rogue.oti.com...
> > > > > A new release (1.0.1) is now available at the following location:
> > > > >
> > > > > http://www.sourceforge.net/projects/metrics
> > > > >
> > > > > This version uses the jdt.core.dom AST mechanism to actually parse
> the
> > > > > compilation units in order to calculate more complex metrics such
as
> > the
> > > > > McCabe cyclomatic complexity, also known as V(G). This also
allowed
> > > > > for a more meaningful count of blocks; it now measures maximum
> nested
> > > > block
> > > > > depth for each method, instead of simply all blocks.
> > > > >
> > > > > As a side effect of the above, lines of code now counts comments
> > > *within*
> > > > > method bodies. I have not found an easy way to strip those, since
> the
> > > > AST's
> > > > > MethodDeclaration does not expose the real source, only source
> without
> > > > > linebreaks and the offset/length for the entire method body. I now
> use
> > > the
> > > > > latter
> > > > > to calculate the number of lines.
> > > > >
> > > > > Because using the ASTs slowed the calculations down a lot, the
> values
> > > are
> > > > > now
> > > > > stored as persistent properties on the underlying resource and are
> > only
> > > > > recalculated when either the resource was changed since the last
> > > > > calculation,
> > > > > or a new version of the metrics plugin was installed (which could
> > > contain
> > > > > new metrics
> > > > > not currently cached)
> > > > >
> > > > > Using this has not changed; simply open the properties for a
> project,
> > > > > package root,
> > > > > package fragment or compilation unit and look at the Metrics page.
> > > > >
> > > > > Please let me know if you find any problems, or want to suggest
> other
> > > > > metrics
> > > > > to calculate. I'm thinking about how to make the metrics pluggable
> > using
> > > > the
> > > > > standard extension mechanism.
> > > > >
> > > > > Enjoy,
> > > > >
> > > > > Frank Sauer
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Wed Sep 25 14:30:01 GMT 2024
Powered by FUDForum. Page generated in 0.04269 seconds |
] 
Search
Help
Register
Login
Home
