Re: Maven: cannot run keel:maven

Mike,

>Oops. Checking in now...
>  
>
I see the checkins....I'll get them....ADSL here is painfully slow :-(

>>So, I ran "maven war" from my project directory. It built 
>>default-1.0.war and default-1.0-uber.jar.
>>    
>>
>
>Default-1.0.war? That's wierd. It should just be "default.war"
>
>  
>
You are right, it is default.war....I  have been looking at the Maven 
repo too long :-).

>>  How do I run the Keel 
>>webapp?  Putting default.war in Tomcat's webapp directory is what I did, 
>>but it doesn't expand any of the JSPs. etc.
>>    
>>
>
>This is what someone else was reporting - it's *supposed* to be using
>the "preGoal" in the Keel plugin to put all the JSP material in the
>right place. I must be out of sync still...
>
>  
>
>>  I noticed that default.war 
>>includes default-1.0-uber.jar in WEB-INF/lib, and in it are all the 
>>JSPs, XSLs, etc.....how are we supposed to use this bundling scheme?
>>    
>>
>
>The uber shouldn't have any JSP's in it. Any jars marked as <war.bundle>
>are *NOT* included in the "special" uber built for a weball (so no
>duplication). The idea is the JSP's (etc) are extraced, copied into
>src/webapp, then bundled up into the war as normal. Do you show anything
>in src/webapp?
>
>  
>
In src/webapp, there are: META-INF/, test/, WEB-INF/ and 
jspRedirector.jsp (only file in there, the other three are 
directories).  This is the same as in target/default.
In default-1.0-uber.jar, all the XSL files are in src/xsl/cocoon/*/*.xsl 
and all the JSPs in src/jsp/struts/*/*.jsp.

>>I know you said that some of the comm-*  modules need to be split-up 
>>further, but as it is, is Keel runnable when built with Maven?
>>    
>>
>
>Quite runnable. I've been running 3 or 4 (so far) of the example apps,
>as well as 3 custom apps I have going locally, and Helm
>(example-projects/helm)
>
>  
>
Oh...what I'd give to be there :-).  I guess something different between 
yours and the CVS version.

>>Also, could you please summarize how the Maven build system 
>>(project.xml) needs to be configured to tell what pieces of a module go 
>>to the client and server sides?  As I understand it:
>>- Any and all dependency JARs will go to the Keel-sever side
>>    
>>
>
>Unless they are marked <keel.client>, yes.
>
>  
>
>>- Any dependency marked with a  "<war.bundle>true</war.bundle>" property 
>>will *also* be copied to WEB-INF/lib.
>>    
>>
>
>Yes - but not duplicated in the uberjar. Basically the uberjar is the
>server piece.
>
>  
>
>>- What is the function of the  "<keel.server>true</keel.server>" property?
>>    
>>
>
>To indicate jars that are in both client *and* server sides
>
>  
>
>>- Is there a way to specify that a JAR is *only* for the client side?
>>    
>>
>
>Yes. <keel.client> :-)
>
>  
>
OK...got it.  by default, dependency is server-side.  You specify 
keel.client to put it on the client side.  keel.client and keel.server 
both to put it in server as well as client.

>>- I think the resources definition in project.xml is used to copy stuff 
>>to the webapp.  Generically, how and where do I put stuff in a 
>>particular (custom) module that I want copied over to the root directory 
>>of the webapp?
>>    
>>
>
>Hmm. Src/struts would do it for Struts, but I like your suggestion below
>- cleaner...
>
>  
>
What I am after is a place to put "common" stuff for all clients, for 
instance, static HTML pages for a site, etc.  Also, I need a place to 
put files that should be copied over to WEB-INF, for instance, config 
files for Sitemesh, which are common regardless of Struts/Cocoon, etc.

>>- A suggestion:  now would be a good time to move away from "magic" 
>>mappings in our build system.  For instance, we have src/jsp/struts for 
>>Struts stuff,src/xsl/cocoon for Cocoon, src/vm/velocity Velocity, etc.  
>>which get mapped into the webapp root.  Instead, we could just have a 
>>src/webapp or webroot, or whatever that would be the place to put UI 
>>files for all apps, and not have the build system know about specific 
>>dirs for specific types of clients.
>>    
>>
>
>The only snag I see with that is that we then get *all* client files for
>*all* UI's - e.g. all the cocoon files end up in a struts deploy, right?
>  
>
>>  The module author could still group 
>>files by client if they so chose, just the build system wouldn't know or 
>>care.  This would work much better with the various WEB/J2EE IDE plugins 
>>also, for instance the Eclipse J2EE plugin puts the web root files in 
>><project>/WebContent.  If we did this, what we have now would need some 
>>edits to work, but it would be relatively easy to do.
>>    
>>
>
>Yes, I agree - simple is good! But how to avoid copying the unnecessary
>files? Or do we care?
>
>  
>
You are right, copying unused files would be the downside.  My own 
feeling is "don't care".  For the Keel modules, we need to package *all* 
the UI files in the JAR anyway, since we can't tell which client user is 
going to choose.  For users' own files, most likely they will stick to 
one type of client anyway.   But I think  the overall simplicity  and 
the  generality of the layout for all clients would be a big benefit, 
and this would be a small price to pay. 

Shash

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