I'm completely +1 for what Manfred is saying here. I don't think there's ever been a clearer explanation of what we're doing and why with the current setup. In fact, I never completely understood the details until this mesage.
Note that I'm probably the most-adversely-affected person by this (I don't have any Maven knowledge, and I am an Eclipse user, so I'm dependent on Werner/Mario/others for telling me how to make all of this work together). But I don't see any problems with what Manfred has suggested from an IDE (Eclipse-centric) point of view. And as he points out, if there's an issue revealed by this change, then it's a real dependency issue between tomahawk and Impl that needs to be fixed rather than re-hidden. 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.
