roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil Gangolli <>
Subject Re: location of db creation and migration scripts in Roller 5
Date Mon, 08 Feb 2010 15:39:46 GMT

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.


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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message