Discussion: New package org.ofbiz.base.types

[Adam Heath-2]

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.

Just because it wasn't done correctly in the past does not mean it
should be done incorrectly now.

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

As ofbiz gets bigger, and used by more people, we *will* have to be
considerate of upgrades between major versions.

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

Um, the trunk is the next release.  Why can't you see that?

> For now, it would help if we could stay on subject.

This is on subject, you just don't see it.

[Adam Heath-2]

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.

You maintain your downstream changes a certain way.  Others may do it
differently.

And, you are special, as am I, and anybody else who has actual real
commit rights.  We are way above the curve when it comes to upgrading
and using ofbiz.  There could be other people who are not so lucky.

You've said that doing a simple rename would solve this problem for
downstream users.  Why, yes, that is correct.  But how will they know
to do that rename?  When the next version of ofbiz is released, the
classes will not exist at the new location, and their code won't
compile, or it will fail at runtime.  Where will they go to find out
how to fix their code?  Will there be release notes?  Will you update
them to list what has to be done to fix their files?

If you did it has I suggested, then have javac give a deprecation
warning at compile time, and log a message at runtime if it happens to
be used, then it would make it much easier for downstreams to see the
problem, and it would also let their code continue to work
transparently, instead of just breaking stuff from the get-go.

[Adam Heath-2]

David E Jones wrote:
> 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.

Internal classes can be moved around at will.  Such examples are thing
 inside the entity engine, the service engine, and the widget system.
 Those are deep internal classes.

However, base is a set of utility classes, that can be reused by tons
of code, tons of components.  All of base could be considered api, and
therefor should be dealt with in a saner manner.

[Jacopo Cappellato-4]

Adam,

what you say is right but it is also true that if a development team was able to create a custom application on OFBiz, it should also be able to figure this out quite easily.
Everyone in the software industry is aware that after an upgrade the tools/framework used to build a custom application, some tests and fixes are required.

Kind regards,

Jacopo

On Feb 20, 2010, at 6:22 PM, Adam Heath wrote:

> 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.
>
> You maintain your downstream changes a certain way.  Others may do it
> differently.
>
> And, you are special, as am I, and anybody else who has actual real
> commit rights.  We are way above the curve when it comes to upgrading
> and using ofbiz.  There could be other people who are not so lucky.
>
> You've said that doing a simple rename would solve this problem for
> downstream users.  Why, yes, that is correct.  But how will they know
> to do that rename?  When the next version of ofbiz is released, the
> classes will not exist at the new location, and their code won't
> compile, or it will fail at runtime.  Where will they go to find out
> how to fix their code?  Will there be release notes?  Will you update
> them to list what has to be done to fix their files?
>
> If you did it has I suggested, then have javac give a deprecation
> warning at compile time, and log a message at runtime if it happens to
> be used, then it would make it much easier for downstreams to see the
> problem, and it would also let their code continue to work
> transparently, instead of just breaking stuff from the get-go.

[Adam Heath-2]

Jacopo Cappellato wrote:
> Adam,
>
> what you say is right but it is also true that if a development team was able to create a custom application on OFBiz, it should also be able to figure this out quite easily.
> Everyone in the software industry is aware that after an upgrade the tools/framework used to build a custom application, some tests and fixes are required.

Sure, everyone is aware that upgrades of systems we use require us to
change our own systems to follow suit.  However, what I am saying is
that how will our users know what they have to change?

I am willing to say that, in this particular case, we don't need to
have deprecated classes stay in the old location.  However, we still
need to document the move.  If it doesn't happen now when the move
occurs, will we remember to do it right before we release?  Is your
memory really that good?

[Jacopo Cappellato-4]

On Feb 20, 2010, at 6:49 PM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> Adam,
>>
>> what you say is right but it is also true that if a development team was able to create a custom application on OFBiz, it should also be able to figure this out quite easily.
>> Everyone in the software industry is aware that after an upgrade the tools/framework used to build a custom application, some tests and fixes are required.
>
> Sure, everyone is aware that upgrades of systems we use require us to
> change our own systems to follow suit.  However, what I am saying is
> that how will our users know what they have to change?
>
> I am willing to say that, in this particular case, we don't need to
> have deprecated classes stay in the old location.  However, we still
> need to document the move.  If it doesn't happen now when the move
> occurs, will we remember to do it right before we release?  Is your
> memory really that good?

Again, I agree with you and I also agree that documenting this change is a good idea.
But I still think that this specific issue could be discovered and fixed (even without documentation) by a decent developer in less than 20 minutes after a system upgrade.
If there is a document it is even better...

Jacopo

[Scott Gray-2]

On 20/02/2010, at 12:01 PM, Jacopo Cappellato wrote:

>
> On Feb 20, 2010, at 6:49 PM, Adam Heath wrote:
>
>> Jacopo Cappellato wrote:
>>> Adam,
>>>
>>> what you say is right but it is also true that if a development team was able to create a custom application on OFBiz, it should also be able to figure this out quite easily.
>>> Everyone in the software industry is aware that after an upgrade the tools/framework used to build a custom application, some tests and fixes are required.
>>
>> Sure, everyone is aware that upgrades of systems we use require us to
>> change our own systems to follow suit.  However, what I am saying is
>> that how will our users know what they have to change?
>>
>> I am willing to say that, in this particular case, we don't need to
>> have deprecated classes stay in the old location.  However, we still
>> need to document the move.  If it doesn't happen now when the move
>> occurs, will we remember to do it right before we release?  Is your
>> memory really that good?
>
>
> Again, I agree with you and I also agree that documenting this change is a good idea.
> But I still think that this specific issue could be discovered and fixed (even without documentation) by a decent developer in less than 20 minutes after a system upgrade.
> If there is a document it is even better...
>
> Jacopo

That's why I was in favor of using deprecation, it's a fantastic form of documentation.  Every time you compile it's there in your face telling you that you need to change something and what to change it to.
20 minutes may sound fine, but it's the accumulation of at least years worth of these types of changes multiplied by the number of people affected by them.  When you look at it in those terms it is a fairly expensive strategy.

Regards
Scott

[Jacopo Cappellato-4]

On Feb 20, 2010, at 8:10 PM, Scott Gray wrote:

>>
>> Again, I agree with you and I also agree that documenting this change is a good idea.
>> But I still think that this specific issue could be discovered and fixed (even without documentation) by a decent developer in less than 20 minutes after a system upgrade.
>> If there is a document it is even better...
>>
>> Jacopo
>
> That's why I was in favor of using deprecation, it's a fantastic form of documentation.  Every time you compile it's there in your face telling you that you need to change something and what to change it to.
> 20 minutes may sound fine, but it's the accumulation of at least years worth of these types of changes multiplied by the number of people affected by them.  When you look at it in those terms it is a fairly expensive strategy.
>

Agreed. This is also one of the reasons I would like to issue more frequent releases (at least one per year).

Regards,

Jacopo


> Regards
> Scott
>

[Ean Schuessler]

Scott Gray wrote:
> That's why I was in favor of using deprecation, it's a fantastic form of documentation.  Every time you compile it's there in your face telling you that you need to change something and what to change it to.
> 20 minutes may sound fine, but it's the accumulation of at least years worth of these types of changes multiplied by the number of people affected by them.  When you look at it in those terms it is a fairly expensive strategy.
>  
I agree. Its also fairly straightforward for use to maintain a list of
deprecated items and phase them out as they become more than a release
(or two) old. We should try to remember that we are writing for business
users and we need to become more conservative about how we approach
long-term maintainability. I know that sounds depressing to the code
poet in all our hearts but that's what external GIT repositories are for!

Its not hard to imagine a business that hired a group of people to build
them a custom OFBiz solution which they now are trying to maintain. If
the people who did the job for them did it right then hopefully their
custom code is neatly isolated into a component they can just move over.
It would be nice if they had a year of warning to put together a team to
phase out deprecated bits that look dangerous. Of course, this leaves
aside the fact that you need a lot of luck, skill and patience to
migrate your data between ofbiz releases but hopefully we can tackle
that problem down the road as well.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[David E. Jones-2]

On Feb 22, 2010, at 5:48 PM, Ean Schuessler wrote:

> Scott Gray wrote:
>> That's why I was in favor of using deprecation, it's a fantastic form of documentation.  Every time you compile it's there in your face telling you that you need to change something and what to change it to.
>> 20 minutes may sound fine, but it's the accumulation of at least years worth of these types of changes multiplied by the number of people affected by them.  When you look at it in those terms it is a fairly expensive strategy.
>>
> I agree. Its also fairly straightforward for use to maintain a list of
> deprecated items and phase them out as they become more than a release
> (or two) old. We should try to remember that we are writing for business
> users and we need to become more conservative about how we approach
> long-term maintainability. I know that sounds depressing to the code
> poet in all our hearts but that's what external GIT repositories are for!

This is another example of why a good separation between the framework and the application code would be really helpful.

> Its not hard to imagine a business that hired a group of people to build
> them a custom OFBiz solution which they now are trying to maintain. If
> the people who did the job for them did it right then hopefully their
> custom code is neatly isolated into a component they can just move over.
> It would be nice if they had a year of warning to put together a team to
> phase out deprecated bits that look dangerous. Of course, this leaves
> aside the fact that you need a lot of luck, skill and patience to
> migrate your data between ofbiz releases but hopefully we can tackle
> that problem down the road as well.

Migrating data between versions is a bit of a pain. At least you can compare schemas and see a history of schema changes and such, and hopefully our list of revisions requiring data migration will be maintained well enough for someone to have a one stop place to see what they're dealing with.

For custom code or code changes the framework separation would again be really helpful. What I'm thinking is that if we had a really separately maintained and developed framework then it could have real releases and the applications side of the project could stick to one real release at a time. That would mean that the whole project could be migrated from one framework version to the next, and when that is done users would know that is happening and be able to do it with their code too.

Anyway, I'm just thinking out loud, I don't know how we'd actually go about doing this with the current community setup and how people normally work with others and the code. Even separating the framework and removing dependencies on the applications so that we could maintain them separately would be a lot of work. I suppose there are other ways of going about all of this, but the ways I'm thinking of would require a different community structure, a lot of volunteer time that probably wouldn't be paid for, etc. And that... I'm not sure on whats or hows there. I've certainly thought about it a lot, and have some of my own ideas, but in thinking I've started to question every principal that OFBiz is based on (which I guess is the only way to really solve problems, ie question assumptions etc).

-David

[Adrian Crum-2]

Based on the replies to this thread, I created a new package - org.ofbiz.base.lang - and I moved some classes there. Revision 916987.

-Adrian

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

> From: Adrian Crum <[hidden email]>
> Subject: Discussion: New package org.ofbiz.base.types
> To: [hidden email]
> Date: Friday, February 19, 2010, 8:32 PM
> 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
>
>
>
>      
>