Fools walk in where other fear to tread. LOL
It and setup are my two priorities at the moment.
like you I only have so much time, but I am plugging away at it.
I am sure if funding came about there were be many that would change
their priorities.
Jacques Le Roux sent the following on 9/26/2010
You are ideas sounds both interesting, but I wonder if we will ever have enough
commitment to do them...
Jacques
From: "BJ Freeman"
I think for the first cut I have simplified it both for the committer
and for the clients current version of ofbiz.
A webtools that goes to the Commit email arch
I think for the first cut I have simplified it both for the committer
and for the clients current version of ofbiz.
A webtools that goes to the Commit email archive and reads the commits
and compares then to the svn image of ofbiz and the Customize components
that are either in the component-ofb
On 09/22/2010 05:59 PM, Adam Heath wrote:
On 09/22/2010 05:53 PM, Adam Heath wrote:
On 09/22/2010 05:44 PM, Jacques Le Roux wrote:
From: "Adam Heath"
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 w
On Sep 22, 2010, at 2:38 PM, Adam Heath wrote:
> 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.
>
>
Yes I don't cover that type of customization,
I copy the component into hot-deploy for simplicity.
then I modify the component I copied.
when an update is done from the svn the original component may get updated.
now I what to know if what I did in my copied component was effected.
Like they remo
t;>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Design-improvements-tp2550130p2551369.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
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 th
t;>
>>> 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.
>>>>
>>>>
>>>
>>
>>
>
>
>
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Design-improvements-tp2550130p2551300.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
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 co
Yes I use it. thanks for your effort.
Let me explain further that when I say 50 apps I am not talking about
installations but different applications, Like Real estate(5),
Education(4), Film Industry(6), Restaurants(and bars) (6)
the numbers in parentheses are the vertical apps in the class of a
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
On 09/22/2010 05:53 PM, Adam Heath wrote:
On 09/22/2010 05:44 PM, Jacques Le Roux wrote:
From: "Adam Heath"
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 nev
On 09/22/2010 05:44 PM, Jacques Le Roux wrote:
From: "Adam Heath"
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
From: "Adam Heath"
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
I too keep my customizations out of the normal svn path so they don't
get changed.
apparently I have different customizations than you do.
let take a example:
the customization routes to the party profile and expect a certain
action and behavior.
the party profile is changed in a way that the pr
The only "customization" I do is a patch file that changes settings and
comments out unused applications. There have been a few times where the
files being changed were updated in the trunk and I had to update my
patch file accordingly.
I keep custom applications in the hot-deploy folder - whe
glad you see what I am speaking of.
the one thing I said was it would notify the customizer their code at
sos and so needs to be changed.
i agree that such migration automation can not cover all.
however if every new "improvement" is done individually then the task is
not how large, though not
to further this I did state the problem as code changes to a component
and how they effect customization.
to get more granular leads to discussion about that particular problem
but does not address the migration problem for customizations.
=
BJ Freeman
Strategic Power Of
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
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
Adrian Crum sent the following on 9/22/2010 1:25 PM:
BJ,
That reply is not very informative. Also, your original message makes a
lot of broad generalizations and it d
On 09/22/2010 06:42 AM, BJ Freeman wrote:
I speak not as a voting member of ofbiz but one that has some 50 apps
built on ofbiz.
What is your definition of app? An install of an application? In
that case, we have 50+ server based installs.
However, we only have a few actual custom applicati
BJ,
That reply is not very informative. Also, your original message makes a
lot of broad generalizations and it doesn't specify what changes are
causing a problem and why.
If you want things to improve, you will need to be more specific.
-Adrian
On 9/22/2010 1:18 PM, BJ Freeman wrote:
time
time it takes to move an app to the next "improvement"
Jacques Le Roux sent the following on 9/22/2010 5:46 AM:
Just curious; what are/have been you main stumbling blocks?
Jacques
From: "BJ Freeman"
I speak not as a voting member of ofbiz but one that has some 50 apps
built on ofbiz.
I doubt
Hans and Jacques:
up till now the rule expressed is
dig in yourself or hire someone familiar enough to do the upgrade.
what I am proposing is that when new "improvements" overwrite existing
code, that a migration plan be developed with scripts.
we now have a patches folder that could be used a
Just curious; what are/have been you main stumbling blocks?
Jacques
From: "BJ Freeman"
I speak not as a voting member of ofbiz but one that has some 50 apps
built on ofbiz.
I doubt if I had know of the way improvements have been implemented and
the work that it would take to upgrade all 50 ap
Hi BJ,
If you have contributions suitable for the general public, count me in.
I know how you feel, i have the same here too.
Again, create Jira issues with patches and sure, me, Jacques and others
will have a look at it.
Regards,
Hans
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself
I speak not as a voting member of ofbiz but one that has some 50 apps
built on ofbiz.
I doubt if I had know of the way improvements have been implemented and
the work that it would take to upgrade all 50 apps I would have chose ofbiz.
In short if you ever expect to have ofbiz be a main stay app f
28 matches
Mail list logo
