I believe it is much more intuitive to have a shared package for both the components and the implementation to use instead of doing build wizardry and copying the shared codebase to both implementation and the components.
You are just creating redundancy (even if it is automatically executed) like that, and even more, you can get problems if you have the shared code in both the implementation and the components and you get different versions of the code... regards, Martin On 5/30/05, John Fallows <[EMAIL PROTECTED]> wrote: > On 5/30/05, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > The "shared code" issue was misleading in Sean's first mail. In fact > > it was a typo - Sean, please correct me if I missed something. > > John, to get your confidence back ;-) please be assured, there is not > > a single class that is shared between api and impl in a way that makes > > api depend on impl. The "shared classes" we speek of are shared > > between impl and components (aka tomahawk). > > Thanks for clarifying, Manfred. :-) > (and btw, I have every confidence that MyFaces will be a great success) > > On the issue of dependency between impl and tomahawk components - it > would be ideal if there were zero dependencies upon the impl codebase. > I don't believe it is feasible to reverse the dependency direction, > and have impl depend on tomahawk components, since the MyFaces impl > should be able to stand alone. > > One possibility that eliminates this issue is to repackage the shared > implementation code (automatically during build) into each > implementation codebase. I have seen other projects do this, > especially for package-private utility classes that are needed by > classes in both the private implementation and the public API, but > without exposing those utilities in the public API contract. > > Alternatively, rather than weaving build magic, some of these shared > classes might be promoted into the public API for everyone to use. > > Kind Regards, > John Fallows. >
