Re: Maven: cannot run keel:maven

Shash:

On Sun, 2005-02-27 at 20:23, Sasvata (Shash) Chatterjee wrote:
> Mike,
> 
> >I've been fixing a lot of things, and getting further behind on
> >checkins, sorry! Catching up this morning as best I can.
> >  
> >
> No problem....this is a big job!

Getting smaller, fortunately, and thanks to your help!

> 
> > One other item here: I used to be using the 
> > module-properties.properties to determine which Keel module was client 
> > side, etc. Then I realized you
> >
> >can put a "properties" section in the POM. The latest MavenTool doesn't
> >rely on the .properties files in keel-build at all anymore. If you check
> >various POM's, you'll see the properties are in there.
>
> Great.  This means we no longer need to use "maven keel:maven", right?

Well, it's still very handy for adding all required dependencies, and
checking for cross-module conflicts. It's just that now it gets it's
info from the POMs directly, instead of an intermediary file

> > I believe that's it, yes. I really need to get all this written down -
> >
> >as soon as I'm sure it works 100%, which from your report, it isn't yet! 
> >
> I am ready to help debug this :-).  Looking in what's generated, 
> temp/webapp seems to have the required JSPs, etc., but it also has conf 
> and other stuff as well. The JSPs are also in temp/newjar.  It seems 
> like whatever code is copying the JSPs etc. to temp.newjar (which ends 
> up in uberjar, I think), should be copying those to src/webapp instead.  
> Am I on the right track....where should I go debug this with some etra 
> echo's?

Yes, this is definitely the right track. The plugin.jelly in the
keel-build/maven-plugins/keel dir is where the action for that is.

> > I agree. I suggest we use src/webapp, as that's the Maven default place
> >
> >for webapp files to "live".
> >
> Sounds good.  I'll see here if the IDE's let us change this to whatever 
> we wish or not.  If not, it might be helpful to use a Maven property for 
> the directory, which if not specified, remains src/webapp by default.

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.

> > CAVEAT: If in the project you actually build
> >the "war" from you put stuff in src/webapp, it will get toasted as part
> >of the build process, as that's where the stuff extracted out of the
> >jars gets copied. So don't do a "maven war" or a "maven war:webapp" in a
> >module directory!
> >  
> >
> Ouch...wonder if we can check for this....this could be a devastating 
> one liner bomb in the waiting :-(

Indeed. Not sure how to check for it, though - perhaps just back up the
dir in case...

> >I'll give this a try here, if it's clean I'll go ahead & check in.
> >Should reduce confusion even further, which is always a good thing!
> >  
> >
> Mike, it might be better for us to wait until the rest of the build is 
> working for us all, and then only do this one change.

Agreed. One miracle at a time :-)

> I am taking the conversation from the other email with the same subject 
> to reduce extra postings. 
> 
> >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.

> >W/o re-writing the config handling (again), yes, we need the uberjar. No
> >doubt there are faster ways to build it, but I wanted it to work
> >properly at first, not necessarily quickly.
> >
> >  
> >
> Understood.  I definitely agree, get the build to stabilize, then make 
> it faster.  Just wanted to make sure, I wasn't doing it the long way 
> because I didn't know the right way to do it.

I think when we clean up some of the unit tests to make them "real" unit
tests (as opposed to integration tests), this will be less painful. I'm
sure there are many optimizations to the build possible, however.

> 
> >No, I don't think you are. I'm loathe to optimize this too much until it
> >settles down as completely rock solid, as anything other than a "total
> >re-build" requires more thought on the developers part, and there's
> >already too much to think about when building as it is (still).
> >
> >Simple is a bit slow at this point, I realize, but I'd like to defer
> >optimizations as long as possible.
> >  
> >
> OK...make sense.....we can look at this later.

Not too much later :-)

Mike

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

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