Rickard, I run into similar issues but I happily resolve them by having extra copies of classes. This is my rationale...
To me a J2EE unit of deployment is ALSO A UNIT OF DEVELOPMENT AND TEST. So if I've tested EJB X (the main element of package X) with a set of helper classes and value objects including java class Y, I don't want the developer of Y to be able to change Y and redeploy it independently of X. This approach suits large team development. Each subteam is responsible for development and testing of a unit of deployment, and once a shared set of interfaces, exceptions, and data types has been agreed and developed they can only be changed with the agreement of all affected subteams. Most of the time subteams can develop independently, which is one of the most critical things to enable in a large team environment. Of course this carries a runtime penalty that may eventually become a problem in production. If it does I develop a more optimised packaging scheme based on the runtime topology of the computing resources and if necessary introduce an additional step in the development process to accomodate the repackaging. Note that this step is typically already present in the process anyway - it's needed for final function testing, performance testing, stress testing and support testing. cheers... Ian ======================================== Ian McCallion Alexis Systems Limited Romsey, UK Tel: +44 1794 514883 Fax: +44 1794 501692 ======================================== =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
