You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Gerry Chike <gc...@cisco.com> on 2001/02/22 20:57:59 UTC
Final Release 1.0 Time Frame
Hi Craig,
Do you have a "time frame" for the final release of Struts 1.0? I'm working on a project that needs to make either a Go or No-go based on the timing of the final release. I appreciate any thoughts or feedback regarding this issue.
Thanks,
Gerry
Good, Cheap, or Fast: Pick any two.
---------------------------------------------------------------------------
. . Gerry Chike
.|. .|. IT Engineer, CSE-IT
.|||. .|||. Cisco Systems - RTP
.|||||. .|||||. Phone: +1 919.392.2701
.:|||||||:. .:|||||||:. 7025 Kit Creek Rd RTP, NC 27709-4987
Cisco Systems gchike@cisco.com
---------------------------------------------------------------------------
Re: Ted Husted: An entry for the FAQ(Re: building struts)
Posted by Ted Husted <ne...@husted.com>.
Thanks, Rob.
I hope we have some better luck with the Jakarta FAQ-o-matic soon.
-Ted.
Re: Ted Husted: An entry for the FAQ(Re: building struts)
Posted by Rob Leland <Ro...@freetocreate.org>.
I left out one important point.
That is to copy the ant/dist/lib files to your ant/lib dir so the
revised
FAQ entry would look like:
This should go in the FAQ:
Question:
I cannot building struts, I keep getting either a
java.lang.ClassNotFoundException:
org.apache.tools.ant.taskdefs.optional.TraXLiaison
or a
java.lang.SecurityException: sealing violation
I played with my adjusted my class paths for 5 hours,
Help ... what can I do ?
Answer:
I would recommend ALWAYS building 'ant' before
trying to build 'struts' for the first time.
Why? It seems that ant customizes itself for
each environment, and determines which XML parser
you are using.
Once I did that struts builds without a hitch.
1) Read the Build instructions for ANT,
creating the ANT_HOME, and other needed
enviromental variables.
2) Then run build.bat - to perform the bootstrap build of ant
and
build the final version of Ant.
3) Copy the ANT_HOME/dist/lib jar files to ANT_HOME/lib .
4) Make sure you read the 'struts' build guide,
and have installed all required packages.
5) Change to the struts directory.
5) Then type 'build'
If this doesn't work then make sure that your
CLASSPATH references only one jaxp.jar and that
parser.jar isn't in your CLASSPATH
Ted Husted: An entry for the FAQ(Re: building struts)
Posted by Rob Leland <Ro...@freetocreate.org>.
This should go in the FAQ:
Question:
I cannot building struts, I keep getting either a
java.lang.ClassNotFoundException:
org.apache.tools.ant.taskdefs.optional.TraXLiaison
or a
java.lang.SecurityException: sealing violation
I played with my adjusted my class paths for 5 hours,
Help ... what can I do ?
Answer:
I would recommend ALWAYS building 'ant' before
trying to build 'struts' for the first time.
Why? It seems that ant customizes itself for
each environment, and determines which XML parser
you are using.
Once I did that struts builds without a hitch.
1) Read the Build instructions for ANT,
creating the ANT_HOME, and other needed
enviromental variables.
2) run the bootstrap.bat to build a first version of ant.
3) Then run build.bat - to build the final version of Ant.
4) Make sure you have read the 'struts' build guide,
and have installed all required packages.
5) Change to the struts directory.
5) Then type 'build'
If this doesn't work then make sure that your
CLASSPATH references only one jaxp.jar and that
parser.jar isn't in your CLASSPATH
"Craig R. McClanahan" wrote:
>
> Rob Leland wrote:
>
> > Ok:
> >
> > I am trying to build struts Feb 22 using:
> >
> > ant 1.3-b3, options.jar (1.3 b3); jaxp 1.1
> >
> > I haven't been sucessfull yet.
> >
>
> For day-to-day development I use current CVS code for Ant, with the JAXP
> 1.1
> JAR files plus the Xerces 1.2.0 JAR file on my classpath (in that
> order).
>
> Sealing violations happen because the JAXP jar files are sealed, and
> Xerces is
> found ahead of JAXP.
>
> >
> > Which version of ant are you using to build struts.
> > Have you tried gump ?
>
> I watch the output but haven't played with it directly. Once I have
> time, I'll
> probably migrate to using GUMP-based output to create the nightly builds
> of
> Struts -- but I want to think about that a little more first.
>
> Craig
>
> >
> > BUILD FAILED
> >
> > java.lang.SecurityException: sealing violation
> > at java.net.URLClassLoader.defineClass(URLClassLoader.java:234)
> > at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> > at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> > at java.lang.Class.forName0(Native Method)
> > at java.lang.Class.forName(Class.java:120)
> > at
> > javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:117)
> > at
> > org.apache.tools.ant.ProjectHelper.getParserFactory(ProjectHelper.java:706)
> > at
> > org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:105)
> > at
> > org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:85)
> > at org.apache.tools.ant.Main.runBuild(Main.java:403)
> > at org.apache.tools.ant.Main.main(Main.java:149)
Re: PROPOSAL - Testing Framework
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> It hasn't been discussed on STRUTS-DEV, so it's probably worth talking about.
>
> How do folks feel about this? Was the pain of having to download the
> prerequisite packages worth the ability to use whatever versions you preferred?
Personally, I've always admired the Turbine Developer's Kit.
I also think Struts may interest a lot of people who are not used to
working in open source environments, and may find the list of
prerequesite packages daunting.
I would like to make getting Struts up and running as simple as
possible, especially for people who are testing a number of framework
approaches.
If possible, I would say we document how to use Struts with other
versions to give the power users a boost, but provide a "plug and play"
bundle for mere mortals.
On a related note, if no one objects, I would also still like to
refactor the installation page as mentioned here
<
http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg00320.html
>
which may jive with this suggestion.
-Ted.
Re: PROPOSAL - Testing Framework
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Robert Leland wrote:
> "Craig R. McClanahan" wrote:
> > Note that the below comments relate to packaging JAR files in the *source*
> > repositories of various projects -- as stated above, I have no problem with the
> > idea of creating a "Struts Development Kit" if people find that useful.
>
> So.... This would be a separate archive with all needed jar's and
> their matching documentation ?
>
> These files would not live in the CVS tree, just on the web site ?
> I like this better because packing all this stuff in the CVS tree
> makes downloading slow. For instance pulling J2EEUnit from CVS slow.
> This is because ant.jar,jaxp.jar,junit.jar, etc.
> are in the J2EEUnit module.
>
The way we do this in Tomcat offers one model:
* No dependency JAR files are included in the Tomcat CVS repository
* The Tomcat build process has numerous external project dependencies,
which you point at with environment variables to grab the versions you want
of each such package.
* The output of the "dist" target is a nightly distribution that includes everything
you need to run Tomcat (including an XML parser, servlet API classes, etc.).
If we do something like this for Struts, I would suggest that we leave the existing
packaging for the nightly downloads (for people who just want to stay up to date),
and a separate "Struts Developer Kit" that has everything you need.
Question -- would a Struts Development Kit include a servlet container? If so, the
choice is pretty obvious. If not, why not? Where do you draw the line of what a
development kit would include?
>
> I suggest only releasing a developers kit for each released
> version of struts. Struts 1.0, 1.1.
Conceptually, there is no difficulty creating the SDK with nightly distributions as
well.
> Also I see a number of people in
> the jakarta-general list frowning on putting binaries under CVS control.
> If a developer wants to work with the current CVS sources then
> they would have to build their own environment.
>
> >
> > Turbine (and others) use "target" where you have "out" -- I'm OK with either.
>
> I would say then lets stick with "target" just to 'walk softly' on Jakarta
> conventions.
>
> So what where do we stand on the revised directory structure for struts ?
>
I will try to summarize what I think has been discussed in a separate message.
>
> -Rob
Craig
Re: PROPOSAL - Testing Framework
Posted by Robert Leland <Ro...@free2create.org>.
"Craig R. McClanahan" wrote:
> Note that the below comments relate to packaging JAR files in the *source*
> repositories of various projects -- as stated above, I have no problem with the
> idea of creating a "Struts Development Kit" if people find that useful.
So.... This would be a separate archive with all needed jar's and
their matching documentation ?
These files would not live in the CVS tree, just on the web site ?
I like this better because packing all this stuff in the CVS tree
makes downloading slow. For instance pulling J2EEUnit from CVS slow.
This is because ant.jar,jaxp.jar,junit.jar, etc.
are in the J2EEUnit module.
I suggest only releasing a developers kit for each released
version of struts. Struts 1.0, 1.1. Also I see a number of people in
the jakarta-general list frowning on putting binaries under CVS control.
If a developer wants to work with the current CVS sources then
they would have to build their own environment.
>
> Turbine (and others) use "target" where you have "out" -- I'm OK with either.
I would say then lets stick with "target" just to 'walk softly' on Jakarta
conventions.
So what where do we stand on the revised directory structure for struts ?
-Rob
Re: PROPOSAL - Testing Framework
Posted by Martin Cooper <ma...@tumbleweed.com>.
See comments intermixed.
> > > > 1- In build.bat, the CP variable does not define an XML parser.
> > > > %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be
added.
> > Or,
> > > > is that voluntarily because you want to leave the choice to the
> > developer to
> > > > choose his one jaxp compliant parser ? Personnaly, I prefer to force
it
> > to a
> > > > choice that will always work. I prefer to leave my CLASSPATH always
> > empty
> > > > because otherwise it creates lots of problems when you switch from
one
> > > > project to another ...
> > > >
> > >
> > > My preference has always been to allow people to choose their own
tools --
> > such
> > > as their own version of Ant, their own XML parser, their own servlet
API
> > > version, and so on -- rather than force these decisions. After all,
> > Struts will
> > > be used in applications that have all manner of dependencies on
different
> > > versions of these things.
> > >
> >
> > Yes, I understand that but my point is only to make it easy for person
who
> > download struts and want to try it. I'm always trying to make the
software I
> > write as much "plug and play" (or should I say "download and run") as
> > possible. But this does not preclude power users to use other versions
of
> > these libraries.
> >
>
> I totally agree with the "plug and play" download for Struts *users*.
That's
> the same reason that a binary distribution of Tomcat contains everything
you
> need that can be legally included.
>
> But, that is slightly different from the requirements to *build* Struts --
> which, of course, would include scripts for creating the "plug and play"
> download for users. IMHO, it should be possible to build the "plug and
play"
> download with different combinations of packages to suit different needs.
All
> of this requires relatively more complexity in the Struts build process
itself
> -- but it need not compromise the usability of what typical users are
> downloading.
I have to agree with Craig on this one. I think developers should be able to
choose their own tools, rather than have the decision made for them. I
should be able to decide how Ant is configured on my system, and which
servlet implementation I build against.
On a slightly different tack, I also wouldn't want to see the download size
for struts balloon dramatically because all the external software is now
internal. People should only have to download what they need. (For example,
when I download the nightly build, I really don't want another version of
Ant or the servlet API implementation.)
> > I didn't know Ant was supposed to be run like this. It actually makes
sense
> > if you consider Ant as an application that you install on your system
> > somewhere and then you call it (from there) with different build
> > configurations.
> >
>
> Yep ... just point ANT_HOME at wherever you've installed Ant, and it is
supposed
> to work.
>
> Unfortunately, I've had problems getting the bin/ant.bat script to work on
Win98
> :-(.
I use Ant like this all the time, actually, for work projects as well as
Struts. The only issue with Win98 is that you have to define ANT_HOME and
friends using the ugly short form of the path (e.g. use C:\Java\jakart~1.2
instead of C:\Java\jakarta-ant-1.2).
> > > > 5- What do you think about creating a build directory where you put
the
> > > > files that are needed to run the build of struts. They would be :
> > build.xml,
> > > > build.bat, all Ant jars (that's only if you agree with point 3 of
course
> > ...
> > > > :) ), maybe some other batch files to help start other targets from
> > Windows.
> > > > The output of the build will go in a directory named out/ for
example (I
> > > > have always found the name build/ for the output to be confusing. It
> > means
> > > > "a build" but also "to build" ...)
> > > >
> > >
> > > I personally prefer the build.xml and associated scripts to be in the
> > top-level
> > > directory so you do not have to go hunting for them.
Yes, this is my preference too. It is also how I have organized our projects
at work.
> There is one other interesting issue with the servlet API classes in
particular
> -- it is legal for a servlet container to provide their own implementation
of
> these classes, so the one from Tomcat may or may not actually *run* in a
> different servlet container, although you should not have any problems
just
> compiling against it.
Although I realise that the API would be (or should be!) the same, I prefer
to build against the implementation that is used by the container I am going
to deploy against. It just feels "safer". Of course, with something like
Struts, there is no single target platform, but it would seem to me that
having different developers using different implementations would ensure
better exposure.
> As stated above (and is also obvious if you look at the Tomcat build
process
> :-), I don't have a problem with external build dependencies. But I am
> definitely in the minority.
Then I guess I'm in that same minority. :-}
--
Martin Cooper
Tumbleweed Communications
Re: PROPOSAL - Testing Framework
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Vincent,
See intermixed.
Vincent Massol wrote:
> Craig,
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <st...@jakarta.apache.org>
> Sent: Saturday, February 24, 2001 10:44 PM
> Subject: Re: PROPOSAL - Testing Framework
>
> > Vincent Massol wrote:
> >
> > > I am now looking at Struts in order to write the test suite (I have only
> > > looked at build.bat and build.xml so
> > > far ...) and I have notice the following details that may need to be
> > > corrected/improved :
> > >
> >
> > Hello Vincent,
> >
> > Sorry for the slow response ... I was really focused yesterday on getting
> the
> > beta out. Now we can start planning next steps.
> >
> > >
> > > 1- In build.bat, the CP variable does not define an XML parser.
> > > %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added.
> Or,
> > > is that voluntarily because you want to leave the choice to the
> developer to
> > > choose his one jaxp compliant parser ? Personnaly, I prefer to force it
> to a
> > > choice that will always work. I prefer to leave my CLASSPATH always
> empty
> > > because otherwise it creates lots of problems when you switch from one
> > > project to another ...
> > >
> >
> > My preference has always been to allow people to choose their own tools --
> such
> > as their own version of Ant, their own XML parser, their own servlet API
> > version, and so on -- rather than force these decisions. After all,
> Struts will
> > be used in applications that have all manner of dependencies on different
> > versions of these things.
> >
>
> Yes, I understand that but my point is only to make it easy for person who
> download struts and want to try it. I'm always trying to make the software I
> write as much "plug and play" (or should I say "download and run") as
> possible. But this does not preclude power users to use other versions of
> these libraries.
>
I totally agree with the "plug and play" download for Struts *users*. That's
the same reason that a binary distribution of Tomcat contains everything you
need that can be legally included.
But, that is slightly different from the requirements to *build* Struts --
which, of course, would include scripts for creating the "plug and play"
download for users. IMHO, it should be possible to build the "plug and play"
download with different combinations of packages to suit different needs. All
of this requires relatively more complexity in the Struts build process itself
-- but it need not compromise the usability of what typical users are
downloading.
>
> > On Ant in particular, I would actually prefer us to run Ant via
> > "$ANT_HOME/bin/ant" (Unix) or "%ANT_HOME%\bin\ant.bat" (Windows). That
> way, we
> > can let Ant itself worry about the changing directory structures required
> by
> > different versions of Ant. In addition, modern versions of "ant" and
> "ant.bat"
> > let you define system properties via "~/.antrc" (Unix) or
> "%HOME%\antrc_pre.bat"
> > and "%HOME%\antrc_post.bat" (Windows).
> >
>
> I didn't know Ant was supposed to be run like this. It actually makes sense
> if you consider Ant as an application that you install on your system
> somewhere and then you call it (from there) with different build
> configurations.
>
Yep ... just point ANT_HOME at wherever you've installed Ant, and it is supposed
to work.
Unfortunately, I've had problems getting the bin/ant.bat script to work on Win98
:-(.
>
> > >
> > > 2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and
> > > optional.jar) but in the jakarta-ant distribution that I got using CVS,
> the
> > > ant.jar and optional.jar are generated and put in dist\lib.
> > >
> >
> > Switching to $ANT_HOME/bin/ant will take care of this kind of thing.
> >
> > >
> > > 3- Is that an Apache choice not to bundle the needed external jars
> within
> > > your own project ?
> >
> > Different Apache subprojects do it differently -- this is my choice (and
> I'm
> > probably in the minority here). I use quite a few open source projects,
> and the
> > number of copies of ant.jar and xerces.jar on my hard drive is pretty
> > disgusting.
>
> That's true, but is it a problem ?
>
Note that the below comments relate to packaging JAR files in the *source*
repositories of various projects -- as stated above, I have no problem with the
idea of creating a "Struts Development Kit" if people find that useful.
<soapbox>
It's definitely a problem if you want to rebuild from source -- you have to
remember to use the right version of ant for the right subpackage.
It's definitely a problem if you try to combine packages that use incompatible
versions of dependent packages -- and this happens much more because of the
habit of "everything you need" in CVS repositories.
It's definitely a problem because this habit encourages developers to not worry
about interoperatbility.
</soapbox>
>
> >
> > > I would tend to prefer to bundle ant
> > > jars and servletapi jars for Struts because (a) they are only used to
> build
> > > struts, not for runtime and (b)otherwise the building of struts will
> fail or
> > > succeed depending on the state of these other projects, thus you might
> get
> > > lots of posts on the mailing list from persons trying to build Struts
> but
> > > failing just because they have a bad version of Ant for instance (I
> speak
> > > from experience as for J2EEUnit I tried several Ant release and I can
> tell
> > > you they were not all working, far from that, and I had to struggle to
> find
> > > the good one. At least I know that the one I bundle is going to work
> with no
> > > problem and from time to time I upgrade it. In other words I certify my
> app
> > > to work with such version. However if the enn developer want to use a
> > > newer/older version, he is free to try it ...). Thoughts ? (Sorry if
> this
> > > way of doing it has already been discussed at length ... :( )
> > >
> >
> > It hasn't been discussed on STRUTS-DEV, so it's probably worth talking
> about.
> >
> > How do folks feel about this? Was the pain of having to download the
> > prerequisite packages worth the ability to use whatever versions you
> preferred?
> >
> > >
> > > 4- build.xml need more comments, better formatting and some minor
> additional
> > > refactorings (to my opinion). Am I allowed to do that ?
> > >
> >
> > Yes. Once we agree on a path, any of the docs or build scripts are fair
> game,
> > along with the code :-).
> >
> > >
> > > 5- What do you think about creating a build directory where you put the
> > > files that are needed to run the build of struts. They would be :
> build.xml,
> > > build.bat, all Ant jars (that's only if you agree with point 3 of course
> ...
> > > :) ), maybe some other batch files to help start other targets from
> Windows.
> > > The output of the build will go in a directory named out/ for example (I
> > > have always found the name build/ for the output to be confusing. It
> means
> > > "a build" but also "to build" ...)
> > >
> >
> > I personally prefer the build.xml and associated scripts to be in the
> top-level
> > directory so you do not have to go hunting for them.
> >
> > Currently, the 'build" directory is an *output* of the Struts build
> process,
> > rather than an input. We'd have to change that (for example, some
> subprojects
> > use "target" for their destinations). In your scenario below, it looks
> like
> > this should be changed to "out".
> >
>
> I like to have a build directory where I put the ant jars + batch/sh files.
> You have only one for the moment but the number will grow with support of
> several servlet API. Moreover, for those on work on Windows, it is good to
> have several batch files named after the target they execute so we can start
> them by double-clicking on them. Then we'll have a batch file/sh for
> automatically running all the tests in all servlet engines, ... That's why I
> like to have a dedicated build directory...
>
That makes sense ... let's go with that.
>
> > >
> > > 6- If you agree on point 3, creating a lib directory at the top level to
> put
> > > the servletapi jar would be a good idea.
> >
> > Which version?
>
> This depends on whether you want to support both API 2.2 and 2.3. If yes,
> you could bundle both and just append a different prefix like 22 and 23.
> Yes, I know I also prefer to try to keep the original name but it's not that
> bad. Or use two directories like lib\servletapi22 and lib\servletapi23.
>
There is one other interesting issue with the servlet API classes in particular
-- it is legal for a servlet container to provide their own implementation of
these classes, so the one from Tomcat may or may not actually *run* in a
different servlet container, although you should not have any problems just
compiling against it.
>
> >
> > Right now, Struts requires only servlet 2.2 / JSP 1.1 APIs, but my daily
> work on
> > Tomcat 4.0 requires me to use the servlet 2.3 / JSP 1.2 servlet.jar file.
> This
> > is the kind of problem you run into by forcing a choice on the developer
> :-).
> >
>
> Then you can have 2 build files, one to build stuts with Servlet API 2.2 and
> one for Servlet API 2.3. You'll need that someday, when you'll have to
> support both API and you'll have some code specific to 2.2 and other
> specific to 2.3
>
> > > . Also I need to put the j2eeunit +
> > > junit jars. Putting them in lib/ would be a good idea I think.
> > >
> >
> > As opposed to saying "go build these projects yourself and provide an
> > environment variable pointing at them"? Yah, OK, I guess -- a "lib"
> directory
> > it is.
> >
>
> :) Otherwise we increase the number of dependencies with external projects
> you have to download ...
>
As stated above (and is also obvious if you look at the Tomcat build process
:-), I don't have a problem with external build dependencies. But I am
definitely in the minority.
>
> > >
> > > 7- Why do you have a conf/ directory under src ? Wouldn't you prefer it
> to
> > > have
> > > at the top level (or is it a Jakarta requirement) ? Something like :
> > >
> >
> > Conceptually, I think of these files as part of the source code, but it's
> no big
> > deal one way or the other to me.
> >
>
> Yes, I agree but everything in jakarta-struts is part of the source, right ?
> I don't really care either. Only that (example, share, test, unit) really
> seem to go together because they are code whereas conf/, doc/ are other
> subjects. Here is my preferred structure (updated) :
>
> jakarta-struts
> |_ out (generated by the build script)
> |_ dist
> |_ build
> |_ (support batch/sh files) + ant jars (if we agree on that) + build.xml
> (if ok)
> |_ conf
> |_ unit
> |_ doc
> |_ src
> |_ example
> |_ share
> |_ test
> |_ unit
> |_ web
>
Turbine (and others) use "target" where you have "out" -- I'm OK with either.
>
> > >
> > > jakarta-struts
> > > |_ out (generated by the build script)
> > > |_ build
> > > |_ conf
> > > |_ doc
> > > |_ src
> > > |_ example
> > > |_ share
> > > |_ test
> > > |_ web
> > >
> >
> > You would need an additional output directory, "dist", for the target of
> the
> > "distribution" build.
> >
>
> Yes, see above
>
> > >
> > > 8- I'd like to use the src/test/ directory to put the struts unit tests.
> > > What is the already existing test directory ? Was it done for that
> purpose ?
> > >
> >
> > It has the Java sources for the struts-test.war web application, in the
> same way
> > that "src/example" has the Java sources for the "struts-example.war" web
> app.
> >
> > I would prefer not to eliminate this web app, because it offers a quick
> and
> > dirty way to exercize the various custom tags as they are being build
> > interactively. However, it would not bother me to change the name.
> >
> > How about directory "src/unit" for the unit tests (and, correspondingly,
> package
> > name "org.apache.struts.unit.*" when you are not required to have the unit
> tests
> > in the same package as the class being tested)?
> >
>
> ok see above. For the package, I usually prefer to use the same packages as
> the classes under tests (for protected method test). Having 2 types of
> packages seem a bit artificial to me
>
Yes, you definitely need to use the same package names for testing package
private stuff.
>
> > >
> > > 9- I'd like to create a test/ subdirectory un conf/ where I'll put all
> the
> > > configuration files needed for the struts unit tests. Is that ok?
> > >
> >
> > If we use "src/unit" for the unit test sources, it should probably be
> > "conf/unit" for consistency. But I am fine with a subdirectory here.
> >
> ok
>
> > >
> > > 10- The strategy I have followed with J2EEUnit for it's tests was to run
> the
> > > tests in the out/ directory, i.e. not deploy to the servlet engine
> install
> > > directory. I like to control the files that I generate. By being located
> > > under out/, they (a) are easy to clean up, (b) do not affect any other
> > > webapp running on my system, (c) I can use the setting I want for my
> servlet
> > > engine for the tests without affecting the main config of my servlet
> engine.
> > > I would suggest the following directory hierarchy :
> > >
> > > jakarta-struts
> > > |_ out
> > > |_ tests
> > > |_ tomcat-3.2
> > > |_ conf
> > > |_ webapps
> > > |_ work
> > > |_ tomcat-4.0
> > > |_ ...
> > > |_ resin-1.2
> > > |_ ...
> > > |_ ...
> > > |_ conf
> > > |_ test
> > > |_ j2eeunit.properties
> > > |_ tomcat
> > > |_ testserver-3.2.xml
> > > |_ testserver-4.0.xml
> > >
> >
> > Sounds reasonable -- the only recommended change would be to use "unit"
> rather
> > than "test" as a directory name if we choose *not* to eliminate the
> current
> > struts-test webapp.
> >
>
> ok for unit
>
> > >
> > > 11- Does Struts support only one servlet api at a time (like the 2.2
> one) or
> > > is it your plan to support several, like 2.2 and 2.3 ?
> > >
> >
> > Right now, all of Struts is based on the servlet 2.2 / JSP 1.1 APIs. At
> some
> > point in the future, I would like to start building optional capabilities
> that
> > require 2.3 / 1.2, but for the foreseeable future we cannot really make
> that a
> > requirement.
> >
> > Fortunately, the 2.3 / 1.2 servlet API classes are "forwards compatible",
> so
> > that you can generally compile against them and still run on a 2.2/1.1
> servlet
> > container, as long as you avoid any of the new method calls.
> >
> > >
> > > Please feel free to discard anything that I have said that does not fit
> your
> > > plan. I understand that I am new here ... However, I just wanted to let
> you
> > > know my thoughts in case I bring forward something that can improve
> Struts.
> > >
> > > Tell me what you think of these and tell me how I have to proceed for
> > > building the test suite ? Do I
> > > change the files and send the to you by email ? What can I apply from
> the
> > > above mentionned points ? Is there a CVS branch that I
> > > should work on instead of the main one ?
> > >
> >
> > What I'd like to do is the following:
> >
> > * Propose you and Rob as committers (see separate message) according
> > to the standard Jakarta policies and practices, so you can both have
> > write access to the CVS repository.
> >
> > * Make the organizational changes that come out of the above discussion
> > in the current HEAD branch, to be completed prior to 1.0-beta-2. (I
> don't
> > anticipate the need for more than one more beta cycle, but we'll see
> what
> > bug reports show up).
> >
> > * At that point, make the 1.0 code a branch in the repository, so we can
> > make the HEAD branch available for starting on 1.1 related stuff.
> >
> > Does that sound like a plan?
> >
>
> Thanks ! That's great ... Let's get the work done ... :)
>
+1 :-)
>
> > >
> > > Thanks.
> > > Vincent.
> >
> > Craig
> >
>
> Vincent.
Craig
Re: PROPOSAL - Testing Framework
Posted by Ted Husted <ne...@husted.com>.
Vincent Massol wrote:
> Yes, I understand that but my point is only to make it easy for person who
> download struts and want to try it. I'm always trying to make the software I
> write as much "plug and play" (or should I say "download and run") as
> possible. But this does not preclude power users to use other versions of
> these libraries.
Hugely +1 here.
Tire-kickers welcome!
> Then you can have 2 build files, one to build stuts with Servlet API 2.2 and
> one for Servlet API 2.3. You'll need that someday, when you'll have to
> support both API and you'll have some code specific to 2.2 and other
> specific to 2.3
Just to brainstorm -- Resin (I think) did a neat thing during the 1.1
transition. There was a preprocessor that would scan the code and switch
it back and forth between 1.1 and 1.2.
> Yes, I agree but everything in jakarta-struts is part of the source, right ?
> I don't really care either. Only that (example, share, test, unit) really
> seem to go together because they are code whereas conf/, doc/ are other
> subjects. Here is my preferred structure (updated) :
After unpacking the applications that come with Struts, the first thing
I find myself doing is copying the source from src/$application to
$application/WEB-INF/src. This way the source for the classes is near
the source for the JSPs.
If the source for the Web applications travelled with the webapp JARs,
people could download just the applications, try those on for size, and
take a peek at the source code. This leads to a staged introduction to
Struts where people can
(1) Download and install the Struts documentation and example
applications,
(2) Then download the binary distribution to try compiling your own
Struts application,
(3) And/or, download the full source distribution, to build Struts from
scratch.
Some people may stop at (2), others may skip directly to (3).
Of course, with Ant I guess we could keep the Web app source where it
is, and then just copy it over when the Web applications were built as
deliverables.
<
http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg00320.html
>
The other thing to think about is the idea of Struts "template"
applications, that people could download use as the base for their own
work. Here, we would want a common approach to storing the source with
the application so that these would be easy to download and use.
-Ted.
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
Craig,
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Saturday, February 24, 2001 10:44 PM
Subject: Re: PROPOSAL - Testing Framework
> Vincent Massol wrote:
>
> > I am now looking at Struts in order to write the test suite (I have only
> > looked at build.bat and build.xml so
> > far ...) and I have notice the following details that may need to be
> > corrected/improved :
> >
>
> Hello Vincent,
>
> Sorry for the slow response ... I was really focused yesterday on getting
the
> beta out. Now we can start planning next steps.
>
> >
> > 1- In build.bat, the CP variable does not define an XML parser.
> > %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added.
Or,
> > is that voluntarily because you want to leave the choice to the
developer to
> > choose his one jaxp compliant parser ? Personnaly, I prefer to force it
to a
> > choice that will always work. I prefer to leave my CLASSPATH always
empty
> > because otherwise it creates lots of problems when you switch from one
> > project to another ...
> >
>
> My preference has always been to allow people to choose their own tools --
such
> as their own version of Ant, their own XML parser, their own servlet API
> version, and so on -- rather than force these decisions. After all,
Struts will
> be used in applications that have all manner of dependencies on different
> versions of these things.
>
Yes, I understand that but my point is only to make it easy for person who
download struts and want to try it. I'm always trying to make the software I
write as much "plug and play" (or should I say "download and run") as
possible. But this does not preclude power users to use other versions of
these libraries.
> On Ant in particular, I would actually prefer us to run Ant via
> "$ANT_HOME/bin/ant" (Unix) or "%ANT_HOME%\bin\ant.bat" (Windows). That
way, we
> can let Ant itself worry about the changing directory structures required
by
> different versions of Ant. In addition, modern versions of "ant" and
"ant.bat"
> let you define system properties via "~/.antrc" (Unix) or
"%HOME%\antrc_pre.bat"
> and "%HOME%\antrc_post.bat" (Windows).
>
I didn't know Ant was supposed to be run like this. It actually makes sense
if you consider Ant as an application that you install on your system
somewhere and then you call it (from there) with different build
configurations.
> >
> > 2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and
> > optional.jar) but in the jakarta-ant distribution that I got using CVS,
the
> > ant.jar and optional.jar are generated and put in dist\lib.
> >
>
> Switching to $ANT_HOME/bin/ant will take care of this kind of thing.
>
> >
> > 3- Is that an Apache choice not to bundle the needed external jars
within
> > your own project ?
>
> Different Apache subprojects do it differently -- this is my choice (and
I'm
> probably in the minority here). I use quite a few open source projects,
and the
> number of copies of ant.jar and xerces.jar on my hard drive is pretty
> disgusting.
That's true, but is it a problem ?
>
> > I would tend to prefer to bundle ant
> > jars and servletapi jars for Struts because (a) they are only used to
build
> > struts, not for runtime and (b)otherwise the building of struts will
fail or
> > succeed depending on the state of these other projects, thus you might
get
> > lots of posts on the mailing list from persons trying to build Struts
but
> > failing just because they have a bad version of Ant for instance (I
speak
> > from experience as for J2EEUnit I tried several Ant release and I can
tell
> > you they were not all working, far from that, and I had to struggle to
find
> > the good one. At least I know that the one I bundle is going to work
with no
> > problem and from time to time I upgrade it. In other words I certify my
app
> > to work with such version. However if the enn developer want to use a
> > newer/older version, he is free to try it ...). Thoughts ? (Sorry if
this
> > way of doing it has already been discussed at length ... :( )
> >
>
> It hasn't been discussed on STRUTS-DEV, so it's probably worth talking
about.
>
> How do folks feel about this? Was the pain of having to download the
> prerequisite packages worth the ability to use whatever versions you
preferred?
>
> >
> > 4- build.xml need more comments, better formatting and some minor
additional
> > refactorings (to my opinion). Am I allowed to do that ?
> >
>
> Yes. Once we agree on a path, any of the docs or build scripts are fair
game,
> along with the code :-).
>
> >
> > 5- What do you think about creating a build directory where you put the
> > files that are needed to run the build of struts. They would be :
build.xml,
> > build.bat, all Ant jars (that's only if you agree with point 3 of course
...
> > :) ), maybe some other batch files to help start other targets from
Windows.
> > The output of the build will go in a directory named out/ for example (I
> > have always found the name build/ for the output to be confusing. It
means
> > "a build" but also "to build" ...)
> >
>
> I personally prefer the build.xml and associated scripts to be in the
top-level
> directory so you do not have to go hunting for them.
>
> Currently, the 'build" directory is an *output* of the Struts build
process,
> rather than an input. We'd have to change that (for example, some
subprojects
> use "target" for their destinations). In your scenario below, it looks
like
> this should be changed to "out".
>
I like to have a build directory where I put the ant jars + batch/sh files.
You have only one for the moment but the number will grow with support of
several servlet API. Moreover, for those on work on Windows, it is good to
have several batch files named after the target they execute so we can start
them by double-clicking on them. Then we'll have a batch file/sh for
automatically running all the tests in all servlet engines, ... That's why I
like to have a dedicated build directory...
> >
> > 6- If you agree on point 3, creating a lib directory at the top level to
put
> > the servletapi jar would be a good idea.
>
> Which version?
This depends on whether you want to support both API 2.2 and 2.3. If yes,
you could bundle both and just append a different prefix like 22 and 23.
Yes, I know I also prefer to try to keep the original name but it's not that
bad. Or use two directories like lib\servletapi22 and lib\servletapi23.
>
> Right now, Struts requires only servlet 2.2 / JSP 1.1 APIs, but my daily
work on
> Tomcat 4.0 requires me to use the servlet 2.3 / JSP 1.2 servlet.jar file.
This
> is the kind of problem you run into by forcing a choice on the developer
:-).
>
Then you can have 2 build files, one to build stuts with Servlet API 2.2 and
one for Servlet API 2.3. You'll need that someday, when you'll have to
support both API and you'll have some code specific to 2.2 and other
specific to 2.3
> > . Also I need to put the j2eeunit +
> > junit jars. Putting them in lib/ would be a good idea I think.
> >
>
> As opposed to saying "go build these projects yourself and provide an
> environment variable pointing at them"? Yah, OK, I guess -- a "lib"
directory
> it is.
>
:) Otherwise we increase the number of dependencies with external projects
you have to download ...
> >
> > 7- Why do you have a conf/ directory under src ? Wouldn't you prefer it
to
> > have
> > at the top level (or is it a Jakarta requirement) ? Something like :
> >
>
> Conceptually, I think of these files as part of the source code, but it's
no big
> deal one way or the other to me.
>
Yes, I agree but everything in jakarta-struts is part of the source, right ?
I don't really care either. Only that (example, share, test, unit) really
seem to go together because they are code whereas conf/, doc/ are other
subjects. Here is my preferred structure (updated) :
jakarta-struts
|_ out (generated by the build script)
|_ dist
|_ build
|_ (support batch/sh files) + ant jars (if we agree on that) + build.xml
(if ok)
|_ conf
|_ unit
|_ doc
|_ src
|_ example
|_ share
|_ test
|_ unit
|_ web
> >
> > jakarta-struts
> > |_ out (generated by the build script)
> > |_ build
> > |_ conf
> > |_ doc
> > |_ src
> > |_ example
> > |_ share
> > |_ test
> > |_ web
> >
>
> You would need an additional output directory, "dist", for the target of
the
> "distribution" build.
>
Yes, see above
> >
> > 8- I'd like to use the src/test/ directory to put the struts unit tests.
> > What is the already existing test directory ? Was it done for that
purpose ?
> >
>
> It has the Java sources for the struts-test.war web application, in the
same way
> that "src/example" has the Java sources for the "struts-example.war" web
app.
>
> I would prefer not to eliminate this web app, because it offers a quick
and
> dirty way to exercize the various custom tags as they are being build
> interactively. However, it would not bother me to change the name.
>
> How about directory "src/unit" for the unit tests (and, correspondingly,
package
> name "org.apache.struts.unit.*" when you are not required to have the unit
tests
> in the same package as the class being tested)?
>
ok see above. For the package, I usually prefer to use the same packages as
the classes under tests (for protected method test). Having 2 types of
packages seem a bit artificial to me
> >
> > 9- I'd like to create a test/ subdirectory un conf/ where I'll put all
the
> > configuration files needed for the struts unit tests. Is that ok?
> >
>
> If we use "src/unit" for the unit test sources, it should probably be
> "conf/unit" for consistency. But I am fine with a subdirectory here.
>
ok
> >
> > 10- The strategy I have followed with J2EEUnit for it's tests was to run
the
> > tests in the out/ directory, i.e. not deploy to the servlet engine
install
> > directory. I like to control the files that I generate. By being located
> > under out/, they (a) are easy to clean up, (b) do not affect any other
> > webapp running on my system, (c) I can use the setting I want for my
servlet
> > engine for the tests without affecting the main config of my servlet
engine.
> > I would suggest the following directory hierarchy :
> >
> > jakarta-struts
> > |_ out
> > |_ tests
> > |_ tomcat-3.2
> > |_ conf
> > |_ webapps
> > |_ work
> > |_ tomcat-4.0
> > |_ ...
> > |_ resin-1.2
> > |_ ...
> > |_ ...
> > |_ conf
> > |_ test
> > |_ j2eeunit.properties
> > |_ tomcat
> > |_ testserver-3.2.xml
> > |_ testserver-4.0.xml
> >
>
> Sounds reasonable -- the only recommended change would be to use "unit"
rather
> than "test" as a directory name if we choose *not* to eliminate the
current
> struts-test webapp.
>
ok for unit
> >
> > 11- Does Struts support only one servlet api at a time (like the 2.2
one) or
> > is it your plan to support several, like 2.2 and 2.3 ?
> >
>
> Right now, all of Struts is based on the servlet 2.2 / JSP 1.1 APIs. At
some
> point in the future, I would like to start building optional capabilities
that
> require 2.3 / 1.2, but for the foreseeable future we cannot really make
that a
> requirement.
>
> Fortunately, the 2.3 / 1.2 servlet API classes are "forwards compatible",
so
> that you can generally compile against them and still run on a 2.2/1.1
servlet
> container, as long as you avoid any of the new method calls.
>
> >
> > Please feel free to discard anything that I have said that does not fit
your
> > plan. I understand that I am new here ... However, I just wanted to let
you
> > know my thoughts in case I bring forward something that can improve
Struts.
> >
> > Tell me what you think of these and tell me how I have to proceed for
> > building the test suite ? Do I
> > change the files and send the to you by email ? What can I apply from
the
> > above mentionned points ? Is there a CVS branch that I
> > should work on instead of the main one ?
> >
>
> What I'd like to do is the following:
>
> * Propose you and Rob as committers (see separate message) according
> to the standard Jakarta policies and practices, so you can both have
> write access to the CVS repository.
>
> * Make the organizational changes that come out of the above discussion
> in the current HEAD branch, to be completed prior to 1.0-beta-2. (I
don't
> anticipate the need for more than one more beta cycle, but we'll see
what
> bug reports show up).
>
> * At that point, make the 1.0 code a branch in the repository, so we can
> make the HEAD branch available for starting on 1.1 related stuff.
>
> Does that sound like a plan?
>
Thanks ! That's great ... Let's get the work done ... :)
> >
> > Thanks.
> > Vincent.
>
> Craig
>
Vincent.
Re: PROPOSAL - Testing Framework
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Vincent Massol wrote:
> I am now looking at Struts in order to write the test suite (I have only
> looked at build.bat and build.xml so
> far ...) and I have notice the following details that may need to be
> corrected/improved :
>
Hello Vincent,
Sorry for the slow response ... I was really focused yesterday on getting the
beta out. Now we can start planning next steps.
>
> 1- In build.bat, the CP variable does not define an XML parser.
> %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added. Or,
> is that voluntarily because you want to leave the choice to the developer to
> choose his one jaxp compliant parser ? Personnaly, I prefer to force it to a
> choice that will always work. I prefer to leave my CLASSPATH always empty
> because otherwise it creates lots of problems when you switch from one
> project to another ...
>
My preference has always been to allow people to choose their own tools -- such
as their own version of Ant, their own XML parser, their own servlet API
version, and so on -- rather than force these decisions. After all, Struts will
be used in applications that have all manner of dependencies on different
versions of these things.
On Ant in particular, I would actually prefer us to run Ant via
"$ANT_HOME/bin/ant" (Unix) or "%ANT_HOME%\bin\ant.bat" (Windows). That way, we
can let Ant itself worry about the changing directory structures required by
different versions of Ant. In addition, modern versions of "ant" and "ant.bat"
let you define system properties via "~/.antrc" (Unix) or "%HOME%\antrc_pre.bat"
and "%HOME%\antrc_post.bat" (Windows).
>
> 2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and
> optional.jar) but in the jakarta-ant distribution that I got using CVS, the
> ant.jar and optional.jar are generated and put in dist\lib.
>
Switching to $ANT_HOME/bin/ant will take care of this kind of thing.
>
> 3- Is that an Apache choice not to bundle the needed external jars within
> your own project ?
Different Apache subprojects do it differently -- this is my choice (and I'm
probably in the minority here). I use quite a few open source projects, and the
number of copies of ant.jar and xerces.jar on my hard drive is pretty
disgusting.
> I would tend to prefer to bundle ant
> jars and servletapi jars for Struts because (a) they are only used to build
> struts, not for runtime and (b)otherwise the building of struts will fail or
> succeed depending on the state of these other projects, thus you might get
> lots of posts on the mailing list from persons trying to build Struts but
> failing just because they have a bad version of Ant for instance (I speak
> from experience as for J2EEUnit I tried several Ant release and I can tell
> you they were not all working, far from that, and I had to struggle to find
> the good one. At least I know that the one I bundle is going to work with no
> problem and from time to time I upgrade it. In other words I certify my app
> to work with such version. However if the enn developer want to use a
> newer/older version, he is free to try it ...). Thoughts ? (Sorry if this
> way of doing it has already been discussed at length ... :( )
>
It hasn't been discussed on STRUTS-DEV, so it's probably worth talking about.
How do folks feel about this? Was the pain of having to download the
prerequisite packages worth the ability to use whatever versions you preferred?
>
> 4- build.xml need more comments, better formatting and some minor additional
> refactorings (to my opinion). Am I allowed to do that ?
>
Yes. Once we agree on a path, any of the docs or build scripts are fair game,
along with the code :-).
>
> 5- What do you think about creating a build directory where you put the
> files that are needed to run the build of struts. They would be : build.xml,
> build.bat, all Ant jars (that's only if you agree with point 3 of course ...
> :) ), maybe some other batch files to help start other targets from Windows.
> The output of the build will go in a directory named out/ for example (I
> have always found the name build/ for the output to be confusing. It means
> "a build" but also "to build" ...)
>
I personally prefer the build.xml and associated scripts to be in the top-level
directory so you do not have to go hunting for them.
Currently, the 'build" directory is an *output* of the Struts build process,
rather than an input. We'd have to change that (for example, some subprojects
use "target" for their destinations). In your scenario below, it looks like
this should be changed to "out".
>
> 6- If you agree on point 3, creating a lib directory at the top level to put
> the servletapi jar would be a good idea.
Which version?
Right now, Struts requires only servlet 2.2 / JSP 1.1 APIs, but my daily work on
Tomcat 4.0 requires me to use the servlet 2.3 / JSP 1.2 servlet.jar file. This
is the kind of problem you run into by forcing a choice on the developer :-).
> . Also I need to put the j2eeunit +
> junit jars. Putting them in lib/ would be a good idea I think.
>
As opposed to saying "go build these projects yourself and provide an
environment variable pointing at them"? Yah, OK, I guess -- a "lib" directory
it is.
>
> 7- Why do you have a conf/ directory under src ? Wouldn't you prefer it to
> have
> at the top level (or is it a Jakarta requirement) ? Something like :
>
Conceptually, I think of these files as part of the source code, but it's no big
deal one way or the other to me.
>
> jakarta-struts
> |_ out (generated by the build script)
> |_ build
> |_ conf
> |_ doc
> |_ src
> |_ example
> |_ share
> |_ test
> |_ web
>
You would need an additional output directory, "dist", for the target of the
"distribution" build.
>
> 8- I'd like to use the src/test/ directory to put the struts unit tests.
> What is the already existing test directory ? Was it done for that purpose ?
>
It has the Java sources for the struts-test.war web application, in the same way
that "src/example" has the Java sources for the "struts-example.war" web app.
I would prefer not to eliminate this web app, because it offers a quick and
dirty way to exercize the various custom tags as they are being build
interactively. However, it would not bother me to change the name.
How about directory "src/unit" for the unit tests (and, correspondingly, package
name "org.apache.struts.unit.*" when you are not required to have the unit tests
in the same package as the class being tested)?
>
> 9- I'd like to create a test/ subdirectory un conf/ where I'll put all the
> configuration files needed for the struts unit tests. Is that ok?
>
If we use "src/unit" for the unit test sources, it should probably be
"conf/unit" for consistency. But I am fine with a subdirectory here.
>
> 10- The strategy I have followed with J2EEUnit for it's tests was to run the
> tests in the out/ directory, i.e. not deploy to the servlet engine install
> directory. I like to control the files that I generate. By being located
> under out/, they (a) are easy to clean up, (b) do not affect any other
> webapp running on my system, (c) I can use the setting I want for my servlet
> engine for the tests without affecting the main config of my servlet engine.
> I would suggest the following directory hierarchy :
>
> jakarta-struts
> |_ out
> |_ tests
> |_ tomcat-3.2
> |_ conf
> |_ webapps
> |_ work
> |_ tomcat-4.0
> |_ ...
> |_ resin-1.2
> |_ ...
> |_ ...
> |_ conf
> |_ test
> |_ j2eeunit.properties
> |_ tomcat
> |_ testserver-3.2.xml
> |_ testserver-4.0.xml
>
Sounds reasonable -- the only recommended change would be to use "unit" rather
than "test" as a directory name if we choose *not* to eliminate the current
struts-test webapp.
>
> 11- Does Struts support only one servlet api at a time (like the 2.2 one) or
> is it your plan to support several, like 2.2 and 2.3 ?
>
Right now, all of Struts is based on the servlet 2.2 / JSP 1.1 APIs. At some
point in the future, I would like to start building optional capabilities that
require 2.3 / 1.2, but for the foreseeable future we cannot really make that a
requirement.
Fortunately, the 2.3 / 1.2 servlet API classes are "forwards compatible", so
that you can generally compile against them and still run on a 2.2/1.1 servlet
container, as long as you avoid any of the new method calls.
>
> Please feel free to discard anything that I have said that does not fit your
> plan. I understand that I am new here ... However, I just wanted to let you
> know my thoughts in case I bring forward something that can improve Struts.
>
> Tell me what you think of these and tell me how I have to proceed for
> building the test suite ? Do I
> change the files and send the to you by email ? What can I apply from the
> above mentionned points ? Is there a CVS branch that I
> should work on instead of the main one ?
>
What I'd like to do is the following:
* Propose you and Rob as committers (see separate message) according
to the standard Jakarta policies and practices, so you can both have
write access to the CVS repository.
* Make the organizational changes that come out of the above discussion
in the current HEAD branch, to be completed prior to 1.0-beta-2. (I don't
anticipate the need for more than one more beta cycle, but we'll see what
bug reports show up).
* At that point, make the 1.0 code a branch in the repository, so we can
make the HEAD branch available for starting on 1.1 related stuff.
Does that sound like a plan?
>
> Thanks.
> Vincent.
Craig
Re: PROPOSAL - Testing Framework
Posted by Vincent Massol <vm...@octo.fr>.
I am now looking at Struts in order to write the test suite (I have only
looked at build.bat and build.xml so
far ...) and I have notice the following details that may need to be
corrected/improved :
1- In build.bat, the CP variable does not define an XML parser.
%ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added. Or,
is that voluntarily because you want to leave the choice to the developer to
choose his one jaxp compliant parser ? Personnaly, I prefer to force it to a
choice that will always work. I prefer to leave my CLASSPATH always empty
because otherwise it creates lots of problems when you switch from one
project to another ...
2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and
optional.jar) but in the jakarta-ant distribution that I got using CVS, the
ant.jar and optional.jar are generated and put in dist\lib.
3- Is that an Apache choice not to bundle the needed external jars within
your own project ? I would tend to prefer to bundle ant
jars and servletapi jars for Struts because (a) they are only used to build
struts, not for runtime and (b)otherwise the building of struts will fail or
succeed depending on the state of these other projects, thus you might get
lots of posts on the mailing list from persons trying to build Struts but
failing just because they have a bad version of Ant for instance (I speak
from experience as for J2EEUnit I tried several Ant release and I can tell
you they were not all working, far from that, and I had to struggle to find
the good one. At least I know that the one I bundle is going to work with no
problem and from time to time I upgrade it. In other words I certify my app
to work with such version. However if the enn developer want to use a
newer/older version, he is free to try it ...). Thoughts ? (Sorry if this
way of doing it has already been discussed at length ... :( )
4- build.xml need more comments, better formatting and some minor additional
refactorings (to my opinion). Am I allowed to do that ?
5- What do you think about creating a build directory where you put the
files that are needed to run the build of struts. They would be : build.xml,
build.bat, all Ant jars (that's only if you agree with point 3 of course ...
:) ), maybe some other batch files to help start other targets from Windows.
The output of the build will go in a directory named out/ for example (I
have always found the name build/ for the output to be confusing. It means
"a build" but also "to build" ...)
6- If you agree on point 3, creating a lib directory at the top level to put
the servletapi jar would be a good idea. Also I need to put the j2eeunit +
junit jars. Putting them in lib/ would be a good idea I think.
7- Why do you have a conf/ directory under src ? Wouldn't you prefer it to
have
at the top level (or is it a Jakarta requirement) ? Something like :
jakarta-struts
|_ out (generated by the build script)
|_ build
|_ conf
|_ doc
|_ src
|_ example
|_ share
|_ test
|_ web
8- I'd like to use the src/test/ directory to put the struts unit tests.
What is the already existing test directory ? Was it done for that purpose ?
9- I'd like to create a test/ subdirectory un conf/ where I'll put all the
configuration files needed for the struts unit tests. Is that ok?
10- The strategy I have followed with J2EEUnit for it's tests was to run the
tests in the out/ directory, i.e. not deploy to the servlet engine install
directory. I like to control the files that I generate. By being located
under out/, they (a) are easy to clean up, (b) do not affect any other
webapp running on my system, (c) I can use the setting I want for my servlet
engine for the tests without affecting the main config of my servlet engine.
I would suggest the following directory hierarchy :
jakarta-struts
|_ out
|_ tests
|_ tomcat-3.2
|_ conf
|_ webapps
|_ work
|_ tomcat-4.0
|_ ...
|_ resin-1.2
|_ ...
|_ ...
|_ conf
|_ test
|_ j2eeunit.properties
|_ tomcat
|_ testserver-3.2.xml
|_ testserver-4.0.xml
11- Does Struts support only one servlet api at a time (like the 2.2 one) or
is it your plan to support several, like 2.2 and 2.3 ?
Please feel free to discard anything that I have said that does not fit your
plan. I understand that I am new here ... However, I just wanted to let you
know my thoughts in case I bring forward something that can improve Struts.
Tell me what you think of these and tell me how I have to proceed for
building the test suite ? Do I
change the files and send the to you by email ? What can I apply from the
above mentionned points ? Is there a CVS branch that I
should work on instead of the main one ?
Thanks.
Vincent.
Re: building struts
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Rob Leland wrote:
> Ok:
>
> I am trying to build struts Feb 22 using:
>
> ant 1.3-b3, options.jar (1.3 b3); jaxp 1.1
>
> I haven't been sucessfull yet.
>
For day-to-day development I use current CVS code for Ant, with the JAXP
1.1
JAR files plus the Xerces 1.2.0 JAR file on my classpath (in that
order).
Sealing violations happen because the JAXP jar files are sealed, and
Xerces is
found ahead of JAXP.
>
> Which version of ant are you using to build struts.
> Have you tried gump ?
I watch the output but haven't played with it directly. Once I have
time, I'll
probably migrate to using GUMP-based output to create the nightly builds
of
Struts -- but I want to think about that a little more first.
Craig
>
> BUILD FAILED
>
> java.lang.SecurityException: sealing violation
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:234)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:120)
> at
> javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:117)
> at
> org.apache.tools.ant.ProjectHelper.getParserFactory(ProjectHelper.java:706)
> at
> org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:105)
> at
> org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:85)
> at org.apache.tools.ant.Main.runBuild(Main.java:403)
> at org.apache.tools.ant.Main.main(Main.java:149)
building struts
Posted by Rob Leland <Ro...@freetocreate.org>.
Ok:
I am trying to build struts Feb 22 using:
ant 1.3-b3, options.jar (1.3 b3); jaxp 1.1
I haven't been sucessfull yet.
Which version of ant are you using to build struts.
Have you tried gump ?
BUILD FAILED
java.lang.SecurityException: sealing violation
at java.net.URLClassLoader.defineClass(URLClassLoader.java:234)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:120)
at
javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:117)
at
org.apache.tools.ant.ProjectHelper.getParserFactory(ProjectHelper.java:706)
at
org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:105)
at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:85)
at org.apache.tools.ant.Main.runBuild(Main.java:403)
at org.apache.tools.ant.Main.main(Main.java:149)
Re: Final Release 1.0 Time Frame
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Gerry Chike wrote:
> Hi Craig,
> Do you have a "time frame" for the final release of Struts 1.0? I'm working on a project that needs to make either a Go or No-go based on the timing of the final release. I appreciate any thoughts or feedback regarding this issue.
As it happens, I'm going to be creating the Beta 1 release this afternoon (just licked the last problem reported in the bug tracking system). I would anticipate the time between beta 1 and a final release to be a small number of
weeks -- the only new "functionality" that I want to see added is unit tests, so there should be no disruption of the stability of basic Struts features.
>
> Thanks,
> Gerry
>
Craig
>
> Good, Cheap, or Fast: Pick any two.
It's amazing how many people don't remember this :-)