New "directory" packaging type

I am unassigning this issue as it gives the wrong impression. I dont have enough hours in the day to look at this issue at the moment and keeping it assigned to me give the reporter hope that I might be able to look at it. I am very sorry. If this issue is a real blocker for production then I would suggest you look for resource in the community to fix the problem, I am happy to respond to emails and guide. Where the code base is Rwiki or Search, I have absolutely no problem with someone else working on the code, this after all is a community.

I'm reopening because I think I was able to address Ian's concern.

Ian, hopefully you're OK w/ me just assigning this directly to you. Please let me know if you still believe this is solved elsewhere.

Talked with Jen. Assembly plugin definitely wasn't going to work for us, mainly because of the bugs listed. But it also didn't address the deployment issue – we needed to be able to unroll these configuration artifacts to arbitrary locations.

I did a little more research and found which does almost everything we need. It was just missing two items:

1) Deployment to arbitrary file system locations, e.g. sakai.home can technically be anywhere, so we'd like the freedom to deploy a localized sakai.properties anywhere on the file system. Same basic problem applies to the Terracotta config files we've needed to deploy recently.

2) Deployment of "classified" artifacts. Install of classified artifacts worked fine b/c of logic in ConfigurationMojo, but if you ran your install and sakai:deploy goals independently, the classification specified at install time would effectively be lost.

So... I'm attaching a two-part patch which I believe addresses these two issues while preserving complete backward compatibility with features implemented by SAK-12281.

1) SAK-13700-meets-SAK-12281.diff – source code diff on my working copy of https://source.sakaiproject.org/svn/maven2/trunk. The .classpath changes are misleadingly broad, but Eclipse wouldn't build the pristine project successfully without adding a dependency and apparently changing the build path will completely reorganize .classpath.

2) simple.configuration.2 – Zip file referenced by the diff. Needed for unit tests.

The logic for handling symbolic deploy.target paths (shared, server, etc) is identical to what appears elsewhere in ComponentDeployMojo. To keep the patch as narrow as possible, I just copied and pasted that logic.

I also created a dummy project to demonstrate the implemented configuration options. See -r53457 of https://source.sakaiproject.org/contrib/unicon/config/trunk. Comments in https://source.sakaiproject.org/contrib/unicon/config/trunk/pom.xml should act as a readme.

Our first attempt at this used the assembly plugin but ran into problems. Jen will have more detail, but I think we ran afoul of http://jira.codehaus.org/browse/MASSEMBLY-298 and http://jira.codehaus.org/browse/MASSEMBLY-195.

There is an maven 2 assembly plugin for this purpose which is being used by Kernel 1.

I believe that this is appropriate, please say if not.