GORM - Hibernate vs JPA

10 messages

GORM - Hibernate vs JPA

Reply Threaded

How tied is Grails to using Hibernate vs. using generic JPA
bindings? I'm a little concerned that by tying the project to an
LGPL library that we are fundamentally limiting the audience for the
framework and the ability for us to innovate.

Sam

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

graemer

Re: GORM - Hibernate vs JPA

Reply Threaded

At the moment pretty tied. The problem is JPA's lack of a criteria API
and an API to customise the configuration mechanism (ie you have to
use annotations).

As for LGPL, what concerns do you have? You're free to create whatever
products you want with Grails I don't see LGPL limiting it

It would only limited you if you tried to customise and re-sell it as
an ORM tool. For this there may be legs, but then what Apache licensed
ORM tools do you know of that aren't crap?

Cheers

On 9/30/07, Sam Pullara <[hidden email]> wrote:

> How tied is Grails to using Hibernate vs. using generic JPA
> bindings? I'm a little concerned that by tying the project to an
> LGPL library that we are fundamentally limiting the audience for the
> framework and the ability for us to innovate.
>
> Sam
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

Sam Pullara

Re: GORM - Hibernate vs JPA

Reply Threaded

So it sounds pretty tied though I think you can make a criteria API
that generates EJB-QL without much trouble...

As for the LGPL... I've found that software companies are loath to
put any dependencies on Hibernate because of the license. It also
means that Grails is pretty dependent on the Hibernate team fixing
bugs and making enhancements that benefit Grails. I didn't say it
was a huge problem but it does limit the audience somewhat.

As for the decision to not use JPA, it makes Grails look a little non-
standard which might be fine depending on eventual audience. But if
you ever want Oracle, IBM, or BEA to ship Grails in their products I
think we might want to make it JPA rather than explicitly Hibernate.

At the end of the day though I would do what is most practical so if
you think that the other implementations will never be as good or
better than Hibernate and that there won't be any adoption problems
with software companies and enterprises I'll just let the issue
rest. Just wanted to air a bit of my concerns and the possible risks.

Sam

On Sep 30, 2007, at 1:36 PM, Graeme Rocher wrote:

> At the moment pretty tied. The problem is JPA's lack of a criteria API
> and an API to customise the configuration mechanism (ie you have to
> use annotations).
>
> As for LGPL, what concerns do you have? You're free to create whatever
> products you want with Grails I don't see LGPL limiting it
>
> It would only limited you if you tried to customise and re-sell it as
> an ORM tool. For this there may be legs, but then what Apache licensed
> ORM tools do you know of that aren't crap?
>
> Cheers
>
> On 9/30/07, Sam Pullara <[hidden email]> wrote:
>> How tied is Grails to using Hibernate vs. using generic JPA
>> bindings? I'm a little concerned that by tying the project to an
>> LGPL library that we are fundamentally limiting the audience for the
>> framework and the ability for us to innovate.
>>
>> Sam
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

Marc Palmer Local

Re: GORM - Hibernate vs JPA

Reply Threaded

On 30 Sep 2007, at 21:51, Sam Pullara wrote:

> So it sounds pretty tied though I think you can make a criteria API
> that generates EJB-QL without much trouble...
>
> As for the LGPL... I've found that software companies are loath to
> put any dependencies on Hibernate because of the license. It also
> means that Grails is pretty dependent on the Hibernate team fixing
> bugs and making enhancements that benefit Grails. I didn't say it
> was a huge problem but it does limit the audience somewhat.
>

I thought that Hibernate was pretty defacto these days. Spring +
Hibernate is generally the EE platform of choice for those in the
know, and EJB/JPA is for the corps that are "Sun all the way",
roughly speaking.

> As for the decision to not use JPA, it makes Grails look a little
> non-standard which might be fine depending on eventual audience.
> But if you ever want Oracle, IBM, or BEA to ship Grails in their
> products I think we might want to make it JPA rather than
> explicitly Hibernate.
>

I'm not sure this makes sense. What is there to ship. Grails builds
WARs, there is no framework to install. Unless you mean within their
development tools, but then I imagine there's no problem as the LGPL
surely applied to applications made -with- Grails not applications
that allow you to "make" applications with Grails.

> At the end of the day though I would do what is most practical so
> if you think that the other implementations will never be as good
> or better than Hibernate and that there won't be any adoption
> problems with software companies and enterprises I'll just let the
> issue rest. Just wanted to air a bit of my concerns and the
> possible risks.
>

Yes, I understand. I don't think this is a major problem though.
Furthermore, people can always write a plugin that replicates some/
all of GORM but with a different ORM mechanism.

Marc

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

Steven Devijver

Re: GORM - Hibernate vs JPA

Reply Threaded

In reply to this post by Sam Pullara

On 9/30/07, Sam Pullara <[hidden email]> wrote:

> So it sounds pretty tied though I think you can make a criteria API
> that generates EJB-QL without much trouble...
>
> As for the LGPL... I've found that software companies are loath to
> put any dependencies on Hibernate because of the license. It also
> means that Grails is pretty dependent on the Hibernate team fixing
> bugs and making enhancements that benefit Grails. I didn't say it
> was a huge problem but it does limit the audience somewhat.
>
> As for the decision to not use JPA, it makes Grails look a little non-
> standard which might be fine depending on eventual audience. But if
> you ever want Oracle, IBM, or BEA to ship Grails in their products I
> think we might want to make it JPA rather than explicitly Hibernate.

As Graeme indicated there is currently really no option to use JPA.
Hibernate offers the criteria API and the custom configuration hooks
that are required by Grails.

Lets say that if there were no Hibernate and only JPA Grails wouldn't
be what it is today.

>
> At the end of the day though I would do what is most practical so if
> you think that the other implementations will never be as good or
> better than Hibernate and that there won't be any adoption problems
> with software companies and enterprises I'll just let the issue
> rest. Just wanted to air a bit of my concerns and the possible risks.
>
> Sam
>
> On Sep 30, 2007, at 1:36 PM, Graeme Rocher wrote:
>
> > At the moment pretty tied. The problem is JPA's lack of a criteria API
> > and an API to customise the configuration mechanism (ie you have to
> > use annotations).
> >
> > As for LGPL, what concerns do you have? You're free to create whatever
> > products you want with Grails I don't see LGPL limiting it
> >
> > It would only limited you if you tried to customise and re-sell it as
> > an ORM tool. For this there may be legs, but then what Apache licensed
> > ORM tools do you know of that aren't crap?
> >
> > Cheers
> >
> > On 9/30/07, Sam Pullara <[hidden email]> wrote:
> >> How tied is Grails to using Hibernate vs. using generic JPA
> >> bindings? I'm a little concerned that by tying the project to an
> >> LGPL library that we are fundamentally limiting the audience for the
> >> framework and the ability for us to innovate.
> >>
> >> Sam
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
> >>
> >>
> >
> >
> > --
> > Graeme Rocher
> > Grails Project Lead
> > http://grails.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

graemer

Re: GORM - Hibernate vs JPA

Reply Threaded

On 10/1/07, Steven Devijver <[hidden email]> wrote:

> On 9/30/07, Sam Pullara <[hidden email]> wrote:
> > So it sounds pretty tied though I think you can make a criteria API
> > that generates EJB-QL without much trouble...
> >
> > As for the LGPL... I've found that software companies are loath to
> > put any dependencies on Hibernate because of the license. It also
> > means that Grails is pretty dependent on the Hibernate team fixing
> > bugs and making enhancements that benefit Grails. I didn't say it
> > was a huge problem but it does limit the audience somewhat.
> >
> > As for the decision to not use JPA, it makes Grails look a little non-
> > standard which might be fine depending on eventual audience. But if
> > you ever want Oracle, IBM, or BEA to ship Grails in their products I
> > think we might want to make it JPA rather than explicitly Hibernate.
>
> As Graeme indicated there is currently really no option to use JPA.
> Hibernate offers the criteria API and the custom configuration hooks
> that are required by Grails.
>
> Lets say that if there were no Hibernate and only JPA Grails wouldn't
> be what it is today.

Indeed. Also JPA wasn't even finalised yet when we started Grails. I'm
still awaiting the answer to an Apache licensed ORM tool that is not
rubbish? Really I would love to hear of one (btw iBatis doesn't count
as its not really an ORM tool)

Cheers

>
>
> >
> > At the end of the day though I would do what is most practical so if
> > you think that the other implementations will never be as good or
> > better than Hibernate and that there won't be any adoption problems
> > with software companies and enterprises I'll just let the issue
> > rest. Just wanted to air a bit of my concerns and the possible risks.
> >
> > Sam
> >
> > On Sep 30, 2007, at 1:36 PM, Graeme Rocher wrote:
> >
> > > At the moment pretty tied. The problem is JPA's lack of a criteria API
> > > and an API to customise the configuration mechanism (ie you have to
> > > use annotations).
> > >
> > > As for LGPL, what concerns do you have? You're free to create whatever
> > > products you want with Grails I don't see LGPL limiting it
> > >
> > > It would only limited you if you tried to customise and re-sell it as
> > > an ORM tool. For this there may be legs, but then what Apache licensed
> > > ORM tools do you know of that aren't crap?
> > >
> > > Cheers
> > >
> > > On 9/30/07, Sam Pullara <[hidden email]> wrote:
> > >> How tied is Grails to using Hibernate vs. using generic JPA
> > >> bindings? I'm a little concerned that by tying the project to an
> > >> LGPL library that we are fundamentally limiting the audience for the
> > >> framework and the ability for us to innovate.
> > >>
> > >> Sam
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe from this list please visit:
> > >>
> > >> http://xircles.codehaus.org/manage_email
> > >>
> > >>
> > >
> > >
> > > --
> > > Graeme Rocher
> > > Grails Project Lead
> > > http://grails.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > > http://xircles.codehaus.org/manage_email
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

Dmitriy Kopylenko-3

Re: GORM - Hibernate vs JPA

Reply Threaded

Indeed. Also JPA wasn't even finalised yet when we started Grails. I'm
still awaiting the answer to an Apache licensed ORM tool that is not
rubbish? Really I would love to hear of one (btw iBatis doesn't count
as its not really an ORM tool)

JPA-based you mean? OpenJPA perhaps?

Dmitriy.

graemer

Re: GORM - Hibernate vs JPA

Reply Threaded

On 10/1/07, Dmitriy Kopylenko <[hidden email]> wrote:
>
>
> >
> > Indeed. Also JPA wasn't even finalised yet when we started Grails. I'm
> > still awaiting the answer to an Apache licensed ORM tool that is not
> > rubbish? Really I would love to hear of one (btw iBatis doesn't count
> > as its not really an ORM tool)
>
> JPA-based you mean? OpenJPA perhaps?

Ok, just released around a month ago, so a recent development. Might
be a worth a look

Cheers

>
>
> Dmitriy.
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

Dmitriy Kopylenko-3

Re: GORM - Hibernate vs JPA

Reply Threaded

Built on the supposedly solid codebase of BEA's Kodo.

Please note, I'm not "pushing" OpenJPA and in fact I have no experience with it whatsoever. Just throwing some potential options on the table :-)

Cheers,
Dmitriy.

P.S.

BTW, here's a good overview of the product by Patrick: http://www.infoq.com/interviews/openjpa-patrick-linskey

2007/10/1, Graeme Rocher <[hidden email]>:

On 10/1/07, Dmitriy Kopylenko <[hidden email]> wrote:
>
>
> >
> > Indeed. Also JPA wasn't even finalised yet when we started Grails. I'm
> > still awaiting the answer to an Apache licensed ORM tool that is not
> > rubbish? Really I would love to hear of one (btw iBatis doesn't count
> > as its not really an ORM tool)
>
> JPA-based you mean? OpenJPA perhaps?

Ok, just released around a month ago, so a recent development. Might
be a worth a look

Cheers

>
>
> Dmitriy.
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

Steven Devijver

Re: GORM - Hibernate vs JPA

Reply Threaded

In reply to this post by graemer

Some javascript/style in this post has been disabled (why?)

On 10/1/07, Graeme Rocher <[hidden email]> wrote:

> On 10/1/07, Dmitriy Kopylenko <[hidden email]> wrote:
> >
> >
> > >
> > > Indeed. Also JPA wasn't even finalised yet when we started Grails. I'm
> > > still awaiting the answer to an Apache licensed ORM tool that is not
> > > rubbish? Really I would love to hear of one (btw iBatis doesn't count
> > > as its not really an ORM tool)
> >
> > JPA-based you mean? OpenJPA perhaps?
>
> Ok, just released around a month ago, so a recent development. Might
> be a worth a look
>

Don't bother. I've loaded the OpenJPA JAR file in Structure 101, it's
a total mess. XS of 82% (Hibernate is 108%!!). Compare with Spring at
2%.

See attachment.

Steven

> Cheers
>
> >
> >
> > Dmitriy.
> >
> >
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

Project Summary: untitled

Created:	1 oktober 2007 14:58 by Structure101
Classpath:	C:\downloads\apache-openjpa-1.0.0-binary\apache-openjpa-1.0.0\openjpa-1.0.0.jar
Granularity:	"Detail" - includes inner classes, methods and fields
Externals:	"Hide" - referenced items are not included
Excludes:	None
Transformations:	None
Hierarchy:	"Package"
Notes and tips:	On

Tip:

This summary has been generated with "Show notes and tips" enabled - these are shown with a yellow background, like this one. You can switch them off via the drop-down menu in the Overview perspective (or with the -notips switch from the command line).
The Collaboration perspective is great for tracking down your dependency on third party libraries. Set "Show externals" in the project properties and then select the library item in the right-hand tree - anything that doesn't use it will be grayed out in the left-hand tree.

Size

Jars (and/or classpath directories):	2
Packages (that contain classes):	33
Classes (outer):	1,008
Classes (all):	1,455
Classes (external):	22

NI (Number of bytecode Instructions):	406K
LOC (Non Comment Non Blank Lines Of Code):	~175K


Note:	Though less commonly used than LOC, NI is an excellent, style-independent, relative measure of code size. The value for LOC is estimated from the NI.

Flat Tangles

Level	#Items	#Tangles	#Tangled items	Biggest	Degree
Leaf package	33	4	20	9	36%
Jar	1	n/a	n/a	n/a	n/a
Outer class	1,008	11	512	240	33%


Note:	"Flat" tangles are detected and measured from the flat dependency graphs of all items at a specific level. These are independent of the "Design" levels which are created by the higher-level packaging and are measured and reported in the "Excessive Structural Complexity (XS)" section below. Tangles at the Jar or Package-level are highly disruptive. The bigger the tangle, the more problems it is likely to cause. Larger tangles at the class level are likely to cross package boundaries and so may also indicate a problem. The degree is calculated so as to give a higher value for larger tangles - that is, one large tangle will give a higher degree than the same number of items involved in several smaller tangles.
Tip:	The "Leaf package" and "Outer class" tangles can be directly viewed and analyzed in the Slice perspective. To view and analyze jar-level tangles, select the Jar hierarchy in the Composition perspective.

Excessive Structural Complexity (XS)

Cumulative XS:	343,141
Average XS:	84%


Note:	The XS Configuration is a set of thresholds for "Fat" and "Tangles" at different levels of composition. Fat indicates "too much stuff" in one place and is measurable at every level of composition - Design, Package, Class and Method. Cyclomatic Complexity is used as a measure of Fat at the method level - the number of dependencies in the child dependency graph is used at the other levels. For the purposes of XS, tangles are only measured at the design level, i.e. cyclic dependencies between packages. Both Fat and Tangles are measured as the percentage by which the threshold is exceeded. This percentage is multiplied by the size of the item so that the Average XS can be read as a percentage of the code-base. Read more about the concepts behind XS.
Tip:	Use the Measurement perspective to obtain detailed information on the XS in your project. Change the metrics and thresholds used to calculate XS by putting the XS Configuration into "Edit mode" from the drop down menu, bottom-left, in the Measurement perspective. Save the changes as a new named configuration.

XS breakout by metric (and scope)

Metric (and scope)	Threshold	#Offenders	Offenses (%)	XS contribution
Tangled (design)	0	7 of 9	78%	43%
Fat (design)	120	0 of 9	0%	0%
Fat (leaf package)	120	9 of 33	27%	25%
Fat (class)	120	50 of 1,455	3%	27%
Fat (method)	15	164 of 19,399	1%	5%
Total				100%


Note:	The Metric (and scope) column contains all the metrics that are enabled in the selected XS Configuration (named in the previous section). The "Threshold" is taken from the selected XS Configuration The "#Offenders" indicates the number of items that exceed the threshold. The "Offenders (%)" indicates the number of items that exceed the threshold as a percentage of the total number of items at that level. The "XS contribution" indicates the degree to which design tangles and fat at each level contribute to the total amount of XS in the project.
Tip:	Use the Measurement perspective to obtain detailed information on the XS in your project.

Tangled (design): Top 5 (of 7)

Item	Value
org.apache.openjpa.jdbc.kernel	49%
org.apache.openjpa.lib.util	40%
org.apache.openjpa.kernel	23%
org.apache.openjpa	18%
org.apache.openjpa.jdbc	17%


Note:	The "design" level items are high-level packages (i.e. packages that contain sub-packages). Tangles are only measured at this level. The value is calculated as the number of dependencies that go bottom-up as a percentage of all the dependencies on the child graph for the item.
Tip:	To view and analyze these tangles, drill down to the item in the Composition perspective with the Package hierarchy selected from the Model menu. The complete list is available in the Measurement perspective. Make sure you are at the root of the "Drill-down" in the top-left, and then select the Tangled (design) slice of the pie. The "Items with XS" will contain all the items that exceed the threshold at this level.

Fat (design)

No items exceed the threshold for Fat at the design level.


Note:	The "design" level items are high-level packages (i.e. packages that contain sub-packages). The value is calculated as the number of dependencies in the child graph for the item, i.e. the dependency graph of the sub-packages of the measured package.
Tip:	To view and analyze these Fat items, drill down to the item in the Composition perspective with the Package hierarchy selected from the Model menu. Use the "Auto-partition" button on the Dependency Graph to help make sense of big graphs. The complete list is available in the Measurement perspective. Make sure you are at the root of the "Drill-down" in the top-left, and then select the Fat (design) slice of the pie. The "Items with XS" will contain all the items that exceed the threshold at this level.

Fat (leaf package): Top 5 (of 9)

Item	Value
org.apache.openjpa.kernel	407
org.apache.openjpa.jdbc.kernel.exps	400
org.apache.openjpa.kernel.exps	287
org.apache.openjpa.jdbc.meta	253
org.apache.openjpa.persistence	198


Note:	The "leaf package" level items are packages that contain classes. The value is calculated as the number of dependencies in the child graph for the item, i.e. the dependency graph of the classes in the measured package
Tip:	To view and analyze these Fat items, drill down to the item in the Composition perspective. Use the "Auto-partition" button on the Dependency Graph to help make sense of big graphs. The complete list is available in the Measurement perspective. Make sure you are at the root of the "Drill-down" in the top-left, and then select the Fat (leaf package) slice of the pie. The "Items with XS" will contain all the items that exceed the threshold at this level.

Fat (class): Top 5 (of 50)

Item	Value
org.apache.openjpa.kernel.jpql.JPQL	2,190
org.apache.openjpa.kernel.BrokerImpl	936
org.apache.openjpa.kernel.StateManagerImpl	848
org.apache.openjpa.jdbc.sql.DBDictionary	535
org.apache.openjpa.meta.ClassMetaData	528


Note:	The value is calculated as the number of dependencies in the child graph for the item, i.e. the dependency graph of the methods and fields in the class. This is not available if the Granularity for the project is "Overview".
Tip:	To view and analyze these Fat items, drill down to the item in the Composition perspective. Use the "Auto-partition" button on the Dependency Graph to help make sense of big graphs. The complete list is available in the Measurement perspective. Make sure you are at the root of the "Drill-down" in the top-left, and then select the Fat (class) slice of the pie. The "Items with XS" will contain all the items that exceed the threshold at this level.

Fat (method): Top 5 (of 164)

Item	Value
org.apache.openjpa.kernel.Filters.promote(Class, Class):Class	81
org.apache.openjpa.persistence.jdbc.AnnotationPersistenceMappingParser$1.<clinit>():void	70
org.apache.openjpa.kernel.jpql.JPQLTokenManager.jjMoveNfa_0(int, int):int	56
org.apache.openjpa.jdbc.meta.MappingInfo.mergeJoinColumn(MetaDataContext, String, Column, Object[][], int, Table, ClassMapping, ClassMapping, ForeignKeyDefaults, boolean, boolean, boolean):void	52
org.apache.openjpa.event.LifecycleEventManager.fireEvent(LifecycleEvent, Object, Object, int, ListenerList, boolean, List):Object	51


Note:	The value is calculated as the Cyclomatic Complexity (McCabe's metric) of the method. The value is calculated from the bytecode and so may differ from the value that would be calculated from the corresponding source code in some (rare) cases. This is not available if the Granularity for the project is "Overview".
Tip:	To view and analyze these Fat items, drill down to the class that contains the method in any perspective. Click on the "Show source" button on the main toolbar to view the source. The complete list is available in the Measurement perspective. Make sure you are at the root of the "Drill-down" in the top-left, and then select the Fat (method) slice of the pie. The "Items with XS" will contain all the items that exceed the threshold at this level.

Items with highest XS - Top 10 (of 230)

Item	Type	Tangled	Fat	Size	XS
org.apache.openjpa	meta-package	18%	83	406,085	75,019
org.apache.openjpa.kernel	package		407	52,196	36,806
org.apache.openjpa.jdbc	meta-package	17%	23	131,855	22,160
org.apache.openjpa.kernel.jpql.JPQL	class		2,190	22,904	21,648
org.apache.openjpa.kernel	meta-package	23%	4	94,845	21,637
org.apache.openjpa.jdbc.kernel	meta-package	49%	2	27,988	13,719
org.apache.openjpa.jdbc.meta	package		253	25,005	13,144
org.apache.openjpa.persistence	package		198	26,471	10,427
org.apache.openjpa.jdbc.kernel.exps	package		400	13,802	9,661
org.apache.openjpa.kernel.BrokerImpl	class		936	10,663	9,295


Note:	XS is related to the value and the size of the item so that bigger items (usually higher in the hierarchy) score higher. Since excessive structural complexity on bigger items (e.g. packages) will tend to disrupt development activities more than on smaller items (e.g. methods), you should consider fixing these first. Values in red exceed threshold.
Tip:	The complete list is available in the Measurement perspective - make sure you are at the root of the "Drill-down" in the top-left, and do not select any items in the pie. You can integrate the generation of this summary into your build process. See help for details.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email