Re: Maven: cannot run keel:maven

Mike,

>>But I think we might have a problem still, which was the original
>>inspiration for the class-loader separation.  If the client-side needs
>>Xerces-x.y and server-side needs Xerces-z.q....we can no longer do
>>that, correct? 
>>    
>>
>
>No, you're right, we can't do that - but we can avoid doing it (IMO)
>now. In extremis, we'd have to deploy that particular app in a
>socket/jms/etc mode - but on the other hand, we shouldn't have to, as we
>now have 100% fine-grained control of dependencies at every step of the
>way. The only possible spoiler would be the original webapp - and that's
>why there's a webapp directory in keel-build, for tweaked versions of
>the base webapp, if needed. For example, the current Struts is now using
>a Maven build, so it has all versioned jars.
>
>So again we're basically moving this from a deploy/runtime problem to a
>compile/development time issue. Do you think this will bite us? So far
>with the four UIs I'm currently working with (Cocoon, Struts, Thinlet
>and Swing) it hasn't...
>  
>

I think taking advantage of our existing capability of distributing 
client/server should this problem arise, makes great sense.  I am not 
sure how much of a problem this is.  From memory, I believe the two 
cases we ran into (one actually from Expresso days), was that early 
Tomcat versions insisted on an older version of Xerces than we needed on 
the server side, and the other was that Cocoon/ECM was using a different 
version of Avalon Framework than we were using with Keel/Fortress.  I 
think we can keep the classloader code we have in the source tree, even 
though unused, and if we needed to in the future, it would be a matter 
of moving the uber jar to a different directory than WEB-INF/lib, and 
building a classpath as before....we now know how to do it.

Not that I'd attempt it right now :-), but once things settle out 
completely, we can also remove the Channels (from Doug Lea's concurrent 
package) code from the direct client/server interface and simply make 
method calls.  The original reason for using that was to have a finite 
set of common classes between the client/server, and classloading 
issues....we should be able to eliminate that again, and regain some 
performance.

Shash