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.
