You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2001/02/26 01:10:43 UTC
[PROPOSAL] Struts Source Directory Structure
Based on the proposal to include unit tests in Struts, there is a desire
to revise the organization of the source repository. Here is a summary
of my understanding of the most recent proposal, plus some enhancements
to be complete, with annotations on the contents of each directory.
jakarta-struts/
build/ Build scripts and batch files
conf/ Config files for components
share/ Config files for struts.jar
unit/ Config files for unit tests
doc/ Source documentation files
xdocs/ XML input docs and stylesheets
lib/ JAR files of dependent packages
(if we agree to include any)
src/ Java sources for components
example/ Sources for example webapp
share/ Sources for struts.jar
test/ Sources for test webapp
unit/ Sources for unit tests
upload/ Sources for upload webapp
target/ Output of "build" processes
-- no files in CVS repository
dist/ "build dist" output (i.e. the
current nightly distribution)
sdk/ "build sdk" output (i.e. the
proposed Struts Dev. Kit)
unit/ Output of unit test runs
web/ Webapp sources for components
blank/ Web files for blank webapp
example/ Web files for example webapp
template/ Web files for template webapp
test/ Web files for test webapp
upload/ Web files for upload webapp
Comments?
Craig
Re: [PROPOSAL] Struts Source Directory Structure
Posted by Martin Cooper <ma...@tumbleweed.com>.
Two comments:
1) I would prefer not to include external dependencies. After all, they are,
well, external. I understand, though, that not everyone feels the same way
about this.
2) Where would tools go? For example, the form bean generator. I don't think
they should be in struts.jar, so perhaps a 'tools' directory under src?
--
Martin Cooper
Tumbleweed Communications
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Sunday, February 25, 2001 4:10 PM
Subject: [PROPOSAL] Struts Source Directory Structure
> Based on the proposal to include unit tests in Struts, there is a desire
> to revise the organization of the source repository. Here is a summary
> of my understanding of the most recent proposal, plus some enhancements
> to be complete, with annotations on the contents of each directory.
>
> jakarta-struts/
>
> build/ Build scripts and batch files
>
> conf/ Config files for components
> share/ Config files for struts.jar
> unit/ Config files for unit tests
>
> doc/ Source documentation files
> xdocs/ XML input docs and stylesheets
>
> lib/ JAR files of dependent packages
> (if we agree to include any)
>
> src/ Java sources for components
> example/ Sources for example webapp
> share/ Sources for struts.jar
> test/ Sources for test webapp
> unit/ Sources for unit tests
> upload/ Sources for upload webapp
>
> target/ Output of "build" processes
> -- no files in CVS repository
> dist/ "build dist" output (i.e. the
> current nightly distribution)
> sdk/ "build sdk" output (i.e. the
> proposed Struts Dev. Kit)
> unit/ Output of unit test runs
>
> web/ Webapp sources for components
> blank/ Web files for blank webapp
> example/ Web files for example webapp
> template/ Web files for template webapp
> test/ Web files for test webapp
> upload/ Web files for upload webapp
>
>
> Comments?
>
> Craig
>
>
Re: [PROPOSAL] Struts Source Directory Structure
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> src/ Java sources for components
> example/ Sources for example webapp
> share/ Sources for struts.jar
> test/ Sources for test webapp
> unit/ Sources for unit tests
> upload/ Sources for upload webapp
...
> web/ Webapp sources for components
> blank/ Web files for blank webapp
> example/ Web files for example webapp
> template/ Web files for template webapp
> test/ Web files for test webapp
> upload/ Web files for upload webapp
>
> Comments?
These aren't necessarily targeted for the 1.0 timeframe, but
(1) Eventually, I think we should give the Struts "example" application
a proper name, and make room for other example applications. I'd
actually like to do an "examples" (plural) application or some type of
toolkit that demonstrated how to do this and that. Like working FAQ.
(2) It has always seemed to me that sources for any standalone Web
applications should be kept with that application, and that the src
folder should be reserved for the framework (struts.jar) and now the
unit tests.
(2-b) I guess my feeling here is that the org.apache.struts packages are
the "kernel", and the rest is stuff we include with it, the way RedHat
or Mandrake include stuff with the linux kernel. For some reason, I feel
like we should also keep them separate in the tree.
(3) I'd actually like to do a Struts Development Kit and a "Struts
Sampler". The Struts Sampler would just be a ZIP of the Web App WARS,
ready to plug and play. Since this would include the Struts blank
application and documentation, I think a person could actually start
writing Struts apps from there. If someone wants to build Struts, they
could get the SDK the source distribution.
-Ted.
Re: [PROPOSAL] Struts Source Directory Structure
Posted by Rob Leland <Ro...@freetocreate.org>.
"Craig R. McClanahan" wrote:
> I will have only intermittent contact. Vincent and Rob, you should have both
> received your logins by now (or will shortly), so you're welcome to start
> moving stuff around per this agreement.
Ok, hope the automatic build scripts pick up all example
web apps automatically, so renaming will not exclude the old 'test' app.
>
> I'd like to do this fairly soon (i.e. before 1.0-beta-2) so that we can get the
> basic organization structure set correctly. Then, with 1.0-beta-2 we can
> Craig
-Rob
Re: [PROPOSAL] Struts Source Directory Structure
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
I'm +1 on the idea of reusing the directory name "test" for the unit test
suite, and moving the current "test" stuff to some other directory like
"exercise", since that is what they really do. Ultimately, a full fledged unit
test suite will be a superset of the current tags anyway.
In terms of mechanics, I'm going to be out of town Tuesday through Friday this
week (speaking at the International Conference on Java Development in NYC), so
I will have only intermittent contact. Vincent and Rob, you should have both
received your logins by now (or will shortly), so you're welcome to start
moving stuff around per this agreement.
I'd like to do this fairly soon (i.e. before 1.0-beta-2) so that we can get the
basic organization structure set correctly. Then, with 1.0-beta-2 we can
branch the CVS repository and start to work on the 1.1 stuff (there is a lot of
people waiting in the wings to start contributing here) while the remaining
cleanup on 1.0 happens undisturbed.
A few further comments below.
Vincent Massol wrote:
> ----- Original Message -----
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <st...@jakarta.apache.org>
> Sent: Monday, February 26, 2001 1:10 AM
> Subject: [PROPOSAL] Struts Source Directory Structure
>
> > Based on the proposal to include unit tests in Struts, there is a desire
> > to revise the organization of the source repository. Here is a summary
> > of my understanding of the most recent proposal, plus some enhancements
> > to be complete, with annotations on the contents of each directory.
> >
> > jakarta-struts/
> >
> > build/ Build scripts and batch files
>
> +1
>
> >
> > conf/ Config files for components
> > share/ Config files for struts.jar
> > unit/ Config files for unit tests
> >
>
> +1
>
> > doc/ Source documentation files
> > xdocs/ XML input docs and stylesheets
>
> +1
>
> >
> > lib/ JAR files of dependent packages
> > (if we agree to include any)
> >
>
> -1 You have all convinced me that we should leave these outside struts and
> have environment variables to point at them. However, they will be part of
> the SDK or nightly build (or both). So, no lib/ directory. The list of
> external dependencies are (to my knowledge) :
>
So maybe I'm not as much a "Lone Ranger" on this as I thought :-) I'm fine
with not including a "lib" directory in CVS, although we should include one for
the "Struts Development Kit".
>
> - Ant (build process)
> - Stylebook (for generating the documentation/web site)
It is actually not using Stylebook. The dependency is on Ant's <style> tag,
which in turn creates the dependency on an XSL parser described in the next
item. It is really messy to get the right combination of stuff for this to
work, but I've found that having the JAXP-1.1 JAR files (jaxp.jar, crimson.jar,
xalan.jar), plus the xerces.jar from Xerces 1.2, on my classpath -- in that
order -- seems to work.
Longer term, I'm hoping some really good solution for XML based documentation
that can render HTML or PDF output with all of the internal hyperlinks
maintained automatically will come along. Cocoon2 has some promise for this --
in the mean time I suggest we tough it out.
>
> - An XSL processor compatible with Stylebook (Xalan)
> - An XML parser compatible with Ant + Stylebook (Xerces, ...)
> - Servletapi (or any Servlet engine servlet API jar)
> - JUnit (unit tests)
> - J2EEUnit (unit tests)
> - As many servlet engine home directories as possible (ex: TOMCAT_HOME_31,
> TOMCAT_HOME_40, RESIN_HOME_12, ...). These will be used to exercise the
> J2EEUnit tests for Struts. There will be an automated build-test-all script
> to start the tests on each of the servlet engines for whose an environment
> variable is defined. If it is not defined then the tests will be skipped.
> These variables can also be used to automatically deploy the generated
> struts webapps to the servlet engine.
>
Agreed on all of the above.
>
> Am I missing something ?
>
Re: [PROPOSAL] Struts Source Directory Structure
Posted by Vincent Massol <vm...@octo.fr>.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Monday, February 26, 2001 1:10 AM
Subject: [PROPOSAL] Struts Source Directory Structure
> Based on the proposal to include unit tests in Struts, there is a desire
> to revise the organization of the source repository. Here is a summary
> of my understanding of the most recent proposal, plus some enhancements
> to be complete, with annotations on the contents of each directory.
>
> jakarta-struts/
>
> build/ Build scripts and batch files
+1
>
> conf/ Config files for components
> share/ Config files for struts.jar
> unit/ Config files for unit tests
>
+1
> doc/ Source documentation files
> xdocs/ XML input docs and stylesheets
+1
>
> lib/ JAR files of dependent packages
> (if we agree to include any)
>
-1 You have all convinced me that we should leave these outside struts and
have environment variables to point at them. However, they will be part of
the SDK or nightly build (or both). So, no lib/ directory. The list of
external dependencies are (to my knowledge) :
- Ant (build process)
- Stylebook (for generating the documentation/web site)
- An XSL processor compatible with Stylebook (Xalan)
- An XML parser compatible with Ant + Stylebook (Xerces, ...)
- Servletapi (or any Servlet engine servlet API jar)
- JUnit (unit tests)
- J2EEUnit (unit tests)
- As many servlet engine home directories as possible (ex: TOMCAT_HOME_31,
TOMCAT_HOME_40, RESIN_HOME_12, ...). These will be used to exercise the
J2EEUnit tests for Struts. There will be an automated build-test-all script
to start the tests on each of the servlet engines for whose an environment
variable is defined. If it is not defined then the tests will be skipped.
These variables can also be used to automatically deploy the generated
struts webapps to the servlet engine.
Am I missing something ?
> src/ Java sources for components
> example/ Sources for example webapp
> share/ Sources for struts.jar
> test/ Sources for test webapp
> unit/ Sources for unit tests
> upload/ Sources for upload webapp
+1
>
> target/ Output of "build" processes
> -- no files in CVS repository
> dist/ "build dist" output (i.e. the
> current nightly distribution)
> sdk/ "build sdk" output (i.e. the
> proposed Struts Dev. Kit)
> unit/ Output of unit test runs
>
+1
> web/ Webapp sources for components
> blank/ Web files for blank webapp
> example/ Web files for example webapp
> template/ Web files for template webapp
> test/ Web files for test webapp
> upload/ Web files for upload webapp
>
+1
>
> Comments?
>
> Craig
>
Vincent
Re: [PROPOSAL] Struts Source Directory Structure
Posted by Robert Leland <Ro...@free2create.org>.
+1 to all items and don't include dependent libraries in struts
distribution, but do generate a 'struts developers kit'
Michael Gerdau wrote:
> However I don't think 'unit' to be an intuitive name for testing the
> struts framework itself. I'd therefor rather have the testing framework
> under 'test' and rename the current test to something like 'try' or
An alternative would be:
src/ Java sources for components
webapps/
example/ Sources for example webapp
upload/ Sources for upload webapp
test/ Sources for test webapp
share/ Sources for struts.jar
unit/ Sources for unit tests
As far as whether to use 'unit', 'test' or something else
for the unit testing: The current 'test' webapp is really
a test so how about tag-test for the current test application
unit-test for the proposed unit tests.
I'll be away for the next couple of days and don't want to
hold this process up. I am OK with what ever we decide
on this issue, including leaving it as Craig last proposed.
-Rob
Re: [PROPOSAL] Struts Source Directory Structure
Posted by Michael Gerdau <mg...@technosis.de>.
>Based on the proposal to include unit tests in Struts, there is a desire
>to revise the organization of the source repository. Here is a summary
>of my understanding of the most recent proposal, plus some enhancements
>to be complete, with annotations on the contents of each directory.
[newly proposed directory structure skipped]
>Comments?
I see the benefit of the test webapp and certainly won't want to skip
on that.
However I don't think 'unit' to be an intuitive name for testing the
struts framework itself. I'd therefor rather have the testing framework
under 'test' and rename the current test to something like 'try' or
even 'tryout' (agreed, not exactly good names either but possibly
closer to what this webapp is intended for).
Possibly my reluctance to use test for anything other than actually
testing the framework does come from the naming convention of (almost)
all GNU projects. I'm simply rather used to that convention :)
To add my comments to another thread as well:
I'm strongly in favor of leaving 'dependency files' out of the struts
developer edition. And I do favor this for the very same reason Craig
mentioned - it forces developers to consider interoperability as a
virtue in itself.
As many others mentioned the 'user edition' should be made to run out
of the box with a little hazzle as possible.
Best,
Michael
--
Vote against SPAM - see http://www.politik-digital.de/spam/
Michael Gerdau email: mgd@technosis.de
Do still life on your computer--run Windows.
PGP-keys available on request or at public keyserver