Comments on Alex Kotchnev's Blog: Tapestry5 NetBeans Quickstart

Alex,thanks for the quick response. You' re right,...

2008-10-14T03:45:00.000-05:00

Alex,
thanks for the quick response. You' re right, having to rerun the app after every single change is less than optimal. But you mentioned earlier that 'Tapestry supports reloading of the page templates as well as the page classes'. This doesn't seem to be true.
Is there any way to trigger the build automatically?

Ciao,
Dirk

Here's the skinny on this issue : 1. If you place ...

2008-10-13T16:12:00.000-05:00

Here's the skinny on this issue :
1. If you place your .tml pages inside of your web app context directory (that is, under "Web Pages" in NetBeans), the IDE will automatically copy the changed files into the Maven target directory and you will see immediate feedback in the running app.
2. If your .tml files are at the root of the resource tree (that is, under "Other Sources/resources in NetBeans), their changes will not be picked up automatically.
3. Your changes to java classes will not be picked up automatically. Whenever you want to see the changes to your java page classes (and changes to the templates in the resource tree), then you need to run the project (which redeploys it) and voilla.. the stuff is there.

This is less than optimal, there are a couple of BugZilla issues in NetBeans to address these, in the meantime use these instructions to work w/ T5 and NetBeans.

dirk, there are two things to mention here : 1. ...

2008-10-13T10:45:00.000-05:00

dirk,
there are two things to mention here :
1. First double check that your "archiveClasses" option in the pom is set to "false". As dane pointed out in a previous comment, the default setting for the maven project is to package up the project into a war (which might cause you other problems)
2. The secondary (and probably more relevant to you) problem is that the Maven project type doesn't automatically compile your classes and move them into the maven build directory when you make the changes. Thus (unfortunately), when you make a change to your classes, you'd still need to run a build in NetBeans to have the classes copied out to the target directory. For some reason, I recall that the class reloading used to work for me in Jetty and in Glassfish, I had to do the build.

Hi,I followed this article, but for some reason my...

2008-10-13T10:08:00.000-05:00

Hi,

I followed this article, but for some reason my templates for components do not reload. Neither in Glassfish nor in Jetty via mvn jetty:run. Only page templates show changes immediately.

Please help me!

Ciao Frank

Hi,I'd like to point out another problem with this...

2008-08-05T16:13:00.000-05:00

Hi,

I'd like to point out another problem with this setup that took me a lot of time and patience to figure out...

First of all, I had a problem using Jetty (with the jetty:run command that I added in the project properties under Actions), namely that the Tapestry's error handling page was somehow overriden by Jetty's default stacktrace dump. So this was a big annoyance.

Also, Netbeans does not automatically compile and deploy java sources, you have to redeploy (run) the application when they change.

But templates and other resources are copied directly to the target folder and you can view them immediately on the running server, so you only have to redeploy when you change the sources.

So I tried deploying on Tomcat, which worked, until I tried to redeploy (or rerun) the application while the server was still running. This produced an error java.io.FileNotFoundException: JAR entry log4j.properties not found when the server tried to undeploy the app that was still running. This also caused the redeploy to fail. After a server restart, the app would run normally, but this is too time consuming.

The root cause for this, after a few hours of googling and pulling my hair, is that the tapestry5 quickstart maven archetype contains a configuration option that packages the sources as a .jar file and puts them in the lib folder for the target.

The problem is that the Java runtime caches ZIP file indexes and this causes a file not found error when the underlying jar file is changed.

Editing the <archiveClasses> option in the pom.xml file in the root of your project from true to false makes the project deploy the application normally, as an exploded war.

Note that you probably have to do a clean afterwards or manually delete the project's .jar file in the target/project-name/WEB-INF/lib directory.

Hi,My name is James Branam and I'm the NetBeans Co...

2008-05-19T08:22:00.000-05:00

Hi,
My name is James Branam and I'm the NetBeans Community Docs Manager. Your blog entry would make a fantastic tutorial for our Community Docs wiki (http://wiki.netbeans.org//CommunityDocs). Would you be willing to contribute it? If you need any help or have any questions, please contact me at james.branam@sun.com. I look forward to hearing from you.