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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
