This response explains your intentions with the archetype, which is to have a warfile that you can drop into an unmodified container. I assumed it would be to get a development environment setup as quickly as possible and since jetty:run is the prescribed method of getting started, I thought it might help to recommend an alternative pom configuration. There are other methods to create a war you can drop into an unmodified container which will not break jetty:run. I've never touched JRebel because Jetty is fantastic standalone for hot redeploy provided it is configured properly.
I also now see from other posts that you intend to change the h2 connection string so that Jetty can hot redeploy. You've never responded to me with that as a solution, only that the pom has no problems. That is why I felt like my issue was a non-issue and not being taken into serious consideration. So I'm sorry for getting off on the wrong foot with you David. I don't take for granted your efforts on the framework or the work you've put into making jetty easy for beginners. I was only trying to help out and for some people I have. On Dec 31, 12:10 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > On Wed, Dec 30, 2009 at 9:39 PM, joseph hirn <joseph.h...@gmail.com> wrote: > > 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/dd2f48174... > > > 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. > > Let me be clear... badgering me about in issue is not "respectful." You > opened a ticket and I closed it. You posted to this list and I explained > why we were not going to adopt your solution. You posted twice this morning > about this issue including a post about "not being taken seriously." > > I have described my criteria for the default archetypes: they must work > correctly with "mvn jetty:run" from the command line without any other > modifications. Your proposal does not meet this criteria and I have > rejected it. This is not for lack of "taking you seriously." It is because > I and the other Lift committers have been working with newbies and Lift for > almost three years, we've been through thousands of newbie getting started > questions and we've tuned Lift to make Lift easy to get started with. This > means not having to set up a container as part of getting started. > > It is a developers choice as to how to configure their pom.xml file, but the > default Lift archetype will allow the Lift app to start up correctly with > mvn jetty:run or as dropped into an unmodified container. If you want > something different, there's nothing about Lift that requires that the DB > JAR file be specified in the pom.xml file and you are welcome to and > encouraged to change it up to suit your needs. > > So, why is the H2/Jetty restart issue coming up today? I think the reasons > are as follows: > > - Up until recently, Derby was the default DB for the Lift archetypes. > We changed to H2 because by all measures, H2 is better. > - Most developers do not rely on Jetty's code reloading features. They > use JRebel or they kill and manually restart their Jetty instance. > > To summarize: repeatedly asking for the same thing on this list is not > helpful, it's at best a waste of time. We're not removing the DB reference > from the pom.xml file... you can do that if you want. We are working on the > H2/Jetty restart issue. > > David > > > 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 > > ... > > read more » -- 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.
