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