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 <[email protected]> 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. >> > >
