Hello David. It's true that if you only have the dependency marked as provided then yes, it won't run. I am not advocating the use of using <scope> provided. That is only if you are programming to the h2 interfaces directly which you aren't and shouldn't be doing. I am advocating that you do not include h2 as an application dependency, but rather a dependency of the runtime environment which in this case is jetty.
If you put the dependency inside of jetty and remove it from the project dependencies, it will run and survive restarts without issue. I see this post from today describing the same symptom I experience: http://groups.google.com/group/liftweb/browse_thread/thread/dd2f48174c9916ef# I respectfully assert that this is an issue and that most people will not know to change up their pom file to correct the issue. Since the archetype is the gateway to learning the framework, it can be and is a stumbling block to those looking for a quick start into liftweb hacking. On Dec 29, 6:00 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > On Mon, Dec 28, 2009 at 1:13 PM, joseph hirn <joseph.h...@gmail.com> wrote: > > Thanks for the response Indrajit. Yes this is the same issue I had > > opened 246 for and sorry for beating a dead horse. > > > The thing is that in most cases, you do want to container to provide > > the db driver. > > If this is the case that you want, then you can change the pom.xml file that > is generated by the archetype. > > On the other hand, this is the default configuration that works just fine > when doing mvn jetty:run. On the other hand, of you do mvn jetty:run and > have H2 marked as provided, the app doesn't run. > > So, this is not a defect. This is the way things should be. If you want a > different configuration, by all means, change up your pom.xml file. > > > > > It's bad practice to create a war file with dependence > > on a specific database, let alone a specific version of the database > > (1.2.121 of h2 in this case) as it limits the reusability of that > > warfile. I say most cases meaning most production cases, but if this > > is a simple example for development purposes, surely having hot > > redeploy for rapid development is of high value. Spending an hour on > > my first day with Liftweb figuring out why Jetty couldn't handle a > > restart was disgruntling. I still haven't even gotten around to > > learning the cool stuff in Lift because of the derailing. I recently > > spoke with another colleague who had the same issue but he just blamed > > it on Maven so you're off the hook =P > > > If you are 100% intent on providing the h2 jarfile inside of the > > warfile then you could configure maven-war-plugin to include the > > dependency only in the warfile rather than compilation class scope so > > it will not affect jetty:run (it would still affect jetty:run-war). I > > could quickly provide the xml to do this if you deem it worthwhile, > > although I would recommend against it. > > > Ultimately I'm just trying to help people who are getting started like > > myself. Thanks for your time and thoughts in response. > > > On Dec 28, 4:36 am, Indrajit Raychaudhuri <indraj...@gmail.com> wrote: > > > Joseph, > > > > I assume your concern is same as the one that you had mentioned here: > >http://github.com/dpp/liftweb/issues/246/find. > > > > While this is a genuine case for the scenario you described, marking db > > > driver as 'provided' has the side effect of not being included with the > > > generated war (because the container would be expected to provide this). > > > > This is fine if the application is deployed on a container using > > > container managed persistence. However, if you are expecting the db > > > driver to be loaded by the same classloader (context classloader) as the > > > application you would be expected to provide it as part of the war (and > > > therefore not in 'provided' scope). > > > > Cheers, Indrajit > > > > On 28/12/09 1:19 AM, joseph hirn wrote: > > > > > I had started another thread about this being a derby issue but it's > > > > more related to the archetype. > > > > > Still in the M8 archetype, h2 db is dependency of the project rather > > > > than a dependency of Jetty. It is better to have jetty declare the h2 > > > > dep because it keeps the sample app database independent. Even if you > > > > are programming directly to H2 API it is better to mark provided and > > > > have it be provided at runtime by the system or container. The bigger > > > > issue I'm experiencing is that it makes Jetty also unable to survive > > > > hot changes to class files for me. If I change a file and compile > > > > while jetty is running I get this error: > > > ------------------------------------------------------------------------------------------------------------- > > > > org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked > > > > by another process. Possible solutions: close all other connection(s); > > > > use the server mode [90020-121] > > > > > $mvn -version > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > > > > Java version: 1.6.0_16 > > > > Java home: C:\Java\jdk1.6.0_16\jre > > > > Default locale: en_US, platform encoding: Cp1252 > > > > OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows" > > > ------------------------------------------------------------------------------------------------------------- > > > > > This is probably because the application is spinning up the database > > > > and Jetty is unable to clean it out entirely due to it being outside > > > > the scope of a normal web application (I assume is spawns some of its > > > > own threads). > > > > > By moving the dependency inside of Jetty like this I no longer have > > > > the issue. I've used Jetty+Maven alot and have had to do this with > > > > other api's, specifically Tibco RVD: > > > [----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] > > > > <plugin> > > > > <groupId>org.mortbay.jetty</groupId> > > > > <artifactId>maven-jetty-plugin</artifactId> > > > > <configuration> > > > > <contextPath>/</contextPath> > > > > <scanIntervalSeconds>5</scanIntervalSeconds> > > > > </configuration> > > > > > <dependencies> > > > > <dependency> > > > > <groupId>com.h2database</groupId> > > > > <artifactId>h2</artifactId> > > > > <version>1.2.121</version> > > > > </dependency> > > > > </dependencies> > > > > > </plugin> > > > [------------------------------------------------------------------------------------------------------------------------------------------------------------] > > > > > On Dec 16, 6:36 am, Xuefeng Wu<ben...@gmail.com> wrote: > > > >> anyone will add the source.jar? > > > > >> On Wed, Dec 16, 2009 at 3:33 AM, Jim McBeath<goo...@j.jimmc.org> > > wrote: > > > >>> It looks like the source jars are missing from the M8 repository, at > > > >>> least for some of the libraries (for example, > > > >>> <http://scala-tools.org/repo-releases/net/liftweb/lift-util/1.1-M8/ > > >). > > > > >>> Are these perhaps located somewhere else now? Or do they typically > > > >>> get added a bit later? > > > > >>> -- > > > >>> Jim > > > > >>> On Mon, Dec 14, 2009 at 11:37:02AM -0800, David Pollak wrote: > > > >>>> Date: Mon, 14 Dec 2009 11:37:02 -0800 > > > >>>> From: David Pollak<feeder.of.the.be...@gmail.com> > > > >>>> To: liftweb<liftweb@googlegroups.com> > > > >>>> Subject: [Lift] [ANN] Lift 1.1-M8 > > > > >>>> The Lift Web Framework team is pleased to announce the > > lift-1.1-M8 > > > >>> release! > > > > >>> -- > > > > >>> You received this message because you are subscribed to the Google > > Groups > > > >>> "Lift" group. > > > >>> To post to this group, send email to lift...@googlegroups.com. > > > >>> To unsubscribe from this group, send email to > > > >>> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroups.com> > > > > >>> . > > > >>> For more options, visit this group at > > > >>>http://groups.google.com/group/liftweb?hl=en. > > > > >> -- > > > >> Scala中文社区: http://groups.google.com/group/scalacn > > > > > -- > > > > > You received this message because you are subscribed to the Google > > Groups "Lift" group. > > > > To post to this group, send email to lift...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/liftweb?hl=en. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/liftweb?hl=en. > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
