Re: Maven: cannot run keel:maven

Mike,

>It is indeed possible to change it with a Maven property. Don't recall
>the name, but it's in the "war" plugin's doc.
>
>
>  
>
maven.war.src (you use it in plugin.jelly :-)).  Also, even though 
Eclipse's web plugin doesn't offer a GUI to change the dir, I found it 
is fairly simple to manually tweek the .j2ee, .project etc. files to 
make it fit a different structure.  So, we are OK both ways.

>>>The uberjar basically contains all of the server-side components of
>>>Keel, in a single jar file. In standalone apps, this gives you a single
>>>jar to deploy. In client apps, ditto - one jar, double-clickable. In
>>>webapps, it's done the same way partly to be consistent, and partly
>>>because this is how the configuration is read now - out of a single
>>>server-side jar file containing all merged resources. Part of the build
>>>of the uberjar is the "config merge" process, which does slow it down,
>>>but is necessary.
>>>
>>> 
>>>Makes sense, particularly for the distributed servers.  I do have a 
>>>question on the direct client.  Before, the KeelURLClassloader would 
>>>deduce the lib directory for the Keel server, build a classpath and 
>>>isolate the server to use just that classpath.  Now, that we are putting 
>>>the uber JAR in WEB-INF/lib, won't the client side "see" the server side 
>>>classes?
>>>      
>>>
>
>Still two seperate classloaders, but yes, it is possible to "cross-wire"
>inadvertantly. OTOH, the module seperation enforced by Maven means you'd
>have to include a "<keel.server>" module in a <keel.client>-type
>module's dependencies - which we can (and will!) check for. Basically
>I'm moving this test from run-time issue to a compile-time check, in
>essence.
>
>  
>
>>  Also, KeelURLClassLoader and URLClassLoaderPath take the lib 
>>dir and add all the JARs in the directory the the server-side classpath, 
>>which would add all the client-side JARs to the server.  Are we not 
>>doing the classpath separation anymore? Obviously, I am missing 
>>something here...what :-) ?
>>    
>>
>
>You're just missing the complexity, as it's not there anymore :-)
>Basically you're right, we don't need to do all the work with the
>classloader magic anymore. As a result, the server side of Keel runs
>(and *starts*) a fair bit faster, interestingly.
>
>  
>
I had to read through this a bunch of times, and puzzle over it.  But, I 
think the light bulb just went on (in my case it is a fluorescent one 
that flickers for a *loooong* time).
What you are saying is that with Maven's dependencies, at compile time 
we make sure the client-side just sees it's JARs and the server side 
sees it's JARs.  Then, at run-time, even though technically the 
client-side and server-side JARs are visible to both sides, we can 
forget the classloader enforcement because we made sure at compile-time 
that everything was cleanly separated.  Did I get it?

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?

Shash