On 11/29/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > >> that would easy the debugging as well. > >> > > > > why? If you have both sources for api and impl jar in your IDE there > > is no difference. > > > It IS. You have to know at which class to set a breakpoint. Even if you > see a shared class, you have to set the breakpoint to the refactored > shared_tomahawk, shared_impl, etc. Depending on which lib you are going > to debug.
yes, yes, of course - sorry. I should read more carefully. I thought Matthias meant that it's easier to debug if you do not have splittet jars - API and Impl. One of the other 7 discussions we are having concurrently within this thread, you know. ;-) Debugging "shared" IS horror today, sure! Agreed! > Currently this also requires you to know which version you are going to > debug as e.g. Tomahawk uses the shared from the 1.1 trunk while the 1.2 > trunk has its own shared. I already spent a significat amount of time > during debugging until I figured out that fact. > > Also, if you change something in shared you have to run maven ... you > know why ;-) :-) > I don't see any reason why we shoulnd't being able to provide a stable > api even for shared. Thing is: One beneficiary of shared (and not the least important!) is the myfaces-impl, which is a candidate to be provided by J2EE containers. Therefore we MUST ensure that ALL classes that form the actual jsf implementation reside in a private namespace. This is the only way to avoid unwanted sideeffects when users deploy their apps together with other beneficiaries of "shared" (Tomahawk, ...) Please note: this is no unusual case. Some containers use re-packaged XML-Parsers to avoid unwanted sideeffects when a user deploys an app together with a newer (or older) Xerces. Even Sun Java runtime is shipped with a re-packaged Xalan. --Manfred
