Maven-plugin still too much dependent on hardcoded project configuration

I'm gonna try to implement the following corrections and improvements to the maven-plugin:

• Create a separate portal-template resource jar and install it in the repo.
  This should remove the need to have these stored within the plugin.
  I'd like to see the plugin as generic as possible: only functionality, no data (at least, as less as possible)
  Running initMavenPlugin should only be needed again when something in plugin.jelly changes.
• Delay property filtering in the templates to plugin goal execution time.
  Currently, once you run initMavenPlugin you're stuck with (most of) the settings you had at that time.
• Extend/fix different portal name/context handling.
  Right now, "jetspeed" is still embedded in several places causing runtime problems when you try to use a different portal name.
  I'd like to make "jetspeed" a variable value all the way, even when used from the normal (read: non-genapp) context.
• Provide "true" overlay functionality when building your own portal.
  I want to be able to maintain my own portal configuration and load/run portal.install to merge the content of the selected jetspeed-portal-template with my own.
• Output schema generation and run Hsqldb (and hopefully replaced with Derby soon) in the portal target folder (by default), not within the plugin context
  If you run a full test build using Hsqldb (maven j2:start.test.server) the test database is by default run inside the plugin context/environment.
  This leads to a failure at the end because the newly build plugin cannot be installed because Hsqldb has a lock on its database file within the current installed plugin.
  Also, I want the generated sql (as well as the predefined sql) stored in my target portal project so I can (optionally modify, extend and) distribute it.