DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34361>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34361 Summary: Using Manager ant tasks is messy Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Webapps:Manager AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Using ant tasks to deploy, undeploy apps, etc. requires one to copy and paste taskdefs from the documentation into their build.xml which is messy. The docs also instruct the user to copy the catalina-ant.jar file into the $ANT_HOME/lib directory, which is unnecessary if you specify the classpath in your taskdef element and should be avoided when possible. I propose that we have a centralized ant project file will solve these problems for the with a single line of code. Then update the manager-how-to doc to specify how to import this .xml file which is much cleaner. With this solution, the user would need the following code in their ant build script to use the tasks. I assume here that they have set the catalina.home property elsewhere (hopefully their build.properties file): <import file="${catalina.home}/bin/catalina-tasks.xml"/> Another possible solution to this problem is to use taskdef and specify the resource catalina.tasks (under org.apache.catalina.ant) and then specify the classpath inline. However, this also includes the JspC task which has a good deal of dependencies and requires you to import a lot of jar files to run. I believe that this solution represents a good balance of consideration for these issues. The new "catalina-tasks.xml" file will live in $CATALINA_HOME/bin which will import everything in catalina.tasks, including JspC and also import the needed jar files. It will also self-discover the correct catalina.home if it was not previously specified. Drawbacks to this approach: This will slow the build more than excluding JspC because the JspC taskdef will load more classes than just the pure Catalina tasks. Bonuses of this approach: This makes JspC available as well and also prevents the need for either: a.) another catalina.tasks file that does not contains JspC (e.g., "pure-catalina.tasks") b.) the removal of JspC from catalina.tasks (I don't know the dependencies here) or c.) putting a taskdef line in the catalina-imports.xml file for each task that we want to import instead of using a bulk include like I am proposing now. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
