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