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