This is just my opinion, but unless we move to a structures of limited external interfaces separate from the internal implementations of those interfaces, it's going to be tough to maintain backward compatibility. The problem is every line of Java, XML, etc, etc in the project is subject to people wanting it to be backward compatible, whether it makes sense to do so or not.
Backward compatibility is great, but on the other hand OFBiz is turning into a maze of unused code and things that make no sense but that are kept for backward compatibility. I've actually been working for the last few weeks on something to "fix" this, and provide a much more solid foundation for applications like those in OFBiz, but I'm not sure how much people will like the approach... I guess time will tell. -David On Feb 20, 2010, at 2:10 AM, Scott Gray wrote: > The reality is that I don't care enough about the change to continue arguing > about it. > > I like the idea of putting things in their logical place. > I like the idea of maintaining backwards compatibility wherever it is > feasible to do so. > I value the latter over the former even if it isn't currently a "rule". > > I don't consider "update your patches" to be a form of backwards > compatibility. That's irrelevant though, if people are affected by this > change it will be in their code and not in their patches. > > Regards > Scott > > On 20/02/2010, at 1:45 AM, Adrian Crum wrote: > >> There is no reason for you to pack up your marbles and go home. >> >> The question is: There are classes in org.ofbiz.base.util that don't belong >> there because they are data types, not utility classes. What do you think >> about moving them to a different package? >> >> And I *have* considered the downstream user - I am one of them. Updating a >> patch is not too much to ask in my opinion. >> >> -Adrian >> >> --- On Sat, 2/20/10, Scott Gray <[email protected]> wrote: >> >>> From: Scott Gray <[email protected]> >>> Subject: Re: Discussion: New package org.ofbiz.base.types >>> To: [email protected] >>> Date: Saturday, February 20, 2010, 12:33 AM >>> You do it however you feel is right, >>> I don't feel like making any rules. >>> >>> I'm only asking you to consider the downstream user, if you >>> choose not to then that's fine too. >>> >>> Regards >>> Scott >>> >>> On 20/02/2010, at 1:17 AM, Adrian Crum wrote: >>> >>>> Who suggested removing them? They are being moved to a >>> different package. As I already said - an existing >>> installation can do a simple search and replace to >>> accommodate that. Plus, as I have also pointed out, changes >>> like this have been done in the past with no regard to >>> release version compatibility. >>>> >>>> So, yes - this is a thread hijack. What I am >>> suggesting has been done many times before with no warning >>> or discussion, but now it has become an issue. Why should >>> the change I'm proposing follow some new rule? Are you going >>> to make that rule retroactive? How many files in the trunk >>> have been changed/moved/deleted in a backwards-incompatible >>> way since the R 9.04 branch? >>>> >>>> If you want to make new rules, then fine - start a new >>> thread for that. And make sure the new rules apply to the >>> next release, not to the trunk. >>>> >>>> For now, it would help if we could stay on subject. >>>> >>>> -Adrian >>>> >>>> >>>> --- On Sat, 2/20/10, Scott Gray <[email protected]> >>> wrote: >>>> >>>>> From: Scott Gray <[email protected]> >>>>> Subject: Re: Discussion: New package >>> org.ofbiz.base.types >>>>> To: [email protected] >>>>> Date: Saturday, February 20, 2010, 12:07 AM >>>>> I wouldn't say it was hijacked, >>>>> deprecating classes vs. removing them seems pretty >>> pertinent >>>>> to the discussion and has a direct impact on >>> version >>>>> compatibility. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 20/02/2010, at 12:47 AM, Adrian Crum wrote: >>>>> >>>>>> This thread is in no way similar to moving a >>>>> component. I'm suggesting moving a handful of Java >>> classes >>>>> to a new package. Unfortunately, what should have >>> been a >>>>> discussion about that change has been hijacked >>> into a >>>>> different discussion about release strategy and >>> release >>>>> version compatibility. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> --- On Fri, 2/19/10, BJ Freeman <[email protected]> >>>>> wrote: >>>>>> >>>>>>> From: BJ Freeman <[email protected]> >>>>>>> Subject: Re: Discussion: New package >>>>> org.ofbiz.base.types >>>>>>> To: [email protected] >>>>>>> Date: Friday, February 19, 2010, 11:30 PM >>>>>>> wading in late, >>>>>>> I believe the idea behind component was >>> that it >>>>> could be >>>>>>> located and >>>>>>> that was transparent. Like ecommerce got >>> moved but >>>>> it does >>>>>>> not effect >>>>>>> the operation of it. >>>>>>> So any idea you have should follow that >>> concept. >>>>>>> >>>>>>> Adrian Crum sent the following on >>> 2/19/2010 10:07 >>>>> PM: >>>>>>>> --- On Fri, 2/19/10, Adam Heath <[email protected]> >>>>>>> wrote: >>>>>>>>> From: Adam Heath <[email protected]> >>>>>>>>> Subject: Re: Discussion: New >>> package >>>>>>> org.ofbiz.base.types >>>>>>>>> To: [email protected] >>>>>>>>> Date: Friday, February 19, 2010, >>> 9:57 PM >>>>>>>>> Adrian Crum wrote: >>>>>>>>>> --- On Fri, 2/19/10, Scott >>> Gray <[email protected]> >>>>>>>>> wrote: >>>>>>>>>>> From: Scott Gray <[email protected]> >>>>>>>>>>> Subject: Re: Discussion: >>> New >>>>> package >>>>>>>>> org.ofbiz.base.types >>>>>>>>>>> To: [email protected] >>>>>>>>>>> Date: Friday, February 19, >>> 2010, >>>>> 9:45 PM >>>>>>>>>>> On 19/02/2010, at 10:10 >>> PM, >>>>> Adrian >>>>>>>>>>> Crum wrote: >>>>>>>>>>> >>>>>>>>>>>> --- On Fri, 2/19/10, >>> Adam >>>>> Heath <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>>> From: Adam Heath >>> <[email protected]> >>>>>>>>>>>>> Subject: Re: >>> Discussion: >>>>> New >>>>>>> package >>>>>>>>>>> org.ofbiz.base.types >>>>>>>>>>>>> To: [email protected] >>>>>>>>>>>>> Date: Friday, >>> February 19, >>>>> 2010, >>>>>>> 8:56 PM >>>>>>>>>>>>> Adam Heath wrote: >>>>>>>>>>>>>> Adrian Crum >>> wrote: >>>>>>>>>>>>>>> In the >>>>> org.ofbiz.base.util >>>>>>> package >>>>>>>>> there >>>>>>>>>>> are >>>>>>>>>>>>> interfaces and >>> classes >>>>> that don't >>>>>>> really >>>>>>>>> belong >>>>>>>>>>> there - they >>>>>>>>>>>>> are data types, >>> not >>>>> utility >>>>>>> classes. It >>>>>>>>> would be >>>>>>>>>>> nice if we >>>>>>>>>>>>> could create a new >>> package >>>>> to >>>>>>> contain >>>>>>>>> basic data >>>>>>>>>>> types: >>>>>>>>>>>>> >>> org.ofbiz.base.types. The >>>>> new >>>>>>> package >>>>>>>>> would >>>>>>>>>>> contain things >>>>>>>>>>>>> like: Appender, >>>>> DateRange, >>>>>>> Factory, >>>>>>>>> Range, >>>>>>>>>>> ComparableRange, >>>>>>>>>>>>> TimeDuration, >>> etc. >>>>>>>>>>>>>>> The >>>>> org.ofbiz.base.util >>>>>>> package >>>>>>>>> could be >>>>>>>>>>>>> (informally) >>> limited to >>>>> classes >>>>>>> that >>>>>>>>> follow the >>>>>>>>>>> utility >>>>>>>>>>>>> class pattern >>> (only >>>>> static >>>>>>> methods, >>>>>>>>> private >>>>>>>>>>> constructor, >>>>>>>>>>>>> etc). >>>>>>>>>>>>>>> What do >>> you >>>>> think? >>>>>>>>>>>>>> >>> org.ofbiz.base.lang >>>>>>>>>>>>> Where ever they >>> get moved >>>>> to, you >>>>>>> need to >>>>>>>>> check >>>>>>>>>>> for classes >>>>>>>>>>>>> that >>>>>>>>>>>>> existed in a >>> previous >>>>> release, and >>>>>>> make >>>>>>>>> certain >>>>>>>>>>> they still >>>>>>>>>>>>> exist, and >>>>>>>>>>>>> just extend the >>> classes >>>>> that were >>>>>>> copied >>>>>>>>> to the >>>>>>>>>>> new >>>>>>>>>>>>> location. >>> Then, >>>>>>>>>>>>> add deprecation to >>> the >>>>> old >>>>>>> versions. >>>>>>>>>>>> I probably wouldn't do >>> that. >>>>> I >>>>>>> understand what >>>>>>>>> you're >>>>>>>>>>> getting at, but it adds >>>>> unnecessary code >>>>>>> and >>>>>>>>> complexity to >>>>>>>>>>> the project. Anyone >>> wanting to >>>>> upgrade >>>>>>> from a >>>>>>>>> release who >>>>>>>>>>> used the affected classes >>> could do >>>>> a >>>>>>> simple search >>>>>>>>> and >>>>>>>>>>> replace on the import >>> statements. >>>>>>>>>>>> Things like this have >>> been >>>>> moved >>>>>>> around >>>>>>>>> before. >>>>>>>>>>> I agree with Adam, in an >>> ideal >>>>> world, one >>>>>>> would be >>>>>>>>> able to >>>>>>>>>>> uplift their hot-deploy >>> components >>>>> from >>>>>>> 9.04 and >>>>>>>>> drop them >>>>>>>>>>> into 10.x without any >>>>> issues. We're >>>>>>> probably >>>>>>>>> still a >>>>>>>>>>> long way from that but I >>> don't >>>>> think we >>>>>>> should >>>>>>>>> make things >>>>>>>>>>> any harder for the user >>> than we >>>>> need to. >>>>>>>>>> So, where does that process >>> end? >>>>> Should >>>>>>> hot-deploy >>>>>>>>> components from 10.x drop into >>> 11.x >>>>> without any >>>>>>> issues? That >>>>>>>>> would require maintaining code >>> from 9.04 >>>>> AND 10.x >>>>>>> in 11.x. >>>>>>>>> >>>>>>>>> No. >>>>>>>>> >>>>>>>>> Stuff from 9.04 should work >>> without any >>>>> changes >>>>>>> in >>>>>>>>> 10.x. However, >>>>>>>>> there could be warnings issues >>> for >>>>> anything that >>>>>>> isn't >>>>>>>>> being done in >>>>>>>>> an optimal way. >>>>>>>>> >>>>>>>>> This gives downstreams time to fix >>> their >>>>> 9.04 >>>>>>> modules to >>>>>>>>> work properly >>>>>>>>> for 10.x, before we eventually >>> release >>>>> 11.x. >>>>>>>> >>>>>>>> I have used patch files for that and >>> it hasn't >>>>> been a >>>>>>> big issue. For example, my production >>> deployment >>>>> patch >>>>>>> modifies start.properties. In revision >>> 684377 that >>>>> file was >>>>>>> moved to another folder. So, I just >>> updated my >>>>> patch. I >>>>>>> never expected that file's original >>> location to be >>>>> supported >>>>>>> in future versions. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >
