On Dec 21, 2009, at 6:28 PM, Adam Heath wrote: > David E Jones wrote: >> On Dec 21, 2009, at 2:04 AM, Adam Heath wrote: >> >>> David E Jones wrote: >>>> On Dec 21, 2009, at 1:49 AM, Adam Heath wrote: >>>> >>>>> David E Jones wrote: >>>>>> On Dec 21, 2009, at 1:35 AM, Adam Heath wrote: >>>>>> >>>>>>> [email protected] wrote: >>>>>>>> Author: hansbak >>>>>>>> Date: Mon Dec 21 07:31:58 2009 >>>>>>>> New Revision: 892712 >>>>>>>> >>>>>>>> URL: http://svn.apache.org/viewvc?rev=892712&view=rev >>>>>>>> Log: >>>>>>>> Upgrade Axis1 to Axis2. Ofbiz now supports complex parameters in >>>>>>>> webservices including WSDL generation. see OFBIZ-3363 for more info. A >>>>>>>> contribution of Antwebsystems employee Chatree >>>>>>>> >>>>>>>> Added: >>>>>>>> ofbiz/trunk/framework/service/lib/XmlSchema-1.4.3.jar (with props) >>>>>>>> ofbiz/trunk/framework/service/lib/axiom-api-1.2.8.jar (with props) >>>>>>>> ofbiz/trunk/framework/service/lib/axiom-impl-1.2.8.jar (with props) >>>>>>>> ofbiz/trunk/framework/service/lib/axis2-kernel-1.5.1.jar (with props) >>>>>>>> ofbiz/trunk/framework/service/lib/axis2-transport-http-1.5.1.jar >>>>>>>> (with props) >>>>>>>> ofbiz/trunk/framework/service/lib/axis2-transport-local-1.5.1.jar >>>>>>>> (with props) >>>>>>>> ofbiz/trunk/framework/service/lib/commons-httpclient-3.1.jar (with >>>>>>>> props) >>>>>>>> ofbiz/trunk/framework/service/lib/neethi-2.0.4.jar (with props) >>>>>>>> ofbiz/trunk/framework/service/src/org/ofbiz/service/test/ServiceSOAPTests.java >>>>>>>> (with props) >>>>>>>> Modified: >>>>>>>> ofbiz/trunk/LICENSE >>>>>>>> ofbiz/trunk/framework/common/servicedef/services_test.xml >>>>>>>> ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java >>>>>>>> ofbiz/trunk/framework/service/src/org/ofbiz/service/ModelParam.java >>>>>>>> ofbiz/trunk/framework/service/src/org/ofbiz/service/ModelService.java >>>>>>>> ofbiz/trunk/framework/service/src/org/ofbiz/service/engine/SOAPClientEngine.java >>>>>>>> ofbiz/trunk/framework/service/testdef/servicetests.xml >>>>>>>> ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/event/SOAPEventHandler.java >>>>>>> What about .classpath? >>>>>> What about it? We can't assume everyone uses Eclipse... >>>>> What does using eclipse have to do with updating that file? I don't >>>>> use eclipse, but I still update .classpath. I also don't use ant.bat, >>>>> yet I just updated that. >>>>> >>>>> If you know that you have to keep .classpath updated to make eclipse >>>>> work, and you knowingly check in new libraries, or remove old ones, >>>>> then why make eclipse broken? It's really not that hard to change. >>>>> >>>>> Honestly, I don't understand why you would think not keeping it >>>>> uptodate is a good thing. >>>>> >>>>> ... perplexed ... >>>> Where did I write "not keeping it uptodate is a good thing?" And if I >>>> didn't write it, how can you assert I was thinking it? >>> How else could what you wrote be interpreted? Because you responded, >>> it seemed to imply that you disagreed that it wasn't important to keep >>> it uptodate. >>> >>> If you actually meant something else, then you should have said so. >>> >>> My 3 words meant that it should have been updated. What did you >>> actually mean? >>> >>> I still can't see how your response could be interpreted in any other way. >>> >>> And I'm rather perplexed at having to explain my 3 simple words in >>> such detail, esp. to you, David. >> >> What does it have to do with your 3 words? >> >> What did I mean? I meant: >> >> What about .classpath? If Hans doesn't use Eclipse, how can you expect him to >> keep that Eclipse-specific file updated, especially since it has been >> historically maintained by Eclipse users. Some things, like the > LICENSE and >> NOTICE files that Jacques pointed out, really are responsibilities > of committers. >> I wouldn't consider keeping the Eclipse .classpath file one of those > responsibilities. > > We are all in this together. The more people who keep an eye on the > various parts of the project, and the more people who keep things > working, the better. > > There are some things that are *very* easy to check. .classpath is > most definately one of those. Keeping it in sync is so very very very > simple, why shouldn't it be kept in sync when library changes occur? > > At what level should due diligence be thrown out the window? > > When the default memory requirements for ofbiz change, should only the > shell scripts be changed, only the .bat files, or both? What if new > system properties need to be set? Should that only be done in one set > of files? > > Or, for another example, what about keeping the embedded ant working, > vs. an external, system installed ant? > > I completely understand how some people may not use some small part of > ofbiz; there are so many parts, it can be hard to keep them all in > working order. However, some of those small parts are at least easy > to work with, and simple enough to see obviously broken behaviour, > that updating them when other parts change is easy. > > I really still can't believe that you are suggesting that keeping this > very simple to understand text file uptodate is not a worthwhile goal > for everyone.
Don't be ridiculous, I never wrote not implied any such thing. You really should check your assumptions and re-read what I did actually write. And here I go, shouting into the wind again... I may be an idiot, but I'll try not to prove myself insane by writing more (even if I think that definition of insanity is BS). -David > >> Is that clear enough? > > Clear, yes. However, it still doesn't make any sense to me. > >> Shall I go on? Why are you trying to imply that Hans should do this, as if >> he's >> made some sort of mistake and it's his responsibility to correct it? > Why didn't >> you just correct it yourself if you care so much about it? Who says the >> responsibility belongs to one more than another, and if it doesn't > why are you >> trying to get someone else to do something by implying it is their > responsibility >> instead of working with them in a more friendly and respectful way? > > I didn't correct it myself, because more eyes/hands makes for a better > project. The more people we have looking over the system, the better > the system will be. > > Of course I could have correct this issue. I could have even done it > silently. But then no one would learn, and no one would become better. > > Besides, the best practices for contributors(1) says: first, do no harm. > > I can understand when mistakes get made. We are all human, none of us > are perfect. However, when a mistake is eventually made, if it is > never pointed out, how can you expect the person who made the mistake > to get better? I don't point out issues to make people feel bad; I > point them out to make them better. > > I've said this before, I don't consider the background of a person > when I read a commit message. I just comment on that particular commit. > >> Okay, I think that's about all I can figure out to say on this little >> topic... >> if you need more clarification and expansion I'll try to put > together a more >> general philosophical background. On the other hand, I've written a > few blog >> entries that are related to this and that I think explain it rather > well. > > Which blog entries have you written? Links would be nice. > > 1: > http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices > >
