You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/03/11 18:42:20 UTC
Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
At 8:29 AM -0800 3/11/05, Dakota Jack wrote:
>Thanks, Frank. I posted this code in response to Ted's suggestion
>that this is the way to go to establish a dialogue with the committers
>on code.
I would totally endorse Ted's suggestion. The best approach is to
publicly document approaches and, where possible, provide extension
code that can be exercised without rushing a change to the Struts
core. This is how struts-chain was developed and verified as a
reasonable approach before the core was changed. It also happens to
be how validator and tiles evolved. In a much more modest fashion,
this was the origin of the DigestingPlugIn, which I developed and
published and which was adopted into Struts all before I was a
committer.
I feel bad seeing Frank's obvious bitter feelings, and as I noted
elsewhere, I'm sorry I wasn't following the thread closely enough to
warn that his efforts were pushing in a direction that Struts doesn't
follow. In fact, I know of no open source project which would add
incompatible features to an older release, except in the case of a
major version number change.
I don't think we've earned "Struts 2.0" with the other changes we
have, although until we do a release, we could certainly debate
calling the chain based processor Struts 2.0 and making room for
Frank's changes in what would then be a live development version on
the 1.x branch.
As always, remember that we're all volunteers here, and we all have
to scrounge for the time we apply to Struts. Also, we have an
enormous installed base, and we have to take their needs into
account. If the general open source community has come to expect
compatibility between minor version releases, and if we've always
struck a firm stance towards providing that kind of compatibility in
Struts, then we need to maintain consistency.
Frank, have you exhausted any hope of packaging your changes as
something which can be added on to Struts 1.2 without requiring
changes to the core classes? It may seem cumbersome, but I have a
feeling that it would be possible to package your changes as
extensions instead of core changes or a forked Struts distribution.
Where Struts falls short in this regard, I would be interested in
helping design and implement changes to both 1.2 and 1.3 to improve
its extensibility.
If Frank is burned out, but there's as much interest as there seemed
to be on the list, perhaps some of those people would be willing to
carry the baton to the next stage.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Ted Husted <te...@gmail.com>.
There are some links on the RoadMap pages for the likely Bugzilla queries.
* http://struts.apache.org/roadmap.html
The vast majority of the tickets are enhancement requests. A good
number of these might be already implemented and could be closed as
redundant.. The others might be organized into some kind of wish list
on the wiki, and then closed. There's a wiki page started along those
lines at
* http://wiki.apache.org/struts/StrutsIdeaJar
The tickets that should receive the most attention are the
* Problem tickets with patches, and then the
* Problem tickets.
We have been resolving all of the problem tickets regularly, and so
most of these should be relatively recent.
The tickets with patches could be reviewed and tested. If the
description seems sound, and if the patches applies, a "works for me"
comment can be added to the ticket, and perhaps we could change the
status to verified. If the patch doesn't work, we could ping the
submitter. If there is not a reply in 72 hours (our standard
increment), and there is no clear way to resolve the issue, then we
might close it for lack of a working patch.
If there is a problem ticket without a patch, and there is no clear
resolution, we have been know to close problem tickets for lack of a
patch. We might setup a "known issues" page, and refer to those
(closed) tickets there. We could draft a page like that on the wiki,
and then move it to the website when ready, so that people don't add
new issues to the wiki instead of bugzilla.
Since this is an open source project, I personally don't feel it's our
job to fix every problem. However, I do feel we should solicit and
apply patches from the community, and record any known issues that we
don't know how to fix. For very old issues, it might be reasonable
that we move them to another area, like the website, just to keep
bugzilla from bloating.
As a rule, we shouldn't mark something WON'T FIX unless there is a
specific reason why we aren't going to address the issue. For example,
adding functionality to the original Struts Taglibs outside the scope
of the HTML specification.
Personally, I'm not keen on bulk-closing the enhancement tickets
without review. But, if we did, six months is way too brief around
here. It would have to be more like eighteen months.
-Ted.,
On Sat, 12 Mar 2005 11:09:29 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> I'm willing to take on some of this. I figure a small step first...
>
> Can anyone verify for me the total number of tickets in Bugzilla as of
> this day is 2404? I came to this by doing a search on product Struts
> with all possible statuses selected. Are those the correct parameters
> to get that metric?
>
> Next, I did the same search but *removing* the statuses CLOSED, RESOLVED
> and ASSIGNED. I get 345, which should be the number of tickets left to
> be worked on in some fashion that no one has stepped up to take on.
> Does that sound correct?
>
> What I am offering to do is go through those 345 tickets and deal with
> them in some way. Some debate is probably needed as what appropriate
> actions are. Some suggestions:
>
> (1) Any ticket not modified in the last six months will be resolved as
> CLOSED. My reasoning is that if no one has done anything on it in half
> a year, a new ticket should be opened if it still applies (or I suppose
> this ticket explicitly REOPENED by someone).
>
> (2) This will be controversial I suspect... Any ticket applying to a
> version prior to 1.2.4 gets marked as WONTFIX. I am proposing
> end-of-life'ing anything prior to 1.2.4. This doesn't seem quite as
> radical to me in light of the recent discussions about how versions
> develop. Everyone has said new features will only be applied to 1.3,
> anything prior is bug fixes only. Why not go one more step and say only
> the prior version (or two in this case, 1.2.4 and 1.2.5) will be
> supported even for bug fixes? Anyone agree with this?
>
> (3) Any ticket that was REOPENED I will contact the person who reopened
> it to get a status updated from them. My feeling is that if someone
> reopened a ticket, I take that to mean they took responsibility for it.
>
> (4) Any ticket that is VERIFIED I will add a note to saying something to
> the effect of "this ticket should be CLOSED in six months if not
> resolved in the intervening time". My reasoning is that if no one takes
> it on in half a year, chances are it isn't going to get resolved and
> therefore it should be closed and a new ticket opened (or the ticket
> reopened) if someone still wants it fixed.
>
> (5) Any ticket that is UNCONFIRMED I will put a note on it saying
> something like "if no one VERIFIES this in 3 months, the ticket should
> be closed".
>
> These are just some thoughts I had to clean up the database. The
> suggested time periods are of course negotiable. I am of course open to
> any other ideas, whether in addition to these or contravening these.
> The bottom line though is I think there is an opportunity here to clean
> up the database a bit and make it more useful, and I am willing to do
> that work if there is support for the effort.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Ted Husted <te...@gmail.com>.
(Inline.)
On Fri, 11 Mar 2005 16:06:19 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> It's fair that there was discussion, but an obvious problem is still
> apparent... I've only been on the lists for a couple of months. I would
> certainly think no one expects a person to go through the entire list
> archives to catch up :)
>
> I think we really need something that cuts through the "noise" on the
> list, meaning that we have a repository where the discussions on the
> list are boiled down to actual action points for people to reference.
> This is kind of basic project management stuff I'm talking about. You
> debate in a meeting, then someone draws up a list of what is being done
> by who, *referencing* the discussion thread if it is needed. I don't
> see where we have anything like that at this point. I don't believe the
> Wiki nor Bugzilla is it.
The closest thing we have right now are the Roadmap and Versions page.
Other than that, we all just follow along on the list.
I know there are other open source projects that are run more like a
in-house team, but, to date, this hasn't been one of them :)
Unfortunately, most of us are so swamped with our regular jobs, we
can't agree to do something until we are ready to sit down and do it.
If we try, then someone becomes a bottleneck.
If anyone wants to start maintaining something on the wiki, or provide
patches for the Roadmap or Versions page, please have at it.
> > But no, I didn't beat you to the punch, if you feel that a solution is
> > necessary which works with Struts 1.2 without using struts-chain.
>
> That's true, but only to a point... since I've now been told that "no
> new features will ever be added to anything but 1.3 and beyond", there
> is no hope of my work ever being incorporated into the core *if* a
> different direction is used in 1.3. Therefore, in a sense you *did*
> beat me to the punch because there was no chance for me to explore doing
> it in 1.3
I think the meaning here is that no one is eager to open up the 1.2.x
branch for active development, and we are hoping to start shipping the
1.3.x series soon.
Once upon a time, we talked about a 2.x revolution, where we could
break some of the API contracts. But, the general consensus was that
backward compatibility was vital, and we should just evolve 1.x.
We can *evolve* the API contracts, but the expectation is to do it in
depreate/replace/remove series. A good example is the DataSource,
which we evolved out of the API over 1.1 and 1.2, and are removing in
1.3.
> Now, you could say that was my fault for not starting my work with 1.3,
> and I couldn't really argue that :)
>
> > But look at SSL/Ext, or Struts Test Case. Or Hubert's FormDef project.
> > Or AppFuse. These are all things which help people use Struts. There
> > are others.
>
> Your right of course, and like I said, if there is a way to do this as
> an extension to the framework, and especially if someone wants to
> suggest such an option, I am willing to listen and do the work. I will
> explore some possible approaches on my own.
>
> But I still feel this is something that *should* in fact be in the core.
> I don't think anyone is going to change my mind on that point.
> Unfortunately, if I can't convince any of you, then it's just an
> opinion, and everyones' got one :)
If any extension was sufficiently popular, it could find its way into the Core.
But, the key is that the extension has to be popular within the Community.
A good example is the Nested Taglibs. When these came out, none of
the Committers where using them, but there was a groundswell of
support on the User and Dev list. So, we accepted the extension into
the Taglibs package (which was then part of the Core).
> > I remember the proposal, although I don't remember how it was meant to
> > stay accurate and up to date.
>
> The part where I saw my proposal really differing from the Wiki or
> Bugzilla (and in that way be more accurate and up-to-date) is that in an
> automated fashion it would "tickle" for status the assignee of a
> particular enhancement (note that I only intended for it to cover
> enhancements). In other words...
>
> (1) You go to the site and see an enhancement proposal that interests
> you (I could imagine a list of requested/suggested enhancements and a
> separate list of what is actually being done). No one else has stepped
> forward to work on it, so you volunteer. That task is then assigned to you.
>
> (2) At some regular interval (every week?) an automated message goes out
> to you asking for an update on your progress. If no response is
> received within some time period (48 hours?), then that task is
> unassigned, and someone else can pick it up.
>
> In this way, we would always know who is working on what, and at least a
> rough idea of their progress. True, they could just do a quick "I'm
> working on it" update every week, but one has to assume some level of
> commitment to at least write brief *real* update of they were interested
> to volunteer in the first place. If someone drops something, someone
> else can pick it up. In many ways its just a slightly more automated
> version of what exists now, but I think it would make a big difference,
>
> There is more that could be done of course, but this was the starting
> point I suggested and offered to build.
Except for the nags, Bugzilla and the other issue trackers come close
to this. If there is a ticket open for something, people often note
any progress being made. And if progress stops, people have been know
to post a nudge. (Happened to me last week.)
The trick would be to open Bugzilla tickets for the Roadmap items, and
encourage people to log their progress. Realistically, someone with an
itch might have to do the logging themselves at first, to encourage
people to get into the habit. Sadly, in a volunteer environment, it's
hard to insist that people do some things a certain way, unless you
are willing to do it yourself.
JIRA is particularly good at Roadmapping, but until Commons switches
over, we're probably better off wth Bugzilla. :(
> > To be honest (and hopefully not appearing
> > rude), I don't see how having this site would help me have the time to
> > put stuff there, or anyone else who is working on various features.
>
> Not appearing rude at all because clearly it wouldn't :) But someone
> could at least know that what they are working on isn't being done by
> someone else concurrently. At least you wouldn't find out that all your
> hard work was already done by someone else, and they released before you.
>
> Also, we could allow for things like multiple assignees, so that if two
> people had a competing approach to something, we'd know it and both
> would know that their solution may not be choosen. At least they could
> know that up-front instead of only after they did the wasted work.
>
> > I'm not meaning this email to be the final word, or to imply that there
> > the problems you raise are immaterial, but I think those problems are
> > inherent to a community like ours, made up of a bunch of distributed
> > volunteers. I don't even have the bandwidth I'd like to cut code and
> > participate in all of the discussions on the Struts lists, let alone
> > having extra bandwidth for community engineering.
>
> I agree, I'm not pointing out any problems (assuming one agrees they
> *are* problems) that are unusual for such a community-driven project.
>
> I don't however see the sense is saying "that's the way it is, deal with
> it", which is kind of what we're saying, isn't it? I believe
> community-driven development in general suffers from a general lack of
> real project management, and I think we should all strive to introduce
> some. Because its a distributed environment, the issues are different
> and the solutions will be different than in more "typical" environments
> (like an enterprise for instance).
>
> I've tried to offer some solutions, and even if you disgaree (meaning
> Joe or anyone else), I believe there should be discussion on the issue,
> some brainstorming, and see if we can't make it better for all involved
> (or all who *want* to be involved) instead of just being satisfied
> with the status quo.
>
> As much as I hate to say it, sometimes engineers being project managers
> is a bad idea. Perhaps open-source community-driven development
> projects should come to that conclusion and separate the project
> managers from the developers. Just a thought (not even sure *I* would
> agree with it yet).
Oh, I don't think anyone would mind a hands-on project manager being
involved with a project. The operative phrase being "hands-on". It
would be wonderful if someone could keep the Roadmap and Versions page
up to date with the latest list discussions. It would also be
wonderful if someone could open Bugzilla tickets for Roadmap items and
update the comments with any peritennt comments from the Subversion
logs or the list.
But, that someone like that has to be willing to step up and do the
work. Not by telling other people what to do, but by doing it
themselves, and leading by example.
There are no stupid or lazy Committers. Just some very busy coders
already working 50 or 80 hours weeks, helping out the best we can.
And, if someone can show us that better use of Bugzilla or the
equivalent can make better use of our time, of course we'd go along.
But, someone needs to blaze the path.
>
> > Joe
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Dakota Jack <da...@gmail.com>.
+42
On Fri, 11 Mar 2005 17:59:46 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> dbrosius@qis.net wrote:
> > Project management in itself isn't a bad thing, but a very good
> thing. It's when
> > the project managers are perceived to be the bosses of development,
> instead of
> > its secretaries, that there's a problem. I think there are folks who
> could
> > contribute alot to open source projects, and benefit the projects
> greatly, if
> > they were allowed to fill a project manager roll.
>
> I couldn't agree more. As annoying as it is to deal with PMs at work
> sometimes (and as annoying as I'm sure I am to those under me when I
> wear the PM hat), it is really a vital role.
>
> I absolutely think more rigid PM practices should be brought into the
> OSS world. It could only make things better. And I absolutely think
> there should be people with PM skills who *only* do PM chores.
>
> Unfortunately, whether anyone cares to admit it or not, egos play a huge
> role in community-driven development. Egos tend to not going along well
> with anything "rigid".
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I'm willing to take on some of this. I figure a small step first...
Can anyone verify for me the total number of tickets in Bugzilla as of
this day is 2404? I came to this by doing a search on product Struts
with all possible statuses selected. Are those the correct parameters
to get that metric?
Next, I did the same search but *removing* the statuses CLOSED, RESOLVED
and ASSIGNED. I get 345, which should be the number of tickets left to
be worked on in some fashion that no one has stepped up to take on.
Does that sound correct?
What I am offering to do is go through those 345 tickets and deal with
them in some way. Some debate is probably needed as what appropriate
actions are. Some suggestions:
(1) Any ticket not modified in the last six months will be resolved as
CLOSED. My reasoning is that if no one has done anything on it in half
a year, a new ticket should be opened if it still applies (or I suppose
this ticket explicitly REOPENED by someone).
(2) This will be controversial I suspect... Any ticket applying to a
version prior to 1.2.4 gets marked as WONTFIX. I am proposing
end-of-life'ing anything prior to 1.2.4. This doesn't seem quite as
radical to me in light of the recent discussions about how versions
develop. Everyone has said new features will only be applied to 1.3,
anything prior is bug fixes only. Why not go one more step and say only
the prior version (or two in this case, 1.2.4 and 1.2.5) will be
supported even for bug fixes? Anyone agree with this?
(3) Any ticket that was REOPENED I will contact the person who reopened
it to get a status updated from them. My feeling is that if someone
reopened a ticket, I take that to mean they took responsibility for it.
(4) Any ticket that is VERIFIED I will add a note to saying something to
the effect of "this ticket should be CLOSED in six months if not
resolved in the intervening time". My reasoning is that if no one takes
it on in half a year, chances are it isn't going to get resolved and
therefore it should be closed and a new ticket opened (or the ticket
reopened) if someone still wants it fixed.
(5) Any ticket that is UNCONFIRMED I will put a note on it saying
something like "if no one VERIFIES this in 3 months, the ticket should
be closed".
These are just some thoughts I had to clean up the database. The
suggested time periods are of course negotiable. I am of course open to
any other ideas, whether in addition to these or contravening these.
The bottom line though is I think there is an opportunity here to clean
up the database a bit and make it more useful, and I am willing to do
that work if there is support for the effort.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Ted Husted wrote:
> +1
>
> Except that Apache open source projects don't really "allow" people to
> fill roles.
>
> People start filling the roles, and then we recognize their
> contribution -- mainly by granting the system permissions (or "karma")
> to make the contributions directly.
>
> Right now, anyone has karma to bugzilla or the wiki, where most
> project management type tasks would take place.
>
> In practice, documentators and managers are very hard to find. Things
> like code we can use in our day-jobs, but documentation, including
> management documentation, not so much.
>
> -Ted.
>
>
> On Fri, 11 Mar 2005 16:23:22 -0500, dbrosius@qis.net <db...@qis.net> wrote:
>
>>Quoting "Frank W. Zammetti" <fz...@omnytex.com>:
>>
>>
>>>As much as I hate to say it, sometimes engineers being project managers
>>>is a bad idea. Perhaps open-source community-driven development
>>>projects should come to that conclusion and separate the project
>>>managers from the developers. Just a thought (not even sure *I* would
>>>agree with it yet).
>>
>>Project management in itself isn't a bad thing, but a very good thing. It's when
>>the project managers are perceived to be the bosses of development, instead of
>>its secretaries, that there's a problem. I think there are folks who could
>>contribute alot to open source projects, and benefit the projects greatly, if
>>they were allowed to fill a project manager roll.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Ted Husted <te...@gmail.com>.
+1
Except that Apache open source projects don't really "allow" people to
fill roles.
People start filling the roles, and then we recognize their
contribution -- mainly by granting the system permissions (or "karma")
to make the contributions directly.
Right now, anyone has karma to bugzilla or the wiki, where most
project management type tasks would take place.
In practice, documentators and managers are very hard to find. Things
like code we can use in our day-jobs, but documentation, including
management documentation, not so much.
-Ted.
On Fri, 11 Mar 2005 16:23:22 -0500, dbrosius@qis.net <db...@qis.net> wrote:
> Quoting "Frank W. Zammetti" <fz...@omnytex.com>:
>
> >
> > As much as I hate to say it, sometimes engineers being project managers
> > is a bad idea. Perhaps open-source community-driven development
> > projects should come to that conclusion and separate the project
> > managers from the developers. Just a thought (not even sure *I* would
> > agree with it yet).
>
> Project management in itself isn't a bad thing, but a very good thing. It's when
> the project managers are perceived to be the bosses of development, instead of
> its secretaries, that there's a problem. I think there are folks who could
> contribute alot to open source projects, and benefit the projects greatly, if
> they were allowed to fill a project manager roll.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
dbrosius@qis.net wrote:
> Project management in itself isn't a bad thing, but a very good
thing. It's when
> the project managers are perceived to be the bosses of development,
instead of
> its secretaries, that there's a problem. I think there are folks who
could
> contribute alot to open source projects, and benefit the projects
greatly, if
> they were allowed to fill a project manager roll.
I couldn't agree more. As annoying as it is to deal with PMs at work
sometimes (and as annoying as I'm sure I am to those under me when I
wear the PM hat), it is really a vital role.
I absolutely think more rigid PM practices should be brought into the
OSS world. It could only make things better. And I absolutely think
there should be people with PM skills who *only* do PM chores.
Unfortunately, whether anyone cares to admit it or not, egos play a huge
role in community-driven development. Egos tend to not going along well
with anything "rigid".
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by db...@qis.net.
Quoting "Frank W. Zammetti" <fz...@omnytex.com>:
>
> As much as I hate to say it, sometimes engineers being project managers
> is a bad idea. Perhaps open-source community-driven development
> projects should come to that conclusion and separate the project
> managers from the developers. Just a thought (not even sure *I* would
> agree with it yet).
Project management in itself isn't a bad thing, but a very good thing. It's when
the project managers are perceived to be the bosses of development, instead of
its secretaries, that there's a problem. I think there are folks who could
contribute alot to open source projects, and benefit the projects greatly, if
they were allowed to fill a project manager roll.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Joe Germuska wrote:
> Well, that was me, actually. And there had been lots of prior
> discussion, as cited by Hubert in three URLs in a message which
> motivated me to finally do it. That prior discussion dates back more
> than a year.
Yep, I found it in my trash folder. Sorry for the confusion! :)
It's fair that there was discussion, but an obvious problem is still
apparent... I've only been on the lists for a couple of months. I would
certainly think no one expects a person to go through the entire list
archives to catch up :)
I think we really need something that cuts through the "noise" on the
list, meaning that we have a repository where the discussions on the
list are boiled down to actual action points for people to reference.
This is kind of basic project management stuff I'm talking about. You
debate in a meeting, then someone draws up a list of what is being done
by who, *referencing* the discussion thread if it is needed. I don't
see where we have anything like that at this point. I don't believe the
Wiki nor Bugzilla is it.
> But no, I didn't beat you to the punch, if you feel that a solution is
> necessary which works with Struts 1.2 without using struts-chain.
That's true, but only to a point... since I've now been told that "no
new features will ever be added to anything but 1.3 and beyond", there
is no hope of my work ever being incorporated into the core *if* a
different direction is used in 1.3. Therefore, in a sense you *did*
beat me to the punch because there was no chance for me to explore doing
it in 1.3
Now, you could say that was my fault for not starting my work with 1.3,
and I couldn't really argue that :)
> But look at SSL/Ext, or Struts Test Case. Or Hubert's FormDef project.
> Or AppFuse. These are all things which help people use Struts. There
> are others.
Your right of course, and like I said, if there is a way to do this as
an extension to the framework, and especially if someone wants to
suggest such an option, I am willing to listen and do the work. I will
explore some possible approaches on my own.
But I still feel this is something that *should* in fact be in the core.
I don't think anyone is going to change my mind on that point.
Unfortunately, if I can't convince any of you, then it's just an
opinion, and everyones' got one :)
> I remember the proposal, although I don't remember how it was meant to
> stay accurate and up to date.
The part where I saw my proposal really differing from the Wiki or
Bugzilla (and in that way be more accurate and up-to-date) is that in an
automated fashion it would "tickle" for status the assignee of a
particular enhancement (note that I only intended for it to cover
enhancements). In other words...
(1) You go to the site and see an enhancement proposal that interests
you (I could imagine a list of requested/suggested enhancements and a
separate list of what is actually being done). No one else has stepped
forward to work on it, so you volunteer. That task is then assigned to you.
(2) At some regular interval (every week?) an automated message goes out
to you asking for an update on your progress. If no response is
received within some time period (48 hours?), then that task is
unassigned, and someone else can pick it up.
In this way, we would always know who is working on what, and at least a
rough idea of their progress. True, they could just do a quick "I'm
working on it" update every week, but one has to assume some level of
commitment to at least write brief *real* update of they were interested
to volunteer in the first place. If someone drops something, someone
else can pick it up. In many ways its just a slightly more automated
version of what exists now, but I think it would make a big difference,
There is more that could be done of course, but this was the starting
point I suggested and offered to build.
> To be honest (and hopefully not appearing
> rude), I don't see how having this site would help me have the time to
> put stuff there, or anyone else who is working on various features.
Not appearing rude at all because clearly it wouldn't :) But someone
could at least know that what they are working on isn't being done by
someone else concurrently. At least you wouldn't find out that all your
hard work was already done by someone else, and they released before you.
Also, we could allow for things like multiple assignees, so that if two
people had a competing approach to something, we'd know it and both
would know that their solution may not be choosen. At least they could
know that up-front instead of only after they did the wasted work.
> I'm not meaning this email to be the final word, or to imply that there
> the problems you raise are immaterial, but I think those problems are
> inherent to a community like ours, made up of a bunch of distributed
> volunteers. I don't even have the bandwidth I'd like to cut code and
> participate in all of the discussions on the Struts lists, let alone
> having extra bandwidth for community engineering.
I agree, I'm not pointing out any problems (assuming one agrees they
*are* problems) that are unusual for such a community-driven project.
I don't however see the sense is saying "that's the way it is, deal with
it", which is kind of what we're saying, isn't it? I believe
community-driven development in general suffers from a general lack of
real project management, and I think we should all strive to introduce
some. Because its a distributed environment, the issues are different
and the solutions will be different than in more "typical" environments
(like an enterprise for instance).
I've tried to offer some solutions, and even if you disgaree (meaning
Joe or anyone else), I believe there should be discussion on the issue,
some brainstorming, and see if we can't make it better for all involved
(or all who *want* to be involved) instead of just being satisfied
with the status quo.
As much as I hate to say it, sometimes engineers being project managers
is a bad idea. Perhaps open-source community-driven development
projects should come to that conclusion and separate the project
managers from the developers. Just a thought (not even sure *I* would
agree with it yet).
> Joe
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts
Wiki] Updated: StrutsUpload)
Posted by Joe Germuska <Jo...@Germuska.com>.
>Also, we don't know what you guys are cooking up many times, as
>evidenced by the addition (I believe it was Martin) made a night or
>two ago that was along the lines of what I had done but for the 1.3
>branch... it seems like my work prompted him to do something
>similar, and because he could simply do it and add it without any
>discussion, he "beats me to the punch", in essence. Plus, this was
>without any discussion that I saw (I apologize if I missed it) on
>the public lists. How is someone like me or Jack that wants to get
>involved supposed to do so under those conditions? Why would we
>*ever* put the time in without knowing (a) whether it will be
>accepted or not and (b) that one of the Struts team won't just go do
>it themselves?
Well, that was me, actually. And there had been lots of prior
discussion, as cited by Hubert in three URLs in a message which
motivated me to finally do it. That prior discussion dates back more
than a year.
But no, I didn't beat you to the punch, if you feel that a solution
is necessary which works with Struts 1.2 without using struts-chain.
>As Ted correctly says, we're all volunteers, but the difference is
>that you guys know your contributions aren't a waste of time
>(mostly... I realize other members can veto your additions). We
>don't have the luxury of that knowledge before we put the time in.
But look at SSL/Ext, or Struts Test Case. Or Hubert's FormDef
project. Or AppFuse. These are all things which help people use
Struts. There are others.
>You know, I made a proposal a week or two ago to develop a site that
>would track enhancements being worked on, who was doing it, etc. I
>offered to do the site development work and even host it. It was
>rejected for various reasons. I still believe something along those
>lines would go a long way to helping alleviate this problem, and no,
>I still do not agree that the Wiki and/or Bugzilla serves this
>purpose.
I remember the proposal, although I don't remember how it was meant
to stay accurate and up to date. To be honest (and hopefully not
appearing rude), I don't see how having this site would help me have
the time to put stuff there, or anyone else who is working on various
features.
I'm not meaning this email to be the final word, or to imply that
there the problems you raise are immaterial, but I think those
problems are inherent to a community like ours, made up of a bunch of
distributed volunteers. I don't even have the bandwidth I'd like to
cut code and participate in all of the discussions on the Struts
lists, let alone having extra bandwidth for community engineering.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I couldn't find it in the archives, but I did find it in my own trash
folder...
It was actually from Joe, in reply to Hubert, as part of the discussion
about what I was doing. As I said, it's not exactly what I did, but it
is very much along the same lines, except that it's for the 1.3 branch,
and is per-forward only. Here's the message:
Hubert wrote:
>> And I've been silently wishing you'd add it, too. :)
>> We've had discussions about this maybe twice before, and another time
>> I lit the flame, you responded, but I wasn't able to follow through
>> with the discussion.
Joe wrote:
> Well, then, now you've gone and done it, Hubert... I've just committed the basic support for per-forward commands.
>
> I think the next step would be to write a simple command which looks something like this:
>
> public class FormPrepCommand implements Command {
> private String formName; // property
> private String formScope; // property
>
> public boolean execute(Context context) {
>
> if (this.formName != null) {
> ActionContext actionCtx = (ActionContext) context;
> ActionForm form = lookupForm(formName,formScope, actionCtx);
> prepareForm(actionCtx, form);
> return false;
> }
> }
>
> protected ActionForm lookupForm(String formName, String formScope, ActionContext ctx) {
> // standard behavior for looking up a form and making sure its in the right request/session scope
> // classes would rarely override this; maybe it would be private.
> }
>
>
> protected abstract void prepareForm(ActionContext ctx, ActionForm form);
>
> }
>
>
> Then one could use one or more of these in a per-forward chain of renders. Of course other commands could do non-form oriented setup.
>
> Related to what I just checked in, I still like a model where rather than configuring command and catalog on each ForwardConfig, a lookup is done based on the "path" value of the ForwardConfig. No reason not to have both, of course, but I just think my style would be to have a catalog named "page-prep" and a different command in process-view which worked this way.
>
> Joe
Frank W. Zammetti wrote:
> Fair enough, I wasn't certain. :)
>
> I'm trying to find the relevant message now so as to not be posting FUD
> by mistake!
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I feel that Jack is on to something important here... the ability for
"outsiders" to work on Struts seems to me an almost impossible task.
We are constantly told "make a proposal", "put it up in the Wiki" or
"open a ticket with your suggestions", but the problem with that is that
we are spending a lot of time doing things that can be rejected
out-of-hand for any reason by any members of the PMC.
Also, we don't know what you guys are cooking up many times, as
evidenced by the addition (I believe it was Martin) made a night or two
ago that was along the lines of what I had done but for the 1.3
branch... it seems like my work prompted him to do something similar,
and because he could simply do it and add it without any discussion, he
"beats me to the punch", in essence. Plus, this was without any
discussion that I saw (I apologize if I missed it) on the public lists.
How is someone like me or Jack that wants to get involved supposed to
do so under those conditions? Why would we *ever* put the time in
without knowing (a) whether it will be accepted or not and (b) that one
of the Struts team won't just go do it themselves?
As Ted correctly says, we're all volunteers, but the difference is that
you guys know your contributions aren't a waste of time (mostly... I
realize other members can veto your additions). We don't have the
luxury of that knowledge before we put the time in.
You know, I made a proposal a week or two ago to develop a site that
would track enhancements being worked on, who was doing it, etc. I
offered to do the site development work and even host it. It was
rejected for various reasons. I still believe something along those
lines would go a long way to helping alleviate this problem, and no, I
still do not agree that the Wiki and/or Bugzilla serves this purpose. I
seemed to be the only one with that opinion though. The point being,
whether this idea or not, I believe *something* needs to be done because
there are people willing to participate that see a very high barrier to
entry, one that seems to be next to impossible to get around.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
> <SNIP>
> On Fri, 11 Mar 2005 11:42:20 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>
>>At 8:29 AM -0800 3/11/05, Dakota Jack wrote:
>>
>>>Thanks, Frank. I posted this code in response to Ted's suggestion
>>>that this is the way to go to establish a dialogue with the committers
>>>on code.
>>
>>I would totally endorse Ted's suggestion.
>
> </SNIP>
>
> We will see if it works. I did that.
>
> I have made a proposal which can be assessed at this stage. There is
> no question about what would need to be done to implement the code I
> have provided. The basis is, as I said, about 15 lines of code. The
> idea is what is what must be accepted or rejected. I don't have time
> to spin my wheels. If the idea is not acceptable no matter what, then
> that is okay. But, if that is the case, doing "no matter what" is
> spinning wheels.
>
> <SNIP>
>
>>The best approach is to
>>publicly document approaches and, where possible, provide extension
>>code that can be exercised without rushing a change to the Struts
>>core. This is how struts-chain was developed and verified as a
>>reasonable approach before the core was changed. It also happens to
>>be how validator and tiles evolved. In a much more modest fashion,
>>this was the origin of the DigestingPlugIn, which I developed and
>>published and which was adopted into Struts all before I was a
>>committer.
>
> </SNIP>
>
> I am not sure what this means in terms of what I discussed and
> provided. I am not suggesting a change to the Struts core. I am not
> even suggesting something inconsistent with present practice.
>
> <SNIP>
>
>>In fact, I know of no open source project which would add
>>incompatible features to an older release, except in the case of a
>>major version number change.
>
> </SNIP>
>
> Isn't branching common? I may misunderstand this?
>
> </SNIP>
>
>>I don't think we've earned "Struts 2.0" with the other changes we
>>have, although until we do a release, we could certainly debate
>>calling the chain based processor Struts 2.0 and making room for
>>Frank's changes in what would then be a live development version on
>>the 1.x branch.
>
> </SNIP>
>
> If this is just an opening of the RequestProcessor logic, why is it
> discussed so much as "chain based"? Shouldn't the interface allow for
> changes in the future which are not chain based? There is so little
> discussion about core changes on this list that what is happening is
> impossible to tell unless you are one of the few people doing all the
> work. The options from someone on the "outside" seem to be to have
> ten people doing ten things on their own and then submitting it all at
> one time to see who wins, rather than working together. I thought I
> could work with people on a list like this. Is that not the idea?
> This seems to be impossible from my perspective. No matter what you
> provide, it is always met with "we cannot comment on that at this time
> because ...." or "no". It is frustrating, Martin.
>
> <SNIP>
>
>>As always, remember that we're all volunteers here, and we all have
>>to scrounge for the time we apply to Struts. Also, we have an
>>enormous installed base, and we have to take their needs into
>>account. If the general open source community has come to expect
>>compatibility between minor version releases, and if we've always
>>struck a firm stance towards providing that kind of compatibility in
>>Struts, then we need to maintain consistency.
>
> </SNIP>
>
> I think we all know that. I really do. Somehow there is this idea
> that this basic requirement escapes people. But, I don't think it
> does.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Dakota Jack <da...@gmail.com>.
I am not interested in having an upload application accepted by
Struts. Why would I be interested in that? The lack of interest is
in making Struts accommodate these differences with the way it handles
multipart request processing. I changed the application to
accommondate that and the entirety of the relevant code is on the wiki
in 15 lines. I must have said this a number of times, but somehow
that point cannot be heard. Why?
I do not mean that I would not donate an application. But, that is a
fairly superficial, passing, and uninteresting thing. Having the
internals of the framework able to accommodate others as well as
myself is not superficial, not passing, and, at least I think, very
interesting. No one has responded to that point. That is the point,
Ted.
Jack
On Fri, 11 Mar 2005 16:13:53 -0500, Ted Husted <te...@gmail.com> wrote:
> The underlying problem with the upload proposal on the wiki is
>
> > "I have a full application, but no sense putting it all here if there is no interest."
>
> The best way to generate interest is to post a working example. If you
> want to pique interest, you have to go the whole nine yards. Else,
> statements like these become self-fulling prophesies.
>
> Putting the code up on the wiki is great, but you need to post a
> downloadable ZIP someplace with the source code and JARs. (Included a
> statement putting it under the Apache License would also be a good
> idea.)
>
> If you don't have Internet space anyplace, send it to me directly, and
> I'll park it on Struts SourceForge, or someplace.
>
> -Ted.
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Ted Husted <te...@gmail.com>.
The underlying problem with the upload proposal on the wiki is
> "I have a full application, but no sense putting it all here if there is no interest."
The best way to generate interest is to post a working example. If you
want to pique interest, you have to go the whole nine yards. Else,
statements like these become self-fulling prophesies.
Putting the code up on the wiki is great, but you need to post a
downloadable ZIP someplace with the source code and JARs. (Included a
statement putting it under the Apache License would also be a good
idea.)
If you don't have Internet space anyplace, send it to me directly, and
I'll park it on Struts SourceForge, or someplace.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Dakota Jack <da...@gmail.com>.
<SNIP>
On Fri, 11 Mar 2005 11:42:20 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 8:29 AM -0800 3/11/05, Dakota Jack wrote:
> >Thanks, Frank. I posted this code in response to Ted's suggestion
> >that this is the way to go to establish a dialogue with the committers
> >on code.
>
> I would totally endorse Ted's suggestion.
</SNIP>
We will see if it works. I did that.
I have made a proposal which can be assessed at this stage. There is
no question about what would need to be done to implement the code I
have provided. The basis is, as I said, about 15 lines of code. The
idea is what is what must be accepted or rejected. I don't have time
to spin my wheels. If the idea is not acceptable no matter what, then
that is okay. But, if that is the case, doing "no matter what" is
spinning wheels.
<SNIP>
> The best approach is to
> publicly document approaches and, where possible, provide extension
> code that can be exercised without rushing a change to the Struts
> core. This is how struts-chain was developed and verified as a
> reasonable approach before the core was changed. It also happens to
> be how validator and tiles evolved. In a much more modest fashion,
> this was the origin of the DigestingPlugIn, which I developed and
> published and which was adopted into Struts all before I was a
> committer.
</SNIP>
I am not sure what this means in terms of what I discussed and
provided. I am not suggesting a change to the Struts core. I am not
even suggesting something inconsistent with present practice.
<SNIP>
> In fact, I know of no open source project which would add
> incompatible features to an older release, except in the case of a
> major version number change.
</SNIP>
Isn't branching common? I may misunderstand this?
</SNIP>
> I don't think we've earned "Struts 2.0" with the other changes we
> have, although until we do a release, we could certainly debate
> calling the chain based processor Struts 2.0 and making room for
> Frank's changes in what would then be a live development version on
> the 1.x branch.
</SNIP>
If this is just an opening of the RequestProcessor logic, why is it
discussed so much as "chain based"? Shouldn't the interface allow for
changes in the future which are not chain based? There is so little
discussion about core changes on this list that what is happening is
impossible to tell unless you are one of the few people doing all the
work. The options from someone on the "outside" seem to be to have
ten people doing ten things on their own and then submitting it all at
one time to see who wins, rather than working together. I thought I
could work with people on a list like this. Is that not the idea?
This seems to be impossible from my perspective. No matter what you
provide, it is always met with "we cannot comment on that at this time
because ...." or "no". It is frustrating, Martin.
<SNIP>
> As always, remember that we're all volunteers here, and we all have
> to scrounge for the time we apply to Struts. Also, we have an
> enormous installed base, and we have to take their needs into
> account. If the general open source community has come to expect
> compatibility between minor version releases, and if we've always
> struck a firm stance towards providing that kind of compatibility in
> Struts, then we need to maintain consistency.
</SNIP>
I think we all know that. I really do. Somehow there is this idea
that this basic requirement escapes people. But, I don't think it
does.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hubert Rabago wrote:
> Joe most recently mention this sometime last month:
> http://marc.theaimsgroup.com/?l=struts-dev&m=110842402707799&w=2
Yep, I was involved in that thread :) The one thing I will say is that
the whole discussion of "view controllers" and "page prep" is really
different than what I implemented. It is similar without question, but
not the same. In fact, and I say this without ego (which is a rare
thing, I will admit! :) ), I think there is a certain uniqueness to what
I did that is at the very least interesting.
> Aside from this, an email I sent to you (well, on the user list, but
> on the thread where you mentioned this) also linked to a couple of
> threads discussing this feature. That mentioned a few alternatives,
> including one from me. I even noted that the message was almost a
> year old. :)
> http://marc.theaimsgroup.com/?l=struts-user&m=111029587900454&w=2
I didn't read that one until now. Interesting! However, I would make
the same comment... what I did is, while similar, still different.
The difference by the way is the generic nature of my solution... it
doesn't really say much of anything except "for any action mapping
and/or forward, you can execute any number of arbitrary methods of
arbitrary classes". It doesn't push you towards a page-centric
approach, it doesn't force class structures on you, it doesn't tie forms
to forwards or this to that or anything like that. It's very open-ended.
There may be an argument to be made that it's *TOO* generic and open and
therefore open to serious abuse. I could see someone making that argument.
> The 1.3 support includes a change to the config DTD. A 1.2 friendly
> change could look something like:
>
> <forward name="success" path="/page.jsp"
> className="package.SpecificSetupActionForward"/>
>
>
> package.SpecificSetupActionForward would either extend a
> SetupActionForward, or implement a SetupActionForward. In either
> case, a setupView() method would be implemented/overridden.
This is one of the things I was seeking to avoid with my
implementation... I didn't want the classes to be anything other than
POJOs. I didn't want to limit the developer to a single setup method
per class. I also wanted to allow for any number of these calls per
forward. Certainly it can be debated whether that is too much power,
but those were my goals. This suggestion wouldn't accomplish those goals.
> The action's return could look like:
>
> return ViewSetupUtil.setupForward("success", mapping, request);
>
>
> ViewSetupUtil.setupForward() would call findForward("success"), check
> if it's an instanceof SetupActionForward, then call the setupView()
> method and pass the request. Depending on what the setup entails, a
> user may want to break it down into separate statements in the action
> so he can check conditions and alternatively return a different
> forward altogether.
But this intrinsically ties this to a forward, and it also entails more
code in an Action. I'd prefer a purely declarative answer. I also
think we should be able to do this at the action mapping level as well
as the forward level. Also, would this work for global forwards? My
implementation does.
> If you want POJO support, you can do something like:
>
> <forward name="success" path="/page.jsp"
> className="package.SetupActionForward">
> <set-property property="setupClass" value="package.MyForwardSetup"/>
> <set-property property="method" value="setupMethod1"/>
> </forward>
I personally wouldn't like this as I think set-property is too easy to
abuse (and might be already). For instance, one can do:
<record>
<fieldName>FirstName</fieldName>
<fieldValue>Frank</fieldValue>
<fieldName>LastName</fieldName>
<fieldValue>Zammetti</fieldValue>
</record>
Perfectly valid of course, but not as good, in my mind at least, as:
<record>
<firstName>Frank</firstName>
<lastName>Zammetti</lastName>
</record>
Aside from being shorter, which is good for numerous reasons, the second
to me is just a tad clearer in meaning. Not a huge difference I admit,
but a bit. I view set-property like the first example.
> In this case, SetupActionForward would instantiate the named class and
> call the method and pass parameters. Either way, it'd work even
> without any changes to Struts core. :)
Agreed, could work without changes to the core. But I think it makes a
worse compromise: it requires changes on the part of the application
developer. Again, purely declarative was one of my goals.
> There are other variations that can be made, of course.
I very much want to discuss them! However, in my mind, any solution
must meet the following criteria:
(1) Must be purely declarative
(2) Must NOT require changes to existing applications
(3) Must work at the action mapping and forward level (both local and
global)
(4) As per everyone else' opinion, must NOT change any Struts classes
(5) As far as I'm concerned, must use POJOs and must allow for an
arbitrary number of method calls in any number of classes per
mapping/forward
My implementation deals with all but #4. Unfortunately, that's the one
point that is killing it being accepted I think :)
> As far as sharing this to other people, I've done something similar
> with http://www.rabago.net/struts/redirect/. That one even involved a
> custom request processor and the use of a base action. And yes,
> people actually use it. :) Of course, sometimes I also just point
> them to an attachment I made to Bug 866.
That's actually quite cool! :)
> Hubert
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Posted by Hubert Rabago <hr...@gmail.com>.
Hi Frank,
I've been participating in discussions about the feature you proposed
since last year, and I've been looking to participate in its inclusion
into Struts.
> As you said, there did seem to be a lot of support for an idea along the
> lines of what I did, so it seemed like something that should have
> garnered more discussion and perhaps alternative proposals.
Joe most recently mention this sometime last month:
http://marc.theaimsgroup.com/?l=struts-dev&m=110842402707799&w=2
Aside from this, an email I sent to you (well, on the user list, but
on the thread where you mentioned this) also linked to a couple of
threads discussing this feature. That mentioned a few alternatives,
including one from me. I even noted that the message was almost a
year old. :)
http://marc.theaimsgroup.com/?l=struts-user&m=111029587900454&w=2
> I am still very much interested in putting the time in, and I would be
> more than happy to explore alternative ways of doing what I proposed. I
> am open to suggestion!! To be honest, I haven't thought much about ways
> this might be done as an "extension" to Struts... I'm not sure I see a
> good way that would result in the same functionality in the same way
> (which I believe to be a good approach, and many would seem to agree).
> I am listening though! :)
The 1.3 support includes a change to the config DTD. A 1.2 friendly
change could look something like:
<forward name="success" path="/page.jsp"
className="package.SpecificSetupActionForward"/>
package.SpecificSetupActionForward would either extend a
SetupActionForward, or implement a SetupActionForward. In either
case, a setupView() method would be implemented/overridden.
The action's return could look like:
return ViewSetupUtil.setupForward("success", mapping, request);
ViewSetupUtil.setupForward() would call findForward("success"), check
if it's an instanceof SetupActionForward, then call the setupView()
method and pass the request. Depending on what the setup entails, a
user may want to break it down into separate statements in the action
so he can check conditions and alternatively return a different
forward altogether.
If you want POJO support, you can do something like:
<forward name="success" path="/page.jsp"
className="package.SetupActionForward">
<set-property property="setupClass" value="package.MyForwardSetup"/>
<set-property property="method" value="setupMethod1"/>
</forward>
In this case, SetupActionForward would instantiate the named class and
call the method and pass parameters. Either way, it'd work even
without any changes to Struts core. :)
There are other variations that can be made, of course.
As far as sharing this to other people, I've done something similar
with http://www.rabago.net/struts/redirect/. That one even involved a
custom request processor and the use of a base action. And yes,
people actually use it. :) Of course, sometimes I also just point
them to an attachment I made to Bug 866.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki]
Updated: StrutsUpload)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hi Joe,
I'm not burnt out at this point, and I wouldn't even say bitter. I may
have been initially, I am human and so react with emotion, same as
anyone. A more objective review of the situation in the intervening
time though has lead me to a place where I am a bit frustrated by my
inability to not achieve the results I hoped for, but I'm not bitter or
angry.
As you said, there did seem to be a lot of support for an idea along the
lines of what I did, so it seemed like something that should have
garnered more discussion and perhaps alternative proposals. That didn't
happen though, and while the reasons may have been perfectly valid, it
is still frustrating to an "outsider", as Jack put it :)
I am still very much interested in putting the time in, and I would be
more than happy to explore alternative ways of doing what I proposed. I
am open to suggestion!! To be honest, I haven't thought much about ways
this might be done as an "extension" to Struts... I'm not sure I see a
good way that would result in the same functionality in the same way
(which I believe to be a good approach, and many would seem to agree).
I am listening though! :)
However, I am not right now willing to put in time on something to
demonstrate an idea or something that *might" be accepted. If we can
all come to some concensus on how to proceed (that I agree with) then I
would absolutely love to do the work. I am not willing to waste my time
though, as I'm sure no one is.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Joe Germuska wrote:
> At 8:29 AM -0800 3/11/05, Dakota Jack wrote:
>
>> Thanks, Frank. I posted this code in response to Ted's suggestion
>> that this is the way to go to establish a dialogue with the committers
>> on code.
>
>
> I would totally endorse Ted's suggestion. The best approach is to
> publicly document approaches and, where possible, provide extension code
> that can be exercised without rushing a change to the Struts core. This
> is how struts-chain was developed and verified as a reasonable approach
> before the core was changed. It also happens to be how validator and
> tiles evolved. In a much more modest fashion, this was the origin of
> the DigestingPlugIn, which I developed and published and which was
> adopted into Struts all before I was a committer.
>
> I feel bad seeing Frank's obvious bitter feelings, and as I noted
> elsewhere, I'm sorry I wasn't following the thread closely enough to
> warn that his efforts were pushing in a direction that Struts doesn't
> follow. In fact, I know of no open source project which would add
> incompatible features to an older release, except in the case of a major
> version number change.
>
> I don't think we've earned "Struts 2.0" with the other changes we have,
> although until we do a release, we could certainly debate calling the
> chain based processor Struts 2.0 and making room for Frank's changes in
> what would then be a live development version on the 1.x branch.
>
> As always, remember that we're all volunteers here, and we all have to
> scrounge for the time we apply to Struts. Also, we have an enormous
> installed base, and we have to take their needs into account. If the
> general open source community has come to expect compatibility between
> minor version releases, and if we've always struck a firm stance towards
> providing that kind of compatibility in Struts, then we need to maintain
> consistency.
>
> Frank, have you exhausted any hope of packaging your changes as
> something which can be added on to Struts 1.2 without requiring changes
> to the core classes? It may seem cumbersome, but I have a feeling that
> it would be possible to package your changes as extensions instead of
> core changes or a forked Struts distribution. Where Struts falls short
> in this regard, I would be interested in helping design and implement
> changes to both 1.2 and 1.3 to improve its extensibility.
>
> If Frank is burned out, but there's as much interest as there seemed to
> be on the list, perhaps some of those people would be willing to carry
> the baton to the next stage.
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org