Sort of a bug, sort of a feature request.
Using:
* Win2K Pro
* Tomcat 4.0.4
* Eclipse 2 w/ tomcat & easystruts plugins
Using the directory layout as recommended by Jakarta
Tomcat (http://jakarta.apache.org/tomcat/tomcat-4.1-
doc/appdev/source.html). Basically /webapp/APPNAME/
[web | src | doc | build]
Tomcat Path ( & set in Eclipse plugin):
C:\Program Files\Apache Tomcat 4.0\ [from here on
appreviated as '\']
App path
\webapps\ROOT\
Using: Easy Action, Form, & Input page Wizard
Files like *.tld, struts-config.xml, web.xml, lib/tiles.jar
end up in \webapps\ROOT\WEB-INF instead of
\webapps\ROOT\web\WEB-INF
ApplicationResources.properties ends up in
\webapps\ROOT\work\....
The .java files were placed as desired (specified in the
wizard) into \webapps\ROOT\src\....
The generated files will all work if you manually move
them and their configurations into the proper locations
and add/insert to your existing configurations.
Very nice plugin by the way! Keep up the good work!
Logged In: YES
user_id=45582
don't know if I understand this correctly - this layout is
mainly for completely installed and ready to run tomcat.
Especially if a web application is under development we
usually use contexts configured in server.xml. These
contexts are located anywhere in the file system. The tomcat
plugin also offers to add a context to server.xml for a
given project (rightclick on project, select tomcat, ...).
Of course if you deploy your application, you should build a
*.war file - if this is called ROOT.war and you place it in
\webapps it gets deployed to \webapps\ROOT and will be
available with no context name at all.
Correct me, but I don't see any additional feature needed
for easystruts. It generates its files to the webapplication
folder you name, which is perfect.
Logged In: YES
user_id=7933
If i could vote for this bug I would ;)
Ours is slight different but only in naming... I would be more
than happy about improvments to teh generated directory
structure. I jsut entered a similar entry as an RFE.
Logged In: YES
user_id=7933
oko;
A standard is a standard ;)
Really... we can't implement department-wide usage until we
can *at least* control or configure the build environment
structure that Easy Struts generates.... and ours is fairly
close to the "recomended standard".
That doesn't mean that you shouldn't do it any way you like...
but thats my point, Easy Struts is *very* unfriendly about
having its diretories changed.
Greate tool by the way... keep it up.