not sure where you coming from james
I have stated that all customization is done outside of the SVN image,
by either hot-deploy or a seperate folder(which is what I use) of
components the either override or access the svn image.
and that a automated way to check those customization against the
changes in the svn image to see if there are any changes necessary to
the customization would greatly reduce the cost of maintenance.
I have not said that any Customization should be in the svn image or
part of the svn.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
james_sg sent the following on 9/22/2010 6:59 PM:
Hi BJ,
If we customize an application by configuration, upgrades are easier.
If we customize by replacing the codes, upgrades will not be possible.
This means functions / features in OFBiz should be able to turn on / off.
Regards,
James
BJ Freeman wrote:
I disagree. every complicated process is made up of simple processes.
the level you approach it, is what makes it complicated.
An I believe the process can be modeled and implemented.
just as the tests are now, as limited as they are.
what it takes is a commitment by each one that changes the code base to
put their smarts in the direction of what does it take to get from here
to there as far as migration.
one way for instance is to use Diffs or even the patch itself as a basis
for driving the migration.
then is it a matter of tools to use the diffs and patches to run a check
on customization.
I do maintain my own SVN, I would not be this far if I did not.
however it does not help to compare code that outside that of the ofbiz
svn(component that are customized but not part of the code base of ofbiz)
The bottom line, for a business, is overhead to maintain it hard cash.
Jonatan Soto sent the following on 9/22/2010 5:00 PM:
What I see here is that it is not as easy to create an upgrade system for
this kind of project. Perhaps the nature of it, it's a good reason.
Remember
that Ofbiz is an ERP system and tries to cover as much as it can
different
businesses, so IMO it's not like a proprietary product or another kind of
open source project where it is not a common practice to change the trunk
code by everyone and also allows to easily install plugins, mods,
extensions, etc.
IMO, I can say that one good chance to achieve this is to separate the
framework from the apps, already discussed in a lot of posts and I think
it
is strongly accepted by the community. This will get the ability to
extract
an important piece of code which I think is not regularly altered, at
least
in my case, I've modified some apps but never the framework.
From my point of view, the hot-deploy works fine and it's fairly enough
for
a lot of customization purposes and maintain the trunk code untouched.
But
it seems to me that sometimes is not enough mostly when an adaptation of
an
existing app, concretely i18n enters the scene. For example I found to be
very complicated to move the entire Accounting module, IMO the one that
requires more i18n, since it is related with a lot of modules. In this
case
I have had to customize in-place. I have some ideas about that, but I
prefer
to discuss this in a proper post.
BJ, I believe that your problem is related with the number of
installations
do you have/maintain so a little solution may be (if you aren't doing
yet)
the vendor drop technique (
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html). But I
suppose it's only valid if you decided to use the trunk version from the
beginning and kept up to date so often...
On Thu, Sep 23, 2010 at 12:44 AM, Jacques Le Roux<
jacques.le.r...@les7arts.com> wrote:
From: "Adam Heath"<doo...@brainfood.com>
On 09/22/2010 03:33 PM, BJ Freeman wrote:
Am it to gather by this that you can do a direct SVN update and all
your
customization continue to work?
say from 9.04 to 10.04
Ofbiz has never supported upgrades. I agree with BJ here.
Database tables can change. Not all changes are automatic. Such
changes
are not listed in a simple place(in the source).
Values in tables can change. No upgrade conversions are
provided(again,
in a simple place).
Is this useless?
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
Jacques
To solve this, requires running older ofbiz on older database, doing a
test upgrade to each and every new version, and then seeing what is
different. This is a *very* hard problem, not easy to automate, and
takes
smart people lots of time. This is not something you can just force on
the
community. No one has sat down to do this very busy, hard work, so it
hasn't yet been done.
If you run trunk, then it is up to you to solve any per-version upgrade
problems.
However, official releases should really have appropriate, detailed,
upgrade instructions.
