date:20060320

That all sounds good Ted, thanks for writing this!  Just to be clear, 
*anyone* can write such a proposal and call for a vote, it doesn't have 
to be a committer or PMC member, correct?  I understand only those 
people can cast binding votes (which would be ironic: the proposal 
writer couldn't cast a binding vote for their own proposal!), but anyone 
can make such a proposal, correct?  If that is so, would it make sense 
to announce it on the @user list as well, so that as many non-binding 
votes could be cast as there is interest?


Thanks again Ted, assuming anyone can make such a proposal, I think this 
is an excellent post and I for one very much appreciate it!


Frank

Ted Husted wrote:

In the midst of a recent mosh-pit thread,  someone asked What can I
do to change the direction of the Apache Struts project?

The answer would be to summarize the concerns raised in the thread and
create a coherent proposal that lays out another course. (An obvious
place to do that would be the Apache Struts wiki.) When ready, call
for a vote on dev@ as to the proposal.

That's how directions like Shale and WebWork/Action2 were set, and if
anyone wanted to change these directions, simply follow the same
protocol.

Now, I should note that the binding votes on the Shale subproject and
WebWork/Action2 proposals were unanimous, with no dissents or waffling
by PMC members. To succeed, a proposal for an alternative direction
would need to be compelling.

Of course, if  someone felt the Apache Struts PMC was being
unreasonable, intransient, and insular, or has otherwise become a
roadblock to innovation, then someone could appeal to the ASF Board of
Directors. The PMC serves at the pleasure of the board, and the board
can retire or reconstitute the PMC as it sees fit. For more about how
the ASF works, see

* http://apache.org/foundation/how-it-works.html

Though, right now, the method behind our madness goes something like this:

* Both the ASF and Apache Struts are standard-bearers, and, like it or
not, JSF is a designated Java standard. Given volunteers, we believe
that it is appropriate that Apache Struts provide JSF developers with
a MVC framework to fill in the gaps left by JSR 127, just like Struts
Action fills in the gaps left by the servlet platform

* The original Struts Action codebase suffers from design deficiencies
that would take some effort to remedy. Since neither the ASF nor
Apache Struts advocates Not Invented Here Syndrome, we chose to
adopt WebWork as Struts Action 2 -- much the same way that tens of
thousands of teams adopted Struts Action over a homebrew framework.

* Struts Action 1 has a significant installed base, and so long as
there are volunteers to do the work, the codebase will remain open for
improvement, in the Apache Way.

It's no coincidence that these three bullets represent the three
options every Java engineer faces today:

* Do we try JSF?

* Do we try a second-generation framework?

* Do we stay the course?

Since we are working engineers, with day jobs at which we write real
applications, we are providing our own alternative to each option.

Is that good marketing? I really don't know. I didn't come here for
the marketing, I came here for the engineering. The marketing I'll
leave to the likes of IBM, Microsoft, Sun, and Zend.

-Ted.

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






--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

DO NOT REPLY [Bug 38560] - [shale] include local copies of dtds

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38560





--- Additional Comments From [EMAIL PROTECTED]  2006-03-20 15:46 ---
I am not experiencing this problem anymore.  I think this ticket can be closed.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

On 3/19/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

 Craig McClanahan wrote:
  I can certainly buy into release consolidation along these four
 paths.  That
  being said, separating the source artifacts (and the binary jar files
 that
  result from them) is still useful in terms of clearly articulating
  dependencies *within* a particular release.  That becomes much more
  important as we offer finer grained jar files that are optional but
 impose
  their own external dependencies.

 Certainly correct me if I'm wrong, but wouldn't this proposal more or
 less do away with the idea of offering finer grained jar files?  Except
 for Tiles, which I know is being spun off on its own (I presume so the
 same code base can support Struts, Shale and anything else?), are any of
 the other dwarfs in the same kind of boat as Tiles?  It sounds from
 this proposal like they may not be?...


For Shale, at least, I would *not* advocate eliminating separate JAR files.
There are optional features of Shale that themselves have their own
dependencies, and it would be a burden on all Shale users if everything was
combined into one JAR file.  As Ted mentioned earlier in some thread, this
is a lesson that we in the Struts community can learn from what Spring is
doing.

Two use cases in the Shale world:

* Shale Remoting -- a completely standalone JAR file that does not depend on
  anything else in Shale, but is useful for component authors and app
developers
  doing AJAX style development.  40k and zero dependencies, versus 140k
  (for shale-core.jar) and a bunch of dependencies.

* Tiger Extensions -- optional layer on top of Shale that utilizes JDK
1.5annotations
  to reduce or eliminate configuration files.  Including this stuff in a
core Shale
  JAR file would require *all* users to be based on JDK 1.5.

In the Struts 1.x world, the same kind of argument applies to
struts-el.jar(only needed if you are on a  JSP
2.0 platform) and struts-faces.jar (only needed if you are using JSF
components in a Struts based application).

Craig

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Wendy Smoak

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

 Certainly correct me if I'm wrong, but wouldn't this proposal more or
 less do away with the idea of offering finer grained jar files?

I think the separate jars are still a good idea, so that developers
can choose what they want to include in their applications.  A recent
thread on the WebWork user forum brought up a similar issue, and it
sounds like WW is also going to be offering separate jars in addition
to the single one with everything.  Since the sub-projects are already
separated, there's nothing to be gained from re-consolidating the
code.

Back to Don's original question, I don't think this change would be
too difficult.  The build doesn't know about the 'trunk' directories
and if we were to just 'svn mv' it, should work as-is under 'action'
the same as it now works under 'current'.

Then we would just need to find something to make what in m2 terms is
an 'assembly,' to contain whatever we're going to include in the
release.  It looks lke the next version of the m1 distribution plugin
has 'dist:multiproject'.
 * http://maven.apache.org/maven-1.x/plugins/dist/goals.html

It could also be done in maven.xml, but using a plugin would be
better.  Along the way it would be nice to make a few changes, such as
dropping the svn:external 'build' directory and nudging things into a
more consistent structure.

I'm in favor of the proposal, but I probably won't be able to work on
it for a while.  I'll help, though, if someone else wants to get
started.  It might be a good idea to try it in the test repo
(https://svn.apache.org/repos/test/) first.

--
Wendy

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

Re: [OT] What can I do?

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

 That all sounds good Ted, thanks for writing this!  Just to be clear,
 *anyone* can write such a proposal and call for a vote, it doesn't have
 to be a committer or PMC member, correct?  I understand only those
 people can cast binding votes (which would be ironic: the proposal
 writer couldn't cast a binding vote for their own proposal!), but anyone
 can make such a proposal, correct?  If that is so, would it make sense
 to announce it on the @user list as well, so that as many non-binding
 votes could be cast as there is interest?


It is correct that anyone can make such a proposal.  It is also correct to
recognize that existing committers represent the only binding votes on
technical matters like what should Struts 2.x look like -- PMC-member
votes are required only fo releases.  That means, at the moment, that you
have 22 people to lobby.

Feel free to announce whatever you want wherever you want.  Any formal vote,
however, would be called on the Struts Developer list (and must be called by
an existing committer to be relevant, so you'd better plan on recruiting at
least one committer to make the formal proposal in the first place).


Thanks again Ted, assuming anyone can make such a proposal, I think this
 is an excellent post and I for one very much appreciate it!

 Frank


Craig

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

Thanks Wendy, that's what I needed to hear. So far, I haven't heard any -1 type objections, so I'll take your advice
and try the reorg on that other svn site.

When I have it working correctly, I suppose I'll call for the vote. This would be a significant change, and honestly, I
thought there'd be a lot more resistance :) Not that I'm complaining

Don

Wendy Smoak wrote:

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

Certainly correct me if I'm wrong, but wouldn't this proposal more or
less do away with the idea of offering finer grained jar files?

I think the separate jars are still a good idea, so that developers
can choose what they want to include in their applications. A recent
thread on the WebWork user forum brought up a similar issue, and it
sounds like WW is also going to be offering separate jars in addition
to the single one with everything. Since the sub-projects are already
separated, there's nothing to be gained from re-consolidating the
code.

Back to Don's original question, I don't think this change would be
too difficult. The build doesn't know about the 'trunk' directories
and if we were to just 'svn mv' it, should work as-is under 'action'
the same as it now works under 'current'.

Then we would just need to find something to make what in m2 terms is
an 'assembly,' to contain whatever we're going to include in the
release. It looks lke the next version of the m1 distribution plugin
has 'dist:multiproject'.
* http://maven.apache.org/maven-1.x/plugins/dist/goals.html

It could also be done in maven.xml, but using a plugin would be
better. Along the way it would be nice to make a few changes, such as
dropping the svn:external 'build' directory and nudging things into a
more consistent structure.

I'm in favor of the proposal, but I probably won't be able to work on
it for a while. I'll help, though, if someone else wants to get
started. It might be a good idea to try it in the test repo
(https://svn.apache.org/repos/test/) first.

--
Wendy

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)


Craig McClanahan wrote:

In the Struts 1.x world, the same kind of argument applies to
struts-el.jar(only needed if you are on a  JSP
2.0 platform) and struts-faces.jar (only needed if you are using JSF
components in a Struts based application).


+1

As I mentioned, I'm proposing each extension still have its own directory structure, build, and artifact, but just be 
moved up under action/trunk instead of the root.


Don



Craig




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

Re: [OT] What can I do?


Excellent, thank you Craig!

Frank

Craig McClanahan wrote:

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

That all sounds good Ted, thanks for writing this!  Just to be clear,
*anyone* can write such a proposal and call for a vote, it doesn't have
to be a committer or PMC member, correct?  I understand only those
people can cast binding votes (which would be ironic: the proposal
writer couldn't cast a binding vote for their own proposal!), but anyone
can make such a proposal, correct?  If that is so, would it make sense
to announce it on the @user list as well, so that as many non-binding
votes could be cast as there is interest?



It is correct that anyone can make such a proposal.  It is also correct to
recognize that existing committers represent the only binding votes on
technical matters like what should Struts 2.x look like -- PMC-member
votes are required only fo releases.  That means, at the moment, that you
have 22 people to lobby.

Feel free to announce whatever you want wherever you want.  Any formal vote,
however, would be called on the Struts Developer list (and must be called by
an existing committer to be relevant, so you'd better plan on recruiting at
least one committer to make the formal proposal in the first place).


Thanks again Ted, assuming anyone can make such a proposal, I think this

is an excellent post and I for one very much appreciate it!

Frank



Craig



--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

Re: [OT] What can I do?

On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:

 Ted,

 In response to your comment:

 The original Struts Action codebase suffers from design deficiencies
 that would take some effort to remedy.

 This may be true, but I don't believe that it is a completely lost cause.
 The work that I have been doing with Struts Java 5 extensions proves (to me
 at least) that it is possible to move from the existing 1.2 code base to
 something with compelling features and free from the issues often associated
 with the Struts Action 1.

 See:
 http://www.realsolve.co.uk/site/strecks/index.php

 Phil


I happened to see Phil's presentation to the JAVAWUG group in London last
Friday.  There are some interesting ideas here (and they would seem
applicable in either a 1.x or 2.x Struts Action Framework context).  I would
suggest thinking about an optional layer (requires JDK 1.5) on top of the
base framework that made available features like this ... similar in spirit
to what the Tiger Extensions do in Shale.

Craig

Re: [OT] What can I do?

Don't know if this has been mentioned, but the WebWork guys have been doing something similar: 
http://www.opensymphony.com/webwork/wikidocs/J2SE%205%20Support.html


It'd be nice if we could come up with a common set of annotations shared by both Action 1 and 2 (possibly Shale) along 
the lines of Stripes to help transitions.


Don

Craig McClanahan wrote:

On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:

Ted,

In response to your comment:

The original Struts Action codebase suffers from design deficiencies
that would take some effort to remedy.

This may be true, but I don't believe that it is a completely lost cause.
The work that I have been doing with Struts Java 5 extensions proves (to me
at least) that it is possible to move from the existing 1.2 code base to
something with compelling features and free from the issues often associated
with the Struts Action 1.

See:
http://www.realsolve.co.uk/site/strecks/index.php

Phil



I happened to see Phil's presentation to the JAVAWUG group in London last
Friday.  There are some interesting ideas here (and they would seem
applicable in either a 1.x or 2.x Struts Action Framework context).  I would
suggest thinking about an optional layer (requires JDK 1.5) on top of the
base framework that made available features like this ... similar in spirit
to what the Tiger Extensions do in Shale.

Craig




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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)


Craig McClanahan wrote:

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

You know, I was looking at the Struts front page a few minutes ago,
specifically the Extensions, which are the seven dwarfs IIRC.  The one
that sticks out for me as a problem, if that's the right word, is the
JSP Taglib.



I suspect that Struts users who abhor JSP, but like things like Velocity,
would not agree with you :-).


Hehe, probably right :)


Indeed, if you're using Struts as the server end of AJAX transactions, you
don't need this library even if you do happen to use JSP for the human user
interface portion of your application (perhaps using a different framework).

I think it's fair to say that the majority of Struts developers consider

the Struts tags to be intrinsically part of the Struts Action Framework
(SAF).  Except for me who rarely uses them! :)

The analogy I would use us the component kit you use in a JSF app...
*can* you build a JSF app with no component kit at all?



You bet you can.


Do you have any feel for how common it is though?  My guess is that it 
isn't very common, but your certainly in a better position to tell then 
I am.  It just doesn't *feel* like something I would expect to find to 
be common, just like not using the Struts taglibs probably isn't the 
most common usage pattern.



Come to think of it ... there's even a 40kb standalone jar file (
shale-remoting.jar) that does exactly this kind of thing, with no
dependencies on the UI components part of JSF, or even on the rest of Shale
:-).


Cute :-)


Craig


Frank


--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

Re: [OT] What can I do?

2006-03-20 Thread Michael Jouravlev

On 3/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
 On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:
 
  Ted,
 
  In response to your comment:
 
  The original Struts Action codebase suffers from design deficiencies
  that would take some effort to remedy.
 
  This may be true, but I don't believe that it is a completely lost cause.
  The work that I have been doing with Struts Java 5 extensions proves (to me
  at least) that it is possible to move from the existing 1.2 code base to
  something with compelling features and free from the issues often associated
  with the Struts Action 1.
 
  See:
  http://www.realsolve.co.uk/site/strecks/index.php
 
  Phil


 I happened to see Phil's presentation to the JAVAWUG group in London last
 Friday.  There are some interesting ideas here (and they would seem
 applicable in either a 1.x or 2.x Struts Action Framework context).  I would
 suggest thinking about an optional layer (requires JDK 1.5) on top of the
 base framework that made available features like this ... similar in spirit
 to what the Tiger Extensions do in Shale.

 Craig

It this case it might be easier to switch to a framework that was
built with Java 5 from ground up:
http://mc4j.org/confluence/display/stripes/Home

Michael.

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

Re: [OT] What can I do?

2006-03-20 Thread Ted Husted

Is Strecks open to the public, now?

There was the advance notice on dev@, but has there been an
announcemen to user@ yet?

-Ted.

On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:
 Ted,

 In response to your comment:

 The original Struts Action codebase suffers from design deficiencies
 that would take some effort to remedy.

 This may be true, but I don't believe that it is a completely lost cause. The 
 work that I have been doing with Struts Java 5 extensions proves (to me at 
 least) that it is possible to move from the existing 1.2 code base to 
 something with compelling features and free from the issues often associated 
 with the Struts Action 1.

 See:
 http://www.realsolve.co.uk/site/strecks/index.php

 Phil

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

 Craig McClanahan wrote:
  On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
  You know, I was looking at the Struts front page a few minutes ago,
  specifically the Extensions, which are the seven dwarfs IIRC.  The
 one
  that sticks out for me as a problem, if that's the right word, is the
  JSP Taglib.
 
 
  I suspect that Struts users who abhor JSP, but like things like
 Velocity,
  would not agree with you :-).

 Hehe, probably right :)

  Indeed, if you're using Struts as the server end of AJAX transactions,
 you
  don't need this library even if you do happen to use JSP for the human
 user
  interface portion of your application (perhaps using a different
 framework).
 
  I think it's fair to say that the majority of Struts developers consider
  the Struts tags to be intrinsically part of the Struts Action Framework
  (SAF).  Except for me who rarely uses them! :)
 
  The analogy I would use us the component kit you use in a JSF app...
  *can* you build a JSF app with no component kit at all?
 
 
  You bet you can.

 Do you have any feel for how common it is though?  My guess is that it
 isn't very common, but your certainly in a better position to tell then
 I am.  It just doesn't *feel* like something I would expect to find to
 be common, just like not using the Struts taglibs probably isn't the
 most common usage pattern.


Common now?  Probably ot very ... especially if you point someone at the
current website documentaton for this feature[1]  :-).  You need to peruse
the Javadocs, and ask questions on the list, to get very far right at the
moment.  And, most people who evaluate JSF never seem to look at the
underlying infrastructure ... they get obsessed with the components and
either like or dislike it on that basis.

Common in the future?  That's the plan ... it's especially designed for
folks who want to create the server side of AJAX interactions, plus people
who want to write AJAX-enabled components.  The power of expression
evaluation, plus the basic dependency injection capabilities of managed
beans, are just too much goodness to pass up.  JSF's fundamental front
controller architecture is plenty of power for this sort of use case.  With
Shale Remoting, you can plug in (out of the box) a call to any arbitrary
method (it maps based on the request URL), or to any Commons Chain command
or chain implementation.  Adding support to map to an XWork (the underlying
framework that WebWork is based on) interceptor chain is on my list of
things to add, but it's going to be really easy.  Also, something to think
about for the future ... in JSF 1.2 and JSP 2.1, the expression language
APIs and implementation got factored into their own spec document, which
*might* ultimately be a candidate for inclusion in the JDK.  It turns out
that a common expression evaluation library is pretty handy in simplifying
quite a few use cases.  For example, anything that Commons BeanUtils can do
is *much* more elegantly handled with EL expressions and a few appropriate
complementary classes (like converters).

We (Sun) are using this library in the next version of the demo AJAX
components that you can get with Java Studio Creator 2 [2].  Doing so cut
the number of lines of code per component down dramatically (besides the
fact that the original approach didn't take advantage of browser caching,
required you to use /faces/* mapping, yadda yadda).  More importantly, it
got rid of the approach that was used in the initial prototyping of these
components (a separate PhaseListener per component for serving up static
resources and responding to AJAX requests), which is not a particularly
scalable design :-).

 Come to think of it ... there's even a 40kb standalone jar file (
  shale-remoting.jar) that does exactly this kind of thing, with no
  dependencies on the UI components part of JSF, or even on the rest of
 Shale
  :-).

 Cute :-)

  Craig

 Frank


Craig

[1] http://struts.apache.org/struts-shale/features-remoting.html
[2] http://developers.sun.com/jscreator/

Applying Annotations to Struts (Re: [OT] What can I do?)

2006-03-20 Thread Joe Germuska


At 9:15 AM -0800 3/20/06, Craig McClanahan wrote:

On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:


 Ted,

 In response to your comment:

 The original Struts Action codebase suffers from design deficiencies
 that would take some effort to remedy.

 This may be true, but I don't believe that it is a completely lost cause.
 The work that I have been doing with Struts Java 5 extensions proves (to me
 at least) that it is possible to move from the existing 1.2 code base to
 something with compelling features and free from the issues often associated
 with the Struts Action 1.

 See:

  http://www.realsolve.co.uk/site/strecks/index.php


 Phil



I happened to see Phil's presentation to the JAVAWUG group in London last
Friday.  There are some interesting ideas here (and they would seem
applicable in either a 1.x or 2.x Struts Action Framework context).  I would
suggest thinking about an optional layer (requires JDK 1.5) on top of the
base framework that made available features like this ... similar in spirit
to what the Tiger Extensions do in Shale.


I haven't had a chance to look at Phil's work yet, but would just 
point out that it's possible to use annotations without requiring 
Java 5.  That may not be an itch Phil wants to scratch, but worth 
keeping in mind unless there are other aspects which also require 
Java 5.  I know my sysadmin has pretty much guaranteed that we are a 
year or more away from moving our hosted systems to Java 5, and I 
doubt he's the most conservative one out there.  (well...  maybe :) 
naah.)


Spring, at least, supports Annotations in pre-Java-5, so there is an 
example that could be mined.  I don't know how much extra effort it 
takes, but I thought I'd throw it out there...


Joe

--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new.
-- Robert Moog

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

Re: [OT] What can I do?

2006-03-20 Thread Phil Zoio

It will be very shortly. I am waiting for the project approval to go 
through on java.net, which will hopefully be pretty quick. I'll make an 
announcement then.


I haven't made any announcements on the user mailing list. I'll do so 
when I've got the source (and a binary) ready on Java.net.


Phil

Ted Husted wrote:


Is Strecks open to the public, now?

There was the advance notice on dev@, but has there been an
announcemen to user@ yet?

-Ted.

On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:
 


Ted,

In response to your comment:

The original Struts Action codebase suffers from design deficiencies
that would take some effort to remedy.

This may be true, but I don't believe that it is a completely lost cause. The 
work that I have been doing with Struts Java 5 extensions proves (to me at 
least) that it is possible to move from the existing 1.2 code base to something 
with compelling features and free from the issues often associated with the 
Struts Action 1.

See:
http://www.realsolve.co.uk/site/strecks/index.php

Phil
   



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

Re: [OT] What can I do?

2006-03-20 Thread Phil Zoio



I'll definitely take a look at this - should be possible to have 
consistency with the annotations as long as they are covering the same 
use cases.


Phil



Don Brown wrote:

Don't know if this has been mentioned, but the WebWork guys have been 
doing something similar: 
http://www.opensymphony.com/webwork/wikidocs/J2SE%205%20Support.html


It'd be nice if we could come up with a common set of annotations 
shared by both Action 1 and 2 (possibly Shale) along the lines of 
Stripes to help transitions.


Don

Craig McClanahan wrote:


On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:


Ted,

In response to your comment:

The original Struts Action codebase suffers from design deficiencies
that would take some effort to remedy.

This may be true, but I don't believe that it is a completely lost 
cause.
The work that I have been doing with Struts Java 5 extensions proves 
(to me
at least) that it is possible to move from the existing 1.2 code 
base to
something with compelling features and free from the issues often 
associated

with the Struts Action 1.

See:
http://www.realsolve.co.uk/site/strecks/index.php

Phil




I happened to see Phil's presentation to the JAVAWUG group in London 
last

Friday.  There are some interesting ideas here (and they would seem
applicable in either a 1.x or 2.x Struts Action Framework context).  
I would
suggest thinking about an optional layer (requires JDK 1.5) on top of 
the
base framework that made available features like this ... similar in 
spirit

to what the Tiger Extensions do in Shale.

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: Applying Annotations to Struts (Re: [OT] What can I do?)


Joe Germuska wrote:
I haven't had a chance to look at Phil's work yet, but would just point 
out that it's possible to use annotations without requiring Java 5.  
That may not be an itch Phil wants to scratch, but worth keeping in mind 
unless there are other aspects which also require Java 5.  I know my 
sysadmin has pretty much guaranteed that we are a year or more away from 
moving our hosted systems to Java 5, and I doubt he's the most 
conservative one out there.  (well...  maybe :) naah.)


Spring, at least, supports Annotations in pre-Java-5, so there is an 
example that could be mined.  I don't know how much extra effort it 
takes, but I thought I'd throw it out there...


Just curious Joe, are you talking about this sort of thing:

http://www.theserverside.com/news/thread.tss?thread_id=39308


Joe


Frank


--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Nathan Bubna

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
 Craig McClanahan wrote:
  For Shale, at least, I would *not* advocate eliminating separate JAR files.
  There are optional features of Shale that themselves have their own
  dependencies, and it would be a burden on all Shale users if everything was
  combined into one JAR file.  As Ted mentioned earlier in some thread, this
  is a lesson that we in the Struts community can learn from what Spring is
  doing.
 
  Two use cases in the Shale world:
 
  * Shale Remoting -- a completely standalone JAR file that does not depend on
anything else in Shale, but is useful for component authors and app
  developers
doing AJAX style development.  40k and zero dependencies, versus 140k
(for shale-core.jar) and a bunch of dependencies.
 
  * Tiger Extensions -- optional layer on top of Shale that utilizes JDK
  1.5annotations
to reduce or eliminate configuration files.  Including this stuff in a
  core Shale
JAR file would require *all* users to be based on JDK 1.5.
 
  In the Struts 1.x world, the same kind of argument applies to
  struts-el.jar(only needed if you are on a  JSP
  2.0 platform) and struts-faces.jar (only needed if you are using JSF
  components in a Struts based application).

 That all makes perfect sense, thanks Craig.

 You know, I was looking at the Struts front page a few minutes ago,
 specifically the Extensions, which are the seven dwarfs IIRC.  The one
 that sticks out for me as a problem, if that's the right word, is the
 JSP Taglib.

there have been VelocityStruts users eager for the Struts tags to be
separated from the core for a long time.  there's plenty of people
using Struts without the tags.

 I think it's fair to say that the majority of Struts developers consider
 the Struts tags to be intrinsically part of the Struts Action Framework
 (SAF).  Except for me who rarely uses them! :)

 The analogy I would use us the component kit you use in a JSF app...
 *can* you build a JSF app with no component kit at all?  I would guess
 yes... but how many people *would* ever do that?  I would guess very
 few. I think the same is true of the Struts tags.

 I think everything else, Tiles, Flow, EL, etc., really do seem to me to
 be true extensions, and as such it makes sense for them to develop on
 their own, be packaged on their own, and be downloaded separately as
 needed.  My only concern there is simply to document well what
 version(s) of a given extension can be used with a given version of SAF.
   I think this information should always be front and center and easy to
 find quickly.

 But, the JSP Taglib, that one I think really does make more sense to go
 along with the core itself.  I'm not saying it can't be its own JAR...
 that's just a matter of the final build artifact.  I'd probably opt to
 include it in the Struts JAR, but that's really a minor point IMO.  What
 is more important is that I think the taglib should share the same
 version number, release cycle, etc., as the core, and in fact should
 just simply BE part of the core.

 I guess I'm saying I would propose amending Don's proposal to only apply
 to the Struts taglibs :)

  Craig

 Frank

 --
 Frank W. Zammetti
 Founder and Chief Software Architect
 Omnytex Technologies
 http://www.omnytex.com
 AIM: fzammetti
 Yahoo: fzammetti
 MSN: [EMAIL PROTECTED]
 Java Web Parts -
 http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

 -
 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: Applying Annotations to Struts (Re: [OT] What can I do?)

2006-03-20 Thread Phil Zoio



From a workload point of view it wouldn't have made sense for me to go 
down the Java 1.4 annotations route to begin with. What would now make 
it quite difficult to do ex-post is because other Java 5 features are 
used in lots of places (e.g. lots of for ... loops), generics, etc - I 
pretty much accepted the Java 5 limitation from the beginning.


Phil


Joe Germuska wrote:


At 9:15 AM -0800 3/20/06, Craig McClanahan wrote:


On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:



 Ted,

 In response to your comment:

 The original Struts Action codebase suffers from design deficiencies
 that would take some effort to remedy.

 This may be true, but I don't believe that it is a completely lost 
cause.
 The work that I have been doing with Struts Java 5 extensions 
proves (to me
 at least) that it is possible to move from the existing 1.2 code 
base to
 something with compelling features and free from the issues often 
associated

 with the Struts Action 1.

 See:


  http://www.realsolve.co.uk/site/strecks/index.php



 Phil




I happened to see Phil's presentation to the JAVAWUG group in London 
last

Friday.  There are some interesting ideas here (and they would seem
applicable in either a 1.x or 2.x Struts Action Framework context).  
I would
suggest thinking about an optional layer (requires JDK 1.5) on top of 
the
base framework that made available features like this ... similar in 
spirit

to what the Tiger Extensions do in Shale.



I haven't had a chance to look at Phil's work yet, but would just 
point out that it's possible to use annotations without requiring Java 
5.  That may not be an itch Phil wants to scratch, but worth keeping 
in mind unless there are other aspects which also require Java 5.  I 
know my sysadmin has pretty much guaranteed that we are a year or more 
away from moving our hosted systems to Java 5, and I doubt he's the 
most conservative one out there.  (well...  maybe :) naah.)


Spring, at least, supports Annotations in pre-Java-5, so there is an 
example that could be mined.  I don't know how much extra effort it 
takes, but I thought I'd throw it out there...


Joe



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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)


Craig McClanahan wrote:

Common in the future?  That's the plan ... it's especially designed for
folks who want to create the server side of AJAX interactions, plus people
who want to write AJAX-enabled components.  The power of expression
evaluation, plus the basic dependency injection capabilities of managed
beans, are just too much goodness to pass up.  


Obviously going OT for this thread, so I'd be happy to start a new one 
if you want, but this is very interesting to me as a pretty big AJAX 
booster..


Have you ever looked at DWR?  I wonder what your impression is of that? 
 Especially since it has Spring integration, which I'm sure you would 
agree if better dependency injection than the basic capabilities JSF 
provides, and since it works with *any* framework, and allows you to 
access POJOs, I would personally favor that than start using a whole new 
framework.  What benefits would you say there are to using Shale/JSF 
than that with any other framework over a DWR-based solution?  Certainly 
you can fire off a chain in any case if that's your need, so I don't see 
that as being one.  Again, just curious here as an AJAX guy.


I guess what I'm *really* getting at is to ask doesn't AJAX make much of 
this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat 
irrelevant?  Might it even be better to just develop the Shale remoting 
as a separate AJAX library?


Not trying to pick fight :-)


Craig


Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)


Nathan Bubna wrote:

there have been VelocityStruts users eager for the Struts tags to be
separated from the core for a long time.  there's plenty of people
using Struts without the tags.


I didn't know that, thanks for pointing it out.  Do the tags being there 
hinder those users in any way though?  Assuming not, and assuming my 
belief that more Struts developers *DO* use the tags than don't (which 
may not be true!) then I'm not sure it matters, and I would still 
suggest the tags should be part of the core.


Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

DO NOT REPLY [Bug 39040] New: - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39040.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040

   Summary: Refactor Struts initialization to ServletContextListener
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Action
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Opening an enhancement ticket in order to generate some discussion and possibly
give a volunteer an idea for a project :-)

As part of migrating to Action 2, I thought that it might be a good idea to try
to have Struts configured by a ServletContextListener instead of concentrating
that initialization in the servlet.  The main idea would be that this would
steer any compatibility solution towards dispatching requests using a single
mechanism (presumably a future version of WebWork's FilterDispatcher) which
could set up a better framework for sharing and blending than simply leaving a
Struts 1.x ActionServlet in your config until you've factored out all of your
actions.

There would be a lot of tasks to this, but it seems that the first would be
simply factoring the initialization code out of ActionServlet in the Struts 1.x
line so that its basic functionality can be verified in the field.  

Comments?  Volunteers?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:

 Craig McClanahan wrote:
  Common in the future?  That's the plan ... it's especially designed for
  folks who want to create the server side of AJAX interactions, plus
 people
  who want to write AJAX-enabled components.  The power of expression
  evaluation, plus the basic dependency injection capabilities of
 managed
  beans, are just too much goodness to pass up.

 Obviously going OT for this thread, so I'd be happy to start a new one
 if you want, but this is very interesting to me as a pretty big AJAX
 booster..

 Have you ever looked at DWR?  I wonder what your impression is of that?
   Especially since it has Spring integration, which I'm sure you would
 agree if better dependency injection than the basic capabilities JSF
 provides, and since it works with *any* framework, and allows you to
 access POJOs, I would personally favor that than start using a whole new
 framework.  What benefits would you say there are to using Shale/JSF
 than that with any other framework over a DWR-based solution?  Certainly
 you can fire off a chain in any case if that's your need, so I don't see
 that as being one.  Again, just curious here as an AJAX guy.


I've looked at DWR some, but the guys here that did the initial research on
AJAX frameworks liked DOJO better.  Doesn't mean DWR is in any way bad,
mind you ... just that we chose differently.


I guess what I'm *really* getting at is to ask doesn't AJAX make much of
 this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat
 irrelevant?  Might it even be better to just develop the Shale remoting
 as a separate AJAX library?

 Not trying to pick fight :-)


Not swinging back either :-).

At a 30,000 foot level, there are three basic architectures for usng AJAX
(and yes, they overlap a bunch too):

* Eye Candy -- add a little bit of asynch interactivity to an existing
application,
  often done by utilizing existing JavaScript event handlers on the relevant
  HTML tags directly (perhaps with the help of a client side JS library,
  perhaps with just hand coded cut-n-paste JS that you saw on some website).

* Server Side UI -- the UI of an app fundamentally based on widgets
  with asynchronous callbacks, but it's still rendered on the server side
  as is typical of webapps today ... except that the JavaScript/DHTML
  madness is encapsulated in some sort of API (custom tags, JSF components,
  PHP objects, whatever) that hides the complexity from the developer.

* Client Side Controller -- the app itself moves to the client side, and
  asynch callbacks are strictly for exchanging model tier data.

JSF UI components (as well as the framework) work great for the first two
cases.  The UI components are of less use in the third case (although in an
ideal scenario the client side widgets you encapsulated with JSF components
for the first two cases is the same code you use directly for the third
case), but the framework part is still fully capable of doing what you need
to map incoming requests to particular business logic, and helping you
format the response.  Shale Remoting is still very useful in the third case
(as well as being a nice utility library for those building JSF components
to handle the first two cases).

By the way, I agree with you that Spring's dependency injection is more
powerful than that provided by JSF managed beans.  Wouldn't it be cool if
you could use both Spring and JSF together, but configure your JSF managed
beans in Spring just like you do your business logic beans?

Oh yah ... that's already possible :-).  Spring includes integration with
JSF's expression evaluation facilities, so you can use Spring-created beans
in your JSF value binding and method binding expressions, without the
expression user (UI component, Shale Remoting mapping of an AJAX request,
whatever) having to know that.  And that one doesn't even take Shale ...
basic support for this comes out of the box with Spring, and there's an
extension library at SourceForge if you want to get a little fancier (i.e.
put Spring-managed beans into request/session/application scope
automatically, not just create singletons and per-request instances).

 Craig

 Frank


Craig

DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39040.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





--- Additional Comments From [EMAIL PROTECTED]  2006-03-20 19:47 ---
I think this is a good idea - it may be what you intended, but I'd like to 
clarify what you suggest. IMO the refactoring should be considered in two 
parts:

1) Refactor struts initialization code out of the servlet environment 
altogether - so its not tied either to either a Servlet or 
ServletContextListener. As well as achieving the goals you envisage I would 
hope this would make it easier to test the initialization code and could be 
used as part of a test framework for testing the whole of the RequestProcessor 
command chain.

2) Provide a ServletContextListener implementation of the initialization code.

I haven't actually looked at how useful/doable 1) would be - but I think it 
would make a good starting point for consideration.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Nathan Bubna

On 3/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
 Nathan Bubna wrote:
  there have been VelocityStruts users eager for the Struts tags to be
  separated from the core for a long time.  there's plenty of people
  using Struts without the tags.

 I didn't know that, thanks for pointing it out.  Do the tags being there
 hinder those users in any way though?  Assuming not, and assuming my
 belief that more Struts developers *DO* use the tags than don't (which
 may not be true!) then I'm not sure it matters, and I would still
 suggest the tags should be part of the core.

Not directly.  But in so far as extras can hinder releases and sap
development effort from the core, they do hinder the users.  In
general, one of the reasons i liked seeing the Struts extras pulled
out of the core was the hope that bugs and slow development in such
non-essential parts of Struts would no longer be a hinderance to fresh
Struts core releases.  It's a tough trade-off though, i admit.  Either
risk dependency confusion and frustration or else risk having good
code be held back by extras that only a portion of the userbase is
interested in.  Personally, i prefer a little extra dependency
complexity (and that preference even predates the usefulness of Maven
and Ivy for such things) to the stifling of release frequency and
freedom.

 Frank

 --
 Frank W. Zammetti
 Founder and Chief Software Architect
 Omnytex Technologies
 http://www.omnytex.com
 AIM: fzammetti
 Yahoo: fzammetti
 MSN: [EMAIL PROTECTED]
 Java Web Parts -
 http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

 -
 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] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Paul Benedict

I do see benefit in having the struts-taglibs (and actions) being their
own release because there are some very minor enhancements
that don't really require a new action framework release. 
For instance, Struts 1.2.5 added the errorStyle and errorStyleClass
attributes, which probably could have been released faster
if they were separate. This is the same situation for the struts-actions
library which doesn't need a framework upgrade to add new functionality.

However, the biggest downside of separate releases, as I see it,
will be the confusion in the separate versioning of the libraries.
Someone might be asking one day, Does taglibs-1.3.11 go with 
struts-action-1.3.4 or struts-action-1.3.6? It is really going to
be difficult to eyeball which version library depends on which version
library of another. Did I get this wrong? Isn't this how the independent
libraies will be released at different schedules?

If so, an alternative would be to re-tag all libraries and release
them under one distribution version. If struts-taglibs go through
5 quick releases, that's also 5 quick releases of Struts too.

Paul

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Applying Annotations to Struts (Re: [OT] What can I do?)

2006-03-20 Thread Eddie O'Neil

  Believe it or not, Beehive (http://beehive.apache.org) has been
applying Java 5 annotations to Struts 1.1 / 1.2 for a couple of years.
 So, there's another existence proof that this is possible and can
even make things easier.  :)

  We've done this in a sub-project of Beehive called NetUI. 
Certainly, NetUI isn't perfect -- what software ever is ;) -- but it's
worth taking a look at as a source of ideas and lessons learned.  Rich
Feit (on the Beehive PMC and also a Struts committer) worked with Don
on Struts Ti, so I think that there's even an updated version of
NetUI's annotation model in the Ti sandbox.

  If you're curious, there is some relevant NetUI documentation here:

http://beehive.apache.org/docs/1.0.1/netui/pageFlowControllers.html

and a few Beehive folks that are probably interested in sharing
lessons learned and maybe even helping build annotations for Struts
1.x / 2.x.  :)

Eddie



On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:

  From a workload point of view it wouldn't have made sense for me to go
 down the Java 1.4 annotations route to begin with. What would now make
 it quite difficult to do ex-post is because other Java 5 features are
 used in lots of places (e.g. lots of for ... loops), generics, etc - I
 pretty much accepted the Java 5 limitation from the beginning.

 Phil


 Joe Germuska wrote:

  At 9:15 AM -0800 3/20/06, Craig McClanahan wrote:
 
  On 3/20/06, Phil Zoio [EMAIL PROTECTED] wrote:
 
 
   Ted,
 
   In response to your comment:
 
   The original Struts Action codebase suffers from design deficiencies
   that would take some effort to remedy.
 
   This may be true, but I don't believe that it is a completely lost
  cause.
   The work that I have been doing with Struts Java 5 extensions
  proves (to me
   at least) that it is possible to move from the existing 1.2 code
  base to
   something with compelling features and free from the issues often
  associated
   with the Struts Action 1.
 
   See:
 
http://www.realsolve.co.uk/site/strecks/index.php
 
 
   Phil
 
 
 
  I happened to see Phil's presentation to the JAVAWUG group in London
  last
  Friday.  There are some interesting ideas here (and they would seem
  applicable in either a 1.x or 2.x Struts Action Framework context).
  I would
  suggest thinking about an optional layer (requires JDK 1.5) on top of
  the
  base framework that made available features like this ... similar in
  spirit
  to what the Tiger Extensions do in Shale.
 
 
  I haven't had a chance to look at Phil's work yet, but would just
  point out that it's possible to use annotations without requiring Java
  5.  That may not be an itch Phil wants to scratch, but worth keeping
  in mind unless there are other aspects which also require Java 5.  I
  know my sysadmin has pretty much guaranteed that we are a year or more
  away from moving our hosted systems to Java 5, and I doubt he's the
  most conservative one out there.  (well...  maybe :) naah.)
 
  Spring, at least, supports Annotations in pre-Java-5, so there is an
  example that could be mined.  I don't know how much extra effort it
  takes, but I thought I'd throw it out there...
 
  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]

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Nathan Bubna

On 3/20/06, Paul Benedict [EMAIL PROTECTED] wrote:
 I do see benefit in having the struts-taglibs (and actions) being their
 own release because there are some very minor enhancements
 that don't really require a new action framework release.
 For instance, Struts 1.2.5 added the errorStyle and errorStyleClass
 attributes, which probably could have been released faster
 if they were separate. This is the same situation for the struts-actions
 library which doesn't need a framework upgrade to add new functionality.

 However, the biggest downside of separate releases, as I see it,
 will be the confusion in the separate versioning of the libraries.
 Someone might be asking one day, Does taglibs-1.3.11 go with
 struts-action-1.3.4 or struts-action-1.3.6? It is really going to
 be difficult to eyeball which version library depends on which version
 library of another. Did I get this wrong? Isn't this how the independent
 libraies will be released at different schedules?

compatibility is not that difficult to maintain in reality.

for project developers there are just 3 simple rules to follow:
- no point release (1.3.1 to 1.3.2) should ever break a working,
outward facing API
- all minor versions (1.3.x to 1.4.x) should deprecate working,
outward facing APIs before removing (release foo in 1.3.x, deprecate
in 1.4.x, and remove no sooner than 1.5.x, if at all).
- all major versions (1.x.x to 2.x.x) are free to break or change
whatever they wish.

assuming developers respect these well-established patterns, then
users worried about compatibility and dependencies and unwilling to
track all project changes, there are only three simple rules:
- point release versions that go GA are always safe to upgrade
- watch for deprecations when upgrading minor version numbers
- expect things to break with a major version upgrade

and all of that can be done without any documentation apart from the
version numbers themselves.  throw in notice of deprecations in
changelogs, and simple instructions about the latest versions
(struts-taglibs 1.6.x depends on struts-action-core 1.4.x) and what's
the big deal?

also, by separating out the various extra components, you make the
development and maintenance of entirely new components (e.g.
VelocityStruts) easier, because some former internal APIs are now
the external APIs of the core compenents.  since those are now
outward facing, compatibility and stability of the core is more
rigorously maintained.  so for those not under the Struts umbrella,
life becomes better. :)

 If so, an alternative would be to re-tag all libraries and release
 them under one distribution version. If struts-taglibs go through
 5 quick releases, that's also 5 quick releases of Struts too.

heh.  who ever heard of a quick Struts release?  now you're just
talking nonsense. ;-)  but seriously, this is totally unrealistic. 
the different projects will overlap in their various states of
readiness/buginess and the next GA release of any of it must wait
until all of it is ready.

 Paul

 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.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]

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Hubert Rabago

On 3/20/06, Nathan Bubna [EMAIL PROTECTED] wrote:

 compatibility is not that difficult to maintain in reality.

 for project developers there are just 3 simple rules to follow:
 - no point release (1.3.1 to 1.3.2) should ever break a working,
 outward facing API
 - all minor versions (1.3.x to 1.4.x) should deprecate working,
 outward facing APIs before removing (release foo in 1.3.x, deprecate
 in 1.4.x, and remove no sooner than 1.5.x, if at all).
 - all major versions (1.x.x to 2.x.x) are free to break or change
 whatever they wish.

 assuming developers respect these well-established patterns, then
 users worried about compatibility and dependencies and unwilling to
 track all project changes, there are only three simple rules:
 - point release versions that go GA are always safe to upgrade
 - watch for deprecations when upgrading minor version numbers
 - expect things to break with a major version upgrade

One of the problems is when a point release change in one package
relies on a specific point release change in another package.

If struts-action-1.3.2 adds some new functionality, and
struts-taglib-1.3.1 uses this new functionality, a user who is using
struts-action-1.3.1 can't just plug in struts-taglib-1.3.1 without
upgrading the action jar as well.

Throw in several jars each with several versions each, and a user
wanting to upgrade just enough to get one specific feature, but not to
all the newest jars, and you can understand where the confusion can
come from.

Hubert

Hubert

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

Nathan Bubna wrote:

heh. who ever heard of a quick Struts release? now you're just
talking nonsense. ;-) but seriously, this is totally unrealistic.
the different projects will overlap in their various states of

readiness/buginess and the next GA release of any of it must wait
until all of it is ready.

But this hinges on each project having different committed developers, actively developing their code. My original
point is that the committers that are working on action are the same as EL, taglibs, extras, and plugins. Even then,
those projects are more or less in maintenance mode, save perhaps Action 1, which is still being worked on.

The situation you describe is what prompted the splitting of subprojects originally. However, after almost two years of
subprojects and the looming addition of Action 2 later, I think we are seeing based on previous activity that the new
subprojects didn't facilitate easier releases and more activity, but rather complicated our build and release processes.
In the end, if you can do the same thing but with less work and complexity, then do it. I think consolidating Action
1 subprojects, which have no life outside Action 1, is the right step to evolve our code and project structure to better
fit the community and those willing to maintain it.

Don

Paul

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Ted Husted

On 3/20/06, Don Brown [EMAIL PROTECTED] wrote:
 I think we are seeing based on previous activity that the new
 subprojects didn't facilitate easier releases and more activity, but rather 
 complicated our
 build and release processes.

I don't have a problem with anything anyone wants to do here, but I
don't think we've had the opportunity to see anything yet.

The only 1.3.x release anyone has actually tried to make so far was
all seven together, so it was no different that the type of release we
did for 1.1 and 1.2 -- and it took forever. Not because there were
subproject releases, but because for the initial 1.3.0 builds,
everything in all seven had to be just right before anything was
tagged. Same old, same old.

Case in point: All but 1 subproject was ready to go in November, but
we held the other 6 subprojects for three months waiting for a
dependency to mature that affected only one of the subprojects.

That said, I'm happy to let them that is going to do the work make the decision.

-Ted.

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

DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39040.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





--- Additional Comments From [EMAIL PROTECTED]  2006-03-20 22:32 ---
I think we're on the same page -- I figured that an intermediate/shared
ConfigUtil would be used by both ActionServlet and this theoretical listener.
 I hadn't thought specifically about it being a third class.  

I love the idea of minimizing/controlling dependencies upon the Servlet API, but
that could be more work than it's worth, especially since XWork provides that
for Struts 2.x -- but maybe you are just talking about having a straightforward
way to establish a test environment, perhaps with Mock implementations of
Servlet classes?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Paul Benedict

 Throw in several jars each with several versions each, and a user
 wanting to upgrade just enough to get one specific feature, but not to
 all the newest jars, and you can understand where the confusion can
 come from.

Agreed. How does anyone feel about this philosophy, which I see
can solve this problem: On any GA release of a subproject, the version 
number of Struts is incremented, and all the jars are upgraded to the
next version number? The biggest benefit is that a struts-1.3.5.zip would
contain all jars labeled 1.3.5. Granted, most of these subproject upgrades 
would be benign because nothing would change, but there will never be 
confusion about the versioning.

Paul

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39040.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





--- Additional Comments From [EMAIL PROTECTED]  2006-03-21 00:02 ---
I haven't put any effort into looking at the best way to achieve this or whats 
fully required, although from memory the interaction with the servlet 
environment is minimal - mostly getting/setting ServletContext attributes? If 
that is the case then maybe a Map representation of the ServletContext 
attributes would mostly do - which we already have as part of the request 
processing and its context.

If it does turn out to be too much work, then yes just a dependency on the 
ServletContext, which can easily be mocked would be next best.

Really I was just trying to throw out some ideas for consideration for anyone 
who decided to pick this up.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39040.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





--- Additional Comments From [EMAIL PROTECTED]  2006-03-21 00:43 ---
When you refer to removing the dependency on the Servlet API, I'm assuming this
is for the purpose of supporting portlets? In that case, creating an interface
that has the common methods would do the trick. Here's what you need from the
Portlet 1.0 spec:

PLT.10.3.1 Correspondence between ServletContext and PortletContext methods

The following methods of the PortletContext should provide the same
functionality as the methods of the ServletContext of similar name:
getAttribute, getAttributeNames, getInitParameter, getInitParameterNames,
getMimeType, getRealPath, getResource, getResourcePaths, getResourceAsStream,
log, removeAttribute and setAttribute.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r387384 - /struts/shale/trunk/build.xml

2006-03-20 Thread craigmcc

Author: craigmcc
Date: Mon Mar 20 18:47:23 2006
New Revision: 387384

URL: http://svn.apache.org/viewcvs?rev=387384view=rev
Log:
Add sources for the sql-browser example to the release artifacts.

Modified:
struts/shale/trunk/build.xml

Modified: struts/shale/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/build.xml?rev=387384r1=387383r2=387384view=diff
==
--- struts/shale/trunk/build.xml (original)
+++ struts/shale/trunk/build.xml Mon Mar 20 18:47:23 2006
@@ -822,6 +822,18 @@
  excludes=lib/**/
 /copy
 
+!-- Copy sql-browser artifacts --
+mkdirdir=${target.dir}/sql-browser/
+mkdirdir=${target.dir}/sql-browser/ext/
+mkdirdir=${target.dir}/sql-browser/lib/
+copy   todir=${target.dir}/sql-browser
+  filesetdir=sql-browser
+ includes=*.xml *.txt default.properties src/** xdocs/**
+ excludes=**/.svn/
+  filesetdir=sql-browser/dist/
+ includes=docs/**/
+/copy
+
   /target
 
 



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

[Struts Wiki] Update of StrutsReleasePlans by WendySmoak

2006-03-20 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Struts Wiki for change 
notification.

The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsReleasePlans

--
  = 4. Struts Shale Release Plans =
  
   *  ShaleRelease100 - ''Struts Shale Version 1.0.0''
-  *  ShaleRelease101 - ''Struts Shale Version 1.0.1'' (pending)
+  *  ShaleRelease101 - ''Struts Shale Version 1.0.1''
+  *  ShaleRelease102 - ''Struts Shale Version 1.0.2''
  
  = 5. Struts Scripting Release Plans =
  

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

[Struts Wiki] Update of ShaleRelease102 by WendySmoak

2006-03-20 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Struts Wiki for change 
notification.

The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/ShaleRelease102

New page:
= Shale 1.0.2 Release =

== Info ==

 1. Struts [http://struts.apache.org/releases.html#Releases Release Guidelines]
 
 2. [http://wiki.apache.org/incubator/SigningReleases Signing Releases]

 3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines]
 
== Release Manager ==

The release manager is '''TBD'''

== Special Issues ==

This release is likely to be an interim '''test build''' release of Shale 
technology.  As such, you should assume that the APIs are still evolving and 
subject to change.  For a stability rating on each API, see 
http://struts.apache.org/struts-shale/api-stability.html for more information.

== Outstanding Bug Review ==

|| '''ID''' || '''Summary''' || '''Component''' || '''Status''' ||
|| [http://issues.apache.org/bugzilla/show_bug.cgi?id=35066 35066] || Serious 
issue with dialog state || dialog || LATER[1] ||
|| [http://issues.apache.org/bugzilla/show_bug.cgi?id=35839 35839] || Clay 
processes components inside HTML comments || clay || LATER[2] ||
|| [http://issues.apache.org/bugzilla/show_bug.cgi?id=37024 37024] || No clay 
component configuration for MyFaces Tomahawk || clay || LATER[3] ||
|| [http://issues.apache.org/bugzilla/show_bug.cgi?id=37120 37120] || IFrame 
does not work properly inside Shale dialog || dialog || LATER[4] ||
|| [http://issues.apache.org/bugzilla/show_bug.cgi?id=37643 37643] || Add 
documentation for tiles and remoting features || docs || RFE[5] ||


[1] The dialog facility is in need of improved functionality for handling 
multiple simulteously active dialogs, and dealing with back buttons.  This 
issue is deferred to Shale 1.0.3 or later.

[2] The proposed solution to this issue is to cut-n-paste the HTML parser that 
Tapestry uses for reading templates.  Before going that way, it would be 
appropriate to see if the Tapestry developers were interested in abstracting 
out this code (perhaps to a commons project) so that it could be shared more 
easily.

[3] The Shale contribution to addressing this issue is to ensure that 
META-INF/clay-config.jar resources in JAR files loaded as part of the 
application are automatically loaded.  The actual configuration resources for a 
given component library such as Tomahawk, however, should be provided by the 
component library itself rather than by Shale.

[4] Will be addressed as part of the overall support for multiple 
simultaneously active dialogs.

[5] RFE to be reviewed for a subsequent release.


== Remaining Development Tasks ==

|| '''Description''' || '''Status''' ||
|| Dialog - support multiple in-progress dialogs || LATER ||
|| (New) - optional layer of annotation support if running on JavaSE 5 || (./) 
||
|| Documentation - finish basic feature descriptions || LATER ||

== Preparation Checklist ==

|| '''#''' || '''Description''' || '''Status''' ||
|| 1. || Announce plan to dev@ list || _ ||
|| 2. || Review/Complete Remaining Development Tasks || _ ||
|| 3. || Review/Resolve Outstanding Bugs || _ ||
|| 4. || Update Release Notes || _ ||
|| 5. || Check Dependencies || _ ||
|| 6. || Update to version 1.0.2 default.properties, project.xml, 
build/maven2/*.pom || _ ||

The Commons [http://jakarta.apache.org/commons/releases/prepare.html 
Preparation Guide] is a helpful preparation backgrounder, but Commons
uses the beta/release-candidate/final process.

Likewise, the [http://httpd.apache.org/dev/release.html HTTPD Release 
Guidelines] is a helpful overall process backgrounder,
but HTTPD does not use a test-build stage.

Dependency versions for this release:

|| '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' ||
|| Commons !BeanUtils || 1.7.0 || Released || core, clay ||
|| Commons Chain || 1.0.0 || Released || core, clay ||
|| Commons Digester || 1.7.0 || Released || core, clay ||
|| Commons Logging || 1.0.4 || Released || core, clay, test, usecases ||
|| Commons Validator || 1.2.0 || Released || core ||
|| JavaServer Faces || 1.1 || Released || core, clay, test, usecases ||
|| Spring Framework (Optional) || 1.2.2 || Released || core ||
|| Struts Tiles Standalone || --- || Struts Sandbox || core ||

Because this is a test build release, a dependency on an unreleased component 
is acceptable.

== Testing Checklist ==

=== Testing Summary ===

|| '''#''' || '''Description''' || '''Completed''' ||
|| 1. || Run Unit Test targets against JSF RI  || _ ||
|| 2. || Run Unit Test targets against MyFaces  || _ ||
|| 3. || Run Use Cases system integration tests (see below) || _ ||
|| 4. || Play test bundled applications || _ ||

=== Use Cases System Integration Tests ===

|| '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''JSF Version''' 
||  '''Status''' ||
|| 1. || J2SE 1.4.2_10 || Tomcat 5.0.28 || JSF RI 1.1_01 ||  _ ||
|| 2. || J2SE 1.4.2_10 || Tomcat

[Struts Wiki] Update of ShaleRelease101 by WendySmoak

2006-03-20 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Struts Wiki for change 
notification.

The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/ShaleRelease101

--
  == Vote (A) ==
  
  || PMC Member || Quality ||
+ || Wendy Smoak || Alpha ||
+ || Craig !McClanahan || -1 due to missing source code in the SQL Browser app 
||
  
- Voting thread is [http://www.mail-archive.com/dev%40struts.apache.org/FIXME 
here]
+ Voting thread is 
[http://www.mail-archive.com/dev@struts.apache.org/msg19117.html here]
  
  If release vote fails, including for a lack of quorum, remove from dist 
- folder.  
+ folder. ''[DONE]''
  
  == Point Release Checklist (B) ==
  

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

svn commit: r387389 - /struts/shale/trunk/docs/release-notes-1.0.2.html

2006-03-20 Thread wsmoak

Author: wsmoak
Date: Mon Mar 20 19:39:27 2006
New Revision: 387389

URL: http://svn.apache.org/viewcvs?rev=387389view=rev
Log:
Copied the 1.0.1 release notes as a base for 1.0.2.

Added:
struts/shale/trunk/docs/release-notes-1.0.2.html
  - copied, changed from r387388, 
struts/shale/trunk/docs/release-notes-1.0.1.html

Copied: struts/shale/trunk/docs/release-notes-1.0.2.html (from r387388, 
struts/shale/trunk/docs/release-notes-1.0.1.html)
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/docs/release-notes-1.0.2.html?p2=struts/shale/trunk/docs/release-notes-1.0.2.htmlp1=struts/shale/trunk/docs/release-notes-1.0.1.htmlr1=387388r2=387389rev=387389view=diff
==
--- struts/shale/trunk/docs/release-notes-1.0.1.html (original)
+++ struts/shale/trunk/docs/release-notes-1.0.2.html Mon Mar 20 19:39:27 2006
@@ -22,13 +22,13 @@
 html
 
   head
-titleApache Shale (Version 1.0.1) Release Notes/title
+titleApache Shale (Version 1.0.2) Release Notes/title
   /head
 
   body
 
 div align=center
-  h1Apache Shale (Version 1.0.1) Release Notes/h1
+  h1Apache Shale (Version 1.0.2) Release Notes/h1
 /div
 
 ul



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

svn commit: r387397 - /struts/shale/trunk/docs/release-notes-1.0.1.html

2006-03-20 Thread wsmoak

Author: wsmoak
Date: Mon Mar 20 19:52:36 2006
New Revision: 387397

URL: http://svn.apache.org/viewcvs?rev=387397view=rev
Log:
Remove the 1.0.1 release notes; The copy for 1.0.2 should have been a rename 
instead.

Removed:
struts/shale/trunk/docs/release-notes-1.0.1.html


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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)


Paul Benedict wrote:
 Agreed. How does anyone feel about this philosophy, which I see
 can solve this problem: On any GA release of a subproject, the version
 number of Struts is incremented, and all the jars are upgraded to the
 next version number? The biggest benefit is that a struts-1.3.5.zip would
 contain all jars labeled 1.3.5. Granted, most of these subproject 
upgrades

 would be benign because nothing would change, but there will never be
 confusion about the versioning.

I can't really say I like the idea... you could envision a situation 
where one subproject has a number of releases in a relatively short 
time, so all of sudden there's X new versions of Struts that people have 
to figure out it they need or want or not.


Your goal of wanting to remove questions about version compatibility is 
worthy though, I'm just not sure this is the best way to do it.


I actually think this can be dealt with using nothing more than good 
documentation.  Something simple like a table along these lines:


If you use:
  Action 1.2.7
Then you can use:
  EL-   1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7
  Flow- 1.2.9, 1.3.0
If you use:
  Action 1.3.0
Then you can use:
  EL-   1.2.5, 1.2.6, 1.2.7
  Flow- 1.3.0
...and so on...

And also for each subproject:

If you want to use:
  EL- 1.2.3
You can use:
  Action- 1.2.7, 1.2.8, 1.3.0
If you want to use:
  EL- 1.2.4
You can use:
  Action- 1.2.8, 1.3.0
...and so on...

Probably a better way to lay it out, but you get the idea, and I think 
that would do the trick.  The person can grab whatever version of a 
given extension they want, after researching the versions to see what 
they provide, or they can just grab the highest compatible version.  I 
think the key though is that it should be driven off the core Action 
version.  However, it is important to have a reverse-lookup, in effect, 
so that if you need a specific feature in a specific extension version, 
you can at a glance see what version of Action it will work with.



Paul


Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)

2006-03-20 Thread Wendy Smoak

On 3/20/06, Don Brown [EMAIL PROTECTED] wrote:
 Thanks Wendy, that's what I needed to hear.  So far, I haven't heard any -1 
 type objections, so I'll take your advice
 and try the reorg on that other svn site.

 When I have it working correctly, I suppose I'll call for the vote.  This 
 would be a significant change, and honestly, I
 thought there'd be a lot more resistance :)  Not that I'm complaining

From me?  As long as I get my fancy Maven build, I'm happy. ;)

I'm in favor of grouping the Action-related modules in the repository.
 From a release manager perspective, (now that I have one,) I'm less
thrilled about the consolidated release, but that only means I'm less
likely to volunteer to do it.

Struts Action 1.3.1 was simple to put together, while Shale 1.0.1 was
_not_.  Being able to concentrate on a single jar, a single set of
docs, etc., better fits into the blocks of time that I can devote to
this.  I don't think the separate releases ever got a chance to prove
themselves, but if more people (who are going to do the work) want the
consolidated release, it's fine with me.

Looking at the list again, struts-tiles is missing.  And I'm not sure
how Faces is going to fit in there, it has a different set of
dependencies than the others.  That will all sort itself out when you
start moving things around, though. :)

--
Wendy

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

Re: [VOTE] Struts Shale v1.0.1 Quality

2006-03-20 Thread Wendy Smoak

On 3/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:

  Sorry for the late response and the bad news ... -1 on this because the
  sql-browser sample is not included in the shale-framework-1.0.1 artifact,
  and running ant download-dependencies release therefore fails to execute
  correctly :-(.

 Ah RATS!  To make things even worse, it's *my* fault :-( ... the release
 target doesn't copy the SQL Browser demo app sources like it should.  I'll
 fix that in a second.

 Sorry for the time you wasted on this Wendy.

Not at all... most of the work carries forward.  And I should have
caught that. :(

I went ahead and posted the 1.0.2 release plan so that the clock can
start ticking, though I didn't add myself as release manager in case
someone else wants to jump in.

A few other things:
 - I noticed (too late for 1.0.1) that there's a broken link on the
release notes page.  It points to a 'webapps' directory that doesn't
exist in the distribution.
 - 38560 can be closed; Ryan noted that he's not having the issue any longer.
 - There are a couple of 'xdocs/navigation.xml' files that could be
excluded from the distribution.
 - Is the sql-browser app supposed to display columns of data?  I only
see the column headings.

--
Wendy

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

Re: [VOTE] Struts Shale v1.0.1 Quality

On 3/20/06, Wendy Smoak [EMAIL PROTECTED] wrote:

 On 3/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
 
   Sorry for the late response and the bad news ... -1 on this because
 the
   sql-browser sample is not included in the shale-framework-1.0.1artifact,
   and running ant download-dependencies release therefore fails to
 execute
   correctly :-(.
 
  Ah RATS!  To make things even worse, it's *my* fault :-( ... the
 release
  target doesn't copy the SQL Browser demo app sources like it
 should.  I'll
  fix that in a second.
 
  Sorry for the time you wasted on this Wendy.

 Not at all... most of the work carries forward.  And I should have
 caught that. :(


I'm running a pretty full suite of tests on the output of a trunk build
right now, to make sure there are no other hidden ghosts.

I went ahead and posted the 1.0.2 release plan so that the clock can
 start ticking, though I didn't add myself as release manager in case
 someone else wants to jump in.


If you're willing, I'm certainly glad to support and test.

A few other things:
 - I noticed (too late for 1.0.1) that there's a broken link on the
 release notes page.  It points to a 'webapps' directory that doesn't
 exist in the distribution.


Should I go ahead and fix that now?

- 38560 can be closed; Ryan noted that he's not having the issue any longer.


Will take care of that.

- There are a couple of 'xdocs/navigation.xml' files that could be
 excluded from the distribution.


I'll look for those too if you want these fixed before rolling 1.0.2.

- Is the sql-browser app supposed to display columns of data?  I only
 see the column headings.


It is supposed to display data -- we're seeing an artifact of a bug in
MyFaces 1.1.1 (it works with the RI) when the DataModel you are using
returns -1 for a getRowCount() call.  This is theoretically fixed in the
trunk ... after we roll this out, 1.1.2 should be available with the fix and
we can upgrade if it's actually fixed.

It's also amusing to execute SELECT * FROM ZIP_CODES and then SELECT
CITY, STATE FROM ZIP_CODES and watch the table columns get drawn
dynamically based on the returned metadata from the query.  Not particularly
easy to do with Struts tags :-).

--
 Wendy


Craig

DO NOT REPLY [Bug 38560] - [shale] include local copies of dtds

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=38560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38560


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-03-21 04:48 ---
Original reporter also reports that he no longer observes this issue, so
resolving as WORKSFORME to get it off our active radar.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [VOTE] Struts Shale v1.0.1 Quality