Thanks for the responses. I hadn't appreciated the strength of feeling against using external dependencies.
I disagree that using the commons-lang helper classes would yield code that's more likely to contain errors, and also believe they yield more readable code than the auto-generated version. Nevertheless, whatever your view of their usefulness, I agree they are not essential so will remove them from the wiki page. I'll add the general policy on external dependencies to the design page [1], and suggest we resolve the logging questions in a separate thread. If we do come across more external libraries that have a stronger case for inclusion (e.g. an I/O library), can I assume tools like jarjar [2] have already been examined and dismissed? Also, any views on the stuff I wrote on the wiki page about TODO comments? *adjusts tin hat* [1] https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Requirements+and+Design [2] https://code.google.com/p/jarjar/ On 4 June 2013 18:58, Rajith Attapattu <[email protected]> wrote: > On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey <[email protected]> > wrote: > > > On 4 June 2013 18:54, Rajith Attapattu <[email protected]> wrote: > > > > > I'm strongly against using dependencies for the JMS client unless it's > > > unavoidable. > > > We can make exception for slf4j, but even then my preference is to use > > JDK > > > logging. > > > > > > > If only JDK logging weren't so horrible :-) > > > > Agreed, hence my reason to make an exception for slf4j :D > > > > > > > > > > We've had several issues dealing with dependencies in the past. > > > > > > Increasingly our client is being used in various containers like > > > AppServers, ESB's etc.. and mismatched libraries have caused issues. > > > If I put my rpm-packager hat on, then not having dependencies is a huge > > > bonus. > > > > > > One of the explicit goals of proton was to keep the dependencies to a > > > minimum (if not eliminate it completely). > > > I think we should extend that goal for the JMS client as well. > > > > > > > > Agreed. Maybe this is something we should add to the coding standards > :-) > > > > +1 > > > > > -- Rob > > > > > > > Having a compact, dependency free library is always a plus point. > > > > > > Rajith > > > > > > > > > On Tue, Jun 4, 2013 at 12:46 PM, Rob Godfrey <[email protected] > > > >wrote: > > > > > > > On 4 June 2013 18:37, Phil Harvey <[email protected]> wrote: > > > > > > > > > Ah, I expected a swift response about this. Luckily I'd already > > donned > > > > my > > > > > tin hat :-) > > > > > > > > > > On 4 June 2013 17:16, Rob Godfrey <[email protected]> wrote: > > > > > > > > > > > I'm not really a big fan of enforcing commons lang for toString > - > > > > > > sometimes you want/need to have a specific string representation > of > > > an > > > > > > object. > > > > > > > > > > > > > > > Indeed - that's why I wrote "should" rather than "must". I accept > > that > > > > > there are exceptional cases but believe there's a benefit in the > > other > > > > 90% > > > > > of classes doing things in the same way as each other. > > > > > > > > > > For clarity I will add the usual "should vs must" distinction at > the > > > top > > > > of > > > > > the wiki page. > > > > > > > > > > > > > > > > Similarly I think we should be intelligent in defining equals > and > > > > > > hashCode() methods. > > > > > > > > > > > > What I'd actually prefer to say is that every object should > define > > a > > > > > > toString(). > > > > > > > > > > > > > > > > Yep, that's in the main coding standards already. > > > > > > > > > > > > > > > > > In general I'd like to avoid having dependence on external > > libraries > > > > > unless > > > > > > we *really* need to. > > > > > > > > > > > > > > > > You presumably believe that the use of EqualsBuilder and > > > HashCodeBuilder > > > > > for faciliating the bug-free implementation of equals() and > > hashCode() > > > > does > > > > > not merit the inclusion of commons-lang as a dependency? > > > > > > > > > > > > > > > > > > They are tools but, to be honest, my IDE will build correct equals > and > > > > hashCode methods for me (and toString as well) whereas it wouldn't > > > generate > > > > code which used commons lang in this way, so it'd be adding work for > me > > > and > > > > likely increasing the likelihood of my making an error (what with the > > IDE > > > > being automated and all, versus having to code the commans lang > > approach > > > by > > > > hand). > > > > > > > > So... no I don't think it merits adding a dependency to the JMS > client. > > > > Adding any library as a dependency for the client is a big deal > because > > > it > > > > introduces the possibility of a dependency clash with the application > > the > > > > library is being used by. SLF4J is specifically designed for this > case > > > and > > > > is perhaps the only library I'd feel comfortable depending on. > > > Everything > > > > else would need a much stronger justification in my book :-) > > > > > > > > -- Rob > > > > > > > > > >
