Thanks for taking part in this, Mick. Online discussions are always better when others participate :p
From: [EMAIL PROTECTED] on behalf of Mck > > Front end development. There¹s no need to rebuild the war and restart tomcat > > if only templates (or css, javascript, etc) have been changed. > > For css development i edit the css in place in firefox. Once i've found > what works i repeat it into the original source file. > > Is there something similar for javascript? Firebug has a very useful console, which lets you type in (multi line) javascript code. It doesn't seem to be able to modify existing code, etc, on the fly - but the console will do a lot for you. As for the css development technique you mention, I find it pretty hard to remember exactly what changes I've done when I do it though firebug or similar. That leads to me never being able to implement in into the source code at first try, which again leads to several build processes. Being able to modify the .css files and having tomcat notice this "on the fly" removes this problem all together. And I think this is something we should try to achieve. After all, removing extra steps is (almost) always good. ;) > > E.g. If only > > a couple of .vm files have been modified it¹s enough to copy these out to > > tomcat. > This exists already and is part of > http://sesat.no/debugging-velocity-templates.html > That is putting > -DVELOCITY_DEBUG=true -DVELOCITY_DEVELOP_BASEDIR=<paths to templates> > into CATALINA_OPTS (VELOCITY_DEBUG turns off caching so it required. it > is different to VELOCITY_DEBUG_ON). Endre mentioned that this was problematic when it comes to templates and inheritance. E.g. since a template can be fetched from several locations (sitesearch, genericno, generic in our case), the velocity debugging thingy can easily get confused. But, yes. This should be very helpful. Especially when dealing with just one layer of templates. > > Something similar for class files would also be great, since most > > IDE¹s build new class files when they¹re edited. > As long as your container has auto-deployment enabled, you can hit > a /search/? request with the additional parameter reload=all > This should clear out all instances in all SiteKeyedFactories. > Meaning that skin configurations and classes are loaded from scratch by > the sesat-kernel. > I'm not too sure how stable the classloaders are here but i know it > works with configurations files. And it would definitely be nice to have > a reload=java option to clear out just the classloaders belonging to the > site. See FactoryReloads.ReloadArg > > A way of automating this through the IDE would be good. Mick, you might know > > of good ways of achieving this in NetBeans (?). > Well the maven build automatically copies the war files over for you. > So you build the war project in your IDE and you'll have already > deployed the war file to your container. > Since it's often two projects that need to be compiled i use command > line like: > cd search-command-control/; mvn install; cd - > cd war/; mvn install; cd - > and just cycle between them. I'm really more interesting in a way of not having to build the whole war file every time. I feel it often should be enough to compile just the java file(s) that's been modified, and copy the new class file(s) to tomcat. I'm not familiar enough with war's and maven to know if this really is possible. I'll try to investigate this a bit further, but after a short test netbeans, at least, doesn't seem to compile java files instantly as they're modified and saved. At least the class files in the target directory isn't updated. > > A possible solution could be symlinks from $TOMCAT_HOME/webapp/<app> > > to the different target dirs though I¹m not really sure if this is > > possible due to the structure of the projects. > I have successfully used this approach before. > While it works it's a headache when you have multiple checkouts and wish > to change between them. I find the only real wait is the tomcat restart, > not the file copy time, so here the maven build copying the war files > suffices. I see. I guess the multiple checkout thingy can be fixed by switching between several different webapp directories (each one having symlinks pointing at different places). -- Magne _______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
