roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave <>
Subject Re: location of db creation and migration scripts in Roller 5
Date Sun, 14 Feb 2010 03:58:44 GMT
That was entirely my mistake and I'll fix things so that they work as
they did in 4.0, with the scripts in WEB-INF/classes/dbscripts.

- Dave

On Mon, Feb 8, 2010 at 10:39 AM, Anil Gangolli <> wrote:
> I found out that the second issue is due to the fact that the
> ClasspathDatabaseScriptProvider can find the createdb.sql script in the
> roller-planet-business jar instead of the roller-weblogger-business jar.
>  You can get lucky and find the right one or unlucky and pick up the wrong
> one (from the planet jar) at autoinstall time.
> Also (separate issue) the SQLScriptRunner class has a problem parsing the
> one from the planet jar because of the way it ends in comment lines.  It
> needs to end in a statement.
> I think this says we need the scripts to all end up somewhere under
> WEB-INF/classes which is prioritized by the class loader, or we need to
> start naming things distinctly and distinguishing at auto-install time.  The
> latter might be better, but would require some additional code and build
> change.
> Comments?
> On 2/8/10 7:17 AM, Anil Gangolli wrote:
>> Dave et al.
>> After building off the recently mavenized trunk, I found that the real db
>> scripts end up inside the roller-weblogger-business jar under the classpath
>> /sql/<dbtype>/.  There are still a number of older ones ending up in the
>> exploded war  target/roller/WEB-INF/classes/dbscripts/<dbtype>.  These
>> probably ought to go away or be unified with the new ones.
>> The ClasspathDatabaseScriptProvider is prepending the old path
>> ("/dbscripts/" instead of "/sql/") and not finding the createdb.sql for
>> automatic creation/upgrade.
>> It's easy enough to fix the path formation (which I intend to commit to
>> trunk for now, just so it will work), but I think we ought to consider
>> whether having the scripts in the jar is the right thing.  It makes any kind
>> of manual execution or tweaking harder.
>> On a separate, but related note, once I fixed the problem locating the
>> createdb.sql resource, the execution of it by the auto installer is failing
>> after about six tables complaining of an error reading or parsing the
>> script.  If I manually extract the script from the jar and run it via mysql,
>> it seems to work fine.  I am still debugging what is causing that.  It might
>> be some kind of line termination issue or platform-specific issue.  I am
>> currently working on a Mac.
>> --a.

View raw message