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