Hi guys, where things are breaking right now is exactly where we have been too lenient in the beginning and have made tomahawk to be based on impl where it shouldn't.
regards, Martin On 3/9/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: > Mario, > As mentioned earlier, yes, there is some pain with the new shared > structure. But my feeling is that most of the pain is due to the fact > that we have to break with some (bad) habits. > > Please think of the two libs shared_impl and shared_tomahawk as two > *different* things. This affects debugging as well. There is no such > thing as a breakpoint in shared. Because there is no such thing as a > shared lib from the view of impl or tomahawk. You must really discard > that kind of thinking from your brain. The shared module is a *tool* > to create the two different libraries shared_impl and shared_tomahawk. > Nothing more! There is no (and there must not be any) single > dependency on shared from core or tomahawk. So, from the perspective > of core and tomahawk there are the two jars shared_impl and > shared_tomahawk. They differ in nothing to other (third-party) libs > that core and tomahawk depend on. Even more, there exists a > *-source.jar for each of them that can be used for convenience in > IDEs. You can debug or set a breakpoint within commons-logging code, > can't you? So, I do not see any reason why one should not be able to > debug shared_impl or shared_tomahawk in any IDE. > > The other issue is the class.getName() (or FQN-Strings) problem. > Yes, of course, this can be a problem now. I feared things like that > and I will try to help resolve those issues ASAP. Let's look at the > key of the problem here: Why is it an issue when shared_impl and > shared_tomahawk have different FQN-Strings during runtime? Actually > having a problem with that is a sign for having a *functional > dependency* between shared_impl and shared_tomahawk - which is a > no-no! We must get rid of any functional dependency between them > because otherwise > * we still are away from beeing able to release core and tomahawk in > different release cycles, and > * we have no guarantee that tomahawk is independent of myfaces core - > ie. that tomahawk is able to run on top of another JSF impl > > Sorry, I do not see a practicable alternative to our current > architecture. But, of course, we can discuss everything, no question! > Please, tell me if, if there are still unclear issues. > > Manfred > > > > > On 3/9/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Hi! > > > > Its again me ... somewhat angry, so sorry *grrrr* I CANT SET A > > BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl > > and shared_tomahawk. > > Please lets discuss again why this refactoring is needed - PLEASE !!! > > > > > Now I propose to get rid of all those class.getName() (or > > > this.getClass().getName where required) and replace them by a string > > > literal (representing the FQN of the class without any refactoring) > > > > > We cant use the FQN as then the refactoring happen on this string > > literal anyway. > > So I change my proposal to use org.apache.myfaces.XXXXXX > > > > WDYT? > > Mario > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
