On Jan 30, 2009, at 10:39 AM, David E Jones wrote:
I like the commonext name better than appcommon, I forgot about that pattern.In general I'd rather see things from the framework go into the applications than see something like Party go into the framework/ common component. In many cases where party is currently referenced in the framework this may not help anyway, as many things refer to stuff other than just the Party/partyId.Anyway, I'm still not comfortable with moving all of the entity defs currently in framework/common to applications/commonext. We have a lot of code and a few entities for doing basic things (and by basic I mean OS and language types of features, ie things Java supports) like selecting languages and locales and supporting enumerations stored in the database (as opposed to "hard coded") or modeling states and valid state changes. IMO all of those make much more sense as part of the framework.-David
Yes, I agree that entities like Enumeration should stay in the framework/common component; and in general, I think that we should not move any entity to commonext (aka applications/common) at least initially: we should just use the new component to fix the dependency issue we have right now.
Jacopo
smime.p7s
Description: S/MIME cryptographic signature
