Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Fri, 26 Mar 2004, Ted Husted wrote: On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. Upgrading the container, though, is only half the story. That will allow the developers to use newer technologies in new parts of the application, but doesn't necessarily mean that the budget will be available to migrate existing large applications to a different set of JSP tags. That's where the real rub lies, IMHO. -- Martin Cooper Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Ted Husted [EMAIL PROTECTED] wrote: On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. This is why tags like logic:iterate are still useful for Struts 1.x. However, since Struts 2.x will be based on at least Servlet 2.3 where c:forEach is available, IMO logic:iterate has no useful purpose. This applies to other Struts tags but iterate is a good example. David Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Craig R. McClanahan wrote: Quoting Peter A. Pilgrim [EMAIL PROTECTED]: Joe Germuska wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Joe All +1 Some Struts tags are indeed very great. I also found the original html:options tag to really be useful last year at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL c:if or c:when statment is verbose. If there not EL equivalent of html:options, it will be on my todo list. It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for example, has more powerful equivalents of html:options (f:selectItems -- among other fancy things you can make it create hierarchical option lists by emitting optgroup very easily), as well as equivalents for html:messages (h:message for a single field, h:messages for the general messages). So I guess what you are, in fact, saying that we should be using JavaServer Faces or looking to use it, for 2004/2005. One question are the JSF tag actions h:message and h:messages dependent on a JSF implementation or can they be used standalone? Perhaps that is what we need to do as Developer. Write some kind of feature compatibility matrix. Old Tag:New Tag : Description == html:messagesh:messages extends original behaviour and can make it create hierarchical option lists by emitting optgroup. I presume there are some other Struts HTML tags that are favourites with other people too. Likewise, the Struts-Faces integation library has JSF-componetized equivalents for some of the Struts HTML tags (including messages) to make it easier to use as a drop-in replacement. I'd be interested in hearing specifically what other favorite tags their are, to make sure that equivalent functionality is available to a JSF-based user of Struts. logic:iterate superceded by JSTL logic:forward superceded by JSTL logic:redirect superceded by JSTL logic:equal superceded by JSTL logic:notEqual superceded by JSTL logic:greaterThan superceded by JSTL logic:greaterEqual superceded by JSTL etc logic:match no equalivant in JSTL 1.0 but exists String functions in JSTL 1.1 bean:define replace with c:set bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0 to get the size of java.uitl.Collection until there is widespread support JSP 2.0 JSTL 1.1 Investigation continue with rest of Beans taglib ... -- Peter Pilgrim Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
...
logic:match no equalivant in JSTL 1.0 but exists String functions in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes in
those two libraries are going to track pretty tightly. But like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I think
it's nice to have tags which know the special locations, instead of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF tag
actions h:message and h:messages dependent on a JSF implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing specifically
what other
favorite tags their are, to make sure that equivalent functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0
to get
the size of java.uitl.Collection until there is widespread
support JSP 2.0 JSTL 1.1
Investigation continue with rest of Beans taglib ...
--
Peter Pilgrim
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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Peter A. Pilgrim [EMAIL PROTECTED] wrote: snip bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0 to get the size of java.uitl.Collection until there is widespread support JSP 2.0 JSTL 1.1 The current proposal is for Struts 2.0 to be based on Servlet 2.4/JSP 2.0 so we don't need bean:size either. David Investigation continue with rest of Beans taglib ... -- Peter Pilgrim Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Nope. logic:match does substring matching.
Quoting Tim Chen [EMAIL PROTECTED]:
...
logic:match no equalivant in JSTL 1.0 but exists String functions in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes in
those two libraries are going to track pretty tightly. But like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I think
it's nice to have tags which know the special locations, instead of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF tag
actions h:message and h:messages dependent on a JSF implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing specifically
what other
favorite tags their are, to make sure that equivalent functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0
to get
the size of java.uitl.Collection until there is widespread
support JSP 2.0 JSTL 1.1
Investigation continue with rest of Beans taglib ...
--
Peter Pilgrim
Craig
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
You're right (as usual ;))
I was using the String taglib in addition to the JSTL 1.0 taglib to do
the test. (duh)
Although looking at it now.. there isnt any support for begin and ends
in that neither.
-Tim
Kris Schneider wrote:
Nope. logic:match does substring matching.
Quoting Tim Chen [EMAIL PROTECTED]:
...
logic:match no equalivant in JSTL 1.0 but exists String functions in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes in
those two libraries are going to track pretty tightly. But like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I think
it's nice to have tags which know the special locations, instead of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF tag
actions h:message and h:messages dependent on a JSF implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing specifically
what other
favorite tags their are, to make sure that equivalent functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0
to get
the size of java.uitl.Collection until there is widespread
support JSP 2.0 JSTL 1.1
Investigation continue with rest of Beans taglib ...
--
Peter Pilgrim
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
With JSTL 1.1 (JSP 2.0), you get a set of string manipulaton functions (which
Peter was referring to) that includes:
fn:contains(string, substring)
fn:startsWith(string, prefix)
fn:endsWith(string, suffix)
In addition, you also get a length function that operates on collections and
strings:
fn:length(input)
Where input can be: String, array of objects or primitives, Collection,
Iterator, Enumeration, or Map.
Quoting Tim Chen [EMAIL PROTECTED]:
You're right (as usual ;))
I was using the String taglib in addition to the JSTL 1.0 taglib to do
the test. (duh)
Although looking at it now.. there isnt any support for begin and ends
in that neither.
-Tim
Kris Schneider wrote:
Nope. logic:match does substring matching.
Quoting Tim Chen [EMAIL PROTECTED]:
...
logic:match no equalivant in JSTL 1.0 but exists String functions in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello
world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes in
those two libraries are going to track pretty tightly. But like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I think
it's nice to have tags which know the special locations, instead of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF tag
actions h:message and h:messages dependent on a JSF implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing specifically
what other
favorite tags their are, to make sure that equivalent functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0
to get
the
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Kris Schneider [EMAIL PROTECTED] wrote:
Nope. logic:match does substring matching.
IMO, any tag that does not interact with Struts' core resources should
live in the Jakarta Taglibs project. This allows non-Struts projects to
benefit from the functionality while freeing Struts to focus on its core
features. Substring matching doesn't sound like a Struts specific
operation.
David
Quoting Tim Chen [EMAIL PROTECTED]:
...
logic:match no equalivant in JSTL 1.0 but exists String functions
in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello
world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two
isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes
in
those two libraries are going to track pretty tightly. But
like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the
existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts
in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I
think
it's nice to have tags which know the special locations, instead
of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same
goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing
JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF,
for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general
messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF
tag
actions h:message and h:messages dependent on a JSF
implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are
favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing
specifically
what other
favorite tags their are, to make sure that equivalent
functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL
1.0
to get
the size of java.uitl.Collection until there is widespread
support JSP 2.0 JSTL 1.1
Investigation continue with rest of Beans taglib ...
--
Peter Pilgrim
Craig
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
+1. Just keeping the functionality facts straight...
Quoting David Graham [EMAIL PROTECTED]:
--- Kris Schneider [EMAIL PROTECTED] wrote:
Nope. logic:match does substring matching.
IMO, any tag that does not interact with Struts' core resources should
live in the Jakarta Taglibs project. This allows non-Struts projects to
benefit from the functionality while freeing Struts to focus on its core
features. Substring matching doesn't sound like a Struts specific
operation.
David
Quoting Tim Chen [EMAIL PROTECTED]:
...
logic:match no equalivant in JSTL 1.0 but exists String functions
in
JSTL 1.1
...
logic:match equivalent is c:if test=${foo.bar eq 'hello
world'}xxx/c:if
-Tim
Peter A. Pilgrim wrote:
Craig R. McClanahan wrote:
Quoting Peter A. Pilgrim [EMAIL PROTECTED]:
Joe Germuska wrote:
Whether the classic and el taglibs are one chunk or two
isn't
hugely important to me either -- I would prefer that this
decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and make a
corresponding change in the EL version. I suspect that changes
in
those two libraries are going to track pretty tightly. But
like I
said, I'm not pushing for this; just floating it...
Is there any reason that the EL tags wouldn't replace the
existing
tags
for Struts 2.0? Also, IMO, many of the tags can be removed
entirely for
2.0 because they've been replaced by more powerful counterparts
in
the
JSTL.
As I've been saying (a lot, it seems, lately) on struts-user, I
think there are legitimate Struts JSP tags like html:messages
that are not best replaced by JSTL. Any time Struts tools put
resources in special locations in request or session scope, I
think
it's nice to have tags which know the special locations, instead
of
expecting people to dig in and find them. And, for example with
html:messages, the message-property filtering is a useful feature
that would require a lot of verbose JSTL to achieve the same
goal.
So, I'd suspect even in 2.0 there will be arguments for a small
Struts taglib. But I am 100% on board with pushing people to use
the JSTL where it is really equivalent.
Joe
All
+1 Some Struts tags are indeed very great.
I also found the original html:options tag to really be useful
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing
JSTL
c:if or c:when statment is verbose. If there not EL equivalent
of html:options, it will be on my todo list.
It's not just an issue of JSTL and EL-enabling Struts tags. JSF,
for
example,
has more powerful equivalents of html:options (f:selectItems --
among other
fancy things you can make it create hierarchical option lists by
emitting
optgroup very easily), as well as equivalents for html:messages
(h:message for a single field, h:messages for the general
messages).
So I guess what you are, in fact, saying that we should be using
JavaServer
Faces or looking to use it, for 2004/2005. One question are the JSF
tag
actions h:message and h:messages dependent on a JSF
implementation
or can they be used standalone?
Perhaps that is what we need to do as Developer. Write some kind of
feature
compatibility matrix.
Old Tag:New Tag : Description
==
html:messagesh:messages extends original behaviour and
can make it create hierarchical
option lists by emitting optgroup.
I presume there are some other Struts HTML tags that are
favourites
with
other people too.
Likewise, the Struts-Faces integation library has JSF-componetized
equivalents
for some of the Struts HTML tags (including messages) to make it
easier to use
as a drop-in replacement. I'd be interested in hearing
specifically
what other
favorite tags their are, to make sure that equivalent
functionality is
available to a JSF-based user of Struts.
logic:iterate superceded by JSTL
logic:forward superceded by JSTL
logic:redirect superceded by JSTL
logic:equal superceded by JSTL
logic:notEqual superceded by JSTL
logic:greaterThan superceded by JSTL
logic:greaterEqual superceded by JSTL
etc
logic:match no equalivant in JSTL 1.0 but exists String functions
in JSTL 1.1
bean:define replace with c:set
bean:size we need a simple tag lib action for JSP 1.2 and JSTL
1.0
to get
the size of java.uitl.Collection
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Quoting Peter A. Pilgrim [EMAIL PROTECTED]: Craig R. McClanahan wrote: Quoting Peter A. Pilgrim [EMAIL PROTECTED]: Joe Germuska wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Joe All +1 Some Struts tags are indeed very great. I also found the original html:options tag to really be useful last year at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL c:if or c:when statment is verbose. If there not EL equivalent of html:options, it will be on my todo list. It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for example, has more powerful equivalents of html:options (f:selectItems -- among other fancy things you can make it create hierarchical option lists by emitting optgroup very easily), as well as equivalents for html:messages (h:message for a single field, h:messages for the general messages). So I guess what you are, in fact, saying that we should be using JavaServer Faces or looking to use it, for 2004/2005. One question are the JSF tag actions h:message and h:messages dependent on a JSF implementation or can they be used standalone? The h:message and h:messages tags are both JSF components, so they require a JSF implementation -- but *any* JSF implementation will do, because they are standard. Perhaps that is what we need to do as Developer. Write some kind of feature compatibility matrix. Old Tag:New Tag : Description == html:messagesh:messages extends original behaviour and can make it create hierarchical option lists by emitting optgroup. I presume there are some other Struts HTML tags that are favourites with other people too. In this particular case, you'll note that I included s:message in the Struts-Faces integration library. It is a JSF component, but it has semantics like the html:message tag (for example, it looks things up in a Struts MessageResources object instead of resource bundles the way that the standard JSF components work). For the same reason, I included JSF-ized versions of html:base, html:errors, html:form, html:html, html:javascript, html:stylesheet, and bean:write in order to make transition of existing apps very easy. If there's any useful tags I missed that don't already have obvious JSF replacements, I'd be happy to add them as well. Likewise, the Struts-Faces integation library has JSF-componetized equivalents for some of the Struts HTML tags (including messages) to make it easier to use as a drop-in replacement. I'd be interested in hearing specifically what other favorite tags their are, to make sure that equivalent functionality is available to a JSF-based user of Struts. logic:iterate superceded by JSTL logic:forward superceded by JSTL logic:redirect superceded by JSTL logic:equal superceded by JSTL logic:notEqual superceded by JSTL logic:greaterThan superceded by JSTL logic:greaterEqual superceded by JSTL etc Superceded is definitely true for new development. It would be unfair, though, to existing applications to drop them in a 1.x release, however, because it would prevent existing apps from being to upgrade without an expensive rewrite. logic:match no equalivant in JSTL 1.0 but exists String functions in JSTL 1.1 bean:define replace with c:set bean:size we need a simple tag lib action for JSP 1.2 and JSTL 1.0 to get the size of java.uitl.Collection until there is widespread support JSP 2.0
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote: So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;- If all the deliverables are in a single module, is there a way that we can generate a separate changelog for each one? http://maven.apache.org/reference/project-descriptor.html#repository -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
At 6:30 AM -0800 3/25/04, David Graham wrote: Yep, notice I mentioned removing many tags and not *all* tags :-). There are certainly tags we should keep around but I just don't see a need for most of the logic and bean tags in Struts 2.0. Whoops. I read Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? as Is there any reason that the JSTL tags wouldn't replace the existing tags for Struts 2.0? which was wrong. I kind of thought 2.0 would be revolutionary enough that it wouldn't be as simple as just replacing one set of classes with another, but I guess we'll just have to see what gets written! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
At 7:44 AM -0500 3/25/04, Ted Husted wrote: On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote: So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;- If all the deliverables are in a single module, is there a way that we can generate a separate changelog for each one? http://maven.apache.org/reference/project-descriptor.html#repository You can specify a submodule in the repository URL. The project.xml for struts-chain demonstrates this, and I just confirmed that it does what you'd think it would. Run maven site in contrib/struts-chain and then open target/docs/changelog-report.html You'll see that it's limited to struts-chain changes. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Joe All +1 Some Struts tags are indeed very great. I also found the original html:options tag to really be useful last year at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL c:if or c:when statment is verbose. If there not EL equivalent of html:options, it will be on my todo list. I presume there are some other Struts HTML tags that are favourites with other people too. -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Quoting Peter A. Pilgrim [EMAIL PROTECTED]: Joe Germuska wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Joe All +1 Some Struts tags are indeed very great. I also found the original html:options tag to really be useful last year at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL c:if or c:when statment is verbose. If there not EL equivalent of html:options, it will be on my todo list. It's not just an issue of JSTL and EL-enabling Struts tags. JSF, for example, has more powerful equivalents of html:options (f:selectItems -- among other fancy things you can make it create hierarchical option lists by emitting optgroup very easily), as well as equivalents for html:messages (h:message for a single field, h:messages for the general messages). I presume there are some other Struts HTML tags that are favourites with other people too. Likewise, the Struts-Faces integation library has JSF-componetized equivalents for some of the Struts HTML tags (including messages) to make it easier to use as a drop-in replacement. I'd be interested in hearing specifically what other favorite tags their are, to make sure that equivalent functionality is available to a JSF-based user of Struts. -- Peter Pilgrim Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Joe Germuska [EMAIL PROTECTED] wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Yep, notice I mentioned removing many tags and not *all* tags :-). There are certainly tags we should keep around but I just don't see a need for most of the logic and bean tags in Struts 2.0. Widely known is that the Struts tags sit under the nested tags. And that JSTL and EL cannot fill the shoes of the nested tags. If Struts doesn't want to support the taglibs, then thats a separate issue. But for the nested tags to do what they do, they need the Struts tags including all the logic tags. I don't think that we'd drop all the tags, but as for letting some go that aren't in JSTL et al... -1 Btw: I've thought long and hard about how to get the nested concept into JSTL (to remove the dependancy on Struts), but it's just not a fit. The nested tags manage things as much for the trip back to the Struts servlet as much as making the viewing layout code easier. Nested tags live on Struts. I've watched these conversations, but just don't have the time for all the backround study it'd take to make worthy comment. But for the tags, things haven't changed. So, apologies for just piping in on familiar topics. I probably needed a pair of them fantastic gloves already mentioned... Cheers, Arron. David Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Arron Bates [EMAIL PROTECTED] wrote: --- Joe Germuska [EMAIL PROTECTED] wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Yep, notice I mentioned removing many tags and not *all* tags :-). There are certainly tags we should keep around but I just don't see a need for most of the logic and bean tags in Struts 2.0. Widely known is that the Struts tags sit under the nested tags. And that JSTL and EL cannot fill the shoes of the nested tags. If Struts doesn't want to support the taglibs, then thats a separate issue. Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. David But for the nested tags to do what they do, they need the Struts tags including all the logic tags. I don't think that we'd drop all the tags, but as for letting some go that aren't in JSTL et al... -1 Btw: I've thought long and hard about how to get the nested concept into JSTL (to remove the dependancy on Struts), but it's just not a fit. The nested tags manage things as much for the trip back to the Struts servlet as much as making the viewing layout code easier. Nested tags live on Struts. I've watched these conversations, but just don't have the time for all the backround study it'd take to make worthy comment. But for the tags, things haven't changed. So, apologies for just piping in on familiar topics. I probably needed a pair of them fantastic gloves already mentioned... Cheers, Arron. David Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Joe Germuska [EMAIL PROTECTED] wrote: snip Hope that helps. If we stick to our guns about avoiding dependencies on unreleased software, this won't come up again... it's not Maven's fault! Commons Validator is a special case because it's mostly used with Struts. The standalone user population is significantly smaller than the Struts Validator users. We decided that to get true testing of new Commons Validator versions we needed to distribute it with Struts builds. David Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mar 24, 2004, at 4:19 AM, Ted Husted wrote: Next question. In making changes like this, at what point do we start breaking the CVS history? I'd definitely want to keep it all for core and taglibs. The other components might be less important. ** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three problem tickets on the bugzilla list now? Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 07:45:29 -0700, Matt Raible wrote: ** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three problem tickets on the bugzilla list now? Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Well, did-ja have anything to add to the list, Matt? :) http://tinyurl.com/yqxyk If we can clear the outstanding problem tickets, along with any burning issues people haven't reported yet, we can roll 1.2.1. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Well, did-ja have anything to add to the list, Matt? :) Nope - release, release!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004, Ted Husted wrote:
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
So, there are pros and cons both ways, of course. Now we just need
to make a decision and move on it. ;-)
The consensus seems to be to use a single module with top-level-directories
representing each subproject, so lets move forward with that.
So I believe we're talking about something like this:
\core(including tiles and validator)
\apps
\site
\opt-dev (whiteboard or sandbox)
So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference,
although 'sandbox' is used by at least 4 Jakarta sub-projects. (In those,
it's a separate repo, though. Do we want to do the same?)
\opt-taglib
I still like the idea of pushing this down under a generic presentation
directory, or at least under a JSP directory, so that we can move JSP
specific stuff out of core and into this.
\opt-el
Hmm. This is also a taglib...
\opt-faces
The example applications we will have to juggle a bit:
[apps]
/src/example - /mailreader/src/java
/src/examples - /examples/src/java
/src/tiles-documentation -Â /portal/src/java
And the same for /web
/web/{1} -Â {1}/src/webapp/
The other directory moving might go something like this:
[opt-el]
src/contrib/struts-el -Â opt-el
[opt-legacy]
/src/contrib/struts-legacy -Â opt-legacy
[opt-faces]
/src/contrib/struts-faces -Â opt-faces
[opt-dev]
/src/contrib/ -Â opt-dev
[opt-taglib]
src/share/o.a.s/taglib -Â opt-taglib/src/java/o.a.s/taglib
src/test/o.a.s/taglib- opt-taglib/src/test/o.a.s/taglib
doc/userGuide/dev_*.* - opt-taglib/xdocs
doc/userGuide/struts*.* - opt-taglib/xdocs
[site]
/doc/ - site/xdocs
[core]
/src/share -Â core/src/java
/src/test - core/src/test
/ -Â /
This is just a rough starting point. I'd want to try a dry-run offline first, and
post it where people could browse it :)
+1. I was thinking along the same lines.
One question is the packaging of Struts-el. Right now it's org.apache.strutsel. I'm
thinking we might want that to be org.apache.struts.el instead.
Maybe either:
org.apache.struts.taglib.el.${foo}
org.apache.struts.taglib.${foo}.el
The latter just extends the original package names with .el.
We might also want to shuffle some things around in opt-faces to make it more Maven
friendly. It's also sharing the UserDatabase package with the original example, and
so we might want to break the UserDatabase out as a deliverable that multiple
applications could share.
Next question. In making changes like this, at what point do we start breaking the
CVS history? I'd definitely want to keep it all for core and taglibs. The other
components might be less important.
We can arrange to keep CVS history indefinitely. However, we'd want to
stop moving things around as soon as possible, really, and certainly not
move anything after we've created labels or branches in the new tree.
** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three
problem tickets on the bugzilla list now?
Actually, contrary to your comment in the Counting down thread, I don't
have anything up my sleeve (unless I forgot something myself). ;-) It
would be nice to resolve the issue with the Cactus tests not stopping
properly on Tomcat 5.0, but I can live without that if necessary.
--
Martin Cooper
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 11:03:58 -0800 (PST), Martin Cooper wrote: \opt-dev (whiteboard or sandbox) So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference, although 'sandbox' is used by at least 4 Jakarta sub- projects. (In those, it's a separate repo, though. Do we want to do the same?) Let's go for the brevity and consistency of opt-dev. If we're keeping everything in one module, then let's keep it all on one module :) \opt-taglib I still like the idea of pushing this down under a generic presentation directory, or at least under a JSP directory, so that we can move JSP specific stuff out of core and into this. I would strongly prefer that we should tie the TLDs to specific deliverables and avoid taxonomies, The JSP specific stuff should live with the taglibs or be refactored so that it's not JSP-specific :) Obviously, I'm good with alternate presentation technologies, but they should be available as their own deliverables, and rooted in their own TLDs. \opt-el Hmm. This is also a taglib... But with different platform requirements. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 20:35:41 +, Peter A. Pilgrim wrote: Are keeping the basic `src' and `web' main sub directory under each top level directory? I'd prefer we followed the Maven project layout recommendations for each deliverable. This will be the easiest for everyone to grok in the longrun. http://maven.apache.org/reference/dirlayout.html So, under each top-level directory, we would find a layout like /src - java - test - webapp /xdocs /target (generated) - *.jar - distributions - docs - site - ... May be it is worth putting `opt-legacy' and `opt-el' under a `view' directory especially if they are all to do rendering the web user interface You might have meant opt-taglib and opt-el. Legacy is the old datasource implementation. I'd strongly prefer keeping a close relationship between top-level-directories and deliverables, and that we avoid taxonomies. Joe suggested combining opt-el with opt-taglibs, though we'd have to be careful which dependencies are used to build what. (Which makes me think they are not the same deliverable. el might just have a dependency on taglib.) I don't actually use either one much myself, so I have no preferences myself. The example applications tree might be a tad different. Here I'd favor a master apps directory, with a directory for each application beneath that. This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within. /apps - examples - mailreader - tilesPortal - userdb Now that I say it, the same approach might conceivably be used for el, taglibs, and faces. /taglibs - classic - el - faces But, the problem with binding the taglib packages too closely is that they would all have to be distribution-ready before we did a new roll of any. So, an ongoing refactoring in the classic taglibs could block a quick release of the faces taglib. I really want to try and avoid the hydraulic dependencies of the 1.1 era, where we had to have everything ready to release all at once :( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Joe Germuska [EMAIL PROTECTED] wrote: This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within. /apps - examples - mailreader - tilesPortal - userdb Now that I say it, the same approach might conceivably be used for el, taglibs, and faces. /taglibs - classic - el - faces But, the problem with binding the taglib packages too closely is that they would all have to be distribution-ready before we did a new roll of any. So, an ongoing refactoring in the classic taglibs could block a quick release of the faces taglib. I really want to try and avoid the hydraulic dependencies of the 1.1 era, where we had to have everything ready to release all at once :( I think you've already made the case for not pushing all the taglibs things together just because they are the same technology. struts-faces should be its own thing, I'm pretty certain. Joe suggested combining opt-el with opt-taglibs, though we'd have to be careful which dependencies are used to build what. (Which makes me think they are not the same deliverable. el might just have a dependency on taglib.) I don't actually use either one much myself, so I have no preferences myself. Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. David Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Martin Cooper wrote: On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote: On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core since it's just something a volunteer would run offline and the upload. It wouldn't be a true deliverable. And, I'm not convinced that we even need to do such a thing. Even without a few extra JARs of our own, there are still all the Commons JARs. (Though I suppose we could roll together those too.) I'd tend to leave this for a end-user to do, say if there were distributing a particular Struts distribution to several teams in an enterprise. But it would be nice to provide a tool for this (if someone had the itch to write it.) It really sounds like a job for Sun :) On Mon, 22 Mar 2004 20:50:24 -0800 (PST), Martin Cooper wrote: I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies of code, leading to the possibility of why not mine? kinds of things. For larger code bases, we'd also likely need to have some discussions with the incubator folks. But, as you say, let's get our own house in order first, and then come back and talk about this some more. And in deciding how to renovate our house, let's keep in mind that we may be having more children :) How about if we split the difference: core module: /core /site /apps opt-modules: * opt-taglib * opt-el * opt-faces * opt-dev (sandbox) So, we'd go from seven to five. Then, later on, if we invite some of our friends to join us, and they move in, we just add more opt modules. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Ted Husted wrote: On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote: Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core since it's just something a volunteer would run offline and the upload. It wouldn't be a true deliverable. And, I'm not convinced that we even need to do such a thing. Even without a few extra JARs of our own, there are still all the Commons JARs. (Though I suppose we could roll together those too.) I'd tend to leave this for a end-user to do, say if there were distributing a particular Struts distribution to several teams in an enterprise. But it would be nice to provide a tool for this (if someone had the itch to write it.) It really sounds like a job for Sun :) Did you need something beyond what ANT already provides? An untested example: target name=bundle.struts jar jarfile=lib/struts-all.jar zipgroupfileset dir=lib/struts include name=**/*.jar / /zipgroupfileset /jar /target -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Ted Husted wrote: On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) Now it clearer. Well this is how Expresso CVS is laid out and an old investment bank project which I was involved in a couple years ago was laid out like that as well. I guess the hard part of copying jar and build a web app from CVS modules have already been discussed. Still it is the only way to go if you want to Struts to be modular. So +1 from me. -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
FWIW I'm with Martin on this. I don't understand the advantage having separate repositories will give us. Even under one top lever repository directory, we can organize the Struts product(s) however we like. The only advantage I can see in having separate repositories would be to make it easier to grant different groups of committers access to different areas. But that's not what we want to do anyway. Another reason NOT to split into several top level directories is that it adds more clutter to the already busy Apache repository. IMHO fewer top level directories makes it easier for people to find what they need. If there's a compelling reason to split into several top-level repository directories that hasn't been stated (or I've missed), please let me know, otherwise I'd prefer to keep as few as possible. But it's not a life or death issue either way :-) Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: March 22, 2004 11:50 PM To: Craig R. McClanahan Cc: Struts Developers List Subject: Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?) On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Peter A. Pilgrim wrote: Ted Husted wrote: On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) Now it clearer. Well this is how Expresso CVS is laid out and an old investment bank project which I was involved in a couple years ago was laid out like that as well. I guess the hard part of copying jar and build a web app from CVS modules have already been discussed. Still it is the only way to go if you want to Struts to be modular. So +1 from me. Let me clarify my own post ( grabbing GNU Emacs and picture-mode ). The way it is organised under the current CVS module is `src' for Java source and `web' file. So you could live with this structure. 1) I think you should keep the same elementary structure Case#1 CVS Repository | + core (including tiles and validator) | | | +---web | +---src | + examples | | | +---web | +---src | + site | | | +---web | +---src | + whiteboard (or sandbox) | | ... + opt-taglib | | ... + opt-el | | ... + opt-faces 2) Or you can remove all the `web' stuff and merge under one `web' (public_html) module. But I have never liked this idea as a workable solution. I seen it once long ago and I hated it then and now. Case#2 CVS Repository | +--web | | | +-- examples | +-- core | +-- ... | + core (including tiles and validator) | | | +---src | + examples | | | +---src | + site | | | +---src | + whiteboard (or sandbox) | | ... + opt-taglib | | ... + opt-el | | ... + opt-faces In any case in order to build a single WAR or EAR, can be quite hard on the ANT XML build file. There is a lot of possible copying of files, JARing, and/or JARing involved in order to build a release. In my limited architectural experience you only need to get the initial build right once, then you can forget about it, as long as other people developers understand what is going on. 1) Developers have to understand the project directory structure and standards in order to not to step on each other shoes. e.g In order to build a WAR of all modules that runs out of the box, you cannot have two different sub project developers, say from `examples' and `site', each with a CVS file called CVS-MODULE/web/some/foobar/acme.jsp. Conflict of interest on files. The same applies to source code and resources as well. Top level package names must be agreed well in advanced. Of the course the current mapping CVS-MODULE/src/shared/org/apache/struts/** can be simplified to: CVS-MODULE/src/org/apache/struts/** in the new modular structure. 2) Organise fragments that are included into a larger configuration files. e.g Each sub project may have TLD files, Properties files, i18n resources, or Servlet Mappings and Servlet Paths that are merged into a final file. Servlet mapping fragments are inserted into the final web.xml file. Same goes for any Servlet filters. NB: This is similar to using XML includes notation in order build a giant `struts-config.xml', which shared by a large development team. I am not sure if you need to do this as committers. Only I mention it if you need to build a Struts Adventure Petstore demonstration example in the far off future. Will properties file probably have to merge them with ANT core tasks or some custom made build tool. 3) Agree to keep to a convention document so that the mythical `master' build.xml does not blow up into smitherings. 4) Some one has to write standards conventions document so that everybody knows what time it is, and plays in a solid team. 5) Another other business obviously include JUnit, Struts documentation, javadoc etc etc It is starting resemble a big project with more 10+ developers working across CVS modules. Having said all that I wish you great bundle of luck. Regards -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail:
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote: 1) I think you should keep the same elementary structure Moving forward, we have already decided to use Maven as our build environment, which addresses a number of consistency and structural issues. We had also decided to distribute non-core components, like the taglibs, independantly. Independant releases lead to the idea of independant modules. Modules also seem like a good way to handle bringing on some of the more popular extensions. So, the site subproject would be an overview of the Struts project, and then link to the subprojects (including core) for more detail. A contributor mentioned wanting a single JAR. I don't think that's an itch any of Committers are desparate to scratch. And, if anyone did, it's been pointed out that Ant can be used to burst and combine JARs. Anyone could do that. I don't think anyone wants to build a single Struts WAR, especially since we already have multiple example applications in their own WARs. At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
At 3:47 PM -0500 3/23/04, Ted Husted wrote: At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. I don't have a very strong opinion about it. However, from a Maven perspective, if we want to share resources such as a common project.xml, having multiple modules leaves us with no place to put the shared project. I've also had reasonably good results with the maven multiproject goal for building a number of related projects, which would also require a shared project.xml Plus even if infrastructure doesn't mind making new modules, we don't even have to ask if we want to add new module-like subdirectories under a main struts module. I wouldn't veto a multiple module approach, but these seem like a few decent reasons for having a single CVS module. Cocoon seems to coin new modules with each major version; is that a good approach? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: At 3:47 PM -0500 3/23/04, Ted Husted wrote: At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. I don't have a very strong opinion about it. However, from a Maven perspective, if we want to share resources such as a common project.xml, having multiple modules leaves us with no place to put the shared project. I've also had reasonably good results with the maven multiproject goal for building a number of related projects, which would also require a shared project.xml I just to try build Struts with Maven, what am I doing wrong? [EMAIL PROTECTED] [175] maven java:compile __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: commons-validator-1.1.2-dev.jar (try downloading from http://jakarta.apache.org/commons/validator/) Total time: 6 seconds Finished at: Tue Mar 23 22:11:19 GMT 2004 -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
I just to try build Struts with Maven, what am I doing wrong? ... Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: The problem is that the project.xml file declares a dependency on a version of commons-validator which isn't in your local Maven repository and which is not in the shared repository. Maven looked here: http://ibiblio.org/maven/commons-validator/jars/ for commons-validator-1.1.2-dev.jar and as you can see if you follow that URL, it isn't there. You can control the versions that Maven uses for dependencies by specifying certain properties. (Full details at http://maven.apache.org/reference/user-guide.html#Properties_Processing) Probably the easiest way to set the properties would be to create or edit build.properties in the root of your local Struts sandbox (same directory where build.xml and project.xml are). Add the following lines: maven.jar.override=on maven.jar.commons-validator=1.1.1 That's a version of commons-validator that's on the shared Maven repository, although I don't have time just at the minute to see if Struts will still build against it! You could also check out commons-validator and run maven jar:install-snapshot and use maven.jar.commons-validator=SNAPSHOT instead. Hope that helps. If we stick to our guns about avoiding dependencies on unreleased software, this won't come up again... it's not Maven's fault! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: I just to try build Struts with Maven, what am I doing wrong? ... Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: The problem is that the project.xml file declares a dependency on a version of commons-validator which isn't in your local Maven repository and which is not in the shared repository. Maven looked here: http://ibiblio.org/maven/commons-validator/jars/ for commons-validator-1.1.2-dev.jar and as you can see if you follow that URL, it isn't there. You can control the versions that Maven uses for dependencies by specifying certain properties. (Full details at http://maven.apache.org/reference/user-guide.html#Properties_Processing) Probably the easiest way to set the properties would be to create or edit build.properties in the root of your local Struts sandbox (same directory where build.xml and project.xml are). Add the following lines: maven.jar.override=on maven.jar.commons-validator=1.1.1 That's a version of commons-validator that's on the shared Maven repository, although I don't have time just at the minute to see if Struts will still build against it! Yes the above did the trick. I have update the Struts Wiki page. Ta also. You could also check out commons-validator and run maven jar:install-snapshot and use maven.jar.commons-validator=SNAPSHOT instead. Hope that helps. If we stick to our guns about avoiding dependencies on unreleased software, this won't come up again... it's not Maven's fault! ==== -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: I just to try build Struts with Maven, what am I doing wrong? ... Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: I cannot seem to build the resource files. XSL Templates. [EMAIL PROTECTED] [266] maven jar:install ... java:prepare-filesystem: java:compile: [echo] Compiling to m-target/classes java:jar-resources: Copying 16 files to /new/peterp/jakarta-struts/m-target/classes [style] Transforming into /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-bean.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-bean.tld [style] Loading stylesheet /new/peterp/jakarta-struts/doc/stylesheets/tld.xsl [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-html.tld [style] new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal Error! The content of elements must consist of well-formed character data or markup. [style] Failed to process /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml BUILD FAILED File.. file:/new/peterp/jakarta-struts/ Element... ant:style Line.. 29 Column 28 Fatal error during transformation Total time: 16 seconds Finished at: Wed Mar 24 01:14:25 GMT 2004 What are required `build.properties' for Xalan/Struts? Many tia -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
java:jar-resources: Copying 16 files to /new/peterp/jakarta-struts/m-target/classes [style] Transforming into /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-bean.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-bean.tld [style] Loading stylesheet /new/peterp/jakarta-struts/doc/stylesheets/tld.xsl [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-html.tld [style] new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal Error! The content of elements must consist of well-formed character data or markup. [style] Failed to process /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml I don't think your problem is with XSLT (Xalan is defined as a dependency in project.xml just for this purpose) -- from the logs it looks as if struts-bean.xml is being styled correctly before struts-html.xml fails. It seems unlikely that this would be the problem, but are you sure you have the head version of doc/userGuide/struts-html.xml? I just did maven clean followed by maven jar and didn't get any errors. === File: struts-html.xml Status: Up-to-date Working revision:1.76 Repository revision: 1.76 /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) It's possible that there's some other setting in my build.properties that I don't recognize, but I did a little searching and didn't see anything. If you'd like to compare mine to yours, I could send it privately. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: java:jar-resources: Copying 16 files to /new/peterp/jakarta-struts/m-target/classes ==== [style] new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal Error! The content of elements must consist of well-formed character data or markup. [style] Failed to process /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml I don't think your problem is with XSLT (Xalan is defined as a dependency in project.xml just for this purpose) -- from the logs it looks as if struts-bean.xml is being styled correctly before struts-html.xml fails. It seems unlikely that this would be the problem, but are you sure you have the head version of doc/userGuide/struts-html.xml? I just did maven clean followed by maven jar and didn't get any errors. Thanks Joe Running `maven jar' works now. Looks like it was a CVS conflict with an older version. Purged all the `doc' directory tree, then updated CVS to get latest deltas. I got delta 1.76 for `doc/userGuide/struts-html.xml' too. ==== -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004, Ted Husted wrote: On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote: 1) I think you should keep the same elementary structure Moving forward, we have already decided to use Maven as our build environment, which addresses a number of consistency and structural issues. We had also decided to distribute non-core components, like the taglibs, independantly. Independant releases lead to the idea of independant modules. Modules also seem like a good way to handle bringing on some of the more popular extensions. As Joe mentioned, we would still need somewhere to put the shared files, such as Maven's project.xml, the LICENSE and NOTICE files, the KEYS file, etc. In a single-module world, those would live at the top level, just as they do now. In a multi-module world, those should be in another module solely for that purpose. (I certainly wouldn't want a build file that knows about all the individual modules living in core, or any other independently buildable module.) So, the site subproject would be an overview of the Struts project, and then link to the subprojects (including core) for more detail. A contributor mentioned wanting a single JAR. I don't think that's an itch any of Committers are desparate to scratch. And, if anyone did, it's been pointed out that Ant can be used to burst and combine JARs. Anyone could do that. I don't think anyone wants to build a single Struts WAR, especially since we already have multiple example applications in their own WARs. I don't want a single jar or a single war, but I do want to be able to run *one* build process to get all of the pieces to build. I also don't relish the thought of having to maintain multiple Gump descriptors, either. At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. Yep, that's exactly where we are. ;-) Here's what I think are the pros and cons of each approach: One module, multiple directories: + One checkout grabs it all (but an alias can reference multiple modules). + Natural place (top level) for all cross-module files. (See above.) + Labelling and branching across modules is one CVS command. + Don't need CVS admin karma (i.e. Craig) to create new modules. - Harder (?) to check out only portions of the overall code base. Multiple modules: + Easier (?) to check out only portions of the overall code base. + May scale better as we accumulate extensions. - Need an extra module for cross-module files. - Clutters up the Apache CVS repository. The reason for the question marks is that this issue seems to have been implied, but it's not really true. The difference is literally a single character - 'cvs co struts-core' versus 'cvs co struts/core'. The labelling issue is an interesting one. Someone (hi Ted! ;) is going to argue that we'll want to label each module independently because we'll want to release them independently, and I agree with that. But I also think that there will be points in time that we'll want to label or branch the entire code base, which will be easier to do across a single module. So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;-) -- Martin Cooper My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mar 22, 2004, at 7:28 AM, Joe Germuska wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. Right. I include my JARs in CVS and I've been doing it for quite some time with no issues. To be honest, there doesn't seem to be much difference in storing them in CVS vs. uploading them to a Maven repository. For me, it's often seemed easier to stick them in CVS. Of course, if I had managed to convert AppFuse to use Maven - maybe I wouldn't be so bitter. ;-) I do like to be able to checkout my CVS-based project and disconnect and compile later though. No internet dependency is a good thing. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. That's part of it - as well as Ant is easier to understand IMO. I use Maven on a couple projects, but I definitely prefer Ant - mainly b/c I have an Ant build.xml file that I use on all my projects. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Whatever it takes to make Struts easier to build. I guarantee that if you can build Struts with an ANT_HOME (or MAVEN_HOME) and JAVA_HOME set - and that's it - you'll get a lot more contributions. My $.02. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). David --- Joe Germuska [EMAIL PROTECTED] wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
I agree 100% with Matt and make the same prognostication. At 06:46 AM 3/22/2004, you wrote: On Mar 22, 2004, at 7:28 AM, Joe Germuska wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. Right. I include my JARs in CVS and I've been doing it for quite some time with no issues. To be honest, there doesn't seem to be much difference in storing them in CVS vs. uploading them to a Maven repository. For me, it's often seemed easier to stick them in CVS. Of course, if I had managed to convert AppFuse to use Maven - maybe I wouldn't be so bitter. ;-) I do like to be able to checkout my CVS-based project and disconnect and compile later though. No internet dependency is a good thing. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. That's part of it - as well as Ant is easier to understand IMO. I use Maven on a couple projects, but I definitely prefer Ant - mainly b/c I have an Ant build.xml file that I use on all my projects. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Whatever it takes to make Struts easier to build. I guarantee that if you can build Struts with an ANT_HOME (or MAVEN_HOME) and JAVA_HOME set - and that's it - you'll get a lot more contributions. My $.02. Matt - 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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
I have a somewhat nutty suggestion. I suggest that we have someone who is an administrative genius with a flair for teaching and simple statement be an available guide to assist new people in getting the proper builds to work on struts. Such a person would, I predict, be worth 100 times there weight in gold to this list. How this should work is, of course, up for discussion. Maybe, also, for some reason I don't know, this idea is a clunker. Michael At 06:28 AM 3/22/2004, you wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - 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: Making Struts Build Easier (Re: coming out for JSF + Struts , was: Struts JSR?)
One more comment about the difficult of contribution to open source projects in general. I have used a great deal of open source code and modified it quite a bit, but have never been successful in making contributions, although I have made more than one attempt. The problem I have is that I don't use all the same tools as the typical open source project, i.e. Visual SourceSafe instead of CVS. Of course if you step into a project the size of struts without having experience if the background tools, sh.. quickly hits the fan and you have no hope of making a useful contribution. I have no good answers for this, just passing on my $.02... Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 9:47 AM To: Struts Developers List Subject: Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?) Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). David --- Joe Germuska [EMAIL PROTECTED] wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.638 / Virus Database: 409 - Release Date: 3/21/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.638 / Virus Database: 409 - Release Date: 3/21/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
David Graham [EMAIL PROTECTED] wrote: Personally, I find the Struts build files to be complex and confusing. Two weeks ago, I tried to build the struts 1.1 source package against commons-collections-3.0.jar in order to run the unit tests and insure struts still worked properly. After several hours of trying to set it up and make it work, I finally gave up. There is definitely room for improvement in the build/test process. Like those who posted before me, I don't care if it's ant or maven, only that it works. As a counter-example, on the Cayenne project we have 24 external jar files that are stored in otherlib on CVS, but at least the project builds and tests out of the box. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Quoting David Graham [EMAIL PROTECTED]: Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. It's also possible to set up Maven with a local repository so that offline builds still work, too. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. David Craig --- Joe Germuska [EMAIL PROTECTED] wrote: For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - 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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
At 11:52 AM -0500 3/22/04, Mike Kienenberger wrote: Two weeks ago, I tried to build the struts 1.1 source package against commons-collections-3.0.jar in order to run the unit tests and insure struts still worked properly. After several hours of trying to set it up and make ... Like those who posted before me, I don't care if it's ant or maven, only that it works. Do you have the energy to try again with Maven? It should be as simple as adding a couple of lines to build.properties in your local Struts CVS sandbox: maven.jar.override=on maven.jar.commons-collections=3.0 Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote: Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. I continue to think that the easiest thing in the long run will be a module for each product. Where a product is equivalent to a Maven artifact or a deliverable with its own release cycle. So, if infrastructure doesn't care, and we can centralize the permissions, I'd like to go back to something like * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mar 22, 2004, at 11:28 AM, Ted Husted wrote: On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote: Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. I continue to think that the easiest thing in the long run will be a module for each product. Where a product is equivalent to a Maven artifact or a deliverable with its own release cycle. So, if infrastructure doesn't care, and we can centralize the permissions, I'd like to go back to something like * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces -Ted. While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. My $0.02. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things first!) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
From: Matt Raible [mailto:[EMAIL PROTECTED] I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. Along those lines, I'd like to suggest that a complete WAR and/or EAR of examples be included as one command to checkout. I'd even be happy to roll up my sleeves and see about writing the maven/ant stuff to do it. The idea behind this is to make it real simple for people to get the example working to learn Struts. By 1. Download .war file. 2. Place in Tomcat deploy directory. 3. See it work. 4. Look at source (bundled in war). The biggest complaint I get from my customers is they want a simple, plain example of Struts to learn the basics. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things first!) I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up
