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

[Martin Cooper]

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  with a
> > Struts minimum Servlet level of 2.4 where  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?)

[Craig R. McClanahan]

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  tag to really be useful last year
> >>at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
> >> or  statment is verbose. If there not EL equivalent
> >>of , 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  ( -- among
> other
> > fancy things you can make it create hierarchical option lists by emitting
> >  very easily), as well as equivalents for 
> > ( for a single field,  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  and  dependent on a JSF implementation
> or can they be used standalone?
> 

The  and  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 .
> > 
> >>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  in the
Struts-Faces integration library.  It is a JSF component, but it has semantics
like the  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 , ,
 , , , , and
 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.
> > 
> 
>  superceded by JSTL
>  superceded by JSTL
>  superceded by JSTL
>  superceded by JSTL
>  superceded by JSTL
>  superceded by JSTL
>  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.

>  no equalivant in JSTL 1.0  but exists String functions in JSTL
> 1.1
> 
>  replace with 
> 
>   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 ...
> 

The STRUTS-EL doc

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

[Kris Schneider]

+1. Just keeping the functionality facts straight...

Quoting David Graham <[EMAIL PROTECTED]>:

> 
> --- Kris Schneider <[EMAIL PROTECTED]> wrote:
> > Nope.  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]>:
> > 
> > > ...
> > >   no equalivant in JSTL 1.0  but exists String functions
> > in 
> > > JSTL 1.1
> > > ...
> > > 
> > > logic:match equivalent is :
> > > >>
> > > >>
> > > >>> 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  tag to really be useful 
> > > >>> last year
> > > >>> at RBS generating HTML OPTIONS elements. Repeating the same thing
> > JSTL
> > > >>>  or  statment is verbose. If there not EL equivalent
> > > >>> of , 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  ( --
> > 
> > > >> among other
> > > >> fancy things you can make it create hierarchical option lists by 
> > > >> emitting
> > > >>  very easily), as well as equivalents for 
> > > >> ( for a single field,  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  and  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 .
> > > >
> > > >>
> > > >>> 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.
> > > >>
> > > >
> > > >  superceded by JSTL
> > > >  superceded by JSTL
> > > >  superceded by JSTL
> > > >  superceded by JSTL
> > > >  superceded by JSTL
> > > >  superceded by JSTL
> > > 

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

[David Graham]

--- Kris Schneider <[EMAIL PROTECTED]> wrote:
> Nope.  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]>:
> 
> > ...
> >   no equalivant in JSTL 1.0  but exists String functions
> in 
> > JSTL 1.1
> > ...
> > 
> > logic:match equivalent is :
> > >>
> > >>
> > >>> 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  tag to really be useful 
> > >>> last year
> > >>> at RBS generating HTML OPTIONS elements. Repeating the same thing
> JSTL
> > >>>  or  statment is verbose. If there not EL equivalent
> > >>> of , 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  ( --
> 
> > >> among other
> > >> fancy things you can make it create hierarchical option lists by 
> > >> emitting
> > >>  very easily), as well as equivalents for 
> > >> ( for a single field,  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  and  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 .
> > >
> > >>
> > >>> 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.
> > >>
> > >
> > >  superceded by JSTL
> > >  superceded by JSTL
> > >  superceded by JSTL
> > >  superceded by JSTL
> > >  superceded by JSTL
> > >  superceded by JSTL
> > >  superceded by JSTL
> > > etc
> > >
> > >  no equalivant in JSTL 1.0  but exists String functions
> 
> > > in JSTL 1.1
> > >
> > >  replace with 
> > >
> > >   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 tagl

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

[Kris Schneider]

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.  does substring matching.
> >
> >Quoting Tim Chen <[EMAIL PROTECTED]>:
> >
> >  
> >
> >>...
> >>  no equalivant in JSTL 1.0  but exists String functions in 
> >>JSTL 1.1
> >>...
> >>
> >>logic:match equivalent is :
> 
> 
> 
> 
> >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  tag to really be useful 
> >last year
> >at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
> > or  statment is verbose. If there not EL equivalent
> >of , 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  ( -- 
> among other
> fancy things you can make it create hierarchical option lists by 
> emitting
>  very easily), as well as equivalents for 
> ( for a single field,  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  and  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 .
> >>>
> >>>  
> >>>
> >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.
> 
> 
> 
> >>> superceded by JSTL
> >>> superceded by JSTL
> >

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

[Tim Chen]

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.  does substring matching.

Quoting Tim Chen <[EMAIL PROTECTED]>:

 

...
 no equalivant in JSTL 1.0  but exists String functions in 
JSTL 1.1
...

logic:match equivalent is 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  tag to really be useful 
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
 or  statment is verbose. If there not EL equivalent
of , 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  ( -- 
among other
fancy things you can make it create hierarchical option lists by 
emitting
 very easily), as well as equivalents for 
( for a single field,  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  and  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 .
 

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.

   

 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
etc
 no equalivant in JSTL 1.0  but exists String functions 
in JSTL 1.1

 replace with 

  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?)

[Kris Schneider]

Nope.  does substring matching.

Quoting Tim Chen <[EMAIL PROTECTED]>:

> ...
>   no equalivant in JSTL 1.0  but exists String functions in 
> JSTL 1.1
> ...
> 
> logic:match equivalent is :
> >>
> >>
> >>> 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  tag to really be useful 
> >>> last year
> >>> at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
> >>>  or  statment is verbose. If there not EL equivalent
> >>> of , 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  ( -- 
> >> among other
> >> fancy things you can make it create hierarchical option lists by 
> >> emitting
> >>  very easily), as well as equivalents for 
> >> ( for a single field,  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  and  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 .
> >
> >>
> >>> 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.
> >>
> >
> >  superceded by JSTL
> >  superceded by JSTL
> >  superceded by JSTL
> >  superceded by JSTL
> >  superceded by JSTL
> >  superceded by JSTL
> >  superceded by JSTL
> > etc
> >
> >  no equalivant in JSTL 1.0  but exists String functions 
> > in JSTL 1.1
> >
> >  replace with 
> >
> >   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 
D.O.Tech   

-
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]

--- "Peter A. Pilgrim" <[EMAIL PROTECTED]> wrote:



>   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  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?)

[Tim Chen]

...
 no equalivant in JSTL 1.0  but exists String functions in 
JSTL 1.1
...

logic:match equivalent is 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  tag to really be useful 
last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
 or  statment is verbose. If there not EL equivalent
of , 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  ( -- 
among other
fancy things you can make it create hierarchical option lists by 
emitting
 very easily), as well as equivalents for 
( for a single field,  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  and  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 .

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.

 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
etc
 no equalivant in JSTL 1.0  but exists String functions 
in JSTL 1.1

 replace with 

  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]

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  tag to really be useful last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
 or  statment is verbose. If there not EL equivalent
of , 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  ( -- among other
fancy things you can make it create hierarchical option lists by emitting
 very easily), as well as equivalents for 
( for a single field,  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  and  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 .

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.
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
 superceded by JSTL
etc
 no equalivant in JSTL 1.0  but exists String functions in JSTL 1.1

 replace with 

  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?)

[David Graham]

--- 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  with a
> > Struts minimum Servlet level of 2.4 where  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  are still useful for Struts 1.x. 
However, since Struts 2.x will be based on at least Servlet 2.3 where
 is available, IMO  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?)

[Ted Husted]

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  with a
> Struts minimum Servlet level of 2.4 where  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?)

[David Graham]

--- 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  with a Struts
minimum Servlet level of 2.4 where  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?)

[Arron Bates]

> --- 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?)

[Craig R. McClanahan]

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  tag to really be useful last year
> at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
>  or  statment is verbose. If there not EL equivalent
> of , 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  ( -- among other
fancy things you can make it create hierarchical option lists by emitting
 very easily), as well as equivalents for 
( for a single field,  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?)

[Peter A. Pilgrim]

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  tag to really be useful last year
at RBS generating HTML OPTIONS elements. Repeating the same thing JSTL
 or  statment is verbose. If there not EL equivalent
of , 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?)

[Joe Germuska]

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]

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?)

[David Graham]

--- 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.

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?)

[Joe Germuska]

 > 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

--
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?)

[Ted Husted]

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?)

[David Graham]

--- 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?)

[Craig R. McClanahan]

Quoting Ted Husted <[EMAIL PROTECTED]>:

> 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. 
> 

As I've mentioned before, JavaServer Faces is not just about JSP custom tags ...
the components and renderers in this package are just like Struts itself, in
that they're view technology independent.  Technologically, therefoe, "faces"
does not belong under "taglibs".

Further, I'd think the Struts developers would want to explore ways in which
other parts of Struts might benefit from some of the infrastructure features in
JSF, such as managed beans and programmatic expression evaluation.  They are
darned handy.

> 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  :(

Agreed.

> -Ted.

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]

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...

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?)

[Ted Husted]

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?)

[Peter A. Pilgrim]

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")
 \opt-taglib \opt-el \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 / -> /
Are keeping the basic `src' and `web' main sub directory under each
top level directory?
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
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 :)
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.
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.
** 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?
-Ted.
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: [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]

At 2:17 PM -0500 3/24/04, Ted Husted wrote:
 >> \opt-el

 Hmm. This is also a taglib...
But with different platform requirements. :)
Yes, but is there any reason not to treat them as a single 
deliverable?  They have interdependencies that would make this 
attractive, and if users use the correct TLD file, the platform 
dependencies should be invisible.

One wrinkle I see would be that from a compilation standpoint, it 
would be difficult to control the servletapi dependencies, so there 
would be some risk of building the base taglibs using Servlet 2.3 
features.

Even so, I think it's worth looking at making a single 
struts-taglib.jar that would integrate both forms.

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?)

[Ted Husted]

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?)

[Martin Cooper]

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?)

[Matt Raible]

> -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?)

[Ted Husted]

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?)

[Joe Germuska]

At 6:08 AM -0800 3/24/04, David Graham wrote:
--- Joe Germuska <[EMAIL PROTECTED]> wrote:

 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.
Fair enough...  but there's still a snag between the apparently high 
demand for an easy-to-build Struts (based on the traffic in this 
thread) and using dependencies that aren't served from iBiblio.

Basically, the alternatives are to get all dependency versions on 
some repository server somewhere, or to try to better document the 
workarounds when they are necessary.  For a while, I had a comment 
block in project.xml explaining how to work around an unreleased 
validator dependency, but I took it out when the dependency version 
was one served from iBiblio.

In January, there was a thread on commons-dev about syncing Apache 
builds with iBiblio.  It suggested that there might be a secondary 
repository on cvs.apache.org for nightly builds, but it doesn't 
appear that it has been set up.  Don't know if it's stalled, or if it 
was vetoed.

http://thread.gmane.org/gmane.comp.jakarta.commons.devel/39462

It's conceptually easy to add alternative repositories in addition to 
ibiblio -- in fact, our project.properties file has a commented-out 
line from last time we were in this situation, but the repository 
indicated is 404.

I think the solution suggested by Mark Diggory in the commons-dev 
thread (a backup repo for nightly builds) is a pretty good idea; 
maybe we just have to push someone to get it actually set up?

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?)

[Matt Raible]

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?)

[David Graham]

--- Joe Germuska <[EMAIL PROTECTED]> wrote:


> 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?)

[Ted Husted]

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")
\opt-taglib
\opt-el
\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 :)

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.

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.

** 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?


-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?)

[Martin Cooper]

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?)

[Peter A. Pilgrim]

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?)

[Joe Germuska]

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?)

[Peter A. Pilgrim]

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?)

[Peter A. Pilgrim]

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]

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?)

[Peter A. Pilgrim]

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?)

[Joe Germuska]

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?)

[Ted Husted]

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?)

[Peter A. Pilgrim]

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
/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
/src/shared/org/apache/struts/**

can be simplified to:

/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: [EMAIL PROTECTED]
For a

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

[Steve Raeburn]

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

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

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

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

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

Steve


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

Re: "coming out" for JSF + Struts, was: Struts JSR?)

[Michael McGrady]

+1

At 03:15 AM 3/23/2004, you wrote:
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]


-
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]

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?)

[Paul Speed]

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:








-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]

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]

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?)

[Peter A. Pilgrim]

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 avai

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

[Martin Cooper]

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 giv

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

[Craig R. McClanahan]

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

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

[Martin Cooper]

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

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

[Martin Cooper]

On Mon, 22 Mar 2004 [EMAIL PROTECTED] wrote:

> Hi
>
> I think that the move to Maven is a giant leap forward. Now at least we
> can build with requisite jars that are already build. Earlier it ment
> that you would have to buil a bunch of projects before you could
> actually do the real build. Also you can have local repositories for
> when you are offline.

Building the dependencies yourself has *never* been required for Struts.
You can build against released versions of Commons components, or, when
those are in flux and we've been depending on unreleased features, on the
nightly builds of them.

Note that with Maven, you actually have a stronger requirement than with
the Ant build - that the versions of the Commons dependencies you need
have been made available in a Maven repository. (Yes, that can be worked
around, but we're talking here about the ease with which you can just type
'maven' and have everything happen.)

--
Martin Cooper


>
> Hermod
>
> -Opprinnelig melding-
> Fra: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sendt: 22. mars 2004 15:28
> Til: Struts Developers List
> Emne: Making Struts Build Easier (Re: "coming out" for JSF + Struts,
> was: Struts JSR?)
>
>
> >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
>
>

-
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?)

[Gary D Ashley Jr.]

> 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: "coming out" for JSF + Struts, was: Struts JSR?

[Gary D Ashley Jr.]

A simple google search provides a wealth of information:

http://www.google.com/search?q=craig+struts+jsf


PS
Unless I'm missing the sub plot where the "criminal mastermind/evil
genius" tricks us all into using "the wrong" framework, maybe I'm
mistaken, but a simple 'Hey, Thanks Craig' for all the passion and hard
work on Struts and JSF is better than the conspiracy theory innuendos.
;-)   So, Thanks Craig, and by all means, let your code do the talking!

(sorry, temptation to rant got me)  


-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 22, 2004 11:35 AM
To: Struts Developers List
Subject: Re: "coming out" for JSF + Struts, was: Struts JSR?

Quoting Thomas L Roche <[EMAIL PROTECTED]>:

> Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM)
> >> summary: McClanahan should clearly state *in some major
publication*
> 
> >> * that JSF does/will not "replace Struts"
> 
> >> * how JSF and Struts will likely tend to specialize, in future
> 
> >> * how probable specializations will complement (and compete) in
> >>   webapp development
> 
> Ted Husted Sun, 21 Mar 2004 20:28:17 -0500
> > But I think either of us would rather be developing Struts than
> > evangelizing Struts.
> 
> This is not about "evangelizing": it's about clarifying the
> relationship between 2 large parts of J2EE's future, and correcting
> some (apparently) false perceptions. Frankly, I'm perplexed why the
> propagation of the latter has gone unchecked for so long.
> 

That's actually easy to understand.  People believe what they want to
believe,
no matter what I or anyone else says.  I've said exactly the same thing
about
the relationship between Struts and JavaServer Faces for the last 18
months,
and it's going to work out pretty much exactly as I've been saying all
along. 
That doesn't mean anyone is listening, however.

My personal plan is to speak more with code than with words, and ensure
that
Struts continues to include useful functionality that is not present in
the
J2EE platform and its associated standards.  That way, the choice of
whether or
not to use Struts will be based on benefits you gain from using it, just
like
it always has been, and just like it was P.J. (pre-JavaServer Faces :-).

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?)

[Ted Husted]

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?)

[Matt Raible]

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?)

[Ted Husted]

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?)

[Joe Germuska]

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?)

[Craig R. McClanahan]

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: "coming out" for JSF + Struts, was: Struts JSR?

[Craig R. McClanahan]

Quoting Thomas L Roche <[EMAIL PROTECTED]>:

> Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM)
> >> summary: McClanahan should clearly state *in some major publication*
> 
> >> * that JSF does/will not "replace Struts"
> 
> >> * how JSF and Struts will likely tend to specialize, in future
> 
> >> * how probable specializations will complement (and compete) in
> >>   webapp development
> 
> Ted Husted Sun, 21 Mar 2004 20:28:17 -0500
> > But I think either of us would rather be developing Struts than
> > evangelizing Struts.
> 
> This is not about "evangelizing": it's about clarifying the
> relationship between 2 large parts of J2EE's future, and correcting
> some (apparently) false perceptions. Frankly, I'm perplexed why the
> propagation of the latter has gone unchecked for so long.
> 

That's actually easy to understand.  People believe what they want to believe,
no matter what I or anyone else says.  I've said exactly the same thing about
the relationship between Struts and JavaServer Faces for the last 18 months,
and it's going to work out pretty much exactly as I've been saying all along. 
That doesn't mean anyone is listening, however.

My personal plan is to speak more with code than with words, and ensure that
Struts continues to include useful functionality that is not present in the
J2EE platform and its associated standards.  That way, the choice of whether or
not to use Struts will be based on benefits you gain from using it, just like
it always has been, and just like it was P.J. (pre-JavaServer Faces :-).

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?)

[Mike Kienenberger]

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?)

[Edgar P Dollin]

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?)

[Don Brown]

If the automatic download of dependencies is the issue, why not use something like 
Greebo (http://greebo.sourceforge.net/) for folks who perfer Ant?  Even a simple ant 
task that parses dependencies.xml and downloads the jars from ibiblio would suffice.  

Don


- Original Message -
From: David Graham <[EMAIL PROTECTED]>
Date: Mon, 22 Mar 2004 06:46:32 -0800 (PST)
To: Struts Developers List <[EMAIL PROTECTED]>
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]
> 

-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm


-
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?)

[Michael McGrady]

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?)

[Michael McGrady]

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: "coming out" for JSF + Struts, was: Struts JSR?

[Michael McGrady]

I have to agree.  I am somewhat accomplished at programming, but I have 
limited "administrative" talents.  I would have contributed a lot, but I 
just have not been able to talk myself into spending my time learning how 
to get what I need to help.  This is no excuse.  I still feel guilty as 
hell.  But, this is, I would guess, the major block to most people who do 
not contribute.

Michael

At 05:45 AM 3/22/2004, you wrote:

On Mar 22, 2004, at 6:13 AM, Ted Husted wrote:
My point is that this type of prognostication doesn't help Struts in any 
way that matters. What helps is people rolling up their sleeves and doing 
the work. Given the vast numbers of developers using Struts, I'm 
constantly astonished at how hard it is to find more people willing and 
able to do the work.
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. ;-)

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?)

[David Graham]

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?)

[Matt Raible]

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]

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

[hermod . opstvedt]

Hi

I think that the move to Maven is a giant leap forward. Now at least we
can build with requisite jars that are already build. Earlier it ment
that you would have to buil a bunch of projects before you could
actually do the real build. Also you can have local repositories for
when you are offline.

Hermod

-Opprinnelig melding-
Fra: Joe Germuska [mailto:[EMAIL PROTECTED]
Sendt: 22. mars 2004 15:28
Til: Struts Developers List
Emne: Making Struts Build Easier (Re: "coming out" for JSF + Struts,
was: Struts JSR?)


>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]


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


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

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

[Joe Germuska]

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]

Re: "coming out" for JSF + Struts, was: Struts JSR?

[Matt Raible]

On Mar 22, 2004, at 6:13 AM, Ted Husted wrote:
My point is that this type of prognostication doesn't help Struts in 
any way that matters. What helps is people rolling up their sleeves 
and doing the work. Given the vast numbers of developers using Struts, 
I'm constantly astonished at how hard it is to find more people 
willing and able to do the work.

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. ;-)

Matt
 

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

Re: "coming out" for JSF + Struts, was: Struts JSR?

[Ted Husted]

On Mon, 22 Mar 2004 08:00:00 -0500, Thomas L Roche wrote:
> Ted Husted Sun, 21 Mar 2004 20:28:17 -0500
>> But I think either of us would rather be developing Struts than
>> evangelizing Struts.
>>
>
> This is not about "evangelizing": it's about clarifying the
> relationship between 2 large parts of J2EE's future, and correcting
> some (apparently) false perceptions. Frankly, I'm perplexed why the
> propagation of the latter has gone unchecked for so long.

The absolute truth is that "nobody knows".

In practice, we might find that these perceptions are true. Or we may find that these 
perceptions are false. Or, more likely, we will find that they are sometimes true and 
sometimes false. David G doesn't know what will actually happen, neither do I, nor 
you, or even Craig. So, this would just be Craig's best guess against David's best 
guess. May the best guesser win :)

My point is that this type of prognostication doesn't help Struts in any way that 
matters. What helps is people rolling up their sleeves and doing the work. Given the 
vast numbers of developers using Struts, I'm constantly astonished at how hard it is 
to find more people willing and able to do the work. (Except on the user list, where 
I'm constantly astonished at the willingness of users to help other users.)

Sometimes I think market-share actually hurts a project like Struts, since everybody 
thinks somebody else is going to do it :)

-Ted.



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

"coming out" for JSF + Struts, was: Struts JSR?

[Thomas L Roche]

Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM)
>> summary: McClanahan should clearly state *in some major publication*

>> * that JSF does/will not "replace Struts"

>> * how JSF and Struts will likely tend to specialize, in future

>> * how probable specializations will complement (and compete) in
>>   webapp development

Ted Husted Sun, 21 Mar 2004 20:28:17 -0500
> But I think either of us would rather be developing Struts than
> evangelizing Struts.

This is not about "evangelizing": it's about clarifying the
relationship between 2 large parts of J2EE's future, and correcting
some (apparently) false perceptions. Frankly, I'm perplexed why the
propagation of the latter has gone unchecked for so long.


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

Re: "coming out" for JSF + Struts, was: Struts JSR?

[Ted Husted]

On Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM) wrote:
> summary: McClanahan should clearly state *in some major publication*

IMHO, either people like us will be able use JSF without Struts, or we won't.

If we can, great. Less is more. If we can't, we'll create whatever components we need 
to make it so. Darwin will decide. As long as any of us need Struts, we'll keep 
developing Struts. Period. What other people say doesn't matter. If that want to use 
what we use, great. If not, also great. It will still work the same for us either way. 
:)

And, of course, Struts isn't just about JSP tags. A lot of people use Struts with 
Velocity and XLST templates. JSF support for these technologies is a ways off yet.

My real feeling is that struts-dev doesn't need to get swept up in the discussions of 
what-might-be. Market share isn't important. What is important is that we develop what 
we need to use today so that we can be using it tomorrow. Not the figurative tomorrow, 
but the literal one :)

If anyone is *really* interested in showing what a significant Struts+JSF application 
looks like, then someone should roll up their own sleeves and just do it. I'd 
recommend the JPetstore as a likely starting point :)

http://www.ibatis.com/jpetstore/jpetstore.html

Craig's often said that he'd rather be coding than writing about code. Me, I'm happy 
doing either :) -- But I think either of us would rather be developing Struts than 
evangelizing Struts. The proof of the pudding is in the taste.


-Ted.



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

"coming out" for JSF + Struts, was: Struts JSR?

[Thomas L Roche]

summary: McClanahan should clearly state *in some major publication*

* that JSF does/will not "replace Struts"

* how JSF and Struts will likely tend to specialize, in future

* how probable specializations will complement (and compete) in
  webapp development

I.e. pretty much what he has already said in this list, but much more
visibly.

details:

Craig R. McClanahan Sat, 20 Mar 2004 20:57:04 -0800 (rearranged)
> There is going to be tremendous support for JSF in the industry;
> fortunately, we can continue to maintain and enhance Struts without
> having to give that up (thanks to the integration library). Instead,
> we can embrace it

The problem, as I see it, is how to make the industry understand that
JSF will also embrace Struts? (and not in the sense of "embrace and
extend" :-) More below, esp re SFIL.

> My personal vision is that Struts developers will focus their energy
> on the controller and model tiers, leveraging the existence of
> standard (and not) technologies in the view tier.

Personally I agree strongly, and FWIW have advocated something very
similar (i.e. JSF both for view AND as a "M$-killer" for Model1 apps)
in local fora, e.g.

http://ns.cnconsulting.com/pipermail/juglist_trijug.org/2003q4/001106.html

ISTMT this also would also make a lotta sense for JSF, since (again,
it seems to _me_--my bosses may disagree) 

* no one framework is ever gonna do all of Java MVC web application
  development/execution the way that most IT folks want to do it
  (since "most folks" can never agree on much of anything 
  specific :-)

* no one framework is ever gonna have all the resources/mindshare to
  do all of Java MVC web application development/execution "right"
  (presuming "right" could be agreed on), therefore specialization
  makes sense

* MVC is a natural partition for such specialization

Unfortunately

* The JSF community seems to be putting out a competing message, not a
  complementary one: "JSF will replace Struts," or even "JSF is a
  better Struts."

· E.g. Geary said, flat out (not only is it in my notes, I believe
  it was verbatim in a slide), "Is JSF a replacement for Struts? Yes!"

  I challenged him, saying that while JSF 1.0 (with Tiles) can do
  pretty much everything Struts 1.1 can, Struts 2.0 seemed to be
  focused on doing things (e.g. struts-chain) that did not seem to be
  in the JSF plan. At which point he backed off, but continued to
  suggest that JSF should be favored for new-project development. (To
  his credit, Geary also made clear that "JSF and Tiles is a sweet
  combination.")

· One also hears that JCP is "more standard" than the Apache
  process, thus a more better target for development orgs. (Typically
  the Apache process is also deprecated by association with the
  unfortunate Struts 1.0--1.1 delays.) A popular variation asserts
  that JSF will eventually become part of the J2EE spec, while Struts
  never will.

* The "JSF replaces Struts" line has traction. I have heard it from
  consultants (and not just Geary), ISVs, and from ... highly-placed
  persons who I believe should know better :-(

* The "JSF replaces Struts" line has practical impact (which demands
  a substantial, visible response--more on that farther below)

· Development organizations have limited budgets. Managers of
  development orgs always want to "pick _the_ winner" (not just "a
  winner") if they can. There are of course a lotta webapps still to
  be written, and still a LOT of Model1 and "Model1.5" webapps out
  there, many of which folks wanna make more MVC. I suspect managers
  of their development groups will be most receptive to the "JSF (and
  not Struts) for new project development" line.

· Java tool developers face an esp crowded field of Java MVC web
  apps. We are gonna _hafta_ tool JSF, and we want to--it's nicely
  designed, and we wanna target the {Model1, "departmental developer",
  SMB, ASP.NET} space. But when managers of Java tool developers hear
  that "JSF will bury Struts," and hear about their budgets, they are
  gonna wanna say things like, "going forward we expect to actively
  tool JSF and to sunset Struts."

  Note that while I expect tool adoption/quality to be crucial for JSF
  (which very much seems "built to tool"), I do not consider it quite
  so important for Struts. That being said, good tools help, and I am
  very proud of my group's Struts tools, such as our web diagram
  editor. (FWIW I expect to be equally proud of our JSF tools in the
  very near future, and to continue to improve and extend our Struts
  support.)

So ... what to do about this? For starters, "we" can advocate that

* JSF is NOT gonna make Struts obsolete

* JSF AND Struts {is, will be} a sweet combination

but unfortunately I suspect that will not be enough: something's gotta
come "from the top," by which I mean (not entirely in jest)
McClanahan.

Steve Raeburn Sat, 20 Mar 2004 11:40:45 -0800 (rearranged)
>> As the creator of Struts and spec lead for JSF, I think Craig is i