Users - JOB _SANDBOX

[cjhowe]

There is a "best-so-far" practice in the Wiki already
http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21

I would recomend to everyone DO NOT TOUCH THE
UNDERLYING CODE and DO NOT COPY AN ENTIRE APPLICATION
of ofbiz if you don't know what you're doing and/or
you want to benefit from future SVN revisions.

Rememeber that your milage may certainly vary,
especially if you're talking about the OFBiz
framework.

This approach has allowed me to do SVN updates about
monthly (up until the recent JAR removal project),
which on average is about 200 SVN revisions in about
30 minutes.   I can do a fresh install, evaluate the
parts that I use, throw my mini application on it and
evaluate it to make sure nothing suprising pops up.  A
production site should only be using the parts of
OFBiz that you use in order to reduce possible
conflicts.  That coupled with staying up to date with
Si's SVN blog should make you feel about 95% secure
that it's doing what it should be.  


================= Jacques Le Roux wrote:
From: "Andrew Sykes" <andrew at sykesdevelopment.com>


> 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 <andrew at sykesdevelopment.com>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/users

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