RE: Making Struts Build Easier (Re: "coming out" for JSF + Struts, was: Struts JSR?)

[Steve Raeburn]

FWIW I'm with Martin on this. I don't understand the advantage having
separate repositories will give us. Even under one top lever repository
directory, we can organize the Struts product(s) however we like.

The only advantage I can see in having separate repositories would be to
make it easier to grant different groups of committers access to
different areas. But that's not what we want to do anyway.

Another reason NOT to split into several top level directories is that
it adds more clutter to the already busy Apache repository. IMHO fewer
top level directories makes it easier for people to find what they need.

If there's a compelling reason to split into several top-level
repository directories that hasn't been stated (or I've missed), please
let me know, otherwise  I'd prefer to keep as few as possible.

But it's not a life or death issue either way :-)

Steve


> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 22, 2004 11:50 PM
> To: Craig R. McClanahan
> Cc: Struts Developers List
> Subject: Re: Making Struts Build Easier (Re: "coming out" for JSF +
> Struts, was: Struts JSR?)
>
>
> On Mon, 22 Mar 2004, Craig R. McClanahan wrote:
>
> > Quoting Martin Cooper <[EMAIL PROTECTED]>:
> >
> > > On Mon, 22 Mar 2004, Ted Husted wrote:
> > >
> > > > On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
> > > > > While it's great to break out things into separate
> "modules" - I'd
> > > > > love to be able to get struts.jar w/ everything in it
> - including
> > > > > EL and tags.  I can live with all the commons-* JARs
> (even if it is
> > > > > annoying), but in general - the less JARs, the
> better.  It just
> > > > > simplifies things for the developer.
> > > > >
> > > > > I don't care how things are partitioned in CVS, as long as
> > > > > everything builds with one checkout and one command.
> > > >
> > > > If that were someone's itch, it could certainly be
> done. Ant doesn't know
> > > about the module partitions, and so someone could write a
> uber-build that did
> > > something like this.
> > >
> > > If we have all of the pieces in separate repositories,
> though, where would
> > > the files for such an uber-build be checked in? That's
> one of the problems
> > > I have with the multi-repository solution - there is no
> place for files
> > > that span those repositories. If we have one repository
> split into pieces,
> > > then we still have the top level for these things.
>  > >
> >
> > On the multi-repository projects I've worked on, we had a
> special repository
> > just for integration tasks like this.
>
> So we'd need yet another repo - say struts-integration - just
> for this.
> Why is that better than just doing what we need within the
> repo that we
> have already?
>
> > > > But, the problem with thinking of Struts as one
> monothic build is that
> > > every aspect of the framework has to be perfect, all at
> the same time, before
> > > we can call it a "general availability"
> ready-for-prime-time release.  One of
> > > the many reasons 1.1 took so long was that if there was
> any bug in any
> > > component anywhere in the framework, everything
> gridlocked.  :(  :(   :(
> > >
> > > That doesn't need to be true if we don't want it to.
> Recall that for a
> > > time we had a separtely built, separately distributed
> component called
> > > struts-legacy to handle the data source situation. There
> is no need for a
> > > one-to-one correlation between repositories and
> distributable entities.
> > >
> > > > What we want to do ... need to do ... is be able to
> release fixes to
> > > components like the taglibs independently of the core
> controller. Likewise,
> > > we need to release changes to Struts EL or Struts Faces
> (once it goes 1.0)
> > > without having to be sure every other component is ready
> to roll. We should
> > > also be able to release updates to the example
> applications without
> > > re-releasing the rest of the framework, if that's all we
> want to roll right
> > > now.
> > >
> > > Absolutely. And the number of repositories we have is
> entirely orthogonal
> > > to this.
> > >
> >
> > Ultimately true, although it's still somewhat easier to
> visualize if you have
> > separate repositories.
> >
> > > > Some people may not like more JARs, but I know for
> certain that the single
> > > JAR approach is a momentum killer. It's made my life much
> more difficult, and
> > > I think it's chased away some Committers who became
> frustrated by having to
> > > "everything right" in order to one little feature into a
> formal release.
> > >
> > > For the people who want / need a single jar, it would be
> simple enough for
> > > us to provide an Ant target that explodes the desired
> individual jars and
> > > recombines them into a single jar. The only tricky part,
> I think, would be
> > > creating a manifest that identifies the versions of the
> individual pieces
> > > in that jar. That's assuming people want such a beast, of
> course. (I'm not

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

[Steve Raeburn]

Option 1 works for me. Simplest thing that could possibly work. As
you've said, we can always change things around later.

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 20, 2004 9:44 PM
> To: Struts Developers List
> Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status
>
>
> On Sat, 20 Mar 2004, Craig R. McClanahan wrote:
>
> > Quoting Joe Germuska <[EMAIL PROTECTED]>:
> >
> > > At 2:48 PM -0500 3/14/04, Ted Husted wrote:
> > > >I'd say we could branch what we have as 1.2 and start thinking of
> > > >the HEAD as 1.3.
> > > >
> > > >IMHO, the quickest way to sort out what we need to do with the
> > > >Struts-Chain RequestProcessor is to get it out there as
> the nightly
> > > >build. [Many hands make light work ;)]
> > > >
> > > >So, we could reserve the 1.2 for any desperate fixes (as
> we've done
> > > >before), but do anything resembling new development
> against the HEAD
> > > >(1.3).
> > >
> > > I might do something like this over the weekend,
> depending on my time
> > > (then again, I may not at all!)
> > >
> > > But if I did, I'd want to see if anyone had any strong
> feelings, or
> > > fixes they thought they'd like to get in before a branch, or... ?
> > >
> > > Or should all of this wait until we get the move to
> struts.apache.org
> > > settled?  I'm assuming we'll reorganize CVS as part of that, into
> > > struts-core, struts-taglib, etc...
> >
> > I think there's a lot of merit in rationalizing the
> directory structures as part
> > of the move to TLP-ness.
>
> Assuming we don't move to Subversion right now (see other thread), the
> move is effectively a CVS repo rename by the infrastructure
> folks, lock,
> stock and barrel. Any rationalisation is totally up to us.
>
> If we want to break up our existing repo, we have a couple of options:
>
> 1) One top-level 'struts' repo that we break down as we see fit. This
> option leaves everything in our control, since, as far as
> infrastructure@
> is concerned, there is only one CVS repo.
>
> 2) Multiple top-level repos, one of which is a renamed version of our
> current repo, and the remainder of which are new empty repos. We would
> then migrate pieces of our current repo out to the new repos.
>
> 3) Same as (2) above, except that we don't ask for a repo
> rename, but just
> new repos, and we migrate everything ourselves to the appropriate new
> repo.
>
> While (3) is the "cleanest" insofar as we wouldn't have
> leftovers in the
> Attic of the renames repo, it's also a huge amount of work for us, and
> runs the risk of forgetting things.
>
> My preference is for (1). It is the simplest approach, and
> will allow us
> to move things around however we see fit, without having to decide up
> front which other repos we might want. If, at some point, we
> decide we do
> want other top-level repos, we can request them at that time.
>
> > >  Speaking of that, can we/should
> > > we do anything to preserve CVS logs if we move files?  Or will we
> > > start fresh?   I think if we move the actual CVS files it
> will all be
> > > preserved, but I've never tried that.
> > >
> >
> > There are ways to preserve history, but I suspect there
> will be difficulties if
> > we decide to split up what has been a single repository
> (jakarta-struts) into
> > per-subpackage repositories.  A guru on CVS would
> definitely be useful here.
>
> A CVS repo rename will preserve all of our history,
> obviously. After that,
> I can take care of preserving history whatever we decide to
> do (as long as
> we stay with CVS ;). It's slightly easier if we have only one
> repo, but it
> can still be done across repos.
>
> --
> Martin Cooper
>
>
> >
> > > I'm interested in getting the Struts Chain stuff mainstreamed, but
> > > like I said, this may very well not be the weekend I
> start on it.  In
> > > any case, I figured a branch would be cause for a little bit of
> > > discussion amongst committers.
> > >
> >
> > I'm going to focus some energy as well on commons-chain and
> struts-chain now
> > that JavaServer Faces is done.
> >
> > > Joe
> >
> > Craig
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL] Struts infrastructure changes

[Steve Raeburn]

All sound good with the following comments:

1. CVS integrates very nicely with my IDE right now (Eclipse/WSAD). I
don't know how well Subversion would integrate and I'd not want to move
if I lost that integration. I'm sure that also applies to other IDEs.

2. Bugzilla/Jira make no difference to me. Jira looks nicer! David's
point about the history is very important. Can we migrate the data?

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 20, 2004 9:05 AM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Struts infrastructure changes
>
>
> The following is a set of proposed changes to the Apache
> infrastructure to
> accommodate the Struts move to an Apache top level project.
> The idea is to
> come up with a single agreed-upon set of changes that we can
> submit to the
> infrastructure folks as a single request, rather than
> submitting each one
> piecemeal. Your feedback is appreciated.
>
> Mailing Lists
>   New mail domain: struts.apache.org
>   The following lists are standard for an Apache TLP:
> user@
> dev@
> cvs@ (usually forwarded to dev@)
> pmc@
>   Moderator: Ted Husted (same as today)
>   Existing subscribers need to be migrated.
>   Old list addresses should be forwarded for some period of time.
>
> Web Site
>   New virtual host: struts.apache.org
>   Redirect from jakarta.apache.org/struts for some period of time.
>   Writeable by group: struts (see below)
>
> Wiki
>   New wiki: wiki.apache.org/struts
>   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
>
> Unix Group
>   New group: struts
>   Members: (Struts PMC members)
>
> Source Control
>   Old CVS repo: jakarta-struts
>   New CVS repo: struts
>   Optional: Move to Subversion (IMO, not now, but we can discuss.)
>
> Bug Database
>   Optional: Move to Jira (IMO, now's as good a time as any.)
>
>
> One other thing is that we'll want to get external mail archivers to
> switch to the new mailing lists once those are set up. I'm
> not clear on
> whether the infrastructure folks arrange that or we need to do it
> ourselves, but I'll ask when I submit the above.
>
> Anything else I missed? (There are a lot of internal changes
> we'll want to
> make as well, but I'm not trying to address those here.)
>
> --
> Martin Cooper
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts JSR?

[Steve Raeburn]

Like most people, I imagine, I still haven't had time to do more than
give JSF a cursory glance. It's clear that there is some overlap between
JSF and Struts. However, that does not mean that one or other will
simply disappear.

Craig has previously stated that there is still a role for Struts to
play. He has demonstrated by developing a means to integrate the two and
making it available in the Struts distribution. See Struts-Faces in the
Struts contrib directory.

As the creator of Struts and spec lead for JSF, I think Craig is in a
unique position to understand where all this is going. I take the fact
that he has accepted the role of Chair of the newly formed Apache Struts
PMC as a sign that he believes Struts has a strong future and that he's
willing to help its continuing evolution and growth.

Let me be very clear that I'm not trying to speak for Craig here. I'm
just relaying how *I* view things right now. As I don't yet have any
meaningful personal experience with JSF, I have to gauge things based on
what others are saying and doing. I would rather base *my* actions and
effort on Craig's direction than on the fears of others who also have no
meaningful experience of JSF (or Struts).

Bottom line is, Struts will evolve to fill any need not met by the
standards. Which is pretty much how the whole thing got started.

Steve


> -Original Message-
> From: Thomas L Roche [mailto:[EMAIL PROTECTED]
> Sent: March 19, 2004 6:14 PM
> To: [EMAIL PROTECTED]
> Subject: OT: Struts JSR?
>
>
> David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of
> his remarks include
>
> - Is JSF a replacement for Struts? Yes!
>
> - JSF is a standard. Struts will never be a standard.
>
> which I believe to be pretty-nearly-direct quotes. I'm assuming he
> really meant
>
> + JSF 1.0 can do pretty much everything Struts 1.1 can.
>
> + JSF is a JSR, and Struts will never be a JSR.
>
> but I'm wondering about that last statement. What prevents Struts
> from undergoing the JCP? Are there circumstances under which you
> might consider this?
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [ANNOUNCE] Struts goes TLP with unanimous vote...

[Steve Raeburn]

Yay, Struts!

Congratulations to everyone and special thanks to Martin for preparing
the proposal. Thanks also to Craig for agreeing to be the scapego..
err.. VP of the new project.

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 17, 2004 7:21 PM
> To: Struts Developers List
> Subject: Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
>
>
> On Wed, 17 Mar 2004, Arron Bates wrote:
>
> > Guys,
> >
> > Just got the summary email from the Apache board meeting,
> and the Struts
> > proposal went through with flying colours.
> >
> > Congrats guys, really. So much never-ending quality work.
> >
> >
> > I guess that with everyone else out driking Irish alcohol I
> was the first to
> > see the email, and I got to be the whistle-blower. :)
>
> Nah, you just type a little faster than I do. ;-)
>
> I'll be putting together a list, shortly, of what needs to
> happen next for
> us to fully "graduate". Stay tuned...
>
> --
> Martin Cooper
>
>
> >
> >
> > Cheers,
> >
> > Arron.
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache License 2.0

[Steve Raeburn]

I've updated the remaining Java source files to the Apache 2.0 license.
I didn't manage to make Paul's patch work, but I did get the
ReplaceLicense tool to do most of the work.

There are a few things that need to be dealt with:

1. CVS headers

My updates (and Paul's patches) left the CVS headers intact -

$Header$
$Revision$
$Date$

I noticed that the files that had already been updated do not have the
headers. We should be consistent. Do we want to add them where they
don't exist or remove them where they do? I find them useful and would
like them to remain.

2. Incorrect copyright dates

I noticed a number of copyright dates that were clearly incorrect in the
original Apache 1.1 license. For example, there are quite a few '1999-'
dates which, unless I'm mistaken, pre-dates Struts by some way. I assume
they were just cut-and-pasted from elsewhere.

3. Scaffold additional copyright notices:

There are some additional copyright notices in some of the Scaffold
files. I don't know if this is acceptable any longer under the new
license.

-- o.a.s.scaffold.Base Action -->
Copyright (c) 2002 Synthis Corporation.
430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A.
All rights reserved.

This software is licensed to you free of charge under
the Apache Software License, so long as this copyright
statement, list of conditions, and comments,  remains
in the source code.  See bottom of file for more
license information.

This software was written to support code generation
for the Apache Struts J2EE architecture by Synthis'
visual application modeling tool Adalon.

For more information on Adalon and Struts code
generation please visit http://www.synthis.com


-- o.a.s.scaffold.SnoopServlet Action -->
Derived from the Jetty SnoopServlet

and distributed under its open source license
 .


I have added the licenses to the Scaffold notice file, which I think is
where attributions should go. For now, I've also left them in the source
files as well. What should we do with these?

4. I've only updated the Java source files. What other files need to
have an ASL 2.0 license? XML docs? Struts DTD?

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts Logo

[Steve Raeburn]

The intention is that anyone will be able to submit a logo.

But first, the committers will have to decide whether they want a new
logo. ** There is no competition yet! **

Regarding your upload, the entries would be have to be checked and
approved before being displayed on the site. Otherwise people would be
posting all kinds of strange pictures 8-) Your submission is waiting in
the queue.

Please monitor this list to see if we actually decide to hold a
competition, at which time the details would be announced. You would
need to re-submit your entry at that time.

Thanks for your enthusiastic interest though!

Steve


> -Original Message-
> From: Michael Albrecht [mailto:[EMAIL PROTECTED]
> Sent: March 8, 2004 9:42 AM
> To: Struts Developers List
> Subject: Re: Struts Logo
>
>
> Zitat von Steve Raeburn <[EMAIL PROTECTED]>:
>
> > As a sideshow to the Struts TLP proposal, I'd like to resurrect a
> > discussion from a few months ago regarding a new logo for the Struts
> > project.
> >
> > At the time, I put together a site
> > (http://www.ninsky.com/struts/logo/logo.do) to allow submission and
> > voting for a new logo, should we decide we want one. Please
> take a look,
> > and if there's interest from the committers and community,
> then we could
> > launch a competition for a shiny new logo to go with the (possible)
> > shiny new TLP status.
>
> Do you allow everyone submissing logos or is there a special group of
> submitters?
>
> I`m asking because I`ve tried to load one logo up yesterday
> and the submit
> action has not been gone wrong, but the logo is not visible
> at the moment.
>
> Beside this: are there any parameters for the new logo? Width, height,
> filesize?
>
> Michael
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts Logo

[Steve Raeburn]

Oops!. That's what I get for posting too late at night.

http://www.ninsky.com/struts/logo.do was what I meant.
(But Ted's link goes to the same place).

Thanks Martin/Ted for pointing it out.


Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: March 7, 2004 6:37 AM
> To: Struts Developers List
> Subject: Re: Struts Logo
>
>
> This might be the link Steve meant to post:
>
> http://www.ninsky.com/struts/logo/entries.do
>
> On Sun, 07 Mar 2004 01:04:28 -0800, Steve Raeburn wrote:
> > As a sideshow to the Struts TLP proposal, I'd like to resurrect a
> > discussion from a few months ago regarding a new logo for the
> > Struts project.
> >
> > At the time, I put together a site
> > (http://www.ninsky.com/struts/logo/logo.do) to allow submission and
> > voting for a new logo, should we decide we want one. Please take a
> > look, and if there's interest from the committers and community,
> > then we could launch a competition for a shiny new logo to go with
> > the (possible) shiny new TLP status.
> >
> > Steve
> >
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Struts Logo

[Steve Raeburn]

As a sideshow to the Struts TLP proposal, I'd like to resurrect a
discussion from a few months ago regarding a new logo for the Struts
project.

At the time, I put together a site
(http://www.ninsky.com/struts/logo/logo.do) to allow submission and
voting for a new logo, should we decide we want one. Please take a look,
and if there's interest from the committers and community, then we could
launch a competition for a shiny new logo to go with the (possible)
shiny new TLP status.

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Struts as an Apache Top Level Project

[Steve Raeburn]

+1 Struts TLP
+1 Craig for President in 2004. (Sorry, VP)

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 6, 2004 11:20 AM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Struts as an Apache Top Level Project
>
>
> Following up on a brief thread on this list in December [1],
> Craig, Ted
> and I have put together a draft resolution to the board of
> directors [2],
> along with a cover letter [3], that would promote Struts to an Apache
> top-level project (TLP).
>
> The main reasons for moving to a TLP are described on the wiki [4]. In
> Craig's words, "The short answer, though, is we will be in
> charge of our
> own releases (currently, the Jakarta PMC is the only body legally
> recognized to vote on releases of *any* software under Jakarta)." In
> practice, we can really just continue doing what we've always done.
>
> As most of you are no doubt aware, several Jakarta sub-projects have
> already made the transition to TLPs, including Ant, Avalon,
> Gump, James,
> Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in
> favour of the migrations, largely because a single PMC cannot possibly
> oversee a code base the size of all of Jakarta.
>
> If you're OK with Struts being a top-level Apache project,
> please respond
> to this thread with either a +1 or +0. Otherwise, please
> reply with your
> concerns. When we previously discussed this, it did not seem
> like anyone
> was opposed to the idea, but if anyone is, now is the time to
> speak up.
>
> The resolution as drafted lists the Struts Committers who could
> reasonably be considered active at this time. Of course, we should not
> put anyone on the PMC without their buy-in, so the final
> resolution would
> only list the Committers who responded to the Vote with a +1 or +0.
>
> The draft resolution also leaves the name of the Vice President blank.
> Craig seems like the logical candidate, and is willing to act in this
> capacity, but we wanted the VP selection to be a community
> decision. So,
> please also respond with your nomination for Vice President, Apache
> Struts.
>
> Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice
> President.
>
> --
> Martin Cooper
>
> [1]
http://nagoya.apache.org/eyebrowse/SearchList?listId=&listName=struts-de
[EMAIL PROTECTED]&searchText=%22Why+you+*want*+to+be+on+the+PMC%22&de
faultField=subject&Search=Search
[2] http://www.apache.org/~martinc/struts/tlp/resolution.html
[3] http://www.apache.org/~martinc/struts/tlp/cover.html
[4]
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven Build (Re: Struts Change Tracking)

[Steve Raeburn]

Just for the record, what I was thinking of doing was to massage the
docs files into a format that's compatible with Maven and adapting the
XSL files for the Ant build to work with them. That way we'll be able to
run both builds from the same source files. I think it'll be easier to
adapt the XSL files to Maven, than the other way around.

The automated conversion I referred to would be a one-time conversion
from the existing format to the Maven compatible format. There's a bit
of grunt work in analysing the differences between the two and then
checking for anything the conversion missed, but I'm optimistic that
we'll be able to do the conversion with an XML transform (since the
source files are already in XML format).

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: March 3, 2004 3:42 PM
> To: Struts Developers List
> Subject: Re: Maven Build (Re: Struts Change Tracking)
>
>
>
> > -Original Message-
> > From: Steve Raeburn [mailto:[EMAIL PROTECTED]> Thank you.
> >
> > The current build does generate the Mavenized web site when you run
>
> > Just a reminder: the xdocs directory should not be
> maintained - the live
>
> I synced the xdocs to docs about a month ago using a comparison
> tool, though I realized that 'doc' is the master. Because of that
> I wouldn't want it deleted, since getting the docs in there is
> half the work.
>
>
> > test files in their place for continued Maven build
> testing. Thoughts?
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven Build (Re: Struts Change Tracking)

[Steve Raeburn]

Thank you.

The current build does generate the Mavenized web site when you run
'maven site'. Of course the site it builds is generated from the xdocs
directory, which will be out of date by now. I don't have anything right
now to convert from docs->xdocs. If I do get a chance to look at
anything, I'll start with that.

Just a reminder: the xdocs directory should not be maintained - the live
documentation source files are still in docs and are transformed via the
Ant build *only*. If that's considered confusing, then it might be an
idea to remove the xdocs files for now, possibly leaving a couple of
test files in their place for continued Maven build testing. Thoughts?

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: March 2, 2004 9:49 PM
> To: Struts Developers List
> Subject: Re: Maven Build (Re: Struts Change Tracking)
>
>
>
> > -Original Message-
> > From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> > I think I committed anything I had a while ago.
>
> So the demo website that you posted should be able to generated
> using the current build ? Also you mentioned that you had a script
> to automatically move over the docs to xdocs. If so could that also
> be Checked in ?
>
> And of course Congradulations on your new Job !
>
> >
> > If Tim, or anyone else, want to submit patches, I'll gladly
> look them
> > over and check them in but, in the short term, I probably
>
>  won't be doing
> > much myself since I've just started a new job. Once that
> settles down,
> > I'll get back to it.
> >
> > Steve
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: February 27, 2004 5:36 PM
> > > To: Struts Developers List
> > > Subject: Re: Maven Build (Re: Struts Change Tracking)
> > >
> > >
> > > It was Steve R. that said he would committ changes after 1.2.0.
> > >
> > >
> > > > -Original Message-
> > > > From: Tim Chen [mailto:[EMAIL PROTECTED]
> > > > I can help with the maven build. I had some patches for the
> > > maven build
> > > > way back when that were incorporated and have learned quite
> > > a bit more
> > > > about maven since then. I haven't had time to work on
> > > anything else for
> > > > struts lately but I have a bit more time now. But I don't
> > > want to step
> > > > on anyone's toes. If you have something in particular that
> > > you would
> > > > like to to do please let me know. :)
> > > > -Tim
> > > >
> > > > Joe Germuska wrote:
> > > >
> > > > > At 4:48 PM + 2/27/04, Robert Leland wrote:
> > > > >
> > > > >>  > -Original Message-
> > > > >>
> > > > >>>  From: Joe Germuska [mailto:[EMAIL PROTECTED]>
> > > > >>>  Even though Maven isn't our primary build mechanism,
> > > > >>
> > > > >>
> > > > >> Joe, It's been a while but was it you or someone else that
> > > > >> had a bunch of Maven build changes to check in after 1.2.0
> > > > >> went out the door ?
> > > > >
> > > > >
> > > > > Wasn't me; I did update project.xml to version
> > > "1.2.1-dev" and added
> > > > > the 1.2.0 version/tag to the  element.  I
> haven't got
> > > > > anything specific pending.
> > > > >
> > > > > I'd like to work on getting the Cactus tests running
> > > again, although
> > > > > I'll need some other eyes on it, and I would love for
> > > maven to be able
> > > > > to build the site -- I'm not going to have a ton of time
> > > for any of
> > > > > this in the next few weeks, though.
> > > > >
> > > > > Joe
> > > > >
> > > >
> > > >
> > > >
> > >
> -
> > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]

> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven Build (Re: Struts Change Tracking)

[Steve Raeburn]

I think I committed anything I had a while ago.

If Tim, or anyone else, want to submit patches, I'll gladly look them
over and check them in but, in the short term, I probably won't be doing
much myself since I've just started a new job. Once that settles down,
I'll get back to it.

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: February 27, 2004 5:36 PM
> To: Struts Developers List
> Subject: Re: Maven Build (Re: Struts Change Tracking)
>
>
> It was Steve R. that said he would committ changes after 1.2.0.
>
>
> > -Original Message-
> > From: Tim Chen [mailto:[EMAIL PROTECTED]
> > I can help with the maven build. I had some patches for the
> maven build
> > way back when that were incorporated and have learned quite
> a bit more
> > about maven since then. I haven't had time to work on
> anything else for
> > struts lately but I have a bit more time now. But I don't
> want to step
> > on anyone's toes. If you have something in particular that
> you would
> > like to to do please let me know. :)
> > -Tim
> >
> > Joe Germuska wrote:
> >
> > > At 4:48 PM + 2/27/04, Robert Leland wrote:
> > >
> > >>  > -Original Message-
> > >>
> > >>>  From: Joe Germuska [mailto:[EMAIL PROTECTED]>
> > >>>  Even though Maven isn't our primary build mechanism,
> > >>
> > >>
> > >> Joe, It's been a while but was it you or someone else that
> > >> had a bunch of Maven build changes to check in after 1.2.0
> > >> went out the door ?
> > >
> > >
> > > Wasn't me; I did update project.xml to version
> "1.2.1-dev" and added
> > > the 1.2.0 version/tag to the  element.  I haven't got
> > > anything specific pending.
> > >
> > > I'd like to work on getting the Cactus tests running
> again, although
> > > I'll need some other eyes on it, and I would love for
> maven to be able
> > > to build the site -- I'm not going to have a ton of time
> for any of
> > > this in the next few weeks, though.
> > >
> > > Joe
> > >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven status

[Steve Raeburn]

The Maven xdocs are not supposed to be maintained (yet). I only copied
them there originally to experiment with the Maven build process.

When we're happy with the Maven build, the documentation will be
automatically converted so there is no need to maintain both.

Steve

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: January 10, 2004 3:52 PM
> To: [EMAIL PROTECTED]
> Subject: Maven status
>
>
> We have duplicate documentation files in the maven xdocs
> directory and in
> the usual docs directory.  I updated the docs version of
> volunteers.xml
> today and am not looking forward to updating the xdocs
> version of the same
> file.  What is the status of the Maven build and when are we
> completely
> switching?  Are we even updating the Maven files?  Maintaining two
> versions of the documentation is a pain and will lead to one of the
> versions becoming outdated.
>
> David
>
> __
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: @author tags in Struts code

[Steve Raeburn]

fferent contributor lists?
>  What sort
> > of
> > >>>>criteria are used to figure out if someone deserves a listing?
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>I'm referring to this one:
> > >>>http://jakarta.apache.org/struts/volunteers.html
> > >>>
> > >>>What are the others you've seen?  If there are
> duplicates, we should
> > >>>probably combine them into one page.
> > >>>
> > >>>Providing a patch for code or docs qualify someone to be
> listed on
> > the
> > >>>site.
> > >>>
> > >>>David
> > >>>
> > >>>
> > >-
> > >* @author Berin Loritsch* @author Giacomo Pati* @author Pierpaolo
> > >Fumagalli* @author Stefano Mazzocchi* @author Anthony Kay* @author
> > Arron
> > >Bates* @author Cedric Dumoulin* @author Craig McClanahan*
> @author Craig
> > R.
> > >McClanahan* @author David Geary* @author David Graham*
> @author David
> > >Wintefeldt* @author David Winterfeldt [probably the correct one]*
> > @author
> > >Dominique Plante* @author Don Brown* @author Don Clasen*
> @author Eddie
> > >Bush* @author Erik Hatcher* @author Florent Carpentier*
> @author James
> > >Mitchell* @author James Turner* @author Jea-noel Ribette*
> @author Jeff
> > >Hutchinson* @author Jimmy Larsson* @author Joe Germuska* @author
> > Leonardo
> > >Quijano* @author Luis Arias * @author Marius Barduta*
> @author Martin
> > >Cooper* @author Martin F N Cooper* @author Michael Westbay* @author
> > Mike
> > >Schachter* @author Niall Pemberton * @author Oleg V
> Alexeev* @author
> > Paul
> > >Sundling* @author Ralph Schaer* @author Robert Leland* @author Rob
> > Leland*
> > >@author Scott Carlson* @author Steve Raeburn* @author Ted Husted
> > >
> > >
> > >
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Joe Germuska as a Struts Committer

[Steve Raeburn]

+1 

(He has to do all the Maven stuff, right ;-))

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: December 7, 2003 6:19 PM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Joe Germuska as a Struts Committer
> 
> 
> Joe has been involved in the Struts community for some time 
> now, and has
> been a great contributor on the -dev and -user lists, as well 
> as in the
> bug database. I believe Joe would be a great asset to the 
> team, and that
> it's time we invited him to join us as a Struts committer.
> 
> Here's my +1.
> 
> --
> Martin Cooper
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cactus tests (Re: Maven test run)

[Steve Raeburn]

Joe,
Thanks for the patches. I should be able to take a look at them
tomorrow.
I'd be happy to bounce some ideas around with you as soon as I have any
:-)

Steve

> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: December 6, 2003 7:41 AM
> To: Struts Developers List
> Subject: Cactus tests (Re: Maven test run)
>
>
> On Dec 1, 2003, at 10:53 AM, Steve Raeburn wrote:
> > 2. Run the Cactus tests
>
> OK, since the TLDs are out of the way (Thanks Tim, Steve!), I got
> started on this one this morning.  I've gotten decently far along but
> have to quit now.  If anyone else is interested in working on
> this bit,
> let me know so we can cooperate; otherwise, I'll try to get further
> before posting to Bugzilla.
>
> I've gotten most of the preliminary config/setup done and Cactus is
> just getting started and now it wants a copy of tools.jar (for JSP
> compilation).  I'm not quite sure how to hit that one, since Apple
> bundles tools.jar with the core java classes, which Tomcat
> won't allow
> in WEB-INF/lib  I guess I'll just have to get my own
> standalone copy of
> tools.jar.  (Is it 100% java, or am I going to have to repackage
> Apple's classes.jar?)
>
> Anyway, just wanted to let people know I was working on this, in case
> others were also interested...
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
>   "We want beef in dessert if we can get it there."
>-- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 25267] - Mavenise cactus tests

[Steve Raeburn]

Is that a proposal I hear? ;-)

Steve

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: December 6, 2003 10:00 PM
> To: Struts Developers List
> Subject: Re: DO NOT REPLY [Bug 25267] - Mavenise cactus tests
> 
> 
> On Sat, 7 Dec 2003 [EMAIL PROTECTED] wrote:
> 
> 
> I'm not complaining, but wouldn't this be easier if Joe could committ
> these himself?  (hint hint ;)
> 
> 
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > .
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25267
> >
> > Mavenise cactus tests
> >
> >
> >
> >
> >
> > --- Additional Comments From [EMAIL PROTECTED]  
> 2003-12-07 04:59 ---
> > Created an attachment (id=9429)
> > patch to maven.xml to prepare Cactus
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -- 
> James Mitchell
> Software Developer / Struts Evangelist
> http://www.struts-atlanta.org
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Disadvantages of Struts?

[Steve Raeburn]

Thanks, Wendy. I spotted you'd done that after I posted :-)

> -Original Message-
> From: Wendy Smoak [mailto:[EMAIL PROTECTED]
> Sent: December 3, 2003 3:29 PM
> To: Struts Developers List
> Subject: RE: Disadvantages of Struts?
>
>
>
> > This question should really be addressed to the struts-user list.
>
> Already done.  I answered it over there and copied the OP.  Just doing
> my part to keep people from bothering you guys while you work
> feverishly
> to release 1.2. :)
>
> --
> Wendy Smoak
> Application Systems Analyst, Sr.
> ASU IA Information Resources Management
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Disadvantages of Struts?

[Steve Raeburn]

This question should really be addressed to the struts-user list.

Thanks

Steve

> -Original Message-
> From: Robert H. Tran [mailto:[EMAIL PROTECTED]
> Sent: December 3, 2003 2:10 PM
> To: Struts Developers List
> Subject: Disadvantages of Struts?
> 
> 
> I just wonder if Struts comes with any significant drawback. 
> I mean not in
> terms of when to use Struts and when not to use it 
> necessarily, but more in
> the line of anyone's wishes that it had been better. Any 
> advice is very
> appreciated.
> 
> - Robert.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Should Struts ship with all of the commons jar files needed to get Struts datasources working?

[Steve Raeburn]

Rick,
What DataSource are you trying to set-up? GenericDatSource in
struts-legacy.jar is independent of DBCP so you shouldn't need those
jars.

The following configuration works for me, even when I remove
commons-dbcp and commons-pooling jars from tomcat (4.1.29)

  




  

You don't really need the type property, since GenericDataSource is the
default.

Steve

> -Original Message-
> From: Rick Hightower [mailto:[EMAIL PROTECTED]
> Sent: December 3, 2003 2:20 PM
> To: 'Struts Developers List'
> Subject: Should Struts ship with all of the commons jar files
> needed to
> get Struts datasources working?
>
>
> Currently 1.1 does not ship with commons jar files needed to
> get Struts
> datasources working.
>
>
>
> You need booth commons-pooling and commons-dbcp to get Struts
> Datasources to
> work, but they are *not* included with Struts 1.1. (In fact
> in Struts 1.1.,
> you also need Struts Legacy jar file as well.)
>
>
>
> I think this got through because if you are using Tomcat then both
> commons-pooling and commons-dbcp ship in the shared folder.
> You do need to
> download them if you are using another application server.
> You do need to
> download them only if you are going to use Struts Datasources. My
> understanding was that Struts would ship with the entire set
> of commons jar
> files needed to utilize all of the features of Struts. Are
> Struts Datasource
> EOL or something?
>
>
>
>
>
>
>
> Rick Hightower
>
> Chief Technology Officer
>
> ArcMind
>
> Know the Next!
>
> http://www.arc-mind.com 
>
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Enhancement in forms

[Steve Raeburn]

Struts *does* support both the input and validation of dates in
international formats. See struts-validator.war in the Struts
distribution for an example.

I suspect you are defining a field on your ActionForm as type
java.util.Date and expecting Struts to correctly populate it. That is
not recommended and would only work with a date in -MM-dd format, as
you have found.

The ActionForm is *not* a business bean, it is merely a buffer for data
from your HTML form. ActionForms allow data to be validated before being
passed to your application and buffer the input values so they can be
redisplayed to the user (if a validation error occurs, for example).
Since form values are supplied via HTTP as Strings, it is recommended
that you only use Strings (and possibly booleans) in your ActionForms.

There are a couple of ways you can transfer form values to your business
beans:
1. Copy the properties to a business bean in your Action (possibly using
BeanUtils).
2. Add extra getters to your ActionForm that perform the type
conversions.

If you employ the second strategy you might have an ActionForm with a
StartDate property that returns a String. To get a Date, you could add a
second method, e.g. getStartDateAsDate() that performs the conversion
and returns a Date.

The two options are not mutually exclusive. Use whatever works for you.

For more info, please search the struts-user list archives. This subject
has cropped up before and you may find alternative explanations useful.

Steve


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: December 3, 2003 10:21 AM
> To: Struts Developers List
> Subject: Enhancement in forms
>
>
>
>
> Hello pros,
>
>  I am using Struts and found a bad problem: it doesn't accept
> internacionalized input for dates and numbers.
>  As experimented, dates are accepted only in the
> '-MM-aa' pattern.
> I posted this bug at bugzilla for  Struts and commons-beanutils as I
> couldn't use it in the RequestProcessor to perform the
> localized populate.
>  I have a version of the RequestProcessor and
> common-beanutils here
> that works all right as I fixed them, posted the patches to
> bugzilla and I
> am waiting for something to happen!
>  Why doesn't Struts implement this feature? If it
> implements, how's
> it's used?
>
>  Will my patches be used for fixing theses bugs or I am
> doing it the
> wrong way?
>  I really need answers because it involves a very
> important project
> that will change the future of my company... one of our
> problems is that we
> have proprietary frameworks everywhere and we want to change
> to Struts if
> it fits our needs for the view layer.
>
>  Thank you guys,
>
> Stutz
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

http://maven.apache.org/repository-upload.html

Perhaps, if Maven is widely adopted by Apache projects, it would make
sense to set up an Apache based repository. Then projects would be able
to directly publish their own jars.

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: December 3, 2003 6:33 AM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> Joe Germuska wrote:
>  > Would it be a good idea to make an alternate JAR
> repository for Struts
>  > so that this step can be automated without depending on the iBiblio
>  > managers?  It's trivial to do in Maven -- in fact, now
> that I look, I
>  > see that it's configured in the "project.properties" file, but that
>  > line is commented out:
>  >
>  > #maven.repo.remote=http://www.ibiblio.org/maven/,http://
>  > jakarta.apache.org/struts/repo
>  >
>  > Any reason not to set that up so that it works?
>
> I'm still not clear on how the whole ibiblio thing works.
> But, yes, we
> should be making our nightly snapshot JAR available someplace and
> updating it every day as part of an automated process. Ditto
> for any of
> our Commons JAR dependencies.
>
> One question would be whether we should be distributing JARs
> from this
> server or not. Infrastructure is trying to limit the points of access
> for distributions.
>
> -Ted.
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven build: Update

[Steve Raeburn]

Thanks to Tim & Joe for supplying patches. They made it nice and easy
for me to take that last step and get the tlds generated and into the
jar.

As far as I can tell, the struts jar is now being built correctly and
should be a drop-in replacement for the one generated by the Ant build.
Please feel free to test it and tell me I missed something.

The only difference I'm aware of is that the Manifest is being generated
by Maven rather than being copied from /conf. Does anyone have any views
on whether this is OK, or if we should use the manually maintained
version? BTW, I've just noticed that the /conf version still says
version 1.1. That may be an argument in favour of generating it :-)

Here's where we stand:
1. Generate the TLD files (& docs)
-- TLDS are done, I'll look at the docs as part of 4. --
2. Run the Cactus tests
3. Build the web apps & contribs
4. Migrate the documentation

I'm going to take a look at Cactus next. There's a nice little section
on using Cactus with Maven in JUnit in Action by Messrs. Massol &
Husted. Let's hope they did a good job explaining it ;-)

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: When is the next release?

[Steve Raeburn]

You can reduce the range that is checked for changes using:
maven.changelog.range in project.properties
It's currently set to 180 days (~6 months)

Steve


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: December 2, 2003 8:57 AM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> Robert Leland wrote:
>  > Maven already creates a changelog for struts when a
> site:generate is
>  > performed.
>
> Yes, in the end, that's what I did. Had to munge it a bit to
> agree with
> our stylesheets, but no big. I checked in six month's worth,
> but didn't
> update the site since it makes for a  big page. I'm thinking we can
> archive one-month blocks and link backward from the current month.
>
> My own immediate plans are to segment the changelog into one-month
> blocks, update the release notes with the appropriate
> high-level bullets
> (based on a review of the changelog), and start patching the
> documentation as needed.
>
> I believe as soon as the next Validator ships, we could go ahead and
> roll 1.2.0. It may or may not be GA material, but we should
> get it out
> there where the community can decide.
>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

What happens now is that the tlds are defined in XML documents that are
run through an XSLT transform. This allow both the tld files and the
taglib documenation to be produced from the same source.

It confused the hell out of me when I first tried to edit the tld files,
but I think it's a very cool feature.

See
/docs/userGuide/struts-bean.xml
/docs/userGuide/struts-html.xml
etc.

/docs/stylesheets/tld.xsl is used to generate the actual tlds
/docs/stylesheets/struts.xsl generates the documentation

I don't think it should be hard to move this across to Maven (we could
always write an Ant task :-)), it just needs some effort to do it.

Steve


> -Original Message-
> From: Tim Chen [mailto:[EMAIL PROTECTED]
> Sent: December 1, 2003 9:56 AM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> lol Steve,
> I wonder that myself sometimes. But eventually you'll
> save alot of
> time and energy by extending the default task versus having
> to write the
> whole thing from scratch.
> Regarding generating the TLD files I'm not exactly sure
> what u mean
> by that. Do you mean like XDoclets generates TLDs?
> -Tim
>
> Steve Raeburn wrote:
>
> >Tim,
> >
> >Thanks for the patch. I took a look, and it will certainly
> help. There
> >are a few more things that need to be tackled before we're ready to
> >create the distribution with Maven.
> >
> >1. Generate the TLD files (& docs)
> >2. Run the Cactus tests
> >3. Build the web apps
> >4. Migrate the documentation
> >
> >Inspired by your patch, I realize that we might be able to do some of
> >that by calling Ant tasks. It does raise one question about
> Maven. If we
> >still have to write Ant tasks, is there enough benefit in
> switching to
> >Maven? We'll see how it shakes out :-)
> >
> >Steve
> >
> >
> >
> >>-Original Message-
> >>From: Tim Chen [mailto:[EMAIL PROTECTED]
> >>Sent: November 30, 2003 9:01 PM
> >>To: 'Struts Developers List'
> >>Subject: RE: Maven test run
> >>
> >>
> >>As a Struts user I would rather not wait for the mavenization
> >>to hold up
> >>the 1.2.0 release niether.
> >>As a Maven user though I can get the Struts release packages to look
> >>just like the awesome release target that Martin built for the ant
> >>process (Look at my maven.xml patch in bugzilla for an
> >>example on how to
> >>get maven's default dist target to do what we like). I'm kind
> >>of having
> >>a hard time finding time to do it right now but I'm sure it would be
> >>ready for the next Struts release (after the initial 1.2.0
> release :))
> >>Currently I can 'hack' the release to look identical to the current
> >>release but I didn't want to do that just so that we can
> use maven to
> >>build a release.
> >>I agree that the web apps and contrib needs to be separate
> >>projects but
> >>since I'm not a maven expert, I don't know what the 'best
> >>way' of doing
> >>things are. So if someone has an opinion about it.. please speak up.
> >>
> >>Thanks,
> >>Tim Chen
> >>[EMAIL PROTECTED]
> >>
> >>
> >>
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

Tim,

Thanks for the patch. I took a look, and it will certainly help. There
are a few more things that need to be tackled before we're ready to
create the distribution with Maven.

1. Generate the TLD files (& docs)
2. Run the Cactus tests
3. Build the web apps
4. Migrate the documentation

Inspired by your patch, I realize that we might be able to do some of
that by calling Ant tasks. It does raise one question about Maven. If we
still have to write Ant tasks, is there enough benefit in switching to
Maven? We'll see how it shakes out :-)

Steve

> -Original Message-
> From: Tim Chen [mailto:[EMAIL PROTECTED]
> Sent: November 30, 2003 9:01 PM
> To: 'Struts Developers List'
> Subject: RE: Maven test run
>
>
> As a Struts user I would rather not wait for the mavenization
> to hold up
> the 1.2.0 release niether.
> As a Maven user though I can get the Struts release packages to look
> just like the awesome release target that Martin built for the ant
> process (Look at my maven.xml patch in bugzilla for an
> example on how to
> get maven's default dist target to do what we like). I'm kind
> of having
> a hard time finding time to do it right now but I'm sure it would be
> ready for the next Struts release (after the initial 1.2.0 release :))
> Currently I can 'hack' the release to look identical to the current
> release but I didn't want to do that just so that we can use maven to
> build a release.
> I agree that the web apps and contrib needs to be separate
> projects but
> since I'm not a maven expert, I don't know what the 'best
> way' of doing
> things are. So if someone has an opinion about it.. please speak up.
>
> Thanks,
> Tim Chen
> [EMAIL PROTECTED]
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

At the minute, I've just copied the docs over to see how it would work
out. My opinion is "not bad, but more work required". As far as I'm
concerned, the Maven build is still experimental and not ready for
primetime.

It might be an option to build the website from Maven in the (very) near
future, but I think we'll need to do some restructuring before the
library build will work with Maven. (Separate out the taglibs, web apps,
contribs into separate sub-projects).

I don't think we should let the Mavenization process hold up the 1.2.0
release. There's a lot of changes waiting to get out and I think it best
not to combine those with a change in the build process. Hopefully, we
can integrate it into the build as we move forward through 1.2.x.

For maintenance purposes, the live documentation is still in docs. Don't
bother trying to maintain xdocs yet. I hope we'll be able to translate
the docs in place & maintain the history.

I'm not sure the end is in sight yet, but I'm now more confident now
that the end is achievable with Maven :-)

Steve


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: November 29, 2003 12:31 PM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> David Graham wrote:
> > You're going to delete the old versions in /doc right?  We
> certainly don't
> > want to maintain 2 versions of our docs.  It would be good
> not to lose the
> > cvs history on all of these in the moves to xdocs so maybe
> we can just
> > move the files in the filesystem on cvs.apache.org instead of just
> > checking in brand new versions in xdocs?
>
> If we're ready to convert the documentation to Maven, then we
> could just
> point the xdoc plugin at our doc directory by setting the
> maven.docs.src
> property.
>
> http://maven.apache.org/reference/plugins/xdoc/properties.html
>
> I'm OK with doing this, but it should be a deliberate
> decision, and we
> should probably have an actual vote.
>
> Of course, there is still some work to do, and I can help
> with that over
> the next week. But I think the end is in sight :)
>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

I've updated the Maven build to generate some documentation. Use 'maven
site' to generate it.

I copied the documentation over from docs to xdocs. There are some
differences between the tags expected by the Maven xdoc transofrmation
and our existing XSL transformation. It's causing some funky formatting
at the moment, but it will be fixable. I've noticed the following so
far:

  -  elements are not recognized. I've changed them to
 for now.
  - Block code examples need to be wrapped in a  tag. See
index.xml for an example.
  - Many (all?) of the anchors aren't operational

I've also been experimenting with customization of the site. Main
changes are in project.properties, but I've also added a custom JSL
stylesheet (struts.jsl) which would allow complete control over the
generated site. You might find the current look familiar ;-)

TODO:
  - Figure out the best way to migrate the xml docs
   (essentially change the source docs or change the JSL stylesheet)
  - Generate tlds and taglib documentation
  - Look into using the multi-project plugin to build webapps & contrib
  - Play with the Cactus plugin to get the other tests running

Anyone who wants to explore Maven, feel free to dive in :-)

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: November 28, 2003 3:10 PM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> Steve, would it be possible to merge what you started here with the
> current Maven build?
>
> -Ted.
>
> Steve Raeburn wrote:
> > In the spirit of rolling up sleeves, this is the result of
> a very quick look
> > at Maven:
> > http://www.apache.org/~sraeburn/maven/index.html
> >
> > I'll keep playing with this for now, because it's not fit
> to be checked in
> > yet and I've only built the core /src/share files. There's
> also more work to
> > do in configuring the various reports.
> >
> > Don't expect all the links to work, or any of the reports
> to be correct
> > (though already, some of them look useful).
> >
> > Steve
> >
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Ted Husted,
>Junit in Action  - <http://www.manning.com/massol/>,
>Struts in Action - <http://husted.com/struts/book.html>,
>JSP Site Design  -
> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

Sure, I'll have a go at it this evening. I'm not sure how far different
they are anyway.

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: November 28, 2003 3:10 PM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> Steve, would it be possible to merge what you started here with the
> current Maven build?
>
> -Ted.
>
> Steve Raeburn wrote:
> > In the spirit of rolling up sleeves, this is the result of
> a very quick look
> > at Maven:
> > http://www.apache.org/~sraeburn/maven/index.html
> >
> > I'll keep playing with this for now, because it's not fit
> to be checked in
> > yet and I've only built the core /src/share files. There's
> also more work to
> > do in configuring the various reports.
> >
> > Don't expect all the links to work, or any of the reports
> to be correct
> > (though already, some of them look useful).
> >
> > Steve
> >
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Ted Husted,
>Junit in Action  - <http://www.manning.com/massol/>,
>Struts in Action - <http://husted.com/struts/book.html>,
>JSP Site Design  -
> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

Me too!

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: November 28, 2003 12:56 AM
> To: Struts Developers List
> Subject: RE: Maven test run
> 
> 
> On Thu, 27 Nov 2003 [EMAIL PROTECTED] wrote:
> 
> > Good point, thanks for solving the mystery.  I've updated 
> the test to not
> > depend on the hashmap order.
> 
> Cool. Works for me. :-)
> 
> --
> Martin Cooper
> 
> 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

I've updated project.xml to reference the validator 1.1.1 jar. You need
to manually download it from http://www.apache.org/~rleland/ and place
it in your local repository.

.maven
  plugins
  repository
...
commons-validator  <-- you may need to create directories below here
  jars
 commons-validator-1.1.1-dev.jar


maven jar then works (at least for me :-))

There were no tests found because the test section was commented out!
(and the example include pattern doesn't match our naming convention).
I've enabled the JUnit tests. Using Cactus with Maven is beyond me, for
now :-)

When Maven runs the tests, TestModuleConfig is throwing a
NullPointerException that doesn't show up when running from Ant. I'm
inclined to believe that the Maven configuration requires more work
rather that it actually being a problem with ModuleConfig.

The Maven build remains HIGHLY experimental!!


Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: November 28, 2003 12:05 AM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> After copying my local Validator build to Maven's repo, I get
> the same as
> you do - no tests to run.
>
> Doing the Ant test.junit thing, I get the
> TestActionConfigMatcher failure,
> but it looks like Steve has tracked that one down.
>
> --
> Martin Cooper
>
>
> On Thu, 27 Nov 2003, James Mitchell wrote:
>
> > On Thu, 27 Nov 2003, Ted Husted wrote:
> >
> > > When I run the maven jar target, the upload tests fail
> > > (MultipartTestSuite).
> >
> > On a fresh copy ofwelleverything (maven 1.0-rc1,
> jakarta-struts,
> > etc, etc)  I cannot do anything with maven.
> >
> > The attempt to download validator SNAPSHOT fails.  When I change
> > project.xml to use 1.0.1 or 1.0.2, it downloads, but the
> compile fails
> > complaining about missing ValidatorUtils.
> >
> > I downloaded a nightly, moved it to
> > ~/.maven/repository/commons-validator/jars/.
> >
> > Then changed "SNAPSHOT" to "nightly" in project.xml.
> >
> > Then this:
> >
> > [EMAIL PROTECTED] jakarta-struts]$ maven jar
> >  __  __
> > |  \/  |__ _Apache__ ___
> > | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> > |_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc1-SNAPSHOT
> >
> > java:prepare-filesystem:
> >
> > java:compile:
> > [echo] Compiling to m-target/classes
> > [javac] Compiling 266 source files to
> > /home/jmitchell/cvs/jakarta-struts/m-target/classes
> >
> /home/jmitchell/cvs/jakarta-struts/src/share/org/apache/struts
> /tiles/actions/DefinitionDispatcherAction.java:78:
> > warning: org.apache.struts.tiles.DefinitionsUtil in
> > org.apache.struts.tiles has been deprecated
> > import org.apache.struts.tiles.DefinitionsUtil;
> >^
> >
> > 
> >
> >
> >
> /home/jmitchell/cvs/jakarta-struts/src/share/org/apache/struts
> /validator/ValidatorPlugIn.java:264:
> > warning:
> org.apache.commons.validator.ValidatorResourcesInitializer in
> > org.apache.commons.validator has been deprecated
> >
> ValidatorResourcesInitializer.initialize(resources,
> > bis, false);
> > ^
> > 41 warnings
> >
> > java:jar-resources:
> > Copying 15 files to
> /home/jmitchell/cvs/jakarta-struts/m-target/classes
> >
> > test:prepare-filesystem:
> > [mkdir] Created dir:
> > /home/jmitchell/cvs/jakarta-struts/m-target/test-classes
> > [mkdir] Created dir:
> > /home/jmitchell/cvs/jakarta-struts/m-target/test-reports
> >
> > test:test-resources:
> >
> > test:compile:
> > [echo] No test source files to compile.
> >
> > test:test:
> > [echo] No tests to run.
> >
> > jar:jar:
> > [jar] Building jar:
> > /home/jmitchell/cvs/jakarta-struts/m-target/struts-1.2.0.jar
> > BUILD SUCCESSFUL
> > Total time: 26 seconds
> > Finished at: Fri Nov 28 01:40:35 EST 2003
> >
> >
> >
> >
> >
> > "No tests to run"Am I missing something here?
> >
> >
> >
> >
> > >
> > > But, when I run the ant test.junit test, only the
> > > TestActionConfigMatcher test fails.
> > >
> > > Is it me, or do others share this experience?
> > >
> > > If so, any ideas as to why this would be?
> > >
> > > -Ted.
> > >
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Legacy APIs - Short Term Plan

[Steve Raeburn]

Not in struts-documentation.war :-) 

Steve

> -Original Message-
> From: Andrew Hill [mailto:[EMAIL PROTECTED]
> Sent: November 27, 2003 11:40 PM
> To: Struts-Dev
> Subject: RE: Legacy APIs - Short Term Plan
> 
> 
> eh?
> Arent they in some kind of wierd xml format?
> 
> 
> 
> 
> hmmm. No they arent, and the javadocs are there too. :-)
> Oops. Ignore my previous post. It seems Im talking nonsense. Sorry.
> 
> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Friday, 28 November 2003 14:56
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: RE: Legacy APIs - Short Term Plan
> 
> 
> On Fri, 28 Nov 2003, Andrew Hill wrote:
> 
> > While your at it how about actually including the javadocs in the
> > distribution (or the source dist).
> > A static html version of the other struts docs that doesnt 
> require you to
> > crank up a servlet container everytime you want to check 
> something would
> > also be very nice.
> 
> You don't need a container to unzip a file.
> 
> 
> >
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Friday, 28 November 2003 10:32
> > To: Struts Developers List
> > Subject: Re: Legacy APIs - Short Term Plan
> >
> >
> > David Graham wrote:
> >  > By "API" do you mean javadocs?  I've found it useful to 
> compare Sun's
> >  > JDK javadocs between versions and I imagine some people 
> would like to
> >  > compare Struts versions.
> >
> > People who wish to do this can maintain their own local 
> copies (and save
> > some of the bandwidth people kindly contribute to us). 
> Maintaining them
> > through our web site just confuses people.
> >
> > It made sense when there was a big gap between releases, 
> but, hopefully,
> > those days are past.
> >
> > -Ted.
> >
> >
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -- 
> James Mitchell
> Software Developer / Struts Evangelist
> http://www.struts-atlanta.org
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven test run

[Steve Raeburn]

I'm also getting a failure on TestActionConfigMatcher (using Ant build):

Name isn't correct
junit.framework.AssertionFailedError: Name isn't correct
at
org.apache.struts.config.TestActionConfigMatcher.testCheckSubstitutionsM
atch(TestActionConfigMatcher.java:202)
...

cfg.getName() is returning 'name2', but the test expects 'name'

fConfigs contains:
[0] = name2
[1] = name

The problem seems to be that the test relies on the order of the array
elements but ActionConfig stores the configs in a HashMap which does not
return its values collection in a guaranteed order. I would have
expected the failure to be intermittent, but it fails consistently for
me. Maybe in practice the order is consistent for a platform, JDK, day
of the week etc. etc. :-)

As an experiment, I changed the HashMap to a TreeMap, and the tests
pass. I don't know if this would have any knock on effects elsewhere
though. Might be better to rethink the test so it doesn't rely on the
ordering. Or even just drop that section since it's really only testing
findForwardConfigs(), not the matcher.


Steve



> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: November 27, 2003 9:36 PM
> To: Struts Developers List
> Subject: Re: Maven test run
>
>
> Hmmm...I just updated, uncommented those two lines, and ran "ant
> test.junit" - all tests passed.  Anyone else?
>
> Don
>
> On Thu, 27 Nov 2003, Ted Husted wrote:
>
> > When I run the maven jar target, the upload tests fail
> > (MultipartTestSuite).
> >
> > But, when I run the ant test.junit test, only the
> > TestActionConfigMatcher test fails.
> >
> > Is it me, or do others share this experience?
> >
> > If so, any ideas as to why this would be?
> >
> > -Ted.
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ApacheCon logo can be removed

[Steve Raeburn]

Ted,

As you're updating the web site, the ApacheCon logo can be removed now.
If you've already finished, I'll get it later on.

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Parsing Error in struts

[Steve Raeburn]

Most likely you haven't closed a JSP tag correctly. Try commenting out
sections of your JSP to narrow down where the error is.

But you should be asking on the struts-user list not here.

Steve

> -Original Message-
> From: Abhijeet Mahalkar [mailto:[EMAIL PROTECTED]
> Sent: November 13, 2003 9:21 PM
> To: Struts Developers List
> Subject: Parsing Error in struts
>
>
> I am getting following error is there anybody who can guide me for he
> same
>
> [11/14/03 10:38:12:954 GMT+05:30] 11d6d752 WebGroup  E SRVE0026E:
> [Servlet Error]-[End of content reached while more parsing
> required: tag
> nesting error?]: org.apache.jasper.compiler.ParseException:
> End of content
> reached while more parsing required: tag nesting error?
>  at org.apache.jasper.compiler.JspReader.popFile(JspReader.java:293)
>  at
> org.apache.jasper.compiler.JspReader.hasMoreInput(JspReader.ja
> va(Compiled
> Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Inlined Compiled
> Code))
>  at
> org.apache.jasper.compiler.Parser$Tag.accept(Parser.java(Compi
> led Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Inlined Compiled
> Code))
>  at
> org.apache.jasper.compiler.Parser$Tag.accept(Parser.java(Compi
> led Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Inlined Compiled
> Code))
>  at
> org.apache.jasper.compiler.Parser$Tag.accept(Parser.java(Compi
> led Code))
>  at
> org.apache.jasper.compiler.Parser.parse(Parser.java(Compiled Code))
>  at org.apache.jasper.compiler.Parser.parse(Parser.java:1110)
>  at org.apache.jasper.compiler.Parser.parse(Parser.java:1106)
>  at
> org.apache.jasper.compiler.ParserController.parse(ParserContro
> ller.java:309)
>  at org.apache.jasper.compiler.Compiler.compile(Compiler.java(Compiled
> Code))
>  at
> com.ibm.ws.webcontainer.jsp.servlet.JspServlet.loadJSP(JspServ
> let.java(Compi
> led Code))
>  at
> com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapp
> er.loadIfNeces
> sary(JspServlet.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapp
> er.service(Jsp
> Servlet.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile(
> JspServlet.jav
> a(Compiled Code))
>  at
> com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service(JspServ
> let.java(Compi
> led Code))
>  at
> javax.servlet.http.HttpServlet.service(HttpServlet.java(Compil
> ed Code))
>  at
> com.ibm.ws.webcontainer.servlet.StrictServletInstance.doServic
> e(StrictServle
> tInstance.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._servic
> e(StrictLifecy
> cleServlet.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.IdleServletState.service(Stric
> tLifecycleServ
> let.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service
> (StrictLifecyc
> leServlet.java(Inlined Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.ServletInstance.service(Servle
> tInstance.java
> (Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dis
> patch(ValidSer
> vletReferenceState.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispa
> tch(ServletIns
> tanceReference.java(Inlined Compiled Code))
>  at
> com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleW
> ebAppDispatch(
> WebAppRequestDispatcher.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatc
> h(WebAppReques
> tDispatcher.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward
> (WebAppRequest
> Dispatcher.java(Compiled Code))
>  at
> org.apache.struts.action.RequestProcessor.doForward(RequestPro
> cessor.java:10
> 69)
>  at
> org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesR
> equestProcesso
> r.java:274)
>  at
> org.apache.struts.action.RequestProcessor.processForwardConfig
> (RequestProces
> sor.java:455)
>  at
> org.apache.struts.tiles.TilesRequestProcessor.processForwardCo
> nfig(TilesRequ
> estProcessor.java:320)
>  at
> org.apache.struts.action.RequestProcessor.process(RequestProce
> ssor.java:279)
>  at
> org.apache.struts.action.ActionServlet.process(ActionServlet.j
> ava:1480)
>  at
> org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:506)
>  at
> javax.servlet.http.HttpServlet.service(HttpServlet.java(Compil
> ed Code))
>  at
> javax.servlet.http.HttpServlet.service(HttpServlet.java(Compil
> ed Code))
>  at
> com.ibm.ws.webcontainer.servlet.StrictServletInstance.doServic
> e(StrictServle
> tInstance.java(Compiled Code))
>  at
> com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._servic
> e(StrictLifecy
> cleServlet.java(Compiled Code))
>  at
> com.ibm.ws.webcont

RE: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Steve Raeburn]

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Jonathan Revusky
> Sent: November 13, 2003 2:24 PM
> To: [EMAIL PROTECTED]


> Or, really, to put it bluntly, I was not addressing you, Steve.

If you wanted a private conversation, you should have emailed Craig
directly.

PERSONALLY, I think that linking to Basebeans now creates more confusion
and doubt for Struts users than it does assistance. After all, Vic is
saying that Apache has acted unlawfully, which might give potential
users cause to not use Apache software, including Struts. I don't see
why we should promote that.

> I would have a greater tendency to carefully consider any points that
Vic raises in the future.

That's your prerogative. Perhaps if you'd seen some of Vic's ramblings,
as I have, you might think differently and be as tired of them as I am.
Please check the mail archives before getting too upset on Vic's behalf.

There are 21 Struts committers, none of whom has objected to the web
site update. That should speak volumes. Unless any of them have concerns
I suggest we return the list to the business of discussing Struts
development.

Steve




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Steve Raeburn]

Vic,

I'm sure you're a great developer. I know you've been a great advocate
for Struts. I haven't even said you are wrong. Just that you choose your
forums inappropriately and you put your arguments in a way that seems
rambling and paranoid. It's hard to even *understand* your postings, let
alone have any sympathy for them.

You've been spreading FUD which is at best distracting and at worst
harmful to the Struts/Apache communities. This has continued despite
*many* requests for you to stop (or at least address the correct forum).

I don't see why you would expect any support from the community you are
attacking.

Steve

BTW. Your book is still prominently listed on the Struts welcome page.
And it's Machiavellian.


> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
> Sent: November 13, 2003 2:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-struts/doc/resources archives.xml
> consultants.xml powered.xml sigs.xml
>
>
> There are many people that criticized Struts, saying
> Barracuda is better
> that Struts; or JSF is better than Struts, etc.  What a PITA.
>
> The issue I raised was not a Struts issue, but a Political issue on a
> different list. If you are Democrat, then Republicans are a
> PITA, it be
> easier if there were just no Republican sites (or the other
> way around,
> depending on you POV). So this has little to do with Struts!
>
> But ... if you want to discuss or judge the merits of “my”
> politics on
> this on this list, there is a tangent you can draw. There is a change
> that Apache SF is copying a design,
> ( http://theserverside.com/home/thread.jsp?thread_id=22337#101419 )
>   and according to the archive of “Elba.sf.net” the plans is
> to, quote:
> "Think of Elba (jBoss code) as a latticework for Geronimo--and as a
> shield to buffer the Geronimo codebase and CVS repository
> from any LGPL
> code. As Geronimo is built, its code will replace the code from Elba"
> (end quote)
> So my reading comprehension says: They will take jBoss design, and
> refractor it, and PMC went along with this, a mistake I
> think. What PITA!
> So what is the tangent to Apache Open Source projects,
> developers and users?
> This is: I spend 30% of my time “selling” Apache open source
> technology
> to business, that it is a safe platform to be on. If there is a
> precedent that Apache open source developers are capable or
> inclined to
> use a legal loophole, and that they could/would refractor a
> design of a
> client’s application, it would make it harder for ALL of us
> in the open
> source community to get gigs. What a PITA that would be!
>
> But don’t go with the selfish Makaveli-an above, if one sees
> a bunch of
> kids beating up a girl, it be a PITA to help her, so much easier to
> cross the street. Well… for better or worse, I did not cross
> the street!
>
> .V
>
> ps: ah… support open source?
>
>
> Steve Raeburn wrote:
> > The committers of the Struts project are entrusted by the Apache
> > Foundation to determine the content of the Struts portion of the
> > website.  None of us has objected to Craig's update,
> probably because
> > we've all grown tired of Vic being a PITA. (Incidentally
> he's always a
> > PITA about non-technical, POLITICAL issues.)
> >
> > It's done. Hopefully, Vic will get the message that nobody
> here wants to
> > listen to his ramblings and we can all move on with the
> development of
> > Struts and leave the conspiracy theories behind.
> >
> > Steve
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Scaffold FindForwardIndexed - FindForward for indexed properties

[Steve Raeburn]

No attachment came through. Your best best is to open a buzilla
enhancement request against the Nightly Build and attach your code
there.

http://nagoya.apache.org/bugzilla/

Steve


> -Original Message-
> From: Kevin Brown [mailto:[EMAIL PROTECTED]
> Sent: November 13, 2003 1:42 PM
> To: Struts Developers List
> Subject: Scaffold FindForwardIndexed - FindForward for indexed
> properties
>
>
> All,
>
> I wrote the attached FindForwardIndexed class (inspired by scaffold
> FindForward) which I find useful when I have a list of
> indexed properties
> and an action that can be take in each row.   The class
> forwards based on
> the indexed property submitted, and appends the index to the
> forward path
> (will append ${value} if path ends in "=" otherwise will append
> "index=${value}", where ${value} is the index.
>
> mappings look like so:
> 
>path="/workingScenarioModify.do"/>
>path="/deleteScenario.do?myindex="/>
>   
>   
>
> The test case attached is illustrative, but does not work
> properly because I
> have not gotten the
> mock objects to work properly.
>
> Enjoy.
>
> -Kevin
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

[Steve Raeburn]

The committers of the Struts project are entrusted by the Apache
Foundation to determine the content of the Struts portion of the
website.  None of us has objected to Craig's update, probably because
we've all grown tired of Vic being a PITA. (Incidentally he's always a
PITA about non-technical, POLITICAL issues.)

It's done. Hopefully, Vic will get the message that nobody here wants to
listen to his ramblings and we can all move on with the development of
Struts and leave the conspiracy theories behind.

Steve


> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Jonathan Revusky
> Sent: November 13, 2003 10:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-struts/doc/resources archives.xml
> consultants.xml powered.xml sigs.xml
>
>
> Craig R. McClanahan wrote:
> > Quoting Vic Cekvenich <[EMAIL PROTECTED]>:
> >
> >
> >>Was that called for Craig?
> >
> >
> > Yep.
> >
> >
> >>Maybe putting in the4 context of ... ASF was accused of stealing
> >>designs, and Vic decided to presure ASF?
> >>
> >>http://www.mail-archive.com/general%40jakarta.apache.org/msg
> 08432.html
> >>
> >
> >
> > Feel free to go make your case on someone else's website.
>
>
> As an external observer (I keep one eye on various forums in this
> application space) I cannot help but make certain comments.
>
> First of all, as regards your statement above in which you refer to
> "someone else's website", I parse this to mean that you consider the
> jakarta.apache.org/struts website to be _yours_. As a matter
> of fact, it
> is not. It belongs to the Apache Software Foundation, a non-profit
> entity set up with a certain charter and that has received
> support from
> various organizations.
>
> If the website in question were your personal website (which
> it is not)
> then there would be no issue whatsoever in terms of removing
> material on
> the basis of arbitrary, personal considerations. In terms of
> one's own
> personal website, one can be as petty and arbitrary as one wishes.
> However, if you are maintaining the Struts-related material on
> apache.org, on behalf of ASF, I think one should be subject
> to certain
> constraints related to professional ethics, and one's behavior should
> not be petty and arbitrary, subject to personal animosities and so on.
>
> Let me develop this a bit further. Presumably the BaseBeans site was
> linked in the first place because it was considered to be something
> potentially of interest to the Struts community. It stands to reason.
> What other reason would there be to link it?
>
> Correct me if I'm wrong.
>
> Now, as far as I can see, a legitimate reason to remove the
> link would
> be the determination that the BaseBeans site is no longer
> potentially of
> interest to the Struts community. However, BaseBeans, as far
> as I know,
> continues to offer the same products and/or services that it offered
> when originally linked. If the site was potentially of interest to
> Struts users when it was linked, it would seem that nothing
> has occurred
> to change that.
>
> Any 3rd party observer would draw the conclusion from this that Mr.
> Cekvenich made statements in a certain context that rubbed
> you the wrong
> way, so you are removing the link in retaliation. In other words, the
> decision was based on purely personal or political grounds,
> not on any
> objective basis.
>
> So the link was and continues to be of interest (at least
> potentially)
> to Struts users. (That's why it was initially linked and nothing has
> changed.) And now, you want users who visit this page not to see the
> link -- that is potentially of interest to them -- because of
> a personal
> or political conflict with Mr. Cekvenich.
>
> The link might be potentially beneficial to a Struts user who is
> interested in the services that Mr. Cekvenich's company
> offers. However,
> since that would also benefit Mr. Cekvenich, an individual
> towards whom
> you are not hiding animosity, you prefer for the link not to be there.
>
> I can only speak for myself but this gives me a very bad
> impression. It
> is suggestive of a lack of professionalism, a lack of ethics,
> and also
> even a lack of consciousness of these kinds of issues. By
> that, I mean
> that you even state in a CVS commit commment that will be publicly
> visible that this was the basis of your decision to remove the link.
>
> This is my honest reaction, I hope I am expressing myself clearly. If
> there is anything about the above that is unclear to you,
> feel free to
> request clarification.
>
> >
> >>>  Vic Cekvenich of BaseBeans.com has made it clear in
> public postings that
> >>>  he is ashamed of using Struts, and has engaged in an
> attack on the
> >>
> >>proper
> >>
> >>>  behavior of the Apache Software Foundation's Board of
> Directors.  In
> >>
> >>these
> >>
> >>>  circumstances, it would be hypocritical for BaseBeans to
> benefit from
> >>
> >>the
> >>
> >>>  free advertising value of being visible on the Struts
> web

RE: [Vote]Disable bugs for Struts 1.0

[Steve Raeburn]

+1 

Steve

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: November 3, 2003 7:28 PM
> To: [EMAIL PROTECTED]
> Subject: [Vote]Disable bugs for Struts 1.0
> 
> 
> I would like to propose disabling filing of NEW bugs for Struts 1.0,
> I know BugZilla 2.16.3 can do this not sure about 2.14.2
> 
> Bugs filed against 1.0 are a waste of time for committers and 
> for reporters.
> Only bugs filed against 1.1 final, or the nightly builds have 
> any hope 
> in being addressed.
> If there were patches included with the reciently reported 1.0 
> enhancements, I might feel
> differently. As it is NEW Struts 1.0 BugZilla reports are just Noise 
> that I filter out.
> 
> -Rob
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC

[Steve Raeburn]

Results of today's testing.

JUNIT - Fails on TestActionConfigMatcher. This is recent and unrelated to
the taglibs problem.
TC41 - Passes.
TC33 - JSP compile error on TestIncludeTag.jsp. But the tests all pass!!
What's up with that?

[java] 2003-10-23 15:42:44 - Ctx(/test) : compile error: req=R( /test +
/test/org/apache/struts/taglib/bean/TestIncludeTag.jsp + null) -
org.apache.jasper.compiler.ParseException:
C:\projects\jakarta-struts\target\test\servers\tomcat33\webapps\test\test\or
g\apache\struts\taglib\bean\TestIncludeTag.jsp(18,74) Attribute  has no
value

But I'm not seeing the test failures that you guys are.

I've posted the full results at http://www.ninsky.com/struts/build/

If I can look at anything else, let me know.

Steve

> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> Sent: October 22, 2003 11:32 PM
> To: Struts Developers List
> Subject: RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC
> 4.1, TestErrorsTag1 fails under TC 3.3
>
>
> I ran the tests today on 33 and 41 with a new checkout and everything
> worked. Strange. I'll do it it again tomorrow to double check that I'm not
> crazy.
>
> (I'm on 1.4.2_01, W2K, Cactus 13-1.4.1, TC3.3a, TC4.1.27)
>
> Steve
>
> > -Original Message-
> > From: James Mitchell [mailto:[EMAIL PROTECTED]
> > Sent: October 22, 2003 10:49 PM
> > To: 'Struts Developers List'
> > Subject: RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC
> > 4.1, TestErrorsTag1 fails under TC 3.3
> >
> >
> > This has been the source of many nights of frustration for me.
> >
> > The problem appears to be with Cactus.
> >
> > Here's what I'm doing:
> > Windows XP Pro
> > JDK 1.4.1_02
> > Cactus 13-1.4.1
> > and a brand spanking new cvs checkout
> >
> >
> > As I am typing this, I am remote debugging Jboss/Tomcat and with a
> > breakpoint set on the infamous TestIncludeTag, I execute this in a
> > browser:
> >
> > http://localhost:8080/test/JspRedirector?Cactus_TestMethod=testIncludeTa
> > gForward&Cactus_TestClass=org.apache.struts.taglib.bean.TestIncludeTag&C
> > actus_AutomaticSession=true&Cactus_Service=CALL_TEST&cacheId=1
> >
> > ...the remote debugger correctly stops at my breakpoint
> >
> > I create a new Expression as "request.getServerPort()" and I'll give you
> > 3 guesses as to what it evaluates to
> >
> > I don't have the source (nor the desire to attain it) for any version of
> > Cactus for further investigation, but it appears that the request
> > wrapper (org.apache.cactus.server.HttpServletRequestWrapper) is not
> > returning the correct value, which causes several tests to fail.
> >
> > Using any of the tags in a normal environment (non cactus) works
> > fine..go figure.
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Struts Evangelist
> > http://www.struts-atlanta.org
> > 678.910.8017
> > AIM:jmitchtx
> >
> >
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, October 22, 2003 11:14 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: DO NOT REPLY [Bug 21906] - IncludeTagTest fails
> > > under TC 4.1, TestErrorsTag1 fails under TC 3.3
> > >
> > >
> > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21906>.
> > > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > > INSERTED IN THE BUG DATABASE.
> > >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21906
> >
> > IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3
> >
> > [EMAIL PROTECTED] changed:
> >
> >What|Removed |Added
> > 
> > 
> >  Status|RESOLVED|REOPENED
> >  Resolution|FIXED   |
> >
> >
> >
> > --- Additional Comments From [EMAIL PROTECTED]  2003-10-23 03:13
> > ---
> > This still fails for me could someone else
> > verify that the test.tomcat.41 test passes.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3

[Steve Raeburn]

I ran the tests today on 33 and 41 with a new checkout and everything
worked. Strange. I'll do it it again tomorrow to double check that I'm not
crazy.

(I'm on 1.4.2_01, W2K, Cactus 13-1.4.1, TC3.3a, TC4.1.27)

Steve

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: October 22, 2003 10:49 PM
> To: 'Struts Developers List'
> Subject: RE: DO NOT REPLY [Bug 21906] - IncludeTagTest fails under TC
> 4.1, TestErrorsTag1 fails under TC 3.3
>
>
> This has been the source of many nights of frustration for me.
>
> The problem appears to be with Cactus.
>
> Here's what I'm doing:
> Windows XP Pro
> JDK 1.4.1_02
> Cactus 13-1.4.1
> and a brand spanking new cvs checkout
>
>
> As I am typing this, I am remote debugging Jboss/Tomcat and with a
> breakpoint set on the infamous TestIncludeTag, I execute this in a
> browser:
>
> http://localhost:8080/test/JspRedirector?Cactus_TestMethod=testIncludeTa
> gForward&Cactus_TestClass=org.apache.struts.taglib.bean.TestIncludeTag&C
> actus_AutomaticSession=true&Cactus_Service=CALL_TEST&cacheId=1
>
> ...the remote debugger correctly stops at my breakpoint
>
> I create a new Expression as "request.getServerPort()" and I'll give you
> 3 guesses as to what it evaluates to
>
> I don't have the source (nor the desire to attain it) for any version of
> Cactus for further investigation, but it appears that the request
> wrapper (org.apache.cactus.server.HttpServletRequestWrapper) is not
> returning the correct value, which causes several tests to fail.
>
> Using any of the tags in a normal environment (non cactus) works
> fine..go figure.
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017
> AIM:jmitchtx
>
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 22, 2003 11:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: DO NOT REPLY [Bug 21906] - IncludeTagTest fails
> > under TC 4.1, TestErrorsTag1 fails under TC 3.3
> >
> >
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > .
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21906
>
> IncludeTagTest fails under TC 4.1, TestErrorsTag1 fails under TC 3.3
>
> [EMAIL PROTECTED] changed:
>
>What|Removed |Added
> 
> 
>  Status|RESOLVED|REOPENED
>  Resolution|FIXED   |
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]  2003-10-23 03:13
> ---
> This still fails for me could someone else
> verify that the test.tomcat.41 test passes.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Upgrading from 1.1 to Nightly Build

[Steve Raeburn]

> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]
> Sent: October 20, 2003 10:35 AM
> To: [EMAIL PROTECTED]
> Subject: Upgrading from 1.1 to Nightly Build
>
>
> I upgraded from 1.1 to last night's build and discovered a whole bunch
> of steps needed to upgrade.
>
> http://tinyurl.com/rmai
>
> I ended up with 3 issues in the end.  They are as follows:
>
> 1. org.apache.struts.tiles.Controller requires you to implement both
> execute and perform - even though perform is deprecated.

That's because it's an interface and you *have* to implement the interface
methods. Can you not just extend ControllerSupport? It implements both
methods but the default behaviour for perform is just to call execute,
saving you the need to implement it yourself. (This is the same way that
Action was modified).

> 2. org.apache.lang.math.NumberUtils.stringToInt(String) has been
> deprecated according to the compiler.  Not according to its javadocs
> (http://tinyurl.com/rmci)

The JavaDoc on the website doesn't neccessarily reflect the latest source.
The CVS version has it deprecated:

 * @deprecated Use [EMAIL PROTECTED] #toInt(String)}
 *  This method will be removed in Commons Lang 3.0
 */
public static int stringToInt(String str) {
return toInt(str);
}

> 3.  ValidatorForm.getFieldMap() is deprecated, and there's no signs
> that a replacement exists.

Again, the online Javadoc may not reflect the latest source. From CVS
version:

/**
 * The Fields are returned as an unmodifiable
Map.
 * @deprecated Use containsField(String) and getField(String) instead.
 */
public Map getFieldMap() {
return Collections.unmodifiableMap(hFields);
}

HTH

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Using Eclipse to contribute to Struts

[Steve Raeburn]

James' version uses 'Check out As...' rather than 'Check out as Project'.
That's probably better as you can set up the classpath and get the code
completion feature etc. working more easily. My notes don't cover that at
all so use his first.

And he has pretty pictures  :-)

Steve

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: October 16, 2003 10:33 PM
> To: 'Struts Developers List'
> Subject: RE: Using Eclipse to contribute to Struts
>
>
>
> Here's a little something I put together also:
>
>  http://www.struts-atlanta.org/helping-develop-struts/index.html
>
>
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017
> AIM:jmitchtx



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Using Eclipse to contribute to Struts

[Steve Raeburn]

I wrote an answer, but it got a bit long for this list, so I posted it on my
web site for Hien and anyone else who's interested.

http://www.ninsky.com/struts/eclipse.html

Steve

> -Original Message-
> From: Hien Q Nguyen [mailto:[EMAIL PROTECTED]
> Sent: October 16, 2003 7:50 PM
> To: Struts Developers List
> Subject: Re: Using Eclipse to contribute to Struts
>
>
> Hi Indrajit,
>
> Thanks for replying.  The link that you mentioned is geared toward more
> of  Struts Users.  I'm actually interested in getting Struts source
> code from the CVS repository and set up a project in eclipse so that I
> can tinker with Struts source code and soon hopefully I'd be able to
> contribute.
>
> I guess what I want to know is if any Struts developer uses Eclipse as
> their IDE for the development of Struts.  If so, what is your set up
> like?
>
> Thanks,
> --Hien



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven test run

[Steve Raeburn]

In the spirit of rolling up sleeves, this is the result of a very quick look
at Maven:
http://www.apache.org/~sraeburn/maven/index.html

I'll keep playing with this for now, because it's not fit to be checked in
yet and I've only built the core /src/share files. There's also more work to
do in configuring the various reports.

Don't expect all the links to work, or any of the reports to be correct
(though already, some of them look useful).

Steve




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]

[Steve Raeburn]

Well Rob has already made a start on adding Maven. I did try building with
it, but hit a snag downloading the validator jar and I've not had a chance
to have another look since.

I wouldn't have a problem with releasing based on a Maven RC because it's
not a run-time dependency. Having said that I would consider our use of
Maven to be experimental for a while, until we get more familiar with it,
and run it in parallel with the current Ant build. I'm sure that before too
long it will become obvious whether the experiment has succeeded or not.

Steve



> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: October 2, 2003 10:18 AM
> To: Struts Developers List
> Subject: Re: [Vote] Choosing a build/doc gen tool(s) [was: Re: The
> Forrest Option]
>
>
> Steve Raeburn wrote:
>  > I'd like to add Maven now, learn from the experience on 1.x and then
>  > use that to optimize the project organization and build process for
>  > version 2.
>
> If the people voting +1 are ready to roll up their collective sleeves
> and give Maven a try, then that would be fine with me. The missing piece
> has been someone saying "I'm ready to do Maven *now*".
>
> My only concern is that Maven has not had a stable release. After ten
> betas, it has just published a RC1, but that's still shy of 1.0.
>
> During the 1.1 incubation period, we withheld making a final release
> until all our dependent JARs were also in a final release state. But,
> since Maven is a production environment, and not a JAR teams would need
> to include in their own releases, this consideration might not apply.
>
> So, if we would be able to ship a GA of Struts with a Maven Release
> Candidate, then I'm fine with whatever anyone wants to do.
>
> But, if anyone is going to vote against a Struts GA on the grounds that
> Maven is prerelease, then we should wait until Maven hits 1.0.
>
> I don't mind waiting on the Commons Validator, but I wouldn't want to
> wait on Maven.
>
> -Ted.
>
>
> Don Brown wrote:
>  > I'm assuming a move to Maven is inevitable?
>
> "You will be assimilated."
>
>
>
> James Mitchell wrote:
>  > Mavenization:
>  > [ ] +1 - I am in favor of using Maven for build/dist/test/etc.
>  > [X] +0 - I agree, but cannot help at this time.
>  > [ ] -0 - I don't agree, but not enough to give a -1.
>  > [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>  >
>  > Forrestization:
>  > [ ] +1 - I am in favor of using Forrest for site generation.
>  > [X] +0 - I agree, but cannot help at this time.
>  > [ ] -0 - I don't agree, but not enough to give a -1.
>  > [ ] -1 - I am not in favor of using Forrest for site generation.
>  >
>  > Other:
>  > [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest Option]

[Steve Raeburn]

Maven: +1
Forrest: -0
Forrest plug-in: Possibly, but not yet.

I'm more interested in streamlining the build and I don't consider the
website production to be  broken, so Forrest is not a big priority for me.
I'm not saying never, but I see Maven as more of a priority and would rather
wait and see on Forrest.

I'd like to add Maven now, learn from the experience on 1.x and then use
that to optimize the project organization and build process for version 2.

Steve

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: October 1, 2003 9:58 PM
> To: Struts Developers List
> Subject: [Vote] Choosing a build/doc gen tool(s) [was: Re: The Forrest
> Option]
>
>
> Most of us have given (or at least hinted at) our opinions, so
> let's give a
> show of hands:
>
> Mavenization:
> [X] +1 - I am in favor of using Maven for build/dist/test/etc.
> [ ] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Maven for build/dist/test/etc.
>
> Forrestization:
> [X] +1 - I am in favor of using Forrest for site generation.
> [ ] +0 - I agree, but cannot help at this time.
> [ ] -0 - I don't agree, but not enough to give a -1.
> [ ] -1 - I am not in favor of using Forrest for site generation.
>
> Other:
> [X] - I would like to pursue the Maven-with-Forrest-as-a-plugin idea.
>
>
> (If I left out any, please add them)
>
>
>
> One question I have about all this, (and please forgive me if I
> missed it in
> any of the messages in this thread) how does using either approach affect
> the generation of the .tld from our source?
>
>
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017
> 770.822.3359
> AIM:jmitchtx



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: September 29, 2003 12:08 PM
> To: Struts Developers List
> Subject: RE: XHTML Web site updates
>
> And now the downside to using tableless css webpages... Take a look at the
> taglibs api pages in mozilla.  The borders don't show up quite right
> (maybe a mozilla bug?).

I'm not sure what you mean about the borders. They look ok in Moz 1.5a on
Windows.
Here's what I'm seeing ... http://cvs.apache.org/~sraeburn/tables.gif

It is intentional that the table border is slightly thicker than the
internal cell borders. If you don't like it, that's another discussion :-)

> Also, the new ApacheCon image overwrites the content to the right of it in
Opera (the borders are correct though :-).

I've altered the layout so it should be able to accommodate the ApacheCon
logo down to smaller screen sizes.
Should also correct the IE float problem that Mike mentioned.

>
> We need to be more sensitive to webpage changes now that we're using html
> that browsers may not implement correctly or consistently.  These
> particular issues are no big deal though.
>
> David
>

More of a screen size issue than a browser compatibility issue. You guys
need to put in requisitions for bigger monitors and I need to make sure I
check at 800x600 :-)

Thanks for spotting the problem.

Steve





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: September 29, 2003 3:46 AM
> To: Struts Developers List
> Subject: Re: XHTML Web site updates
>
> +1 as to the new "sidebar" approach. I'm quite pleased with the way all
> this turned out.

I hope you'll also like the new table formatting for taglibs and task lists
:-)

> I should just do this myself, but if you had a moment, could you slip in
> a link to ApacheCon at the top of our sidebar, like the one at the
> Jakarta site. They've asked all the Apache projects to do this.
> Technically, we're not the project, Jakarta is, but since we kinda get
> our share of hits ...

Done.

I also took the opportunity to tidy up the web site files, removing the
obsolete versions that were still kicking around.
The web site should now match what's in CVS, with the addition of the 1.02
UserGuide and Javadocs.

In case I've been overzealous, I've archived the old site at
http://cvs.apache.org/~sraeburn/site-archive-20030929/

Regarding the archived 1.02 docs - there doesn't seem to be a link to them
anywhere. Shall I add one?

Also, we don't have the current release (1.1) docs on the site which might
be confusing for some users. Do we want to maintain docs for the current
version as well, and add appropriate links?


Steve

>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Standard HTML Tags (was Extending Standard Tags ...)

[Steve Raeburn]

Sorry, excuse the formatting on that last message. I hope this is more
readable.

-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED]
Sent: September 28, 2003 10:46 PM
To: Struts Developers List
Subject: RE: Standard HTML Tags (was Extending Standard Tags ...)


See below.

> -Original Message-
> From: Nathan Bubna [mailto:[EMAIL PROTECTED]
> Sent: September 28, 2003 8:30 PM
> To: Struts Developers List
> Subject: Re: Standard HTML Tags (was Extending Standard Tags ...)
>
>
> > Agreed. It's almost unthinkable, but you can even develop an app without
> > Struts :-) But I was focussing on JSP which is still the most common
view
> > technology. At the minute it's not practical to create a JSP Struts app
> > without the html taglib so, in my view, Struts as an application
framework
> > is dependent on that taglib.
>
> that's ridiculous.  i've been working on Struts apps for nearly a
> year and i have *never* once used the html taglib.  if you wanna
> say Struts is "dependent" on it, you've got the funkiest definition
> of "dependent" that i've heard in a long while.  following that
> logic i could say that the internet is dependent on Internet Explorer
> because it's the most common means of using it.

It's not ridiculous if you actually read what I wrote. I specifically and
carefully said, "a JSP Struts app". I know that there are other view
technologies but the fact is that JSP *is* the most prevalent and as such I
think it is a good and important thing that Struts supports it "out of the
box".

> > Yup, that's a possible (probable?) way forward. I'm not ignoring other
> > view technologies or JSF, just focussing on what is commonly in use now.
>
> focus is fine.  tunnelvision is not.

Indeed. I was attempting to explain that my comments are limited to Struts
in a JSP context, not that Struts should only support JSP or that other
technologies like JSF (or Velocity) should be ignored. I thought the phrase,
"I'm not ignoring other view technologies or JSF", explained that.
Obviously I was unclear.

> > For discussion, here's my view of how things might progress:
> >
> > - Short term: continue to separate the taglibs from the Struts core into
> > their own cvs/build/distribution.
>
> continue?  i didn't know the taglibs had even begun to be moved to a
separate
> cvs, build, or distribution.  and if i'm wrong on this one, i'd love to be
> corrected :).

You are wrong. David & Rob have been working on reducing the coupling of the
tag libraries to the Struts core, introducing TagUtils to take over some of
the work that RequestUtils was doing for the tag libaries. The purpose being
to reduce the inter-package dependencies allowing the taglibs to be
distributed in their own jar with their own release cycle.

> > - Medium term: drop support for the old taglibs and move the el
> > tags up to the core distribution (or their own distribution if that's
what
> > is decided). I understand that breaks support for JSP 1.1 and I'm
personally
> > OK with that but I do appreciate that may not be the general consensus.
> > ...
>
> i don't believe any taglibs or other view technology should be part of the
> core distribution.  the question of "where" these View libraries
> are developed is secondary.  i'm definitely with Ted on this one.
> develop it wherever there's a community interested in developing it,
> but please give the taglibs a separate release cycle.

If there's a community outside the Struts project itching to develop and
maintain a Struts JSP tag library, please let me know.

All I meant was that I would be happy to drop legacy support for the JSP 1.1
taglibs in favour of JSTL and the Struts-EL tags FOR JSP BASED APPLICATIONS.
At the moment the el tags are languishing in the contrib directory and I
think they should be the primary Struts taglib FOR JSP BASED APPLICATIONS.

See above regarding a seperate release cycle.

> over in VelocityTools, we've tried hard to dispel this notion that Struts
is a
> JSP technology.  i think we've had a little success with that, but you're
not
> really helping here.  while it's true that other view technologies can use
> Struts, as long as the Struts developers treat JSP as the "standard" view
and
> distribute the two together, i believe you are significantly limiting the
> potential of Struts as a framework/controller for applications (web and
> otherwise).

I believe over at Struts, people have also been doing the same. Right at the
top of the Struts home page it says, "For the View, Struts works well with
JavaServer Pages, including JSTL and JSF, as well a

RE: Standard HTML Tags (was Extending Standard Tags ...)

[Steve Raeburn]

See below.

> -Original Message-
> From: Nathan Bubna [mailto:[EMAIL PROTECTED]
> Sent: September 28, 2003 8:30 PM
> To: Struts Developers List
> Subject: Re: Standard HTML Tags (was Extending Standard Tags ...)
>
>
> > Agreed. It's almost unthinkable, but you can even develop an app without
> > Struts :-) But I was focussing on JSP which is still the most common
view
> > technology. At the minute it's not practical to create a JSP Struts app
> > without the html taglib so, in my view, Struts as an application
framework
> > is dependent on that taglib.
>
> that's ridiculous.  i've been working on Struts apps for nearly a
> year and i have *never* once used the html taglib.  if you wanna
> say Struts is "dependent" on it, you've got the funkiest definition
> of "dependent" that i've heard in a long while.  following that
> logic i could say that the internet is dependent on Internet Explorer
> because it's the most common means of using it.

It's not ridiculous if you actually read what I wrote. I specifically and
carefully said, "a JSP Struts app". I know that there are other view
technologies but the fact is that JSP *is* the most prevalent and as
such I think it is a good and important thing that Struts supports it
"out of the box".

> > Yup, that's a possible (probable?) way forward. I'm not ignoring other
> > view technologies or JSF, just focussing on what is commonly in use now.
>
> focus is fine.  tunnelvision is not.

Indeed. I was attempting to explain that my comments are limited to Struts
in
a JSP context, not that Struts should only support JSP or that other
technologies like JSF (or Velocity) should be ignored. I thought the phrase,
"I'm not ignoring other view technologies or JSF", explained that.
Obviously I was unclear.

> > For discussion, here's my view of how things might progress:
> >
> > - Short term: continue to separate the taglibs from the Struts core into
> > their own cvs/build/distribution.
>
> continue?  i didn't know the taglibs had even begun to be moved to a
separate
> cvs, build, or distribution.  and if i'm wrong on this one, i'd love to be
> corrected :).

You are wrong. David & Rob have been working on reducing the coupling of the
tag libraries to the Struts core, introducing TagUtils to take over some of
the work that RequestUtils was doing for the tag libaries. The purpose being
to reduce the inter-package dependencies allowing the taglibs to be
distributed in their own jar with their own release cycle.

> > - Medium term: drop support for the old taglibs and move the el
> > tags up to the core distribution (or their own distribution if that's
what
> > is decided). I understand that breaks support for JSP 1.1 and I'm
personally
> > OK with that but I do appreciate that may not be the general consensus.
> > ...
>
> i don't believe any taglibs or other view technology should be part of the
> core distribution.  the question of "where" these View libraries
> are developed is secondary.  i'm definitely with Ted on this one.
> develop it wherever there's a community interested in developing it,
> but please give the taglibs a separate release cycle.

If there's a community outside the Struts project itching to develop and
maintain
a Struts JSP tag library, please let me know.

All I meant was that I would be happy to drop legacy support for the JSP 1.1
taglibs in favour of JSTL and the Struts-EL tags FOR JSP BASED APPLICATIONS.
At the moment the el tags are languishing in the contrib directory and I
think they should be the primary Struts taglib FOR JSP BASED APPLICATIONS.

See above regarding a seperate release cycle.

> over in VelocityTools, we've tried hard to dispel this notion that Struts
is a
> JSP technology.  i think we've had a little success with that, but you're
not
> really helping here.  while it's true that other view technologies can use
> Struts, as long as the Struts developers treat JSP as the "standard" view
and
> distribute the two together, i believe you are significantly limiting the
> potential of Struts as a framework/controller for applications (web and
> otherwise).

I believe over at Struts, people have also been doing the same. Right at the
top
of the Struts home page it says, "For the View, Struts works well with
JavaServer
Pages, including JSTL and JSF, as well as Velocity Templates, XSLT, and
other
presentation systems." I also recall several occasions on the struts-user
mailing
list when Struts committers have corrected the misconception that Struts is
in
any way bound to JSP. In fact, I'm pretty sure I've said it myself.

I don't quite understand why I am not helping. I'm in favour of repackaging
the
taglibs and giving them a seperate release cycle. I want to reduce the
number
of Struts specific libraries in favour of the the general purpose and
standard
JSTL. And I think it's great that users have a choice of view technologies.

The only thing I disagree with you about is that I think the Struts taglib
is fine where it is and should

RE: Standard HTML Tags (was Extending Standard Tags ...)

[Steve Raeburn]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: September 28, 2003 1:51 PM
> To: Struts Developers List
> Subject: RE: Standard HTML Tags (was Extending Standard Tags ...)
>
> --- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> >
> > I'm still happy to be in the view business, but I do think that
> > decoupling
> > the controller from the view would be A Good Thing.
>
> The controller has no dependency on the view.  The taglibs are dependent
> on what the controller stores in the various scopes.  You could develop an
> app without using the html taglib at all (XML, Velocity, etc).

Agreed. It's almost unthinkable, but you can even develop an app without
Struts :-) But I was focussing on JSP which is still the most common view
technology. At the minute it's not practical to create a JSP Struts app
without the html taglib so, in my view, Struts as an application framework
is dependent on that taglib.

> FWIW, JSF has much richer view support than Struts does.  It supports
> features that Struts users have wanted like binding form data to native
> data types on beans that don't implement any particular interface or
> extend a certain class.

Yup, that's a possible (probable?) way forward. I'm not ignoring other view
technologies or JSF, just focussing on what is commonly in use now.

For discussion, here's my view of how things might progress:

- Short term: continue to separate the taglibs from the Struts core into
their own cvs/build/distribution.

- Medium term: drop support for the old taglibs and move the el tags up to
the core distribution (or their own distribution if that's what is decided).
I understand that breaks support for JSP 1.1 and I'm personally OK with that
but I do appreciate that may not be the general consensus.

- Medium to Long Term: JSF is probably going to be the way to go for the
view in JSP apps. A Jakarta/Struts Faces implementation would appear to fit
very well alongside the Struts controller framework.

Steve

>
> David
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Standard HTML Tags (was Extending Standard Tags ...)

[Steve Raeburn]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: September 28, 2003 3:18 PM
> To: Struts Developers List
> Subject: Re: Standard HTML Tags (was Extending Standard Tags ...)
>
> Steve Raeburn wrote:
> > I still feel that many of the html tags are *necessary* for use in
> > a Struts app.
> >
> Unless you are using some alternative tag library for rendering your
> markup, such as the struts-faces library when it is done, or any other
> HTML rendering tag library that someone wanted to adapt (as needed) to
> work on top of Struts.

...

> Of course, the whole discussion of migrating tag libraries elsewhere is
> totally academic unless there is someone who wants to *do* it instead of
> just talk about it.  In the absence of that, there's nothing wrong with
> leaving them exactly where they are.

Sure, I just wanted to suggest that moving them is not only unneccessary but
perhaps not a good way to go.

...

> > I'm still happy to be in the view business, but I do think that
> > decoupling the controller from the view would be A Good Thing.
> >
> Agreed ... personally, I'm working on a different solution (than the
> Struts html tag library) to that problem :-).

Looking forward to it, but I think we need to hang on to the taglibs just a
little while longer :-)

Steve





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Standard HTML Tags (was Extending Standard Tags ...)

[Steve Raeburn]

I think I'm coming at this from a different perspective than you :-)

The acid test for me is whether you could sensibly create a Struts app
without using the tags (just talking JSP here). While you can get by without
bean or logic tags, I still feel that many of the html tags are *necessary*
for use in a Struts app.

More below...

-Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
...
> Jakarta Taglibs maintains a Dreamweaver extension, why could they not
> maintain a Struts extension?

They could but, because JSP is the most common view technology, I think
Struts would be diminished without the html tag library.

> Likewise, Jakarta Velocity maintains a Struts extension. Should we ask
> Nathan Bubna et al. to bring that here because it is dependent on Struts?

But it's also dependent on Velocity :-) I think the need arose from users of
Velocity wanting to use Struts rather than the other way round. I think it
probably adds more value to Velocity than Struts and, you've pointed out,
that's were the developers are.

> The new Commons Chain package supports extensions for Servlets,
> Portlets, and JavaServer Faces, which are technologies not maintained by
> the Chain team.

That's not really the same. Struts would depend on Chain, much as it now
depends on other commons packages. Chain is useful in many other situations
that don't include Struts. That's not *currently* the case for the taglibs.

My view is that Struts taglib (html) depends on Struts *and* Struts depends
on the tags. It's that co-dependency that leads me to think they should stay
together.

> IMHO, it's not a question of technology. It's a question of community
> support. If the people who actively maintain these tags wanted to
> maintain them at Jakarta Taglibs, there's no technical reason to keep
> them here. Conversely, there's no technical reason to move them either.
> It's just a matter of where the people doing the work want to do the work.

And I think that the Struts project is where the maintainers of the Struts
taglib are / will be :-)
Changes to the tags will be as a result of changes to Struts and it requires
an understanding of the internals of Struts to effectively support the tags.
...

> There could a
> generic html library that didn't care about Struts, and then a
> specialized one that utilized the Struts defaults. This strategy works
> well for the Velocity Tools and should work just as well for taglibs.
>
> We keep saying that JSTL has no corollary to the html taglibs. Well,
> maybe then it needs one. :) We moved BeanUtils and friends to Commons,
> and I can't even count how many projects use these utilities now. Maybe
> we should do the same with the html tags. The problems we are trying to
> solve are the same problems everyone else is trying to solve. We shared
> the wealth with Commons, maybe its time to do the same with Taglibs.

That's a very definite possibility. If we can decouple the tags from Struts
so that they could be used independently *then* it would make sense to treat
them as a generic tag library. I would support moves in that direction, I
just don't think they're ready to stand on their own two feet *yet*.

> But, hey, I'm not a taglib guy, and I'm not going to be doing the work,
> so it's not my decision. =:) I just want to be sure that them that does
> the work and make the decisions are aware of their options.
>
> We scuttled Generic Datasource to get out of the Model business, and,
> volunteers willing, maybe it's time to get out of the View business too.
>
> -Ted.

I'm still happy to be in the view business, but I do think that decoupling
the controller from the view would be A Good Thing.

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Running and Writing Struts Tests

[Steve Raeburn]

I think there is currently an unresolved problem that's causing the tests to
fail.
See
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
e.org&msgNo=21406

Steve

> -Original Message-
> From: Chris Gastin [mailto:[EMAIL PROTECTED]
> Sent: September 27, 2003 11:02 PM
> To: Struts Developers List
> Subject: Running and Writing Struts Tests
>
>
> I apologize this is a little off topic, and If I can not get
> answer here. I will direct it to the Cactus list. I am trying to
> set up my local environment to run the current set of Struts
> tests. I want to ensure that I am writing valid tests for the
> patches I submit. All tests with exception of the tests in the
> org.apache.struts.taglib.* packages are giving a valid PASS or
> FAIL. All tests in the org.apache.struts.taglib.* packages give
> me the following error
>
> org.apache.cactus.util.ChainedRuntimeException: Failed to get the
> test results at [http://localhost:8080/test/JspRedirector]
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.dispatch
> 49_doTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAsp
> ect.aj[1k]:131)
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.around49
> _doTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspec
> t.aj[1k]:1222)
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.doTest(D
efaultHttpClient.java;org/apache/cactus/util/log/> LogAspect.aj[1k]:115)
>  at
> org.apache.cactus.internal.client.WebClientTestCaseDelegate.runWeb
> Test(WebClientTestCaseDelegate.java;org/apache/cactus/util/log/Log
> Aspect.aj[1k]:333)
>  at
> org.apache.cactus.internal.client.WebClientTestCaseDelegate.runGen
> ericTest(WebClientTestCaseDelegate.java;org/apache/cactus/util/log
> /LogAspect.aj[1k]:281)
>  at
> org.apache.cactus.internal.client.WebClientTestCaseDelegate.runTes
> t(WebClientTestCaseDelegate.java;org/apache/cactus/util/log/LogAsp
> ect.aj[1k]:257)
>  at
> org.apache.cactus.ServletTestCase.runCactusTest(ServletTestCase.java:287)
>  at org.apache.cactus.ServletTestCase.runBare(ServletTestCase.java:250)
>  at junit.framework.TestResult$1.protect(TestResult.java:106)
>  at junit.framework.TestResult.runProtected(TestResult.java:124)
>  at junit.framework.TestResult.run(TestResult.java:109)
>  at junit.framework.TestCase.run(TestCase.java:118)
>  at junit.framework.TestSuite.runTest(TestSuite.java:208)
>  at junit.framework.TestSuite.run(TestSuite.java:203)
>  at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Re
> moteTestRunner.java:392)
>  at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteT
> estRunner.java:276)
>  at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(Remote
> TestRunner.java:167)
>
> org.apache.cactus.client.ParsingException: Not a valid response
> [500 Internal Server Error]
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.callGetR
> esult(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspect.
> aj[1k]:251)
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.dispatch
> 49_doTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAsp
> ect.aj[1k]:126)
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.around49
> _doTest(DefaultHttpClient.java;org/apache/cactus/util/log/LogAspec
> t.aj[1k]:1222)
>  at
> org.apache.cactus.client.connector.http.DefaultHttpClient.doTest(D
efaultHttpClient.java;org/apache/cactus/util/log/> LogAspect.aj[1k]:115)
>  at
> org.apache.cactus.internal.client.WebClientTestCaseDelegate.runWeb
> Test(WebClientTestCaseDelegate.java;org/apache/cactus/util/log/Log
> Aspect.aj[1k]:333)
>  at
> org.apache.cactus.internal.client.WebClientTestCaseDelegate.runGen
> ericTest(WebClientTestCaseDelegate.java;org/apache/cactus/util/log
> /LogAspect.aj[1k]:281)
>  at
> org.apache.cactus.internal.client.WebClientTestCaseDelegate.runTes
> t(WebClientTestCaseDelegate.java;org/apache/cactus/util/log/LogAsp
> ect.aj[1k]:257)
>  at
> org.apache.cactus.ServletTestCase.runCactusTest(ServletTestCase.java:287)
>  at org.apache.cactus.ServletTestCase.runBare(ServletTestCase.java:250)
>  at junit.framework.TestResult$1.protect(TestResult.java:106)
>  at junit.framework.TestResult.runProtected(TestResult.java:124)
>  at junit.framework.TestResult.run(TestResult.java:109)
>  at junit.framework.TestCase.run(TestCase.java:118)
>  at junit.framework.TestSuite.runTest(TestSuite.java:208)
>  at junit.framework.TestSuite.run(TestSuite.java:203)
>  at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Re
> moteTestRunner.java:392)
>  at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteT
> estRunner.java:276)
>  at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(Remote
> TestRunner.java:167)
>
> As you can see an Internal Server Error is getting thrown. Has
> anyone else experience this problem when running the Test in the
> taglib package.
>
> My local environment is Eclipse 2.1.1, CactusPlugin for Eclipse
>

RE: [Results] Struts to depend on Validator 1.1.0

[Steve Raeburn]

Sorry Rob, I meant to respond but got distracted after reading your message.
FWIW, a belated +1 :-)

BTW, why isn't Validator 1.1.0 available in the normal download location?

Steve

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: September 27, 2003 7:59 PM
> To: Struts Developers List
> Subject: [Results] Struts to depend on Validator 1.1.0
>
>
> 4   +1's
> 0   -0,-1
>
> Craig,  If you could upgrade the nightly build to use
> Struts 1.1.0 it's located under
>
>http://jakarta.apache.org/~rleland/ValidatorAlpha/
>
> This version is backward compatible, so it could be used
> for tonight's build.
>
> We will start upgrading the struts source Sunday night.
>
> -Rob
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Extending Standard Tags was Editable Fields V/S Static Text

[Steve Raeburn]

Sorry, I don't understand your point, Vic.

I wasn't saying that the existing tags can't or shouldn't be extended. Just
that IMO the core Struts tags shouldn't be moved to somewhere like Jakarta
Taglibs, because they are dependent on Struts.

On the other hand, those tags that are general purpose and don't rely on
Struts can almost all be replaced with JSTL. Again, I don't think there is
any point moving them anywhere else, because they will probably just be
discontinued at some time in the future.

I think it's great that Matt and others have extended the Struts tags. (In
fact, Matt's calendar tag looks useful for something I'm working on now.) It
shows that it can be done and that not everything needs to be included in
the Struts distribution.

+1 for Variations :-)

Steve

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
> Sent: September 27, 2003 9:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Extending Standard Tags was Editable Fields V/S Static Text
>
>
>
>
> Steve Raeburn wrote:
> > Many of the tags (basically those that have been implemented in
> struts-el)
> > are closely bound to Struts so I don't see that they belong
> anywhere else.
> > (Separate jar, yes. Separate cvs dir, probably). The remaining
> tags have a
> > limited shelf life, having been supesrseded by JSTL.
> >
>
> If I can disagre !with above; ex:
> http://www.mattkruse.com/javascript/javascripttoolbox.zip
>
> This exentds the HTML tag with .js emit.
> Variations are a frequent need.
> .V
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Off topic

[Steve Raeburn]

http://info.astrian.net/jargon/terms/i/IMHO.html

Steve

> -Original Message-
> From: Chris Gastin [mailto:[EMAIL PROTECTED]
> Sent: September 27, 2003 1:49 PM
> To: Struts Developers List
> Subject: Off topic
> 
> 
> I keep seeing IMHO in many posts. What does "IMHO" mean?
> 
> Chris Gastin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Extending Standard Tags was Editable Fields V/S Static Text

[Steve Raeburn]

Many of the tags (basically those that have been implemented in struts-el)
are closely bound to Struts so I don't see that they belong anywhere else.
(Separate jar, yes. Separate cvs dir, probably). The remaining tags have a
limited shelf life, having been superseded by JSTL.

I'd also like to see a separate cvs & distribution of optional packages.

While I'd probably be in favour of Struts becoming a top level project, I
must confess I don't quite understand the criteria for becoming one. Having
Jakarta, XML, DB makes sense to me, but I don't get why Ant and Maven
warrant top level projects (build tools?) or Cocoon (surely that fits in
Jakarta?). If anyone has a clue, please let me know!

Having said that, if it's a question of visibility, Struts certainly
deserves to be recognized as a top level project and it would give us an
opportunity to reorganize the code base and get more people and related
projects on board.

Steve

p.s. Jakarta Faces (or would it be Struts Faces?) would be an interesting
subproject for a top level Struts. Then we'd be covering the V and the C.



> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: September 27, 2003 10:20 AM
> To: Struts Developers List
> Subject: Re: Extending Standard Tags was Editable Fields V/S Static Text
>
>
> Vic Cekvenich wrote:
> > (also IMO Struts HTML and tiles tag could/should migrate to taglibs)
>
> Yes, it would be nice if the taglibs were maintained by Jakarta Taglibs,
> in the same way that the Struts View Tools are maintained by Velocity.
> Struts should make it as easy as possible for presentation technologies
> to hook up to the controller, so that the experts in that technology can
> provide the appropriate adapters for their platform.
>
> But Apache projects are not dumping grounds. To make it happen, a set of
> individuals deeply active in both Jakarta Taglibs and Jakarta Struts
> would have to step up and make the proposal to both communities.
>
> (Personally, I'd also like to see someone with an itch start the ball
> rolling on a Jakarta Faces product. The Sun distribution is apparently
> going to be closed source, and the SourceForge MyFaces project is using
> a restrictive license. Then the Struts-Faces taglib would also have a
> home among experts in that technology.)
>
> Alternatively, we should talk about setting up a series of "optional"
> Struts packages. So, rather than have things like Struts-Faces and
> Struts-el live in the nebulous contrib folder, they could live under
> org.apache.struts.opt.faces and *.opt.el. Likewise, there could be an
> *.opt.taglib. And at some point an opt.xls and maybe an opt.wml.
>
> If we followed the "optional" strategy, I'd also suggest we apply for
> status as a top-level Apache project, so that each of the opt packages
> could be a proper subproject, with its own CVS, set of Committers, and
> so forth.
>
> Though, personally, I'd prefer the idea of letting other Jakarta
> products do what they do best, so that Struts can focus on what it does
> best: provide the C in MVC.
>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: struts-chain, wildcards, web services

[Steve Raeburn]

> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: September 25, 2003 6:16 PM
> To: [EMAIL PROTECTED]
> Subject: struts-chain, wildcards, web services
>
...
>
> Regarding wildcards
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=21813),
> I decided to
> hold of on putting them as it seemed a 1.1.1(2?) was around
> the corner.
> However, as it looks like it is not, I'd like to put it in
> this weekend.
> Again, the patch will not affect any Struts apps that don't
> use wildcards
> in any way, performance or otherwise.  It does open up some
> interesting
> possibilities not only for reduced configuration, but
> things like this:
> http://www.mail-archive.com/[EMAIL PROTECTED]/m
> sg79295.html
>

Seems to me like a good time to get it in, then it'll be available in
1.2

> Finally, regarding web services, anyone know of any efforts
> to expose
> Struts forms/actions as web services?

Shouldn't you be exposing your business objects as web services, not
Struts actions or forms? Struts deals with controlling the user
interface (currently Servlet specific) so any business tier / web
services tier code would be outside of the Struts domain.

Steve

>
> Don
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What happened to the taglib attribute listings?

[Steve Raeburn]

Thanks, I found it in the end but Ted beat me to updating the site :-)

Steve

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: September 11, 2003 5:05 PM
> To: Struts Developers List
> Subject: Re: What happened to the taglib attribute listings?
>
>
> Ted Husted wrote:
>
> > Right now, we use scp to either send up the files or a
> WAR to burst.
> > This requires karma to jakarta.apache.org, which root no
> longer hands
> > out as a matter of course, but should be available for the asking.
>
>
> Every thing was moved to ONE machine minatar (sp ?), cvs,
> web site etc...
> It's no longer necessary to have access to multiple machines.
> Just  scp to cvs.apache.org.
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

I've added back the contributors list, moving it to the left column, under
the menu.
For and example, see:
http://www.ninsky.com/struts/site/userGuide/preface.html

Enabling the list is controlled by an 'authors' attribute at both project
level, via the project.xml file, and for each document.

  http://jakarta.apache.org/struts/userGuide";
  image="../images/struts.gif"
authors="true">

-and/or -

  

If a document level attribute is specified, it will override the project
level attribute.
If neither is specfied , no list will be output.
If an attribute is specified, anything other than "true" will be interpreted
as false.

I think I've set it up to output on most of the pages the before. Please
feel free to amend as you see fit.

Steve


> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: September 10, 2003 6:52 AM
> To: Struts Developers List
> Subject: Re: XHTML Web site updates
>
>
> David Graham wrote:
>
> >>Contributors List
> >>
> >I think it's important to keep the contributors list on those pages
> >because it's a recognition of volunteers' effort.  I agree that
> it gets in
> >the way so maybe the list should be at the bottom of the page in
> a smaller
> >
> >
> +1, absolutely it's through those patches and code contributions that
> keeps Struts going sometimes.
>
> >font.  It would also be nice if it wasn't one long list of names but had
> >columns to make it shorter.  That is probably easier said than done
> >though.
> >
> >David
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What happened to the taglib attribute listings?

[Steve Raeburn]

I've posted a patch to the struts.xsml stylesheet. Ted could you do the
honours?

BTW, I'm not sure what needs to be done to update the live site and if it's
something I could or should be doing. I'd be happy to make the updates if
someone lets me know how.

Steve


> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> Sent: September 11, 2003 12:03 PM
> To: Struts Developers List
> Subject: RE: What happened to the taglib attribute listings?
>
>
> I'll take a look at this now. I'm sure it's nothing major.
>
> Steve
>
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: September 11, 2003 11:48 AM
> > To: Struts Developers List
> > Subject: Re: What happened to the taglib attribute listings?
> >
> >
> > If it's not something we can fix right away, I'll post a copy from an
> > earlier build.
> >
> > David Graham wrote:
> >
> > > That's a definite bug in the build.  Those pages are worthless
> > without the
> > > attribute descriptions.
> > >
> > > David
> > >
> > > --- Kris Schneider <[EMAIL PROTECTED]> wrote:
> > >
> > >>The tag doco pages,I'll tak a look at this for example:
> > >>
> > >>http://jakarta.apache.org/struts/userGuide/struts-html.html
> > >>
> > >>used to include tables listing each of the tags' attributes.
> Was there a
> > >>conscious decision made to remove that information or is
> there just some
> > >>bug in
> > >>the build?
> > >>
> > >>--
> > >>Kris Schneider <mailto:[EMAIL PROTECTED]>
> > >>D.O.Tech   <http://www.dotech.com/>
> > >>
> > >>-
> > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >
> > >
> > >
> > > __
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > > http://sitebuilder.yahoo.com
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > --
> > Ted Husted,
> >Junit in Action  - <http://www.manning.com/massol/>,
> >Struts in Action - <http://husted.com/struts/book.html>,
> >JSP Site Design  -
<http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What happened to the taglib attribute listings?

[Steve Raeburn]

I'll take a look at this now. I'm sure it's nothing major.

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: September 11, 2003 11:48 AM
> To: Struts Developers List
> Subject: Re: What happened to the taglib attribute listings?
>
>
> If it's not something we can fix right away, I'll post a copy from an
> earlier build.
>
> David Graham wrote:
>
> > That's a definite bug in the build.  Those pages are worthless
> without the
> > attribute descriptions.
> >
> > David
> >
> > --- Kris Schneider <[EMAIL PROTECTED]> wrote:
> >
> >>The tag doco pages,I'll tak a look at this for example:
> >>
> >>http://jakarta.apache.org/struts/userGuide/struts-html.html
> >>
> >>used to include tables listing each of the tags' attributes. Was there a
> >>conscious decision made to remove that information or is there just some
> >>bug in
> >>the build?
> >>
> >>--
> >>Kris Schneider 
> >>D.O.Tech   
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >
> > __
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > http://sitebuilder.yahoo.com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Ted Husted,
>Junit in Action  - ,
>Struts in Action - ,
>JSP Site Design  - .
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

Thanks Ted and everyone else for checking. Glad it all worked out. 

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: September 11, 2003 2:54 AM
> To: Struts Developers List
> Subject: Re: XHTML Web site updates
> 
> 
> With an update to Ant 1.5.4, it now WORKSFORME with both 1.4.1_03 and 
> 1.4.2_01. The validation step takes a few seconds, but I'm OK with that.
> 
> I'm posting the new version now. Thanks Steve! It looks great!
> 
> -Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util PropertyMessageResources.java

[Steve Raeburn]

I noticed you used log.trace() instead of log.debug(). Would it be better to
stick with debug for consistency?

Steve

> -Original Message-
...
> dgraham 2003/09/10 21:27:21
>
>   Modified:src/share/org/apache/struts/util
> PropertyMessageResources.java
>   Log:
...
>super(factory, config);
>   -log.info("Initializing, config='" + config + "'");
>   +log.trace("Initializing, config='" + config + "'");
>

etc.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

Thanks, Craig. I hope that last patch will cure it for everyone regardless
of the JDK.

Steve

>
> WORKSFORME on a just-downloaded CVS tree (19:40 Pacific Time), using JDK
> 1.4.2-b28 on Red Hat 9.0 Linux.  The generated pages do indeed look very
> much like the original style.
>
> Craig
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

Thanks James, I'm about to commit an updated build-webbaps.xml file. It
seems to solve my problem on 1.4.1_02.

According to the Ant manual:
reloadstylesheet - Controls whether the stylesheet transformer is created
anew for every transform operation. If you set this to true, performance may
suffer, but you may work around a bug in certain Xalan-J versions. Default
is false. Since Ant 1.5.2.

http://ant.apache.org/manual/CoreTasks/style.html


Setting this to true, appears to work and it's not much slower. Give it a
whirl.

Steve


> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: September 10, 2003 6:03 PM
> To: 'Struts Developers List'
> Subject: RE: XHTML Web site updates
>
>
> Here's my attempt:
>
>
> Buildfile: build.xml
>
> init:
>  [echo] - jakarta-struts 1.2-dev -
>
>  [echo] java.class.path =
> C:\j2sdk1.4.1_02\lib\tools.jar;D:\home\jmitchell\apache_home\apache-ant-
> 1.5.3-1\lib\xml-apis.jar;D:\home\jmitchell\apache_home\apache-ant-1.5.3-
> 1\lib\xercesImpl.jar;D:\home\jmitchell\apache_home\apache-ant-1.5.3-1\li
> b\optional.jar;D:\home\jmitchell\apache_home\apache-ant-1.5.3-1\lib\juni
> t.jar;D:\home\jmitchell\apache_home\apache-ant-1.5.3-1\lib\ant.jar;
>  [echo] java.home = C:\j2sdk1.4.1_02\jre
>  [echo] user.home = C:\Documents and Settings\jmitchell
>
> prepare.dist:
>
> prepare.library:
>  [copy] Copying 1 file to
> D:\home\jmitchell\cvs\jakarta-struts\target\library\classes\META-INF
>
> compile.library:
> [javac] Compiling 35 source files to
> D:\home\jmitchell\cvs\jakarta-struts\target\library\classes
>
> ...
> ...
> 
> ...
> ...
>
>
> static:
>  [echo] Processing webapp validator
>
> compile:
>  [echo] Processing webapp validator
> [javac] Compiling 3 source files to
> D:\home\jmitchell\cvs\jakarta-struts\target\validator\WEB-INF\classes
>  [copy] Copying 3 files to
> D:\home\jmitchell\cvs\jakarta-struts\target\validator\WEB-INF\classes
>
> compile.docs:
> [style] Transforming into
> D:\home\jmitchell\cvs\jakarta-struts\target\documentation
> [style] Processing
> D:\home\jmitchell\cvs\jakarta-struts\doc\acquiring.xml to
> D:\home\jmitchell\cvs\jakarta-struts\target\documentation\acquiring.html
> [style] Loading stylesheet
> D:\home\jmitchell\cvs\jakarta-struts\doc\stylesheets\struts.xsl
> [style] Processing
> D:\home\jmitchell\cvs\jakarta-struts\doc\helping.xml to
> D:\home\jmitchell\cvs\jakarta-struts\target\documentation\helping.html
> [style] Processing
> D:\home\jmitchell\cvs\jakarta-struts\doc\index.xml to
> D:\home\jmitchell\cvs\jakarta-struts\target\documentation\index.html
> [style] Processing
> D:\home\jmitchell\cvs\jakarta-struts\doc\kickstart.xml to
> D:\home\jmitchell\cvs\jakarta-struts\target\documentation\kickstart.html
> [style] Processing
> D:\home\jmitchell\cvs\jakarta-struts\doc\learning.xml to
> D:\home\jmitchell\cvs\jakarta-struts\target\documentation\learning.html
> [style] : Fatal Error! java.lang.NullPointerException Cause:
> java.lang.NullPointerException
> [style] Failed to process
> D:\home\jmitchell\cvs\jakarta-struts\doc\learning.xml
>
> BUILD FAILED
> file:D:/home/jmitchell/cvs/jakarta-struts/build-webapps.xml:222: Fatal
> error during transformation
>
> Total time: 35 seconds
>
> Tool completed successfully
>
>
>
>
>
> I'll post back after I run it again in debug...see if I can track
> this thing down.
>
>
>
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017
> AIM:jmitchtx
>
>
>
>
> > -Original Message-
> > From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, September 10, 2003 8:39 PM
> > To: Struts Developers List
> > Subject: RE: XHTML Web site updates
> >
> >
> > The look and feel you end up with should be almost identical
> > to the existing
> > site.
> > I've uploaded a copy for comparison at
> > http://www.ninsky.com/struts/site/
> >
> > If the build is failing then the CSS file won't be copied
> > over to the target
> > directory so that's why you don't see the formatting.
> >
> > As to why it's failing - I'm pretty sure this is a JDK bug, though I'm
> > surprised you're still having problems on 1.4.2_01. What's
> > the policy on
> > accommodating JDK bugs? I'll try to find a workaround.
> >
> > It would be useful if someone else could run it to see if a
> > pattern emerges.
> >
> > Steve
> >
> &g

RE: XHTML Web site updates

[Steve Raeburn]

The look and feel you end up with should be almost identical to the existing
site.
I've uploaded a copy for comparison at http://www.ninsky.com/struts/site/

If the build is failing then the CSS file won't be copied over to the target
directory so that's why you don't see the formatting.

As to why it's failing - I'm pretty sure this is a JDK bug, though I'm
surprised you're still having problems on 1.4.2_01. What's the policy on
accommodating JDK bugs? I'll try to find a workaround.

It would be useful if someone else could run it to see if a pattern emerges.

Steve


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: September 10, 2003 3:42 PM
> To: Struts Developers List
> Subject: Re: XHTML Web site updates
>
>
> I've installed Sun 1.4.2_01 but I'm still having trouble getting the
> site to render.
>
> I am in favor of rendering the site in valid XHTML, but we need it to
> work with what people will commonly have installed. If the site can't be
> rendered using the standard "Java 1.2 or later" advice, then I'll have
> to ask that the stylesheet changes be withdrawn.
>
> Also, I don't know if my pages are rendering correctly, but the ones I
> am seeing have a "Lynx" look and feel. I don't mind this personally, but
> I do feel that we need to either retain the original layout or migrate
> to Forrest or Maven. Something different is not what we are gong for
> right now. =:0)
>
> -Ted.
>
> Steve Raeburn wrote:
> > Sorry, I'm getting my versions in a muddle. Here's the correct state:
> >
> > Sun 1.4.2_01 - No problem
> > Sun 1.4.1_05 - Intermittent failures
> > Sun 1.4.1_02 - Intermittent failures
> > Sun 1.3.1- No problem
> >
> > 2 many twos and ones :-)
> >
> > Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

Sorry, I'm getting my versions in a muddle. Here's the correct state:

Sun 1.4.2_01 - No problem
Sun 1.4.1_05 - Intermittent failures
Sun 1.4.1_02 - Intermittent failures
Sun 1.3.1- No problem

2 many twos and ones :-)

Steve

> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> Sent: December 10, 2003 8:12 AM
> To: Struts Developers List
> Subject: RE: XHTML Web site updates
>
>
> What JDK are you running on? I did experience a similar
> intermittent problem
> with Sun 1.4.2_01 (on W2K) but _02 runs with no problems.
>
> Steve
>
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: September 10, 2003 3:58 AM
> To: Struts Developers List
> Subject: Re: XHTML Web site updates
>
>
> I'm fine with all this generally, and was going to post the update, but
> I'm having trouble getting it to transform. Several arbitrary files are
> coming back
>
> : Fatal Error! java.lang.NullPointerException Cause:
> java.lang.NullPointerException
> Failed to process
> C:\projects\Apache\jakarta\jakarta-struts\doc\resources\projects.xml
>
> I'll try it again tonight with a clean checkout, but wanted to bring
> this up in case anyone experienced similar problems.
>
> -Ted.
>
> Steve Raeburn wrote:
> > We now have an XHTML 1.0 Strict compliant, CSS based tableless
> layout web
> > site with only one XSL stylesheet to worry about (plus the
> taglib) and no
> > need for a separate "printer friendly" version of the User Guide.
> >
> > I've added a validation task to the build file to ensure that the
> generated
> > documents stay valid over time ;-) and to save having to validate each
> page
> > manually.
> >
> > Anchors
> > ---
> > One thing to watch out for when you're updating documents - I've begun
> > replacing anchors with element ids. So this:
> >
> >   Some text
> >
> > becomes
> >   Some text
> >
> > It's still linked in exactly the same way -- myPage.html#test -- but you
> > need to make sure that you use a valid element id. Anchors in the news
> pages
> > were being specified using the date, but element names cannot
> start with a
> > digit so I've just added the letter 'S' (for Struts) as a prefix.
> >
> >
> > Contributors List
> > -
> > One side effect of merging the XSL stylesheets is that the contributors
> list
> > is currently not written at the start of each chapter. (Some stylesheets
> had
> > it, some didn't so I opted to remove it from the chapter section.)
> >
> > I wondered what the feeling was regarding whether it is
> neccessary to have
> > that list at the top of each page.
> >
> > Personally, I think it gets in the way of reading the
> documentation but it
> > wouldn't be too difficult to add back if that's what's wanted.
> >
> >
> > Let me know what you think or if you find anything I missed.
> >
> > Steve
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Ted Husted,
>Junit in Action  - <http://www.manning.com/massol/>,
>Struts in Action - <http://husted.com/struts/book.html>,
>JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Saving messages in the session

[Steve Raeburn]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
...
>
> This seems more responsive than a periodic cleanup and we wouldn't have to
> cache HttpSession objects which may not be safe/legal.  Also, I think
> placing the cleanup in the RequestProcessor guarantees that it is
> performed rather than relying on Actions to do the cleanup.

+1

> Comments?

you read my mind :-)

Steve





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XHTML Web site updates

[Steve Raeburn]

What JDK are you running on? I did experience a similar intermittent problem
with Sun 1.4.2_01 (on W2K) but _02 runs with no problems.

Steve

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: September 10, 2003 3:58 AM
To: Struts Developers List
Subject: Re: XHTML Web site updates


I'm fine with all this generally, and was going to post the update, but
I'm having trouble getting it to transform. Several arbitrary files are
coming back

: Fatal Error! java.lang.NullPointerException Cause:
java.lang.NullPointerException
Failed to process
C:\projects\Apache\jakarta\jakarta-struts\doc\resources\projects.xml

I'll try it again tonight with a clean checkout, but wanted to bring
this up in case anyone experienced similar problems.

-Ted.

Steve Raeburn wrote:
> We now have an XHTML 1.0 Strict compliant, CSS based tableless layout web
> site with only one XSL stylesheet to worry about (plus the taglib) and no
> need for a separate "printer friendly" version of the User Guide.
>
> I've added a validation task to the build file to ensure that the
generated
> documents stay valid over time ;-) and to save having to validate each
page
> manually.
>
> Anchors
> ---
> One thing to watch out for when you're updating documents - I've begun
> replacing anchors with element ids. So this:
>
>   Some text
>
> becomes
>   Some text
>
> It's still linked in exactly the same way -- myPage.html#test -- but you
> need to make sure that you use a valid element id. Anchors in the news
pages
> were being specified using the date, but element names cannot start with a
> digit so I've just added the letter 'S' (for Struts) as a prefix.
>
>
> Contributors List
> -
> One side effect of merging the XSL stylesheets is that the contributors
list
> is currently not written at the start of each chapter. (Some stylesheets
had
> it, some didn't so I opted to remove it from the chapter section.)
>
> I wondered what the feeling was regarding whether it is neccessary to have
> that list at the top of each page.
>
> Personally, I think it gets in the way of reading the documentation but it
> wouldn't be too difficult to add back if that's what's wanted.
>
>
> Let me know what you think or if you find anything I missed.
>
> Steve
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Ted Husted,
   Junit in Action  - <http://www.manning.com/massol/>,
   Struts in Action - <http://husted.com/struts/book.html>,
   JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

XHTML Web site updates

[Steve Raeburn]

We now have an XHTML 1.0 Strict compliant, CSS based tableless layout web
site with only one XSL stylesheet to worry about (plus the taglib) and no
need for a separate "printer friendly" version of the User Guide.

I've added a validation task to the build file to ensure that the generated
documents stay valid over time ;-) and to save having to validate each page
manually.

Anchors
---
One thing to watch out for when you're updating documents - I've begun
replacing anchors with element ids. So this:

  Some text

becomes
  Some text

It's still linked in exactly the same way -- myPage.html#test -- but you
need to make sure that you use a valid element id. Anchors in the news pages
were being specified using the date, but element names cannot start with a
digit so I've just added the letter 'S' (for Struts) as a prefix.


Contributors List
-
One side effect of merging the XSL stylesheets is that the contributors list
is currently not written at the start of each chapter. (Some stylesheets had
it, some didn't so I opted to remove it from the chapter section.)

I wondered what the feeling was regarding whether it is neccessary to have
that list at the top of each page.

Personally, I think it gets in the way of reading the documentation but it
wouldn't be too difficult to add back if that's what's wanted.


Let me know what you think or if you find anything I missed.

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts web site [was: Re: Conversion of web site docs to XHTML]

[Steve Raeburn]

+1 for only having to use one tool
+1 for being able to customize L&F

I guess that makes me +1 for Maven, but that's qualified by the fact that I
haven't used either so I don't know what bumps we'll hit down the road.

As long as we can produce valid XHTML and customize the L&F I'll be happy.

Steve

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: September 6, 2003 11:13 AM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: Struts web site [was: Re: Conversion of web site docs to
> XHTML]
>
>
> On Sat, 6 Sep 2003, David Graham wrote:
>
> > Date: Sat, 6 Sep 2003 10:55:26 -0700 (PDT)
> > From: David Graham <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED]
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Struts web site [was: Re: Conversion of web site docs to
> > XHTML]
> >
> >
> > --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > > Robert Leland wrote:
> > >  > Do we want to hold a formal vote/lazy consensus on what doc
> > >  > system we are moving to ?
> > >
> > > Don already put the Struts SourceForge site on Forrest, so I
> would lean
> > > in that direction.
> >
> > Does Forrest require that look and feel?  If so, I'm -1 only because it
> > doesn't match the new Jakarta look and feel.  I think Struts
> should fit in
> > with other Jakarta sites.  Also, it seems like most other
> Jakarta projects
> > are using Maven so maybe we should too.
> >
>
> Strictly from the selfish point of view of a developer wanting to minimize
> how many tools I have to use, I'd prefer Maven over Forrest simply because
> it's also a build system.  Or, to put it anothe way, using Maven as a
> build system will give us a website/docs publishing system for free.
>
> Visually, I'm not a huge fan of either system's default L&F, but I don't
> dislike either of them enough to vote -1 on that basis.  My understanding
> is that there is some room for customization with either, though, if we
> wanted to expend the effort to manage our own L&F.
>
> The argument for consistency with other Jakarta subprojects
> is good in theory, but I don't see most Jakarta subproject websites using
> either yet -- at least for their pages on jakarta.apache.org.  It would
> also not be an issue if we ever wanted to become a top-level Apache
> project (like Maven and Ant did), versus staying under Jakarta.
>
> > David
>
> Craig
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts web site [was: Re: Conversion of web site docs to XHTML]

[Steve Raeburn]

Yes, I'd like to get involved in that but I haven't used Maven before so I
need to find time to get to grips with it. I'm aware that this is only an
interim measure but figured it was worth getting done now.

Steve


> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: September 5, 2003 10:43 PM
> To: Struts Developers List
> Subject: Struts web site [was: Re: Conversion of web site docs to XHTML]
>
>
> Steve Raeburn wrote:
>
> >I have committed the first step in transitioning the web site
> documentation
> >to valid XHTML.
> >
> >
> As far as I know we were planning to move over to Maven or forrest.
> I have been working on Mavenizing items as I can.
> Instead of doing the stylesheets maybe your efforts
> could be directed towards integrating those xml docs into
> maven ?
>
> Do we want to hold a formal vote/lazy consensus on what doc
> system we are moving to ?
>
> -Rob
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Conversion of web site docs to XHTML

[Steve Raeburn]

FYI, even looking back at HTML 4.0,  could only contain inline elements.
http://www.w3.org/TR/1998/REC-html40-19980424/struct/text.html#edef-P

That's what I love about this job - you never stop finding out you've been
doing it all wrong :-)

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Conversion of web site docs to XHTML

[Steve Raeburn]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: September 5, 2003 4:29 PM
> To: Struts Developers List
> Subject: Re: Conversion of web site docs to XHTML
>
> Are you sure about this?  Are you saying that
> blah
> is invalid?
>
> David


I'm afraid so.  can only contain inline elements, even in the
transitional dtd. Lists are block level. If you need to contain a list,
you'll have to use a div.

See:
http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-transitional.dtd_p

...


...

Steve





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Conversion of web site docs to XHTML

[Steve Raeburn]

I have committed the first step in transitioning the web site documentation
to valid XHTML.

All documents should now validate as XHTML 1.0 Transitional. If any have
slipped through the net, please feel free to let me know.

Next steps:
 - Replace inline formatting (font tags - Ugh!) with CSS.
 - Remove the printer friendly version and handle print layout with CSS.
 - Tackle the web apps.
 - Merge XSL style sheets into one.

There are a few things you should watch out for when updating the source XML
docs to ensure that the HTML pages continue to validate. They all basically
fall under the category of "make sure you use valid XHTML", but
specifically:

 - All images must have "alt" tags
 - valign is not valid for images
 - ensure that nested lists are valid: the nested   etc.
   tag must be contained in a  tag. (These are a p.i.t.a to unravel.)
 - lists not allowed inside paragraphs
 -  formatted text is not allowed inside paragraphs.

If you'd like to validate the HTML documents after making changes, you can
do so at http://validator.w3.org/ Opera 7 makes it easier to validate by
linking directly to the validator via a hotkey combination ctrl-alt-v


Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws NullPointerException during first execute after tomcat start

[Steve Raeburn]

You could add that suggestion to the bug report if you like.

Steve

> -Original Message-
> From: Rick Hightower [mailto:[EMAIL PROTECTED]
> Sent: September 2, 2003 11:21 AM
> To: 'Struts Developers List'
> Subject: RE: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws
> NullPointerException during first execute after tomcat start
>
>
> Gee... this sounds like they forgot to set the load-on-startup element for
> the Action Servlet.
>
>
> Rick Hightower
> Chief Technology Officer
> Trivera Technologies
> http://www.triveratech.com
> 520 290 6855 (Phone)
> 520 977 8605 (Mobile)
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 02, 2003 3:12 AM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 22878] New: - LookupDispatchAction throws
> NullPointerException during first execute after tomcat start
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22878
>
> LookupDispatchAction throws NullPointerException during first
> execute after
> tomcat start
>
>Summary: LookupDispatchAction throws
> NullPointerException during
> first execute after tomcat start
>Product: Struts
>Version: 1.1 Final
>   Platform: All
> OS/Version: Other
> Status: NEW
>   Severity: Normal
>   Priority: Other
>  Component: Standard Actions
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
>
>
> After every start of tomcat the LookupDispatchAction class throws a
> NullPointerException, but it does only do so the first time any
> LookupDispatchAction is executed. Any call to execute() for any
> LookupDispatchAction after that first call does not throw a
> NullPointerException,
>
> Note that this only occurs when _not_ having a message-resources
> defined in
> struts-config.xml. This also gives the following workaround:
> put  in the
> struts-config.xml
> and
> an 'empty' BugWorkaround.properties in WEB-INF/classes.
>
> NullPointerException is thrown at
> org.apache.struts.actions.LookupDispatchAction.execute(LookupDispa
> tchAction.
> java:236)
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

[Steve Raeburn]

You are right, JSTL doesn't completely remove the need for Struts specific
tags.

I think for the purposes of this discussion, the "next generation" would be
JSTL plus the struts-el taglib and when we talk about the Struts tags, we're
really talking about the traditional, non-el tags.

So keep using the  and other Struts tag and consider migrating to
the EL versions if you are using JSTL.

Steve


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: September 1, 2003 1:17 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
> - Enhancement of the html:link tag)
>
>
> Perhaps this belongs on the user list, but I think it is relevant for
> the discussion at hand. You all seem to regard all of the Struts taglibs
> as one item, for which JSTL is an alternative. While this is certainly
> true for the logic: and bean: tags, I have not seen a replacement for
> the
> html: form tags (that is,  and all the controls) in JSTL.
>
> The user guide
> (http://jakarta.apache.org/struts/userGuide/building_view.html#form_bean
> s)
> suggests we replace
>
> value="<%= loginBean.getUsername() >"/>
>
> with
>
> 
>
> Does the "use JSTL" camp prefer this,
>
> value="">
>
> or am I missing some basic JSTL?
>
> Shai.
>
>
> PS: There is a documentation error there; the original JSP should be
>
> value="<%= loginBean.getUsername() %>"/>
> --^
>
> Shai.
>
>
> ---
> Confidentiality Notice: This email transmission may contain
> confidential or legally privileged information that is intended
> only for the individual or entity named in the e-mail address. If
> you are not the intended recipient, you are hereby notified that
> any disclosure, copying, distribution, or reliance upon the
> contents of this e-mail is strictly prohibited. If you have
> received this e-mail transmission in error, please reply to the
> sender, so that arrangements can be made for proper delivery, and
> then please delete the message from your inbox.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [OT] List problem - Long delays before some posts hit the mailing lists

[Steve Raeburn]

I could understand it if all list traffic was suffering delays, but it just
seems to single out the occasional message while others get through in
seconds.
Oh well, one of the mysteries of the Internet. Just don't be too surprised
if the odd message seems to be bizarrely out of touch with thread. More than
usual anyway :-)

Steve

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: August 31, 2003 6:10 PM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: [OT] List problem - Long delays before some posts hit the
> mailing lists
>
>
> On Sun, 31 Aug 2003, Steve Raeburn wrote:
>
> > Date: Sun, 31 Aug 2003 16:07:25 -0700
> > From: Steve Raeburn <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED]
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: [OT] List problem - Long delays before some posts hit the
> > mailing lists
> >
> > Is anyone else experiencing strange delays with some messages?
> >
> > This message took neary two days to hit the list, but most
> others are pretty
> > immediate. I've had the same thing happen several times on the
> user list.
> > They seem to get there in the end, but must take a tour of the Internet
> > before arriving.
> >
>
> Thank SoBig.F for that.  The messages from this virus (and the
> stupid/useless responses from virus checkers that don't seem to understand
> that the "From" address is forged) have significantly impacted the
> responsiveness of mail servers all over the Internet, because they are
> busy handling all the useless traffic.  Fortunately, it's supposed to
> expire on 9/10/03 ...
>
>
> > Steve
>
> Craig
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Short terms plans

[Steve Raeburn]

As I opened my big mouth on this topic, I'll also keep a special eye out for
any new bugs or patches that come in.

Tiles & Nested tags seem to be popular areas for issues to occur though, and
I'm not particularly familiar with those.

Steve


> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: August 31, 2003 3:02 PM
> To: Struts Developers List
> Subject: Re: Short terms plans
>
>
> On Sun, 31 Aug 2003, Ted Husted wrote:
>
> > Date: Sun, 31 Aug 2003 15:31:22 -0400
> > From: Ted Husted <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Short terms plans
> >
> > Craig R. McClanahan wrote:
> > > Sorry for the late response on this ... it seems like weekends are the
> > > only time I get to play with open source code any more :-(.
> >
> > I hear that, brother! =:0) The catch-as-catch-can thing isn't working
> > for me anymore either, so I think I'll take my own advice
> >
> > http://jakarta.apache.org/struts/faqs/helping.html#corp
> >
> > and block out a regular time for open source development and call it
> > part of the work week. I really want to Bugzilla sorted-out and fill in
> > some of the remaining gaps in the documentation.
> >
> > Since we have a wiki now, I thought it might be helpful to setup a short
> > term plans page. I took the liberty (surprise!) of adding some notes
> > people have made on the list or in Bugzilla recently.
> >
> >
> http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=Struts
> ShortTermPlans
> >
>
> I just added "final cleanups to commons-resources" to my list.
>
> > Also, I setup a Job Jar page on the Wiki
> >
> > http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar
> >
> > I'd like to add this item as well:
> >
> > * A maintainer for the conventional Struts taglibs package is
> > needed. If you are motivated, self-starting developer who is
> > actively using these tags, groks the Apache Way, and can spare the time,
> > please take a look at the outstanding reports for the taglibs
> > components, and start submitting patches for our consideration.
> >
>
> +1.  Lots of people rely on these tags, and will for a long time.
>
> > But thought I should see if we have consensus on this first.
> >
> > At one time, we were not pursuing the conventional tags because we did
> > not want to steer people away from JSTL. But now that we have an
> > actively-supported JSTL tag library, it may be time to fish around for
> > someone to actively maintain this package on behalf of the segment of
> > our Community who need, or choose, to use these tags.
> >
> > Usually, I would suggest we let nature take its course and see if a
> > taglib developer appears spontaneously. But, I think we may have given
> > the community the impression that we are antagonistic towards these
> > tags, and it may be prudent to take affirmative action to correct that
> > impression.
> >
> > -Ted.
> >
>
> Craig
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] List problem - Long delays before some posts hit the mailing lists

[Steve Raeburn]

Is anyone else experiencing strange delays with some messages?

This message took neary two days to hit the list, but most others are pretty
immediate. I've had the same thing happen several times on the user list.
They seem to get there in the end, but must take a tour of the Internet
before arriving.

Steve

> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> Sent: August 29, 2003 8:27 PM
> To: Struts Developers List
> Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
> - Enhancement of the html:link tag)
>
>
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: August 29, 2003 6:08 PM
> >
> > Each of us can only offer support from our own experience. If a person
> > is not using the html taglib, then they might not know the html taglib
> > solution. But if they are using JSTL, they might know a JSTL solution.
>
> Agreed, but I don't think we're *that* rusty on the Struts tags
> yet that we
> wouldn't be able to offer useful advice  :-).
>
> > There's no limit on the number of responses we can post to a question.
> > If someone else knows the html taglib solution, then they can post that
> > solution too.
>
> Yes, I had a very ... ummm ... interesting off-list discussion recently
> where I was trying to explain that to someone. I guess it's as much about
> perception as anything. I don't want to give the impression that
> the Struts
> tags are somehow unsupported or that JSTL is the *only* way to work. Also,
> in many people's eyes Struts 1.1 was only just released so any perceived
> change in the level support might be viewed negatively.
>
> I'm very happy for JSTL to be the recommendation, provided the
> commitment to
> the Struts tags until the end of their lifetime is clear and I
> feel sure it
> will be.
>
> ...
>
> > -Ted.
> >
> > (Hey, maybe I should start answering the html taglib questions with the
> > Velocity Tools solution!)
>
> That would certainly help dispel the "Struts only works with
> JSPs" myth. But
> I believe the standard answer to questions is, "No!  is crap. You want
> to use Perl" :-)
>
>
> Steve
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

[Steve Raeburn]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 29, 2003 6:08 PM
>
> Each of us can only offer support from our own experience. If a person
> is not using the html taglib, then they might not know the html taglib
> solution. But if they are using JSTL, they might know a JSTL solution.

Agreed, but I don't think we're *that* rusty on the Struts tags yet that we
wouldn't be able to offer useful advice  :-).

> There's no limit on the number of responses we can post to a question.
> If someone else knows the html taglib solution, then they can post that
> solution too.

Yes, I had a very ... ummm ... interesting off-list discussion recently
where I was trying to explain that to someone. I guess it's as much about
perception as anything. I don't want to give the impression that the Struts
tags are somehow unsupported or that JSTL is the *only* way to work. Also,
in many people's eyes Struts 1.1 was only just released so any perceived
change in the level support might be viewed negatively.

I'm very happy for JSTL to be the recommendation, provided the commitment to
the Struts tags until the end of their lifetime is clear and I feel sure it
will be.

...

> -Ted.
>
> (Hey, maybe I should start answering the html taglib questions with the
> Velocity Tools solution!)

That would certainly help dispel the "Struts only works with JSPs" myth. But
I believe the standard answer to questions is, "No!  is crap. You want
to use Perl" :-)


Steve




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

[Steve Raeburn]

> Many Jakarta products have subproducts with their own CVS. Perhaps there
> should be a Struts taglib CVS where all three packages could live.
>
> -Ted.
>

+1

What about also doing this for the contrib components? Some of these are
really only concepts or proposals rather than production quality code.
struts-sandbox?

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

[Steve Raeburn]

My original point really was that if the standard for Struts continues to be
2.2/1.1 that we should be careful not to reply to the "How do I do this with
" questions with the stock answer of "use JSTL".

If we're supporting Struts tags then I believe we should first answer the
question that was asked and *then* offer the advice that JSTL offers an
alternative *if* their environment supports it.

I feel it's become a bit too easy to give the JSTL answer and not deal with
the issue as presented. And I do feel that if there are gaps in the
functionality provided by the current supported environment we should at
least consider additions, particularly if someone has gone to the trouble of
providing a patch.

If someone doesn't want to deal with Struts taglib issues than that's fine,
but if there's no one left who's prepared to provide support then at that
point (and I'm not suggesting that we're anywhere near yet) I would urge
that we reconsider the required platform.

Please read this as a gentle reminder/prompt for discussion, rather than a
stern lecture. It's not my intention to cause any offence and it's something
I need to be aware of as much as anyone.

O
   _   /|\
soapbox-> |x|  / \  <- me, no longer on it :-)

Steve


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 29, 2003 1:44 PM
> To: Struts Developers List
> Subject: Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
> - Enhancement of the html:link tag)
>
>
> Craig R. McClanahan wrote:
> > I'm -1 on making Struts 1.2.x dependent on Servlet 2.3 / JSP 1.2.
>
> Ditto. Contrary to popular brief, a great number of organizations have
> *not* migrated to 2.3/1.2, including some of the largest companies in
> the world.
>
> -Ted.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)

[Steve Raeburn]

I'm not singling Vic out for this (honest) but...

The standard advice we are now giving everyone is "use JSTL", which I
wholeheartedly agree with and have said myself. However, I think we need to
make sure that we still adequately support non-JSTL solutions and continue
to consider bug fixes/enhancements to Struts tags EVEN where it would
duplicate JSTL functionality because Struts still supports JSP
1.1/Servlet2.2.

I haven't considered whether this particular enhancement would fall into the
category of something we should do, it just prompted me to raise the issue.

If we've reached the stage where the recommendations we are making *require*
JSTL, then I think it's time to be honest about the required platform for
Struts and up it to 1.1/2.3

Thoughts?

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: August 27, 2003 8:28 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21465
>
> Enhancement of the html:link tag
>
> [EMAIL PROTECTED] changed:
>
>What|Removed |Added
> --
> --
>  Status|ASSIGNED|RESOLVED
>  Resolution||WONTFIX
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]
> 2003-08-28 03:27 ---
> You can/should use JSTL instead.
> .V
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JSTL EL Validator rule: A better requiredif and validatewhen using JSTL

[Steve Raeburn]

Rick,

It certainly sounds interesting but I'd like to have a working example to
play with.

It would be nice if you could:
a. Create a small working example as a war and post in on a website for us
to take a look at.
b. Create an enhancement request in Bugzilla and add your proposed patches
there.

a. will make it easier to quickly review your suggestions without having to
worry about cutting and pasting code and getting things working.
b. will make it easier to add the code to CVS if we decide that's the way to
go.

That's just my personal opinion, but it would make me inclined to look at it
sooner.

Also, I do agree that it could not go into the core until we update the
Struts requirements to Servlet 2.3/JSP 1.2 (or later). I thinking along the
same lines as Rob's speculation - I do think that it might OK to make that
change sooner than Struts 2.0. Even my dodgy ISP has been running Tomcat 4
for a while so maybe it would be good to make a switch. 1.5 might be an
appropriate time to do that???

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Flexible form support (was Re: Simplifying DynaActionForms)

[Steve Raeburn]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 15, 2003 5:55 PM
> To: Struts Developers List
> Subject: Re: Flexible form support (was Re: Simplifying DynaActionForms)
>
...
> One suggestion might be to add a standard "parameter" properties to
> form-bean and action-forward, for the same reasons we have the parameter
> property on action-mapping. You could then just say
>
>  name="UserForm"
>   type="com.oroad.stxx.xform.DOMForm"
>   parameter="/WEB-INF/models/user.xml"/>
...

The problem with adding a 'parameter' is that you then find a need for
another parameter, etc etc. Is  not suitable here? Or, even
better, nested configuration elements under form-bean.

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: jakarta-struts/doc volunteers.xml

[Steve Raeburn]

Got it. Thanks. People keep adding stuff when I'm not looking :-)

Steve

> 
> Also edit the maven project.xml for developer entries.
> 
> -Rob
> 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: When is the next release?

[Steve Raeburn]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: August 10, 2003 12:37 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> I'm a zero-relative guy at heart :-).  My only concern is that people will
> assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
> 1.2.1.
>

Craig, could you clarify what you mean by 1.2?

I would assume 1.2 == 1.2.x, i.e. 1.2 represents the series of 1.2.x
releases.
So 1.2 would represent the 1.2 interface, but 1.2.x would be a particular
implementation.

Steve

>
> Craig
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: When is the next release?

[Steve Raeburn]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: August 9, 2003 8:57 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
> That was my understanding as well -- we agreed to switch to the x.y.z
> style that Apache HTTPD and Tomcat are using, where you post the bits and
> then call for a vote on stability (alpha/beta/general availability).  It's
> perfectly reasonable to have a series of "general availability" releases
> with new features in the 1.2.x series, as long as we continue to maintain
> backwards compatibility within it.
>
> Therefore the first release would be 1.2.1 and we'd keep going from there.

I think it would be strange to go directly to a 1.2.1 release, which I
suspect is why Ted was talking about a beta.
Tomcat has a 4_1_0 tag in CVS, but I don't know if that was released as
such.

It's not my intention to reopen an old discussion, but I would like to
confirm exactly what version this will be.

Steve

>
>
> Craig
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cvs commit: jakarta-struts/contrib/tag-doc build.xml

[Steve Raeburn]

I believe that the original version of the EL tags was correct.
ScriptLanguage is a boolean property indicating whether to output the
'language' attribute for the focus script block. It's actually inherited
from FormTag.

It's a little confusing because ScriptLanguageExpr *is* a String value, but
it's evaluated but the EL evaluator to a Boolean value.

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: August 9, 2003 12:30 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-struts/contrib/tag-doc build.xml
>
>
> craigmcc2003/08/09 12:29:30
>
>   Modified:.build.xml
>contrib/struts-el build.xml
>contrib/struts-el/src/share/org/apache/strutsel/taglib/html
> ELFormTag.java ELHtmlTag.java
> ELJavascriptValidatorTag.java
>contrib/struts-faces build.xml
>contrib/struts-legacy build.xml
>contrib/tag-doc build.xml
>   Log:
>   Correct loading order of properties files to go from most local (current
>   directory) to most global (${user.home}/build.properties).  Since Ant
>   follows a "first definition wins" strategy, this makes the most sense
>   for our convention of allowing local overrides of global
> values.  It also
>   means that I can now do an "ant dist" in the top level
> directory with only
>   one thing in my build.properties file (jdk.version=1.4), so
> this should fix
>   the nightly builds as well (verifying that is my next step).
>
>   Also fixed some compile errors in struts-el -- I don't know how
> that code
>   could have compiled for anyone.  Could someone more familiar with that
>   library make sure I did the changes correctly?
>
>   Revision  ChangesPath
>   1.118 +5 -2  jakarta-struts/build.xml
>
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-struts/build.xml,v
>   retrieving revision 1.117
>   retrieving revision 1.118
>   diff -u -r1.117 -r1.118
>   --- build.xml   8 Aug 2003 06:00:55 -   1.117
>   +++ build.xml   9 Aug 2003 19:29:30 -   1.118
>   @@ -113,9 +113,9 @@
>-->
>
>
>   -
>   -
>
>   +
>   +
>
>
> value="../jakarta-tomcat-4.0/build"/>
>   @@ -204,6 +204,9 @@
>
>
>
>   +
>   +
>   + value="${basedir}/contrib/struts-legacy/dist/struts-legacy.jar"/>
>
>
>
>
>
>
>   1.17  +4 -4  jakarta-struts/contrib/struts-el/build.xml
>
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build.xml,v
>   retrieving revision 1.16
>   retrieving revision 1.17
>   diff -u -r1.16 -r1.17
>   --- build.xml   13 Jun 2003 03:22:14 -  1.16
>   +++ build.xml   9 Aug 2003 19:29:30 -   1.17
>   @@ -51,10 +51,10 @@
> -->
>
> 
>   - 
>   - 
>   - 
> 
>   + 
>   + 
>   + 
>
> 
> 
>   @@ -219,7 +219,7 @@
>-->
>  
>   
>   -   
>   +   
>  
> 
>
>
>
>
>   1.9   +7 -7
> jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/tag
> lib/html/ELFormTag.java
>
>   Index: ELFormTag.java
>   ===
>   RCS file:
> /home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/st
> rutsel/taglib/html/ELFormTag.java,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- ELFormTag.java  26 Jul 2003 05:48:02 -  1.8
>   +++ ELFormTag.java  9 Aug 2003 19:29:30 -   1.9
>   @@ -386,9 +386,9 @@
>this,
> pageContext)) != null)
>setScope(string);
>
>   -if ((bool = EvalHelper.evalBoolean("scriptLanguage",
> getScriptLanguageExpr(),
>   -   this, pageContext)) != null)
>   -setScriptLanguage(bool.booleanValue());
>   +if ((string = EvalHelper.evalString("scriptLanguage",
> getScriptLanguageExpr(),
>   +this,
> pageContext)) != null)
>   +setScriptLanguageExpr(string);
>
>if ((string = EvalHelper.evalString("style", getStyleExpr(),
>this,
> pageContext)) != null)
>
>
>
>   1.8   +7 -7
> jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/tag
> lib/html/ELHtmlTag.java
>
>   Index: ELHtmlTag.java
>   ===
>   RCS file:
> /home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/st
> rutsel/taglib/html/ELHtmlTag.java,v
>   retrieving revision 1.7
>   retrieving revision 1.8
>   diff -u -r1.7 -r1.8
>   --- ELHtmlTag.java  26 Jul 2003 05:48:03 -  1.7
>   +++ ELHtmlTag.java  9 Aug 2003 19:29:30 -   1.8
>   @@ -158,9 

RE: When is the next release?

[Steve Raeburn]

Thanks for taking the time to explain in detail. The bit that was really
confusing me was the idea of jumping from 1.1 to 1.2.1.

I think there's got to be a 1.2.0, but I also think that it should be a
stable, production quality release. People will infer that from the number,
whether we like it or not.

>From that, it would seem that there's still a requirement for betas/rcs
before a minor version increment.

Steve


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 10, 2003 9:43 AM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> AFAIK, the consensus is that our releases should follow the same general
> process used by the Jakarta Commons and the Apache HTTP Server project.
>
> So, for reference, I'm following
>
> http://httpd.apache.org/dev/release.html
>
> and
>
> http://jakarta.apache.org/commons/releases/
>
> but observing the HTTPD numbering system.
>
> Right now, I intend to post a Release Plan for majority approval, either
> late tonight or early tomorrow. This Plan would include when we plan to
> roll the initial Alpha release. (I may even decided just to roll a
> release and post that along with the Plan.) We'd then vote whether to
> upgrade 1.2.1 from Alpha to Beta or General Availability (GA).
>
> Since there are any burning reasons to ship this instantly, I'm taking
> it as a foregone conclusion that this first roll will be at least a
> Beta. I'm confident that there are not any "serious problems that
> prohibits its use", so I don't believe it will not remain an Alpha. But,
> I do suspect that there may be "problems with this release that prohibit
> its widespread adoption" -- even if it simply documenting "what to do
> now that X is deprecated". So, I was calling it a Beta release.
>
> Once we have cleaned up the 1.2.1 roll (which I wager will only be a
> Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the
> General Availability stamp. Of course, nobody knows until the vote.
>
> Heretofore, we have rolled several version of the same "release" and
> then suffixed them B1, B2, and so forth. Moving forward (as I understand
> it), we of these releases get their own integer. If the release does not
> make it to GA, it dies on the vine, we and go onto the next number.
>
> In practice, you often get a odd/even pattern, where the odd was the
> "beta" or "development" version and even is the stable release. Some
> communities, like Linux, Perl, and Emacs, codify this pattern. When the
> odd-beta is sufficiently patched to make it release-worthy, they roll it
> over to the next even number and release that for general availability
>
> AFAIK, we're not enforcing the odd/even pattern or a formal "patch
> level". So, if we roll 1.2.2 and it fails to get the votes for a GA,
> we'd go on to 1.2.3, and if that passes, it becomes the next "stable"
> release, odd or not.
>
> Of course, it would even be possible for 1.2.1 to pass a GA vote, if
> someone called for one. Personally, I think that unlikely, if only for
> documentation issues. But, others could out-vote me if the consensus
> feels differently.
>
> The core idea is that when any of us feel brave enough to roll a
> release, we can tag CVS with the next integer, and have at it. The
> instant we tag and roll it, it's automatically an Alpha. To upgrade the
> status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote
> of the Committers (At least three committers have voted positively for a
> status and that there were more positive than negative votes (three is
> our working quorum for a binding vote)).
>
> To prevent any confusion with the CVS tags and so forth, the releases
> are immutable. Once it's rolled, it's rolled. If there's an issue that
> keeps a release from being upgraded, you either patch it, or tag and
> roll another release.
>
> To ensure that two us don't start rolling a release at once, it's
> prudent to announce your intentions first. Depending on how formal you
> want to be, that announcement might be dubbed a "Release Plan". But the
> only thing that matters is whether the release you roll passes a
> Majority Vote to move it from Alpha to Beta or GA.
>
> At least that's how I understand it =:0)
>
> Since this release is not backwardly compatible with 1.1.x, having
> removed all those deprecations, we are moving to the 1.2.x release
> series. Until something compels us to go on to the 1.3.x series, we can
> make be as many "General Available" releases in this series as we need.
>
> The current GA for Tom

RE: SuccessAction (was RE: Addition of two new actions)

[Steve Raeburn]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: August 9, 2003 3:56 PM
> To: Struts Developers List
> Subject: RE: SuccessAction (was RE: Addition of two new actions)
>
>
> >
> > If Action actually does something useful, could we go crazy and default
> > the
> > type as well?
> >
> >   
> >   
> >   
>
> There is a simpler way of doing that:
> 
>
> The only benefit of SuccessAction was that it allowed you to use the more
> configurable  element to describe the forward so I think
> SuccessAction examples should include  attributes that couldn't
> be done any other way.
>
> Having said all that, I do like that we're trying to get a simpler
> action/forward declaration syntax :-).
>

But forward= doesn't allow you to mix 'n' match context/module relative
forwards :-)

> >
> > Now that's simple. Especially if you allow a global default forward...
> >
> >   
>
> All we know from this is that there is an action mapped to /myAction but
> we don't know what handles it.  Taken by itself, it looks nonsensical and
> would likely cause confusion.  This may be a case where it's *too* simple.
>
> David
>

I wasn't being entirely serious with that, just following it to its logical
conclusion. I did say it probably wasn't very useful. But it would work. If
you know that you can define a global default forward then it makes sense.

It does raise the question of whether we want to allow/look for a global
default action. I'm thinking it may be better to insist that each global
forward has a name, just to avoid confusion. Technically, it works but it
might just be too confusing.

Steve.

> >
> > Probably not quite so useful, but nicely minimal!
> >
> > Steve
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

UML Diagrams (o.a.s.actions)

[Steve Raeburn]

Rob,

You added the .gif UML diagrams for the actions package a couple of months
ago. I'd like to add MappingDispatchAction. Is there a source image anywhere
that I can edit or do I need to edit the .gif itself?

Steve



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)

[Steve Raeburn]

Yup. What Ted said. :-)

I'm still feeling my way here, but does this kind of change *need* a formal
vote?

Steve

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: August 9, 2003 6:03 AM
> To: Struts Developers List
> Subject: Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of
> two new actions)
>
>
> I'd say it was more like a poll to get an early consensus on the best
> name for the class. Any product change would still be subject to a veto
> before the next release.
>
> James Mitchell wrote:
> > Is this a vote?  If so, shouldn't we have [VOTE] on the subject line?
> >>
> >>I *think* we agreed to add this action. Pick a name.
> >>
> >>[ ] ParameterDispatchAction
> >>[ ] MappingDispatchAction
> >>[ ] ConfigDispatchAction
> >>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: When is the next release?

[Steve Raeburn]

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]
> Sent: August 9, 2003 7:43 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> Are we going to take the struts-legacy out this build or remove
> it for 1.3.

I'm for removing it. I can do this if no one else is on it already.

I'd also like to remove the  deprecated attributes (name, style,
type) if there are no objections.

> If so then the data source code will need to be removed, before the beta.
> Beta implies a stable interface.
> Also I thought we were going to do away with alpha/beta/RC  anyway.

I'm sure I read a message on that a couple of days ago, but I can't find it
now. (Must be losing it)
Anyway, the gist was that we don't have a current non-stable/development
release (odd numbered) so we'd need a Beta.

If I could find the message I might understand it myself :-)

Steve

>
> >
> >
> > -Ted.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> --
> Robert Leland [EMAIL PROTECTED]
> --
> Java, J2EE, Struts, Web Application Development
>
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]