Mark, I have now got grep working (following a post from another member indicating that built into git bash!)
> ant download-test-compile This is useful to know as I didn't run the tests script until later. > ant download-validate This didn't report Checkstyle missing - probably as not needed for actual development. Running Checkstyle using ant -Dexecute.validate=true validate did then update the libraries folder > I doubt you'll need a release build So do I by the sound of it - I will probably come back to the forum when looking to commit anything for the first time but I assume that I will just upload any changes that, once approved, will form part of the next release. Of course I will be able to benefit from the newly developed time-delay in the meantime :) I have passed on your observation "but NetBeans is not taking into account the isELIgnored="true" page directive" to the NetBeans community > I'd see if you can disable the JSP validation. If it makes you feel better, > Eclipse's JSP validation has similar issues. That has no effect! We can drop the issues over JSP as the NetBeans community has taken up that baton. > That is an abstract base class. You won't be able to run it. Trust me to pick that one! I have only ever written simple unit tests so not needed to create any abstract classes in my testing, but I should have spent more time looking into your source and then would have spotted the 'abstract' keyword!! In a very weak defence, I tend to use interfaces rather than abstract classes. Anyway, thanks for the naming conventions, that will prove time-saving. For good measure, I ran TestDefaultServlet and that ran the tests successfully. Thanks for the explanation of the dual 'bin' folders. > Yes, the Java compiler is smart enough to generate the byte code as if it was > generated with Java 11 so you are fine to stick with Java 17 as long as the > build version is 11. I have amended my project options to reflect this and rebuilt the project to check everything still works - it does! > Ah. You need to add webapps/examples/WEB-INF/classes as a source folder. That > should fix the two issues above. I must still be missing a link here, I have added that folder to the list of <folders> elements. I also added it to the <view> since, as the project references files inside this folder, it seemed applicable to include it. However, it didn't appear to make any difference - i.e. NetBeans still couldn't tie the source back to those Java classes. I have checked that I have typed the paths correctly and I can see the trailers.ResponseTrailers (& util.CookieFilter) file(s) in the WEB-APP\classes and visible in the project folders (I assume as added to <view>) to back-up paths are valid. NetBeans doesn't let me take any action to try and find the file to resolve the [!], I assume because it is a free form Ant project and so configuration is 'read-only' once loaded (I would have options in Maven to locate the missing resource). I have added my current project.xml and Trailers.ResponseTrailers.jpg to the DropBox folder in case either of them helps. My only observation is that, as I can't find a corresponding XSD file for project.xml, there is another attribute I need to set to indicate that these are class files in a different folder to the one the other package files are in, but that seems unlikely. > I think you mean 8000 for remote debugging but otherwise great. If you can > get this working, you are doing really well. I was using 8080 and appeared to be working although I have not used it in anger yet. I had amended the catalina.bat line "set JPDA_ADDRESS=localhost:8080, because I connect to Tomcat using http://localhost:8080/examples. Your statement concerned me slightly in that I now believe that I had made a wrong assumption. Anyway, I amended the catalina.bat back and set NetBeans remote debugging to the same and it worked as well so I will leave it at 8000. I couldn't find anything on the web re Port 8000 vs 8080 (apart from "use which one you want"), but I suspect that, ideally, the debugging communications should be using a different port to the application otherwise there may be conflicts but couldn't find anything to back up that hypothesis. > - Patch file in diff -u format attached to a BugZilla issue > - GitHub pull request > Happy to provide pointers for either approval if needed. Unfortunately,II will now probably have to wait a bit for that. I will soak the changes to the NetBeans configuration files while I explore Tomcat, once the webapps/examples/WEB-INF/classes issue is sorted and (hopefully) the NetBeans community has resolved the other exceptions. That way, if I discover another missing link, I can incorporate it and upload all the configuration changes at once to minimise confusion. However, I am away in a weeks time - 5th March (Snowboarding at last!), and have to catch up with some other chores / tasks before getting back on the laptop. Hopefully, we can get these last minor sticking points resolved prior to the 5th. Thanks again for your continued patience and valuable insights. John --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
