Re: Maven: cannot run keel:maven

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!

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

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

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

> 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 :-(

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

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

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

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


Shash

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