Using Struts with mid-large size teams

[Robb Nedwick <rn...@yahoo.com>]

We're about to start a project in which we may be using Struts and the
Validator extension, and I was wondering about any experiences (good and
bad) or problems others have had with mid-large size teams when using
Struts.  The team that will be starting the project will be over 10 people
(not sure how many more at this point, but probably 10-15 or so).  Most
people are already experienced with Java/JSP/EJB and we have an established
architecture for our business tier that is working very well for us.

Struts is being evaluated to help clean up the architecture of our
presentation tier (we have some "MVC-like" concepts in our current code, but
Struts seems like a better setup overall right now).  Anyway, I was
wondering what people's experiences were with this size team.

Some potential problems that strike me right away revolve around the fact
that there's only 1 struts-config.xml and validation.xml file that all the
developers will be editing and that this will cause a lot of conflicts for
that file.  I know there's a patch to allow for multiple struts-config
files, but haven't found a similar patch for the validation.xml file.  Also,
the fact that Struts seems to support only a single resource file for I18N
text seems like it will also cause us problems.

What other problems or good experiences have people run into?  We're getting
ready to get started soon, and I'm trying to get as much info as I can for
justifying the move to Struts and to help me with the prototype I've been
working on for educating the development staff.

Thanks for any answers,

Robb Nedwick
rnedwick@yahoo.com


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Using Struts with mid-large size teams

[Arron Bates <ar...@pacific.net.au>]

Look into the what the nightly build can do for you. The one thing that 
may help out is the sub-app ability allowing multiple config.xml and 
resource files for each sub-section of your app. I haven't used this 
myself, but to some extent it's why it was created.

Arron.

Robb Nedwick wrote:

>We're about to start a project in which we may be using Struts and the
>Validator extension, and I was wondering about any experiences (good and
>bad) or problems others have had with mid-large size teams when using
>Struts.  The team that will be starting the project will be over 10 people
>(not sure how many more at this point, but probably 10-15 or so).  Most
>people are already experienced with Java/JSP/EJB and we have an established
>architecture for our business tier that is working very well for us.
>
>Struts is being evaluated to help clean up the architecture of our
>presentation tier (we have some "MVC-like" concepts in our current code, but
>Struts seems like a better setup overall right now).  Anyway, I was
>wondering what people's experiences were with this size team.
>
>Some potential problems that strike me right away revolve around the fact
>that there's only 1 struts-config.xml and validation.xml file that all the
>developers will be editing and that this will cause a lot of conflicts for
>that file.  I know there's a patch to allow for multiple struts-config
>files, but haven't found a similar patch for the validation.xml file.  Also,
>the fact that Struts seems to support only a single resource file for I18N
>text seems like it will also cause us problems.
>
>What other problems or good experiences have people run into?  We're getting
>ready to get started soon, and I'm trying to get as much info as I can for
>justifying the move to Struts and to help me with the prototype I've been
>working on for educating the development staff.
>
>Thanks for any answers,
>
>Robb Nedwick
>rnedwick@yahoo.com
>
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>