[displaytag-devel] servlet.jar

[Benjamin Simpson]

Adding servlet.jar to the build is a bad idea.   In my experience, I have found that j2ee build dependencies can be resolved with a simple ${servletOrJ2ee.classpath} variable resolved in the developer maintained build.properties file.  This would also be a great place to stick the developer’s preferred logging configuration.  Both dependencies I object to in the current env.   Following this rule, we don’t have to keep the actual j2ee or servlet jars in the tree.   This is a slippery slope of additions and bug fixes without direction.  Or am I missing something?   While I am at it, could someone explain to me why the addition of features and dependencies is more important than fixing problems like this below?   /**     * Replace character at given index with the same character to upper case     *     * @param       oldString old string     * @param       index of replacement     * @return      String new string     * @exception   StringIndexOutOfBoundsException &nbsp;     *     **/    public static String toUpperCaseAt( String oldString, int index )       throws NullPointerException, StringIndexOutOfBoundsException    {       int length = oldString.length();       String newString = "";         if( index >= length || index < 0 ) {          throw new StringIndexOutOfBoundsException(             "Index " + index             + " is out of bounds for string length " + length );       }         //get upper case replacement       String upper = String.valueOf( oldString.charAt( index ) ).toUpperCase();         //avoid index out of bounds       String paddedString = oldString + " ";         //get reusable parts       String beforeIndex = paddedString.substring( 0, index );       String afterIndex = paddedString.substring( index + 1 );         //generate new String - remove padding spaces       newString = ( beforeIndex + upper + afterIndex ).substring( 0, length );         return newString;    }     <<<<<<<<<<<<<<<<<  Hmm.  Looks like we like making new strings… >>>>>>>>>>>>>>>>>>>>>>     /**      * Replace character at given index with the same character to upper case      * This utility was refactored from the StringUtils class in the      * display taglibs project.  The replaced code is commented out below to see the      * changes that were made.      *      * @param       oldString old string      * @param       index of replacement      * @return      String new string      **/     public static String toUpperCaseAt(final String oldString,                                        final int index) {         final int len = oldString == null ? -1 : oldString.length();         if(len <= index) return "";         final char [] chars = oldString.toCharArray();         chars[index] = Character.toUpperCase(chars[index]);         return String.valueOf(chars);     }   <<<<<<<<<<<<<<<<<  Hmm.  Looks better, but I am sure there is an even more efficient way to perform the simple task…… >>>>>>>>>>>>>>>>>>>>>>   Through shared examples of how we have taken apart and put back together the .85 release of Ed Hill’s Display Tag Library we will discover the best way to do the simple task of bringing back tabular data for the user.  There should be more arguments about where to inject an Interface and less discussion about who is going to contribute a one off bug fix.   I don’t mean to sound angry, but wtf???  It’s a Saturday.  I want to contribute while my kids are napping.  Where is this project going?   Ben Simpson