I confess to forgetting the abbreviation taxonomy, but does "impl" below refer to the JSF container implementation? If so, I would suggest that you do *not* want Tomahawk or the examples to have direct dependencies on those classes -- because that locks them in to only the MyFaces implementation (a current example of this being the way that Tiles is integrated with MyFaces). Thus (again, if my interpretation is correct), you'd want the following as your direct dependency chains:
api <- share api, share <- impl api, share <- tomahawk api, share <- sandbox (perhaps depend on tomahawk or impl also for some use cases) api, share, tomahawk <- examples Right? Craig On 7/7/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > Hi All, > > I'm playing around with the reorg and trying to get started on > building tests and I've run into the following snag; > > The UIData has a dependency on > > org.apache.myfaces.component.html.util.HtmlComponentUtils > > which is currently in the tomahawk project. This causes a dependency > on tomahawk from api (a circular dependency). > > My understanding of the dependency tree is as follows > > api <- share <- impl > > api, share, impl <- tomahawk > > api, share, impl <- sandbox > > api, share, impl, tomahawk <- examples > > Since the only (apparent to me anyway) additional functionality of > HtmlComponentUtils.getClientID is to consider 'forceId' shouldn't > this call be in a myfaces specific subclass in tomahawk instead of up > in api? Users can't use 'forceId' unless they are using the x: tags > anyway correct? > > HtmlDataTableHack appears to be the best place currently to put this > functionality. > > Thoughts? > > -bd- >
