Maven2 more….. building

11 12 2006

I’ve now got it all building including osp, sam, sections, gradebook (after a break going to the Mall, went into the Apple store, looked and looked and looked, but walked out empty handed…. maybe nothing is quite as tempting as it used to be, but I did see some iPod games, I wonder when Apple will release the dev kit… if ever) sorry… yes its building now. Next problem is which deployer to use.

Most of the Tomcat deployers try to be to cleaver and integrate with the running tomcat runner, when all we really want is something on the filesystem. I’ve had a long hard look at Cargo for maven2, but it doesnt work… cargo:package and cargo:install don’t work and I don’t really want to have a deploy to a running tomcat so cargo:start is out of the question.

The pluto deployer looks promising, and the existing plugin that I have already does unpack, so there is a chance that either of these will do.

Naturally there is some confusion with deploy to a repository (which part of M2 ontology) and deploy to tomcat.

Atlanta is really quite now, no more Poker BOF’s, Aerodynamics BOF’s from the 49th floor…..

there is a confluence page tracking this, where I will upload the poms, pending getting commit. (http://bugs.sakaiproject.org/confluence/display/~ianeboston/Maven2+Migration+Work)

Advertisements

Actions

Information

One response

11 12 2006
Ian Boston

Looks like the only way to do deployment is to use custom types and seperate poms.

sakai-component Will unpack all the contents of the war to components war Will deploy the contents to the target webapp directory sakai-shared will deploy all the dependencies (not transient) to shared sakai-common will deploy all the dependencies (not transient) to common

This is going to need a change in the deploy mechanism of non sakai shared and common… this is probably better than the current situation since it will more clearly define what is shared and what is not




%d bloggers like this: