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