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