Re: Maven: cannot run keel:maven

Shash:

On Sun, 2005-02-27 at 23:53, Sasvata (Shash) Chatterjee wrote:
> 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.

Good!

> > > > 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?

Yes, exactly. Also, because of the better jar/version management, we can
tell ahead of time if there's a conflict of dependency versions, and
simply fix it, rather than "working around it" with the 2 classloaders.

> 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...

Mike
> 
> Shash

http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com