Thanks for the suggestions Aaron. Comments inline.
On 6/21/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
There are two options you should be aware of for a plugin.
One is that you can declare a database pool dependency named
"LiferayDatabase" or whatever. Then provide a Derby database pool
plugin with that name. If the user creates a custom database pool
named "LiferayDatabase" then the Liferay plugin will map to that,
whatever it is. If not, it will download and install the Derby
database pool. (This only works for embedded databases like Derby
where there's no need to point it to a specific DB server, etc.) The
simple alternative is to make the database pool a prerequisite instead
of a dependency, which would mean the user would have to create a pool
with the right name by hand before the plugin would install. As a
side note, we're certainly open to more customized handling of
database pool dependencies, but it's not there in 1.1.
OK this sounds perfect. Before you revealed this I was planning to
create two liferay plugins -- one with the "LiferayDatabase"
dependency and one without -- and then count on the user that has
manually created the db pool to pick the one without the dependency.
But IIUC I can use the technique you describe above to create a single
liferay plugin with the dependency and as long as the manually created
db pool is named correctly the plugin installer will do the right
thing. Neat.
The other option is that a plugin can "obsolete" other modules or
plugins. So the Liferay can obsolete the welcome app, meaning the
welcome app will be uninstalled when the Liferay plugin is installed.
It's kind of heavy-handed, but probably better than having it install
and immediately fail due to the context root conflict.
Brian Chan sent a note earlier that says I can in fact change
liferay's context root by adjusting some XML and a properties file.
I'll look into that but it's nice to have this feature you describe in
my back pocket.
As far as populating the database, you can provide a GBean that runs
whenever a flag like "initialized" is false. Every time it starts it
can check the flag and abort if it's set. If it's not set, it can do
its work, and then set the flag on itself (via a roundabout kernel
call), so it will never execute the initialization again. Or, of
course, just connect to the DB and only execute the initialization if
some known Liferay table is not present.
Since I'm using derby I believe that the DirectoryInitializationGBean
Matt pointed out should do the job. But longer term I agree that a
more specialized GBean like you describe is the right way to go. I'll
create a JIRA for a reusable version of the specialized GBean and
maybe this item can make it into 1.2.
Thanks,
Paul
