Hrm, perhaps you should have qualified your advice: "If you're using NetBeans, then for best performance..."
Also, the packaging of markup on the classpath allows you to create re-usable JARs of components and IMHO is one of the best features of Wicket. So perhaps the qualification should really be, "If you're using NetBeans, and you're not planning on packaging your Wicket components in a re-usable JAR, then for best performance..." The way your original post is phrased makes it sound like a best practice, and it implies the Wicket default to fetch markup from the classpath is inferior. I don't think this is a consensus among the community. jk On Thu, Jun 03, 2010 at 08:57:43PM +1200, [email protected] wrote: > Martijn, > > You are making a *lot* of assumptions. > > Not everybody uses Eclipse. > > Nobody in this thread would consider restarts acceptable, still we are > using this subject. > > HTML files location has to do with performance in the developing > process depending on how the IDE handles the files. > > Please advise how to configure the NetBeans IDE to redeploy a HTML > file in a Java package in a J2EE app server with the same speed as > HTML files in the web directory (milliseconds not seconds). > > > Thanks > > Bernard > > > > > On Sun, 30 May 2010 15:23:09 +0200, you wrote: > > >Huh? > > > >Storing the HTML in the packages has *nothing* to do with requiring > >restarts. Only wrongly configured IDEs may cause that. > > > >If your HTML doesn't get reloaded when you change it, then you should > >run Wicket in DEVELOPMENT mode. Also make sure you've configured > >Eclipse to copy all resources (not just .properties files) > > > >The Wicket Quickstart project and using Maven to generate your eclipse > >project files (mvn eclipse:eclipse) will configure everything > >correctly. > > > >Martijn > > > >On Sat, May 29, 2010 at 11:18 PM, <[email protected]> wrote: > >> Hi, > >> > >> For best performance of redeploys in Wicket, consider storing HTML not > >> in the Java package structure but in the web directory. So if your IDE > >> and app server allow for hot deployment, then HTML changes deploy much > >> faster, ie instantly. In your application init(), you add one > >> statement > >> > >> getResourceSettings().addResourceFolder("wicket"); > >> > >> where "wicket" matches the url-pattern in your filter-mapping in > >> web.xml. > >> > >> PLease see https://issues.apache.org/jira/browse/WICKET-2881 for some > >> background on how to take this one step further. > >> > >> Additionally, with GlassFish V3, you get session preservation on hot > >> deployment of Java classes. > >> > >> You can enable "deploy on save" for convenience. > >> > >> If that is not fast enough, you can run your app in debug mode and hot > >> swap classes after save while you are debugging it. > >> > >> All this comes with the NetBeans IDE. You really don't have to worry > >> about this stuff anymore. > >> > >> Regards > >> > >> Bernard > >> > >> > >> > >> On Sat, 29 May 2010 16:12:46 +0100, you wrote: > >> > >>>have you tried JRebel? ?I've not used it myself, but there was an > >>>interview on JavaPosse recently, sounds like it'd be an ideal fit for > >>>any Wicket developer. > >>> > >>>Dan > >>> > >>>On 22/07/28164 20:59, David Chang wrote: > >>>> I am using Tomcat, any tips about how to develop out > >>>> recompiling/restarting after every change? > >>>> > >>>> Best. > >>>> > >>>> --- On Fri, 5/21/10, Jeremy Thomerson<[email protected]> ?wrote: > >>>> > >>>> > >>>>> From: Jeremy Thomerson<[email protected]> > >>>>> Subject: Re: Can I develop without recompiling/restarting after every > >>>>> change? > >>>>> To: [email protected] > >>>>> Date: Friday, May 21, 2010, 12:17 PM > >>>>> the easiest way to do this is to use > >>>>> the Start class (Start.java) from the > >>>>> quickstart to run an embedded jetty instance in your > >>>>> IDE. ?then, if you run > >>>>> it in debug mode, it will hotswap any possible changes (and > >>>>> tell you if you > >>>>> must restart if it's an incompatible change) > >>>>> > >>>>> -- > >>>>> Jeremy Thomerson > >>>>> http://www.wickettraining.com > >>>>> > >>>>> > >>>>> > >>>>> On Fri, May 21, 2010 at 10:53 AM, ekallevig<[email protected]> > >>>>> wrote: > >>>>> > >>>>> > >>>>>> I'm a front-end developer trying to learn Java (total > >>>>>> > >>>>> n00b) and working on > >>>>> > >>>>>> a > >>>>>> wicket application at work. ?The whole process > >>>>>> > >>>>> feels very slow primarily > >>>>> > >>>>>> because I have to recompile and restart JBoss every > >>>>>> > >>>>> time I make a change. > >>>>> > >>>>>> So I'm wondering what the best way is to avoid having > >>>>>> > >>>>> to do this when > >>>>> > >>>>>> editing .java/.js/.css/.html files during development? > >>>>>> > >>>>> I'd like to just > >>>>> > >>>>>> make > >>>>>> changes and then refresh the browser to test -- is > >>>>>> > >>>>> this possible? > >>>>> > >>>>>> I've seen in the FAQ that you can change the > >>>>>> > >>>>> application settings to > >>>>> > >>>>>> auto-reload markup .html files -- where would I insert > >>>>>> > >>>>> this setting > >>>>> > >>>>>> (remember I'm a total n00b). > >>>>>> > >>>>>> As to .css/.js/.java files -- do I need jRebel or > >>>>>> > >>>>> something like that to > >>>>> > >>>>>> get > >>>>>> these files to reload automatically? > >>>>>> > >>>>>> Thanks for helping out a super-beginner :) > >>>>>> -- > >>>>>> View this message in context: > >>>>>> http://apache-wicket.1842946.n4.nabble.com/Can-I-develop-without-recompiling-restarting-after-every-change-tp2226360p2226360.html > >>>>>> Sent from the Wicket - User mailing list archive at > >>>>>> > >>>>> Nabble.com. > >>>>> > >>>>>> > >>>>>> > >>>>> --------------------------------------------------------------------- > >>>>> > >>>>>> To unsubscribe, e-mail: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
