Discussion: New package org.ofbiz.base.types

[Adrian Crum-2]

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?

-Adrian



     

[Adam Heath-2]

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

[Adam Heath-2]

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.

[Adrian Crum-2]

--- On Fri, 2/19/10, Adam Heath <[hidden email]> wrote:

> From: Adam Heath <[hidden email]>
> Subject: Re: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> 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.

[Scott Gray-2]

On 19/02/2010, at 10:10 PM, Adrian Crum wrote:

> --- On Fri, 2/19/10, Adam Heath <[hidden email]> wrote:
>> From: Adam Heath <[hidden email]>
>> Subject: Re: Discussion: New package org.ofbiz.base.types
>> To: [hidden email]
>> 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.

Regards
Scott

[Adam Heath-2]

Scott Gray wrote:

> On 19/02/2010, at 10:10 PM, Adrian Crum wrote:
>
>> --- On Fri, 2/19/10, Adam Heath <[hidden email]> wrote:
>>> From: Adam Heath <[hidden email]>
>>> Subject: Re: Discussion: New package org.ofbiz.base.types
>>> To: [hidden email]
>>> 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.

Oh, don't get me started on that.

It's not currently possible to do that, due to the delegator changes
that have occurred.  I'd like them to be fixed before a new release is
made.

[Adrian Crum-2]

--- On Fri, 2/19/10, Scott Gray <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >> From: Adam Heath <[hidden email]>
> >> Subject: Re: Discussion: New package
> org.ofbiz.base.types
> >> To: [hidden email]
> >> 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.

Keep in mind that the more code we write, the more code we have to maintain.

[Adam Heath-2]

Adrian Crum wrote:

> --- On Fri, 2/19/10, Scott Gray <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Discussion: New package org.ofbiz.base.types
>> To: [hidden email]
>> 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 <[hidden email]>
>> wrote:
>>>> From: Adam Heath <[hidden email]>
>>>> Subject: Re: Discussion: New package
>> org.ofbiz.base.types
>>>> To: [hidden email]
>>>> 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.

[Adrian Crum-2]

--- On Fri, 2/19/10, Adam Heath <[hidden email]> wrote:

> From: Adam Heath <[hidden email]>
> Subject: Re: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> Date: Friday, February 19, 2010, 9:57 PM
> Adrian Crum wrote:
> > --- On Fri, 2/19/10, Scott Gray <[hidden email]>
> wrote:
> >
> >> From: Scott Gray <[hidden email]>
> >> Subject: Re: Discussion: New package
> org.ofbiz.base.types
> >> To: [hidden email]
> >> 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 <[hidden email]>
> >> wrote:
> >>>> From: Adam Heath <[hidden email]>
> >>>> Subject: Re: Discussion: New package
> >> org.ofbiz.base.types
> >>>> To: [hidden email]
> >>>> 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.

[BJ Freeman]

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 <[hidden email]> wrote:
>> From: Adam Heath <[hidden email]>
>> Subject: Re: Discussion: New package org.ofbiz.base.types
>> To: [hidden email]
>> Date: Friday, February 19, 2010, 9:57 PM
>> Adrian Crum wrote:
>>> --- On Fri, 2/19/10, Scott Gray <[hidden email]>
>> wrote:
>>>> From: Scott Gray <[hidden email]>
>>>> Subject: Re: Discussion: New package
>> org.ofbiz.base.types
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>> wrote:
>>>>>> From: Adam Heath <[hidden email]>
>>>>>> Subject: Re: Discussion: New package
>>>> org.ofbiz.base.types
>>>>>> To: [hidden email]
>>>>>> 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.
>
>
>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: BJ Freeman <[hidden email]>
> Subject: Re: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >> From: Adam Heath <[hidden email]>
> >> Subject: Re: Discussion: New package
> org.ofbiz.base.types
> >> To: [hidden email]
> >> Date: Friday, February 19, 2010, 9:57 PM
> >> Adrian Crum wrote:
> >>> --- On Fri, 2/19/10, Scott Gray <[hidden email]>
> >> wrote:
> >>>> From: Scott Gray <[hidden email]>
> >>>> Subject: Re: Discussion: New package
> >> org.ofbiz.base.types
> >>>> To: [hidden email]
> >>>> 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 <[hidden email]>
> >>>> wrote:
> >>>>>> From: Adam Heath <[hidden email]>
> >>>>>> Subject: Re: Discussion: New
> package
> >>>> org.ofbiz.base.types
> >>>>>> To: [hidden email]
> >>>>>> 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.
> >
> >
> >
> >
> >
> >
>
>

[Scott Gray-2]

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 <[hidden email]> wrote:
>
>> From: BJ Freeman <[hidden email]>
>> Subject: Re: Discussion: New package org.ofbiz.base.types
>> To: [hidden email]
>> 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 <[hidden email]>
>> wrote:
>>>> From: Adam Heath <[hidden email]>
>>>> Subject: Re: Discussion: New package
>> org.ofbiz.base.types
>>>> To: [hidden email]
>>>> Date: Friday, February 19, 2010, 9:57 PM
>>>> Adrian Crum wrote:
>>>>> --- On Fri, 2/19/10, Scott Gray <[hidden email]>
>>>> wrote:
>>>>>> From: Scott Gray <[hidden email]>
>>>>>> Subject: Re: Discussion: New package
>>>> org.ofbiz.base.types
>>>>>> To: [hidden email]
>>>>>> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>>> From: Adam Heath <[hidden email]>
>>>>>>>> Subject: Re: Discussion: New
>> package
>>>>>> org.ofbiz.base.types
>>>>>>>> To: [hidden email]
>>>>>>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >
> >> From: BJ Freeman <[hidden email]>
> >> Subject: Re: Discussion: New package
> org.ofbiz.base.types
> >> To: [hidden email]
> >> 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 <[hidden email]>
> >> wrote:
> >>>> From: Adam Heath <[hidden email]>
> >>>> Subject: Re: Discussion: New package
> >> org.ofbiz.base.types
> >>>> To: [hidden email]
> >>>> Date: Friday, February 19, 2010, 9:57 PM
> >>>> Adrian Crum wrote:
> >>>>> --- On Fri, 2/19/10, Scott Gray <[hidden email]>
> >>>> wrote:
> >>>>>> From: Scott Gray <[hidden email]>
> >>>>>> Subject: Re: Discussion: New
> package
> >>>> org.ofbiz.base.types
> >>>>>> To: [hidden email]
> >>>>>> 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 <[hidden email]>
> >>>>>> wrote:
> >>>>>>>> From: Adam Heath <[hidden email]>
> >>>>>>>> Subject: Re: Discussion:
> New
> >> package
> >>>>>> org.ofbiz.base.types
> >>>>>>>> To: [hidden email]
> >>>>>>>> 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.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

[Scott Gray-2]

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 <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Discussion: New package org.ofbiz.base.types
>> To: [hidden email]
>> 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 <[hidden email]>
>> wrote:
>>>
>>>> From: BJ Freeman <[hidden email]>
>>>> Subject: Re: Discussion: New package
>> org.ofbiz.base.types
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>> wrote:
>>>>>> From: Adam Heath <[hidden email]>
>>>>>> Subject: Re: Discussion: New package
>>>> org.ofbiz.base.types
>>>>>> To: [hidden email]
>>>>>> Date: Friday, February 19, 2010, 9:57 PM
>>>>>> Adrian Crum wrote:
>>>>>>> --- On Fri, 2/19/10, Scott Gray <[hidden email]>
>>>>>> wrote:
>>>>>>>> From: Scott Gray <[hidden email]>
>>>>>>>> Subject: Re: Discussion: New
>> package
>>>>>> org.ofbiz.base.types
>>>>>>>> To: [hidden email]
>>>>>>>> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>>> From: Adam Heath <[hidden email]>
>>>>>>>>>> Subject: Re: Discussion:
>> New
>>>> package
>>>>>>>> org.ofbiz.base.types
>>>>>>>>>> To: [hidden email]
>>>>>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> 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 <[hidden email]>
> wrote:
> >
> >> From: Scott Gray <[hidden email]>
> >> Subject: Re: Discussion: New package
> org.ofbiz.base.types
> >> To: [hidden email]
> >> 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 <[hidden email]>
> >> wrote:
> >>>
> >>>> From: BJ Freeman <[hidden email]>
> >>>> Subject: Re: Discussion: New package
> >> org.ofbiz.base.types
> >>>> To: [hidden email]
> >>>> 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 <[hidden email]>
> >>>> wrote:
> >>>>>> From: Adam Heath <[hidden email]>
> >>>>>> Subject: Re: Discussion: New
> package
> >>>> org.ofbiz.base.types
> >>>>>> To: [hidden email]
> >>>>>> Date: Friday, February 19, 2010,
> 9:57 PM
> >>>>>> Adrian Crum wrote:
> >>>>>>> --- On Fri, 2/19/10, Scott
> Gray <[hidden email]>
> >>>>>> wrote:
> >>>>>>>> From: Scott Gray <[hidden email]>
> >>>>>>>> Subject: Re: Discussion:
> New
> >> package
> >>>>>> org.ofbiz.base.types
> >>>>>>>> To: [hidden email]
> >>>>>>>> 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 <[hidden email]>
> >>>>>>>> wrote:
> >>>>>>>>>> From: Adam Heath
> <[hidden email]>
> >>>>>>>>>> Subject: Re:
> Discussion:
> >> New
> >>>> package
> >>>>>>>> org.ofbiz.base.types
> >>>>>>>>>> To: [hidden email]
> >>>>>>>>>> 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.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

[Scott Gray-2]

The reality is that I don't care enough about the change to continue arguing about it.

I like the idea of putting things in their logical place.
I like the idea of maintaining backwards compatibility wherever it is feasible to do so.
I value the latter over the former even if it isn't currently a "rule".

I don't consider "update your patches" to be a form of backwards compatibility.  That's irrelevant though, if people are affected by this change it will be in their code and not in their patches.

Regards
Scott

On 20/02/2010, at 1:45 AM, Adrian Crum wrote:

> 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 <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Discussion: New package org.ofbiz.base.types
>> To: [hidden email]
>> 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 <[hidden email]>
>> wrote:
>>>
>>>> From: Scott Gray <[hidden email]>
>>>> Subject: Re: Discussion: New package
>> org.ofbiz.base.types
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> From: BJ Freeman <[hidden email]>
>>>>>> Subject: Re: Discussion: New package
>>>> org.ofbiz.base.types
>>>>>> To: [hidden email]
>>>>>> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>>> From: Adam Heath <[hidden email]>
>>>>>>>> Subject: Re: Discussion: New
>> package
>>>>>> org.ofbiz.base.types
>>>>>>>> To: [hidden email]
>>>>>>>> Date: Friday, February 19, 2010,
>> 9:57 PM
>>>>>>>> Adrian Crum wrote:
>>>>>>>>> --- On Fri, 2/19/10, Scott
>> Gray <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>>> From: Scott Gray <[hidden email]>
>>>>>>>>>> Subject: Re: Discussion:
>> New
>>>> package
>>>>>>>> org.ofbiz.base.types
>>>>>>>>>> To: [hidden email]
>>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>>> From: Adam Heath
>> <[hidden email]>
>>>>>>>>>>>> Subject: Re:
>> Discussion:
>>>> New
>>>>>> package
>>>>>>>>>> org.ofbiz.base.types
>>>>>>>>>>>> To: [hidden email]
>>>>>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[David E. Jones-2]

This is just my opinion, but unless we move to a structures of limited external interfaces separate from the internal implementations of those interfaces, it's going to be tough to maintain backward compatibility. The problem is every line of Java, XML, etc, etc in the project is subject to people wanting it to be backward compatible, whether it makes sense to do so or not.

Backward compatibility is great, but on the other hand OFBiz is turning into a maze of unused code and things that make no sense but that are kept for backward compatibility.

I've actually been working for the last few weeks on something to "fix" this, and provide a much more solid foundation for applications like those in OFBiz, but I'm not sure how much people will like the approach... I guess time will tell.

-David


On Feb 20, 2010, at 2:10 AM, Scott Gray wrote:

> The reality is that I don't care enough about the change to continue arguing about it.
>
> I like the idea of putting things in their logical place.
> I like the idea of maintaining backwards compatibility wherever it is feasible to do so.
> I value the latter over the former even if it isn't currently a "rule".
>
> I don't consider "update your patches" to be a form of backwards compatibility.  That's irrelevant though, if people are affected by this change it will be in their code and not in their patches.
>
> Regards
> Scott
>
> On 20/02/2010, at 1:45 AM, Adrian Crum wrote:
>
>> 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 <[hidden email]> wrote:
>>
>>> From: Scott Gray <[hidden email]>
>>> Subject: Re: Discussion: New package org.ofbiz.base.types
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>> wrote:
>>>>
>>>>> From: Scott Gray <[hidden email]>
>>>>> Subject: Re: Discussion: New package
>>> org.ofbiz.base.types
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>>> From: BJ Freeman <[hidden email]>
>>>>>>> Subject: Re: Discussion: New package
>>>>> org.ofbiz.base.types
>>>>>>> To: [hidden email]
>>>>>>> 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 <[hidden email]>
>>>>>>> wrote:
>>>>>>>>> From: Adam Heath <[hidden email]>
>>>>>>>>> Subject: Re: Discussion: New
>>> package
>>>>>>> org.ofbiz.base.types
>>>>>>>>> To: [hidden email]
>>>>>>>>> Date: Friday, February 19, 2010,
>>> 9:57 PM
>>>>>>>>> Adrian Crum wrote:
>>>>>>>>>> --- On Fri, 2/19/10, Scott
>>> Gray <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>>> From: Scott Gray <[hidden email]>
>>>>>>>>>>> Subject: Re: Discussion:
>>> New
>>>>> package
>>>>>>>>> org.ofbiz.base.types
>>>>>>>>>>> To: [hidden email]
>>>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> From: Adam Heath
>>> <[hidden email]>
>>>>>>>>>>>>> Subject: Re:
>>> Discussion:
>>>>> New
>>>>>>> package
>>>>>>>>>>> org.ofbiz.base.types
>>>>>>>>>>>>> To: [hidden email]
>>>>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

[Adrian Crum-2]

--- On Sat, 2/20/10, David E Jones <[hidden email]> wrote:
> I've actually been working for the last few weeks on
> something to "fix" this, and provide a much more solid
> foundation for applications like those in OFBiz, but I'm not
> sure how much people will like the approach... I guess time
> will tell.

Any hints?



     

[Adrian Crum-2]

--- On Sat, 2/20/10, Scott Gray <[hidden email]> wrote:
> The reality is that I don't care
> enough about the change to continue arguing about it.
>
> I like the idea of maintaining backwards compatibility
> wherever it is feasible to do so.

As do I. Please see the XmlSerializable thread.



     

[David E. Jones-2]

On Feb 20, 2010, at 2:51 AM, Adrian Crum wrote:

> --- On Sat, 2/20/10, David E Jones <[hidden email]> wrote:
>> I've actually been working for the last few weeks on
>> something to "fix" this, and provide a much more solid
>> foundation for applications like those in OFBiz, but I'm not
>> sure how much people will like the approach... I guess time
>> will tell.
>
> Any hints?

Soon enough... this is a long-term thing though, and may not be as interesting as you think.

-David