Scott T Weaver wrote:
While I'm +1 on moving the interfaces out from the component implementations, I'm not so sure about moving them into commons.What I had started doing in my branch was moving interfaces out of the component implementations and portal/ and into commons. This makes it easier to test components that may access these other interfaces without having to specifically depend on the component implementation. This also makes our code more modular and extensible. Say, for example, some one wants to implement a persistence store using Hibernate. As the current source layout is set up, the user would have a dependency on the the current persistence store implementation built with OJB because that is where the interfaces are leading them to having to have ALL the dependencies OJB required also. By moving all the persistence store interfaces up into commons, all the developer needs as dependency is the jetspeed 2 commons jar.
As I see it, there are currently two different usages of the commons. One is for building *on top of* J2 specific features like the ServletPortlet or the StrutsServletContextProviderImpl.
The other is for providing interfaces and base classes for assembling and access to the J2 core itself.
From a formal point I don't like it when portlet developers which need only access to the J2 specific features for building *on top of* J2 also import all kinds of core features which are not their concern. I'd rather see those classes be stored in a separate J2 "core" (or whatever).
For now, I'd say move the interfaces to commons but I also would like to discuss if the "core" features aren't better of in a separate core subproject (or whatever it should be called).
Regards,
Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
