Users - JOB _SANDBOX

[Andrew Dupa]

There is no STATUS_ID that has any resemblance to "SERVICE_FINISED" anywhere related to JOB_SANDBOX. I guess we are talking about different versions here.

 

There's an existing service called purgeOldJobs that already exists but I had to manually start, unfortunately I looked at the code and it proceeds to read every job in that is older than 4 days and delete it, this is a problem if you have 25K records to delete, why read them into memory then delete them? Ho hum…oh dear. But I now have it running and it should keep it manageable except for the next problem

 

There is no "max-retry" element associated with a service definition, I get errors in the log when parsing the XML definition file. So jobs just keep on trying forever…great work guys!!!

 

 

On 2/3/06, David E. Jones <[hidden email]> wrote:

On Feb 3, 2006, at 1:56 AM, Andrew Dupa wrote:

> Well I guess I'll just work it out by reading the code and looking
> at the data model. My question was I thought pretty straight
> forward, unfortunately people responded without thinking.
>
> I was hoping this community would be smart and intelligent enough
> to support end users but they are it seems completely lost in a
> world of never ending development which never brings out the real
> world issues. No release management, no testing framework no
> stability. Users who don't read questions but answer with the
> bleeding obvious.

This, perhaps, comes from a misunderstanding of what OFBiz is. It is
clear that it isn't what you expected it to be, and that is the case
for many people who are used to purchasing a piece of software and
becoming a "user" of the software.

In a community-oriented open source project like OFBiz it only exists
because the community drives it. There is no company involved. No
investment from venture capitalists or angels and no bank loans or
anything (well, except maybe American Express and various other
credit card and home equity lenders during slower periods... ;) ).

That means that the dozens of people who contribute to the project on
a regular basis and the hundreds of people who use the software in
their jobs generally can't get involved, I mean really simply cannot
get involved, unless they find some work doing so. Andy and I
invested quite a bit early on in the project, but this is certainly
true of us. Neither of us (while I guess I'm not really sure about
Andy) have a net worth in the black and without money coming in from
consulting work, we'd be in trouble pretty quickly... Actually, it's
not so bad, if it weren't for my ex-wife I'd probably be working 1
week a month for pay, another week per month on the project, and then
spending the remaining time cruising the world on the BMW GS
adventure bike I've been craving for years...

Anyway, back to the point. OFBiz is a community driven project. We
all get along as we can and help move the forward as we can, and to
date ALL significant contributions to the project have been impelled
mostly by making things easier and cheaper in the future for those
involved. Lots of people have wanted to help, but it is just too much
to do as an amateur (unless you have no need for an income... but
even then without a project driving requirements and understanding,
it is hard to get your head around).

So, are there issues? Yeah. It sounds like you want to be involved
with the project as a casual user, and that's almost impossible with
OFBiz. If you aren't involved with the community and working
regularly with the project then you pretty much have to hire someone
who is involved with the community and has invested sufficiently to
be able to work well with it.

How is that different from major ERP packages? For them a "release"
is the same as for us, and they have the same problem with testing as
we do (ie the moving target problem). For them a "release" or a
standardized version is mostly just a sales and marketing tool. Once
these systems are customized (or "installed") out of the box testing
(except for low level components... maybe that's why we have entity
engine unit tests but not much else?) is not very useful, unless they
maintain the tests in parallel with the customizations. They will
also have various patches and changes that bring their system to a
state of being a creation like that of the good Dr. Frankenstein:
some of the "version" they think they have, some of the next version
(but not all), and a bunch of changes that they alone are responsible
for maintaining.

Eventually OFBiz may be more usable for those who want out of the box
use and no involvement whatsoever in the community, but it's not
there yet, and I've written that dozens of times (look at my blog,
the mailing lists, etc for all sorts of things along these lines).
Releases in OFBiz have historically just been marketing efforts. For
anyone doing customization it is a BAD BAD BAD idea to base it on a
release. That will effectively cut them off from interaction with the
community, and it will make it difficult to the point of "not worth
it" to contribute to the project. If everyone just used releases,
OFBiz would simply not exist.

So, I'll say it again: if you aren't involved with the community or
interested in becoming involved then hire someone that is or you'll
be in pain for a long while. It's like "installation" SAP without any
help... not many do that and if they do they hire people with
experience to work on it. There are dozens of service provider
companies all around the world, but don't expect most of them to
advertise much in the OFBiz world. Most of the live sites and other
deployments of OFBiz are sold by the service provider, only a few
companies survive based on the references that come through the open
source project....

Hopefully that's good enough for now... This sort of question comes
up a lot and I try to throw something like this out to the mailing
lists or somewhere every other month or so to make it easier to find.

-David




_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[BJ Freeman]

Andrew:
I run across this a lot. I get the info from the latest release not the
version I am running.
it is best to do a search thru the JIRA entries to see what has been
changed, then make the changes in your code.

I don't suggest a reload to the current SVN since there is no version
upgrade methods, expect for Table structures.



Andrew Dupa sent the following on 2/6/06 6:44 PM:

> There is no STATUS_ID that has any resemblance to "SERVICE_FINISED" anywhere
> related to JOB_SANDBOX. I guess we are talking about different versions
> here.
>
>
>
> There's an existing service called purgeOldJobs that already exists but I
> had to manually start, unfortunately I looked at the code and it proceeds to
> read every job in that is older than 4 days and delete it, this is a problem
> if you have 25K records to delete, why read them into memory then delete
> them? Ho hum…oh dear. But I now have it running and it should keep it
> manageable except for the next problem
>
>
>
> There is no "max-retry" element associated with a service definition, I get
> errors in the log when parsing the XML definition file. So jobs just keep on
> trying forever…great work guys!!!
>
>
>
>
> On 2/3/06, David E. Jones <[hidden email]> wrote:
>
>>
>>On Feb 3, 2006, at 1:56 AM, Andrew Dupa wrote:
>>
>>
>>>Well I guess I'll just work it out by reading the code and looking
>>>at the data model. My question was I thought pretty straight
>>>forward, unfortunately people responded without thinking.
>>>
>>>I was hoping this community would be smart and intelligent enough
>>>to support end users but they are it seems completely lost in a
>>>world of never ending development which never brings out the real
>>>world issues. No release management, no testing framework no
>>>stability. Users who don't read questions but answer with the
>>>bleeding obvious.
>>
>>This, perhaps, comes from a misunderstanding of what OFBiz is. It is
>>clear that it isn't what you expected it to be, and that is the case
>>for many people who are used to purchasing a piece of software and
>>becoming a "user" of the software.
>>
>>In a community-oriented open source project like OFBiz it only exists
>>because the community drives it. There is no company involved. No
>>investment from venture capitalists or angels and no bank loans or
>>anything (well, except maybe American Express and various other
>>credit card and home equity lenders during slower periods... ;) ).
>>
>>That means that the dozens of people who contribute to the project on
>>a regular basis and the hundreds of people who use the software in
>>their jobs generally can't get involved, I mean really simply cannot
>>get involved, unless they find some work doing so. Andy and I
>>invested quite a bit early on in the project, but this is certainly
>>true of us. Neither of us (while I guess I'm not really sure about
>>Andy) have a net worth in the black and without money coming in from
>>consulting work, we'd be in trouble pretty quickly... Actually, it's
>>not so bad, if it weren't for my ex-wife I'd probably be working 1
>>week a month for pay, another week per month on the project, and then
>>spending the remaining time cruising the world on the BMW GS
>>adventure bike I've been craving for years...
>>
>>Anyway, back to the point. OFBiz is a community driven project. We
>>all get along as we can and help move the forward as we can, and to
>>date ALL significant contributions to the project have been impelled
>>mostly by making things easier and cheaper in the future for those
>>involved. Lots of people have wanted to help, but it is just too much
>>to do as an amateur (unless you have no need for an income... but
>>even then without a project driving requirements and understanding,
>>it is hard to get your head around).
>>
>>So, are there issues? Yeah. It sounds like you want to be involved
>>with the project as a casual user, and that's almost impossible with
>>OFBiz. If you aren't involved with the community and working
>>regularly with the project then you pretty much have to hire someone
>>who is involved with the community and has invested sufficiently to
>>be able to work well with it.
>>
>>How is that different from major ERP packages? For them a "release"
>>is the same as for us, and they have the same problem with testing as
>>we do (ie the moving target problem). For them a "release" or a
>>standardized version is mostly just a sales and marketing tool. Once
>>these systems are customized (or "installed") out of the box testing
>>(except for low level components... maybe that's why we have entity
>>engine unit tests but not much else?) is not very useful, unless they
>>maintain the tests in parallel with the customizations. They will
>>also have various patches and changes that bring their system to a
>>state of being a creation like that of the good Dr. Frankenstein:
>>some of the "version" they think they have, some of the next version
>>(but not all), and a bunch of changes that they alone are responsible
>>for maintaining.
>>
>>Eventually OFBiz may be more usable for those who want out of the box
>>use and no involvement whatsoever in the community, but it's not
>>there yet, and I've written that dozens of times (look at my blog,
>>the mailing lists, etc for all sorts of things along these lines).
>>Releases in OFBiz have historically just been marketing efforts. For
>>anyone doing customization it is a BAD BAD BAD idea to base it on a
>>release. That will effectively cut them off from interaction with the
>>community, and it will make it difficult to the point of "not worth
>>it" to contribute to the project. If everyone just used releases,
>>OFBiz would simply not exist.
>>
>>So, I'll say it again: if you aren't involved with the community or
>>interested in becoming involved then hire someone that is or you'll
>>be in pain for a long while. It's like "installation" SAP without any
>>help... not many do that and if they do they hire people with
>>experience to work on it. There are dozens of service provider
>>companies all around the world, but don't expect most of them to
>>advertise much in the OFBiz world. Most of the live sites and other
>>deployments of OFBiz are sold by the service provider, only a few
>>companies survive based on the references that come through the open
>>source project....
>>
>>Hopefully that's good enough for now... This sort of question comes
>>up a lot and I try to throw something like this out to the mailing
>>lists or somewhere every other month or so to make it easier to find.
>>
>>-David
>>
>>
>>
>>
>>_______________________________________________
>>Users mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>
>>_______________________________________________
>>Users mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Dupa]

David

 

I understand what Ofbiz and I also understand what it could be.

 

I have years of experience, probably more than most. I develop large scale, multi site, 40+devs complex java distributed systems. I deal with devs who develop compilers, language definitions and features on web site to applications, I undertstand what you've built how it's been built and the trade offs. I also understand the quality trade offs and developer base code ownership issues. I understand release maangement QA and real world scenarios that crop up that get thru testing.

 

It takes a potential user thousand of man hours to validate a Ofbiz build and even then it's a risk, I see small independant people getting burnt and professionals keeping ideas internal as it's competitive advantage. I can't see the point anymore of OFbiz if you're not supporting the end users. Ofbiz is lost and the code is unstable and buggy.

 

If I had to choose I'd develop my in house solution then risk putting Ofbiz into production. You have lost your way as an open source solution. Let's hope the other crew get it together with regular builds and test infrastructure.

 

Anyway I helped out my friend, he's up and running, I told him to get off Ofbiz asap!!! I told him there's no upgrade path no community support. it's a huge risk that could cost him a lot of money in the end because it always does when it comes to softtware that doesn't play by the rules.

 

Would I consult on Ofbiz. No way, I don't want angry customers.

 

Good luck,

 

I like open source, I like software, but there are rules and when you don't play by the rules costs and bugs go up and quality goes down the toilet.
 

 

On 2/3/06, David E. Jones <[hidden email]> wrote:

On Feb 3, 2006, at 1:56 AM, Andrew Dupa wrote:

> Well I guess I'll just work it out by reading the code and looking
> at the data model. My question was I thought pretty straight
> forward, unfortunately people responded without thinking.
>
> I was hoping this community would be smart and intelligent enough
> to support end users but they are it seems completely lost in a
> world of never ending development which never brings out the real
> world issues. No release management, no testing framework no
> stability. Users who don't read questions but answer with the
> bleeding obvious.

This, perhaps, comes from a misunderstanding of what OFBiz is. It is
clear that it isn't what you expected it to be, and that is the case
for many people who are used to purchasing a piece of software and
becoming a "user" of the software.

In a community-oriented open source project like OFBiz it only exists
because the community drives it. There is no company involved. No
investment from venture capitalists or angels and no bank loans or
anything (well, except maybe American Express and various other
credit card and home equity lenders during slower periods... ;) ).

That means that the dozens of people who contribute to the project on
a regular basis and the hundreds of people who use the software in
their jobs generally can't get involved, I mean really simply cannot
get involved, unless they find some work doing so. Andy and I
invested quite a bit early on in the project, but this is certainly
true of us. Neither of us (while I guess I'm not really sure about
Andy) have a net worth in the black and without money coming in from
consulting work, we'd be in trouble pretty quickly... Actually, it's
not so bad, if it weren't for my ex-wife I'd probably be working 1
week a month for pay, another week per month on the project, and then
spending the remaining time cruising the world on the BMW GS
adventure bike I've been craving for years...

Anyway, back to the point. OFBiz is a community driven project. We
all get along as we can and help move the forward as we can, and to
date ALL significant contributions to the project have been impelled
mostly by making things easier and cheaper in the future for those
involved. Lots of people have wanted to help, but it is just too much
to do as an amateur (unless you have no need for an income... but
even then without a project driving requirements and understanding,
it is hard to get your head around).

So, are there issues? Yeah. It sounds like you want to be involved
with the project as a casual user, and that's almost impossible with
OFBiz. If you aren't involved with the community and working
regularly with the project then you pretty much have to hire someone
who is involved with the community and has invested sufficiently to
be able to work well with it.

How is that different from major ERP packages? For them a "release"
is the same as for us, and they have the same problem with testing as
we do (ie the moving target problem). For them a "release" or a
standardized version is mostly just a sales and marketing tool. Once
these systems are customized (or "installed") out of the box testing
(except for low level components... maybe that's why we have entity
engine unit tests but not much else?) is not very useful, unless they
maintain the tests in parallel with the customizations. They will
also have various patches and changes that bring their system to a
state of being a creation like that of the good Dr. Frankenstein:
some of the "version" they think they have, some of the next version
(but not all), and a bunch of changes that they alone are responsible
for maintaining.

Eventually OFBiz may be more usable for those who want out of the box
use and no involvement whatsoever in the community, but it's not
there yet, and I've written that dozens of times (look at my blog,
the mailing lists, etc for all sorts of things along these lines).
Releases in OFBiz have historically just been marketing efforts. For
anyone doing customization it is a BAD BAD BAD idea to base it on a
release. That will effectively cut them off from interaction with the
community, and it will make it difficult to the point of "not worth
it" to contribute to the project. If everyone just used releases,
OFBiz would simply not exist.

So, I'll say it again: if you aren't involved with the community or
interested in becoming involved then hire someone that is or you'll
be in pain for a long while. It's like "installation" SAP without any
help... not many do that and if they do they hire people with
experience to work on it. There are dozens of service provider
companies all around the world, but don't expect most of them to
advertise much in the OFBiz world. Most of the live sites and other
deployments of OFBiz are sold by the service provider, only a few
companies survive based on the references that come through the open
source project....

Hopefully that's good enough for now... This sort of question comes
up a lot and I try to throw something like this out to the mailing
lists or somewhere every other month or so to make it easier to find.

-David




_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

On Feb 6, 2006, at 7:57 PM, Andrew Dupa wrote:

> David
>
> I understand what Ofbiz and I also understand what it could be.
>
> I have years of experience, probably more than most. I develop  
> large scale, multi site, 40+devs complex java distributed systems.  
> I deal with devs who develop compilers, language definitions and  
> features on web site to applications, I undertstand what you've  
> built how it's been built and the trade offs. I also understand the  
> quality trade offs and developer base code ownership issues. I  
> understand release maangement QA and real world scenarios that crop  
> up that get thru testing.

Wow, you are absolutely incredible. I guess then the SQL query to pop  
out those unwanted records and the data structure analysis required  
to write were a breeze then.

I think I see then what your message here _must_ have been: not a  
request for help, but rather a place to vent your frustrations!

> It takes a potential user thousand of man hours to validate a Ofbiz  
> build and even then it's a risk, I see small independant people  
> getting burnt and professionals keeping ideas internal as it's  
> competitive advantage. I can't see the point anymore of OFbiz if  
> you're not supporting the end users. Ofbiz is lost and the code is  
> unstable and buggy.
>
> If I had to choose I'd develop my in house solution then risk  
> putting Ofbiz into production. You have lost your way as an open  
> source solution. Let's hope the other crew get it together with  
> regular builds and test infrastructure.
>
> Anyway I helped out my friend, he's up and running, I told him to  
> get off Ofbiz asap!!! I told him there's no upgrade path no  
> community support. it's a huge risk that could cost him a lot of  
> money in the end because it always does when it comes to softtware  
> that doesn't play by the rules.

Based on what you said this would be my recommendation as well, ie  
that they no longer continue to use OFBiz. Well, even without what  
you've written I'd recommend that they certainly not use 3.0.0 (I've  
written and recommended that dozens of times).

> Would I consult on Ofbiz. No way, I don't want angry customers.

Based on the way you approached these issues I would agree with you  
here too. Consulting on OFBiz may not be the best idea.

> Good luck,
>
> I like open source, I like software, but there are rules and when  
> you don't play by the rules costs and bugs go up and quality goes  
> down the toilet.

Thanks for the well wishing, it is well appreciated.

There are a number of "rules" of the software industry that we aspire  
to "play by". Still, without them things continue to progress and  
until we reach perfection that is all we can expect. If you are not  
interested in the progress that has been made in the last 2 years or  
in community interaction, there isn't really much we can do. We  
certainly don't have the resources to hop into every OFBiz project  
and solve all of their problems. Man, wouldn't it be nice to have  
that for free! I'd take it in a heart beat!

-David

> On 2/3/06, David E. Jones <[hidden email]> wrote:
> On Feb 3, 2006, at 1:56 AM, Andrew Dupa wrote:
>
> > Well I guess I'll just work it out by reading the code and looking
> > at the data model. My question was I thought pretty straight
> > forward, unfortunately people responded without thinking.
> >
> > I was hoping this community would be smart and intelligent enough
> > to support end users but they are it seems completely lost in a
> > world of never ending development which never brings out the real
> > world issues. No release management, no testing framework no
> > stability. Users who don't read questions but answer with the
> > bleeding obvious.
>
> This, perhaps, comes from a misunderstanding of what OFBiz is. It is
> clear that it isn't what you expected it to be, and that is the case
> for many people who are used to purchasing a piece of software and
> becoming a "user" of the software.
>
> In a community-oriented open source project like OFBiz it only exists
> because the community drives it. There is no company involved. No
> investment from venture capitalists or angels and no bank loans or
> anything (well, except maybe American Express and various other
> credit card and home equity lenders during slower periods... ;) ).
>
> That means that the dozens of people who contribute to the project on
> a regular basis and the hundreds of people who use the software in
> their jobs generally can't get involved, I mean really simply cannot
> get involved, unless they find some work doing so. Andy and I
> invested quite a bit early on in the project, but this is certainly
> true of us. Neither of us (while I guess I'm not really sure about
> Andy) have a net worth in the black and without money coming in from
> consulting work, we'd be in trouble pretty quickly... Actually, it's
> not so bad, if it weren't for my ex-wife I'd probably be working 1
> week a month for pay, another week per month on the project, and then
> spending the remaining time cruising the world on the BMW GS
> adventure bike I've been craving for years...
>
> Anyway, back to the point. OFBiz is a community driven project. We
> all get along as we can and help move the forward as we can, and to
> date ALL significant contributions to the project have been impelled
> mostly by making things easier and cheaper in the future for those
> involved. Lots of people have wanted to help, but it is just too much
> to do as an amateur (unless you have no need for an income... but
> even then without a project driving requirements and understanding,
> it is hard to get your head around).
>
> So, are there issues? Yeah. It sounds like you want to be involved
> with the project as a casual user, and that's almost impossible with
> OFBiz. If you aren't involved with the community and working
> regularly with the project then you pretty much have to hire someone
> who is involved with the community and has invested sufficiently to
> be able to work well with it.
>
> How is that different from major ERP packages? For them a "release"
> is the same as for us, and they have the same problem with testing as
> we do (ie the moving target problem). For them a "release" or a
> standardized version is mostly just a sales and marketing tool. Once
> these systems are customized (or "installed") out of the box testing
> (except for low level components... maybe that's why we have entity
> engine unit tests but not much else?) is not very useful, unless they
> maintain the tests in parallel with the customizations. They will
> also have various patches and changes that bring their system to a
> state of being a creation like that of the good Dr. Frankenstein:
> some of the "version" they think they have, some of the next version
> (but not all), and a bunch of changes that they alone are responsible
> for maintaining.
>
> Eventually OFBiz may be more usable for those who want out of the box
> use and no involvement whatsoever in the community, but it's not
> there yet, and I've written that dozens of times (look at my blog,
> the mailing lists, etc for all sorts of things along these lines).
> Releases in OFBiz have historically just been marketing efforts. For
> anyone doing customization it is a BAD BAD BAD idea to base it on a
> release. That will effectively cut them off from interaction with the
> community, and it will make it difficult to the point of "not worth
> it" to contribute to the project. If everyone just used releases,
> OFBiz would simply not exist.
>
> So, I'll say it again: if you aren't involved with the community or
> interested in becoming involved then hire someone that is or you'll
> be in pain for a long while. It's like "installation" SAP without any
> help... not many do that and if they do they hire people with
> experience to work on it. There are dozens of service provider
> companies all around the world, but don't expect most of them to
> advertise much in the OFBiz world. Most of the live sites and other
> deployments of OFBiz are sold by the service provider, only a few
> companies survive based on the references that come through the open
> source project....
>
> Hopefully that's good enough for now... This sort of question comes
> up a lot and I try to throw something like this out to the mailing
> lists or somewhere every other month or so to make it easier to find.
>
> -David
>
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

David,

As someone who doesn't believe I could knock together my own OFBiz in a
weekend, I think I'll probably stick with OFBiz (at least until Andrew D
blows you out the water with a comparable system - no doubt that's just
around the corner!?)

However, perhaps it would be a good idea to create some documentation
suggesting best practices for development with OFBiz, here's some stuff
I do to try to make my applications a little more future proof during
this period of hectic development...

_Never Ever_ modify the OFBiz code directly (unless I can submit the
change back to OFBiz). Where I need to hack some core part of OFbiz in a
non standard way I create a patch and apply this at build time to the
latest SVN copy. I even do this with things like entityengine.xml.
Depending on the type of change, I'll either apply the patch directly to
an OFBiz component or I'll copy en existing component to hot-deploy and
patch it there (which then overrides the original component). I always
try to use hot-deploy where possible, this cuts down on the the
relationship between my code and OFBiz.

This hardly represents a best practice strategy, but it does reduce the
hassle of updating OFBiz from SVN on a frequent basis. I'm sure there
are lots of other tricks people use to alleviate the pain.

It would be a good idea to assemble all these tricks into something
resembling a strategy for the developer.

My own experience of OFBiz is it's a "God send" when implementing
something new, but after that things can get a bit painful. We still
have a couple of sites running 2.1 because it just isn't viable to
upgrade. Unfortunately it would probably cost about 2x the original
implementation price to actually migrate to a newer OFBiz. On the other
hand our 2.1 stuff still performs well and does everything we need it
to!

I think this represents a slightly different perspective from your own
rather omnipotent view of OFBiz, remember most of us don't have the type
of contracts that allow us to contribute vast chunks of our work back to
the core, changes are therefore something of a surprise and we have to
stumble from one version to another.

Having said all that, I can at least consider myself fortunate enough to
not be under the misconception that OFBiz represents a trivial amount of
work that I could reproduce for myself - I'd love to see my bank
manager's face if I took that proposal to him!

Keep up the good work!
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Jacques Le Roux]

From: "Andrew Sykes" <[hidden email]>


> David,
>
> As someone who doesn't believe I could knock together my own OFBiz in a
> weekend, I think I'll probably stick with OFBiz (at least until Andrew D
> blows you out the water with a comparable system - no doubt that's just
> around the corner!?)

Yeah, really ? ;o)

> However, perhaps it would be a good idea to create some documentation
> suggesting best practices for development with OFBiz, here's some stuff
> I do to try to make my applications a little more future proof during
> this period of hectic development...
>
> _Never Ever_ modify the OFBiz code directly (unless I can submit the
> change back to OFBiz). Where I need to hack some core part of OFbiz in a
> non standard way I create a patch and apply this at build time to the
> latest SVN copy. I even do this with things like entityengine.xml.
> Depending on the type of change, I'll either apply the patch directly to
> an OFBiz component or I'll copy en existing component to hot-deploy and
> patch it there (which then overrides the original component). I always
> try to use hot-deploy where possible, this cuts down on the the
> relationship between my code and OFBiz.

Thanks Andrew to share with us your way to do it. Sorry I have no time to
comment, but yes it seems a reasonnable way. I will try it as I began to have
trouble with the way I'm doing it.


> This hardly represents a best practice strategy, but it does reduce the
> hassle of updating OFBiz from SVN on a frequent basis. I'm sure there
> are lots of other tricks people use to alleviate the pain.
>
> It would be a good idea to assemble all these tricks into something
> resembling a strategy for the developer.

Perhaps, waiting for better, a page in the Wiki (if there is none already
created) would be enough for now ?

Jacques

> My own experience of OFBiz is it's a "God send" when implementing
> something new, but after that things can get a bit painful. We still
> have a couple of sites running 2.1 because it just isn't viable to
> upgrade. Unfortunately it would probably cost about 2x the original
> implementation price to actually migrate to a newer OFBiz. On the other
> hand our 2.1 stuff still performs well and does everything we need it
> to!
>
> I think this represents a slightly different perspective from your own
> rather omnipotent view of OFBiz, remember most of us don't have the type
> of contracts that allow us to contribute vast chunks of our work back to
> the core, changes are therefore something of a surprise and we have to
> stumble from one version to another.
>
> Having said all that, I can at least consider myself fortunate enough to
> not be under the misconception that OFBiz represents a trivial amount of
> work that I could reproduce for myself - I'd love to see my bank
> manager's face if I took that proposal to him!
>
> Keep up the good work!
> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Blessing, Jeffrey J]

As a newcomer to OFBiz, I could benefit from a "How To" with regard to patching the source code.  I've just built the hello1, hello2, and hello3 tutorials from Si Chen, and am now investigating the OpenSourceTravel code base for ideas and I've already encountered the problem Andrew describes.  Could someone point me in the right direction?
 
Thanks (in advance),
-Jeff


From: "Andrew Sykes" <[hidden email]>


> David,
>
> As someone who doesn't believe I could knock together my own OFBiz in a
> weekend, I think I'll probably stick with OFBiz (at least until Andrew D
> blows you out the water with a comparable system - no doubt that's just
> around the corner!?)

Yeah, really ? ;o)

> However, perhaps it would be a good idea to create some documentation
> suggesting best practices for development with OFBiz, here's some stuff
> I do to try to make my applications a little more future proof during
> this period of hectic development...
>
> _Never Ever_ modify the OFBiz code directly (unless I can submit the
> change back to OFBiz). Where I need to hack some core part of OFbiz in a
> non standard way I create a patch and apply this at build time to the
> latest SVN copy. I even do this with things like entityengine.xml.
> Depending on the type of change, I'll either apply the patch directly to
> an OFBiz component or I'll copy en existing component to hot-deploy and
> patch it there (which then overrides the original component). I always
> try to use hot-deploy where possible, this cuts down on the the
> relationship between my code and OFBiz.

Thanks Andrew to share with us your way to do it. Sorry I have no time to
comment, but yes it seems a reasonnable way. I will try it as I began to have
trouble with the way I'm doing it.


> This hardly represents a best practice strategy, but it does reduce the
> hassle of updating OFBiz from SVN on a frequent basis. I'm sure there
> are lots of other tricks people use to alleviate the pain.
>
> It would be a good idea to assemble all these tricks into something
> resembling a strategy for the developer.

Perhaps, waiting for better, a page in the Wiki (if there is none already
created) would be enough for now ?

Jacques

> My own experience of OFBiz is it's a "God send" when implementing
> something new, but after that things can get a bit painful. We still
> have a couple of sites running 2.1 because it just isn't viable to
> upgrade. Unfortunately it would probably cost about 2x the original
> implementation price to actually migrate to a newer OFBiz. On the other
> hand our 2.1 stuff still performs well and does everything we need it
> to!
>
> I think this represents a slightly different perspective from your own
> rather omnipotent view of OFBiz, remember most of us don't have the type
> of contracts that allow us to contribute vast chunks of our work back to
> the core, changes are therefore something of a surprise and we have to
> stumble from one version to another.
>
> Having said all that, I can at least consider myself fortunate enough to
> not be under the misconception that OFBiz represents a trivial amount of
> work that I could reproduce for myself - I'd love to see my bank
> manager's face if I took that proposal to him!
>
> Keep up the good work!
> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users



 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Dupa]

Why not read the thread? You can delete records form the database you know? Or use the admin screen (which is buggy and won't work) Don't ask which tables or fields to look at because these guys are too busy writing their never to be released version. Whoever wrote that code didn't bother to test it or understand it. Just delete some stuff, lucky for you it's not production. (We don't "can't" deal with real world problems here) Can't you work it out yourself. I've joined the Ofbiz community I'm on board now. Work it out yourself...that's how it goes right?

 

David your response is hilarious and pathetic. You're an idiot leading the blind

 

Andrew

 

On 2/7/06, Blessing, Jeffrey J <[hidden email]> wrote:

As a newcomer to OFBiz, I could benefit from a "How To" with regard to patching the source code.  I've just built the hello1, hello2, and hello3 tutorials from Si Chen, and am now investigating the OpenSourceTravel code base for ideas and I've already encountered the problem Andrew describes.  Could someone point me in the right direction?

Thanks (in advance),
-Jeff


From: "Andrew Sykes" <[hidden email]>


> David,
>
> As someone who doesn't believe I could knock together my own OFBiz in a
> weekend, I think I'll probably stick with OFBiz (at least until Andrew D
> blows you out the water with a comparable system - no doubt that's just
> around the corner!?)

Yeah, really ? ;o)

> However, perhaps it would be a good idea to create some documentation

> suggesting best practices for development with OFBiz, here's some stuff
> I do to try to make my applications a little more future proof during
> this period of hectic development...
>
> _Never Ever_ modify the OFBiz code directly (unless I can submit the
> change back to OFBiz). Where I need to hack some core part of OFbiz in a
> non standard way I create a patch and apply this at build time to the
> latest SVN copy. I even do this with things like entityengine.xml.
> Depending on the type of change, I'll either apply the patch directly to
> an OFBiz component or I'll copy en existing component to hot-deploy and
> patch it there (which then overrides the original component). I always
> try to use hot-deploy where possible, this cuts down on the the
> relationship between my code and OFBiz.

Thanks Andrew to share with us your way to do it. Sorry I have no time to
comment, but yes it seems a reasonnable way. I will try it as I began to have
trouble with the way I'm doing it.


> This hardly represents a best practice strategy, but it does reduce the
> hassle of updating OFBiz from SVN on a frequent basis. I'm sure there
> are lots of other tricks people use to alleviate the pain.
>
> It would be a good idea to assemble all these tricks into something
> resembling a strategy for the developer.

Perhaps, waiting for better, a page in the Wiki (if there is none already
created) would be enough for now ?

Jacques

> My own experience of OFBiz is it's a "God send" when implementing
> something new, but after that things can get a bit painful. We still
> have a couple of sites running 2.1 because it just isn't viable to
> upgrade. Unfortunately it would probably cost about 2x the original
> implementation price to actually migrate to a newer OFBiz. On the other
> hand our 2.1 stuff still performs well and does everything we need it
> to!
>
> I think this represents a slightly different perspective from your own
> rather omnipotent view of OFBiz, remember most of us don't have the type
> of contracts that allow us to contribute vast chunks of our work back to
> the core, changes are therefore something of a surprise and we have to
> stumble from one version to another.
>
> Having said all that, I can at least consider myself fortunate enough to
> not be under the misconception that OFBiz represents a trivial amount of
> work that I could reproduce for myself - I'd love to see my bank
> manager's face if I took that proposal to him!
>

> Keep up the good work!

> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

This document is meant to represent the more significant best practices:

http://www.ofbiz.org/best-practices.html

It needs a bit of updating, like the revision control section talks  
about CVS and needs to be updated to be more specific to SVN (which  
does much better with this sort of thing actually). There is some  
information about that in the Wiki, and there are lots of good books  
about SVN including the pragmatic version control one on the Docs &  
Books page.

-David


On Feb 7, 2006, at 4:48 AM, Andrew Sykes wrote:

> David,
>
> As someone who doesn't believe I could knock together my own OFBiz  
> in a
> weekend, I think I'll probably stick with OFBiz (at least until  
> Andrew D
> blows you out the water with a comparable system - no doubt that's  
> just
> around the corner!?)
>
> However, perhaps it would be a good idea to create some documentation
> suggesting best practices for development with OFBiz, here's some  
> stuff
> I do to try to make my applications a little more future proof during
> this period of hectic development...
>
> _Never Ever_ modify the OFBiz code directly (unless I can submit the
> change back to OFBiz). Where I need to hack some core part of OFbiz  
> in a
> non standard way I create a patch and apply this at build time to the
> latest SVN copy. I even do this with things like entityengine.xml.
> Depending on the type of change, I'll either apply the patch  
> directly to
> an OFBiz component or I'll copy en existing component to hot-deploy  
> and
> patch it there (which then overrides the original component). I always
> try to use hot-deploy where possible, this cuts down on the the
> relationship between my code and OFBiz.
>
> This hardly represents a best practice strategy, but it does reduce  
> the
> hassle of updating OFBiz from SVN on a frequent basis. I'm sure there
> are lots of other tricks people use to alleviate the pain.
>
> It would be a good idea to assemble all these tricks into something
> resembling a strategy for the developer.
>
> My own experience of OFBiz is it's a "God send" when implementing
> something new, but after that things can get a bit painful. We still
> have a couple of sites running 2.1 because it just isn't viable to
> upgrade. Unfortunately it would probably cost about 2x the original
> implementation price to actually migrate to a newer OFBiz. On the  
> other
> hand our 2.1 stuff still performs well and does everything we need it
> to!
>
> I think this represents a slightly different perspective from your own
> rather omnipotent view of OFBiz, remember most of us don't have the  
> type
> of contracts that allow us to contribute vast chunks of our work  
> back to
> the core, changes are therefore something of a surprise and we have to
> stumble from one version to another.
>
> Having said all that, I can at least consider myself fortunate  
> enough to
> not be under the misconception that OFBiz represents a trivial  
> amount of
> work that I could reproduce for myself - I'd love to see my bank
> manager's face if I took that proposal to him!
>
> Keep up the good work!
> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

Jeff,

It's a good idea to keep in mind that things are changing quite rapidly
in OFBiz so if you are creating your own webapp along the lines that Si
describes, try to stick to those principles.

Here's some examples...
1/ If you are adding DB schema (entitymodel/entitygroup) make sure you
add it to your own webapp in the way Si describes, don't just open up an
existing entitymodel and add some extra stuff in there.
2/ The same applies to data, make sure xml data sits in your own
application directory, not somewhere else.
This way both of the above do not rely on anything in the OFBiz trunk so
you can be sure that the files your ofbiz-component.xml refers to are
always there.
3/ Don't copy anything you don't need, for example with an ecommerce
app, you might only need a subset of the functionality offered, don't
just copy stuff in case you need it in future, you can always pick it up
later if you need it.
4/ There's some files you just can't avoid customising, for example the
entityengine.xml file. With this file, I make the necessary changes and
then use SVN to create a patch, like so...
        A/ Edit entityengine.xml
        B/ Create a patch (use IDE's 'create patch' or 'svn diff')
        C/ Keep this patch in you application directory and write an ant task
to apply it. e.g.
            <target name="patch">
                <patch patchfile="entityengine.xml.patch"
originalfile="${ofbiz_home}/framework/entity/config/entityengine.xml" />
            </target>
Sometimes these patches fail, but mostly they work just fine.

5/ Always use the hot-deploy directory, just drop you application in
there and OFBiz loads it up after everything else.

There's probably loads more clever tricks, but this will definitely cut
down on the cost of upgrading.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users