Re: Maven: cannot run keel:maven

Shash:

On Sat, 2005-02-26 at 20:48, Sasvata (Shash) Chatterjee wrote:
> Mike,
> 
> >>ent ahead and checked out keel-build form CVS, which does have module 
> >>map.properties, and was able to do a "maven war".  Hoever, default.war 
> >>only has JAR files in WEB-INF/lib, but nothing else.  Just FYI.
> >>
> >>Maybe you can try defining a brand-new/different KEEL_HOME with nothing 
> >>in it, and see if it works for you?

It does now, but now I again have some checkins to catch up on :-)
> >
> >I'm doing some tests today installing from scratch on a "bare" machine,
> >so I'll be trying this several times, and no doubt will trip over it and
> >a few others :-)
> >
> I have the latest tool-maven (3.0) built from CVS and installed in local 
> Maven repo.  Same with the Keel Maven plugin, got 1.2.3 (what is in 
> CVS).  I did a plugin:install, and "maven -i" shows the correct version.
> BTW, how do I build the keel-build JAR?

Ah - there's a project.xml I have here that I need to check in, then you
can build it with the regular "maven jar" and deploy with "maven
jar:deploy". The Maven doc gives the scoop on stuff you have to put in
$HOME/build.properties to be able to deploy.

> When I run "maven keel:maven" it complains about the POM for 
> comm-jms-1.0 missing from the Keel remote repo.

Ok, should be there now.

>   Also, the comm-jms 
> module in CVS is empty, so I couldn't generate it locally, either.

Oops. Checking in now...

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

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

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

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

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

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

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