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 <bjf...@free-man.net> wrote: > >> From: BJ Freeman <bjf...@free-man.net> >> Subject: Re: Discussion: New package org.ofbiz.base.types >> To: dev@ofbiz.apache.org >> 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 <doo...@brainfood.com> >> wrote: >>>> From: Adam Heath <doo...@brainfood.com> >>>> Subject: Re: Discussion: New package >> org.ofbiz.base.types >>>> To: dev@ofbiz.apache.org >>>> Date: Friday, February 19, 2010, 9:57 PM >>>> Adrian Crum wrote: >>>>> --- On Fri, 2/19/10, Scott Gray <scott.g...@hotwaxmedia.com> >>>> wrote: >>>>>> From: Scott Gray <scott.g...@hotwaxmedia.com> >>>>>> Subject: Re: Discussion: New package >>>> org.ofbiz.base.types >>>>>> To: dev@ofbiz.apache.org >>>>>> 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 <doo...@brainfood.com> >>>>>> wrote: >>>>>>>> From: Adam Heath <doo...@brainfood.com> >>>>>>>> Subject: Re: Discussion: New >> package >>>>>> org.ofbiz.base.types >>>>>>>> To: dev@ofbiz.apache.org >>>>>>>> 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
