Properly edited OFBiz manuals

[David E Jones-2]

On Dec 28, 2006, at 2:38 AM, Scott Gray wrote:

> Hi Jacopo, David
>
> I would just as happily submit patches for releases as I do for the  
> trunk, and perhaps we should just assume the community can handle  
> it until we are proven otherwise?  I would expect that we could  
> handle the first release easily, and it would just get harder as  
> the number of releases increases?

This is exactly what I'm hoping for... and I agree that things would  
get harder as the number of release branches increases so we'd want  
to do something to minimize this. Like I mentioned in the email I  
just wrote a somewhat happy medium might be doing a new release  
branch from the trunk once per year.

-David

>
> Regards
> Scott
>
> Jacopo Cappellato wrote:
>> Of course it would also be great to have a real 'stable' releases  
>> (with patches for them etc...) as you are suggesting (and I really  
>> think we could implement the two approaches simultaneously since  
>> what I've proposed could be the basis of a real release  
>> management) but I'm not sure the community will really maintain  
>> them...
>

[Jacques Le Roux]

I agree with David.

IMHO tt seems the best way to go. Having to support 2 or 3 releases seems reasonable. More seems infeasible in our actual reality.

I don't know much about it but it looks like how Debian is driven and that way seems to work well.
If on the road we are lucky and find more ressources (I mean human ressources ;o) we may then go the way Ubuntu is going : creating
a new release every 6 months (Debian frequency is 18 months if I'm not wrong).
Also Ubuntu has chosen to support versions during 18 months. Ubuntu 6.06 LTS being the 1st exception : LTS stands for Long Time
Support meaning 3 years for desktop 5 years for server here (BTW 6.06 means june 2006). I think we may inspire ourself by this
support policy (inspiring is not copying ;o) and external releases numbering. We may have other release number in intern but that
may complicate things a bit.

In conclusion : I like this way to go because it's not too techie and simple to understand for end users (meaning not developpers
here)

WDYT ?

Jacques


----- Original Message -----
From: "David E Jones" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, December 28, 2006 9:15 PM
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz manuals]

>
> On Dec 28, 2006, at 2:09 AM, Jacopo Cappellato wrote:
>
> > David E Jones wrote:
> >> I guess it depends on what the goal of doing a release is. In my
> >> mind the goal should be to create (over time...) a stable set of
> >> artifacts that people can build and deploy on if they choose not
> >> to go with the latest/greatest.
> >> What you're describing is interesting, but how is that any
> >> different than just using the latest from SVN with a little timing
> >> based on knowing what is going on added in, and keeping a list
> >> somewhere of all non-backwards compatible changes and their
> >> revision numbers?
> >
> > Yes, you have described pretty well what I'm suggesting; I'd only
> > add to these that we should also create the upgrade services (and/
> > or upgrade instructions) every time we commit a non-backwards
> > compatible change in svn. As you said, this is not so different
> > from what we are (implicitly) suggesting to do right now (as a best
> > practice to stay up-to-date with the trunk) but I think that it
> > would be nice if the community will officially support it for a few
> > reasons:
> >
> > 1) it's often difficult for users to pick a 'stable' svn snapshot
> > 2) it's often difficult for users to keep track of important
> > changes between their revision and the trunk
> > 3) since it is not so different from what we are suggesting right
> > now, it will not add a huge cost maintaining these extra processes/
> > releases
>
> The problem I see, trying to look at it from the point of a
> prospective end-user, is that this sort of frequent release doesn't
> help me a lot.
>
> 1. If I want a good, stable version where I don't have to worry about
> bugs, which one do I choose?
>
> 2. If I realize there is no perfect version because of constrained
> community resources but at least want to group together with others
> to support a certain release, which one do I choose when there are so
> many coming out so fast?
>
> 3. Once I have chosen and have been running for a while and want to
> upgrade OFBiz, which newer version do I choose (related to the above
> questions) and how much work is it going to be to not be able to
> update from that version to the version I choose, but instead go
> through the upgrade processes for every version between that one and
> the one I choose?
>
>
> >> But, back to the main point: what is the goal of a release in your
> >> mind (and in the mind of anyone else reading in too)?
> >
> > I'd like to get the opinions from others too.
> > Personally I think that releases (or release instructions/plans)
> > should at least help users to keep their system/data in sync with
> > the main trunk, minimizing the upgrade costs and simplifying the
> > users' decisions (i.e. "should I upgrade now?").
> > Of course it would also be great to have a real 'stable' releases
> > (with patches for them etc...) as you are suggesting (and I really
> > think we could implement the two approaches simultaneously since
> > what I've proposed could be the basis of a real release management)
> > but I'm not sure the community will really maintain them...
>
> I'd say if people want to stay in sync with the trunk, there is
> nothing better than the trunk for doing so... In my opinion doing
> some sort of regular "release" would only make it more difficult for
> people to keep up with the trunk and participate in or contribute to
> OFBiz because they would never be quite up to date.
>
> What I'm hoping for is a single, infrequent branch that people can
> rally around and maintain together. If we only do one of these each
> year or so then there will never be a question about which one needs
> fixes back patched to it as we'd only support at MOST 2-3 of these at
> any given time. That would mean people would need to update at least
> once every 3 years, but of course that's just a random artificial
> number and being a community driven thing if there is a group that
> wants to continue to maintain an older branch then great, more power
> to them!
>
> People looking for a good release to use if they are asking question
> #1 above would use the latest release in the latest stable branch
> that is at least, say, 3 months old. For people asking question #2
> above they could just use the latest stable branch as-is from the SVN
> directory for that branch and participate in making the branch better.
>
> -David

[Walter Vaughan]

[..snip..]

Golly, what a can of worms is open here. Actually what drew me to ofBiz was the
amount of updates to the system.

The last commercial ERP solution we considered was SYSPRO. The folks at Syspro
PRIDE themselves on weekly ports to their software. I have/had an .iso of a
marketing DVD they have with almost two hours of non-stop preaching how ERP
systems must and should be updated on a continuous basis, and that point release
updates are evil. (e.g. 5.0 -> 6.0 on done every 18 months)

I was sold. Couldn't justify the seat costs for the number I needed, but I was
sold on the concept. During our courting period I also got a weekly email that
was similar to what Si Chen does with his blog listing the dozen or so
improvements to the system in the past week, and this in an ERP system with
15,000 current installs.

As a end user, what I am looking for is non-failure. Thus far I have more than
enough trust in the core developers to always do the right thing.

--
Walter

[David E Jones-2]

On Dec 28, 2006, at 6:54 PM, Walter Vaughan wrote:

> [..snip..]
>
> Golly, what a can of worms is open here. Actually what drew me to  
> ofBiz was the amount of updates to the system.
>
> The last commercial ERP solution we considered was SYSPRO. The  
> folks at Syspro PRIDE themselves on weekly ports to their software.  
> I have/had an .iso of a marketing DVD they have with almost two  
> hours of non-stop preaching how ERP systems must and should be  
> updated on a continuous basis, and that point release updates are  
> evil. (e.g. 5.0 -> 6.0 on done every 18 months)
>
> I was sold. Couldn't justify the seat costs for the number I  
> needed, but I was sold on the concept. During our courting period I  
> also got a weekly email that was similar to what Si Chen does with  
> his blog listing the dozen or so improvements to the system in the  
> past week, and this in an ERP system with 15,000 current installs.
>
> As a end user, what I am looking for is non-failure. Thus far I  
> have more than enough trust in the core developers to always do the  
> right thing.

I think this really comes down to community needs. There is and  
always will be a trunk moving forward with both new features and bug  
fixes and we'll always want to keep it as stable as possible, and  
people can update whenever they want to.

This is another reason I like the idea of a long period between  
creating new release branches: developers will hopefully never think  
that they can commit something risky without checking it out thinking  
that it won't affect anyone...

Still, I think there is enough demand in the community for periodic  
releases. There is also a marketing aspect here that I think is  
important, especially as we get out as a real ASF project and are  
wanting to attract new users as well as help other people get an idea  
of what OFBiz is all about.

-David

[Jacques Le Roux]

Walter,

Of course I was not thinking of changing that's already exist :
SVN trunk will be always available...

Jacques

----- Original Message -----
From: "Walter Vaughan" <[hidden email]>
To: <[hidden email]>
Sent: Friday, December 29, 2006 2:54 AM
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz manuals]

> [..snip..]
>
> Golly, what a can of worms is open here. Actually what drew me to ofBiz was the
> amount of updates to the system.
>
> The last commercial ERP solution we considered was SYSPRO. The folks at Syspro
> PRIDE themselves on weekly ports to their software. I have/had an .iso of a
> marketing DVD they have with almost two hours of non-stop preaching how ERP
> systems must and should be updated on a continuous basis, and that point release
> updates are evil. (e.g. 5.0 -> 6.0 on done every 18 months)
>
> I was sold. Couldn't justify the seat costs for the number I needed, but I was
> sold on the concept. During our courting period I also got a weekly email that
> was similar to what Si Chen does with his blog listing the dozen or so
> improvements to the system in the past week, and this in an ERP system with
> 15,000 current installs.
>
> As a end user, what I am looking for is non-failure. Thus far I have more than
> enough trust in the core developers to always do the right thing.
>
> --
> Walter
>
>

[Cameron Smith-6]

My 2 metical after following all the other arguments....  I would be happy to help with detailing and preparing the release procedures and regression tests (see below).

1. Goal of a Release
I agree with David that it should provide a stable set of artifacts.  NOT just at the level of screens, but at the level of services and entities because almost everyone who deploys OFBiz customizes it in some way.  This is different from some end-user apps which periodically do a complete rewrite of the internals but keep the interface sufficiently recognizable so as not to alienate the customer base (ex. MS Office, Tomcat 3 -> 4 -> 5).

OFBiz has a great advantage here because all core funcionality exposes an API which is basically the sum of the services and Entities involved, plus a few other standard config structures (ofbiz-component.xml and controller.xml). Therefore I believe we should structure our compatibility objectives around services and entities.  For instance, if we say that release B is "API backwards compatible" with release A, that means extensions which depended on services and/or entities from release A will still work with B.  Some of these services or entities may have added optional parameters or new nullable columns, just as long as they keep providing the old API.  

In contrast, if someone writes their extension to also depend on a certain Util class or simple-method, the releases make no compatibility guarantees here.

For instance I am writing a module now, to do end-of-month VAT reconciliation according to Mozambican regulations.  It uses certain services in the accounting module as building blocks.  If a future release removed or altered the API of those services, I would be stuck.  If a future release added a few extra optional parameters to those services, I would not be forced to alter anything.

2. Release versioning policy and testing
Based on the above discussion and also the contributions made thus far, I would suggest the following approach.
a) We aim at ONE release per year, coming out every June or thereabouts.   I think it is better to have ONE deliverable per year and meet it than two or three which immediately slip.  The Ubuntu project has a larger community, a rich private backer (Mark Shuttleworth), started with a much more established set of release tools and procedures (from Debian), and still slipped Dapper from being 6.04 to 6.06.   Note that only 6.06 is LTS (long term support), and 6.10 is not.

b) The SysPro argument for continuous updates is interesting but rings completely false with the target market I have in mind - small bricks and mortar commercial enterprises.  From my experience both in UK and MZ, these places know their businesses and once they have got ERP support for their core processes, they prefer to get on with business instead of constantly looking for new features.  They prefer to workaround minor feature incompatibilities than risk disruption and instability.

c) So an annual release in the middle of each year gives us this rhythm:
 *At the start of the year, start stabilizing any new or reworked functionality.
 *In May or thereabouts, core commiters insitutue a freeze on big changes and only let in bugfixes
 *In June, make the new branch, test it and commit fixes to the branch.
 *End of June, version the branch and announce it as a release.
 *At this point, commiters let big changes back into the trunk
 *In parallel, the release maintainers do bugfixes ONLY on the release and merge them back into trunk wherever it makes sense.
 *By December, anyone who takes the latest version of the release, should be guaranteed that it is pretty stable.  If they want any features they go for the SVN trunk.

d) Using the definitions here: http://apr.apache.org/versioning.html
 *A release from year N should be minor version compatible with the release from year N-1
 *Once the release from year N is out, it should only suffer patch versions

e) Testing.   David makes a good point about the vastness of OFBiz and the difficulty of guaranteeing that a certain version is stable.  I believe that in the long term, the only solution is to build up a suite of regression tests.  Its a lot of work but it is definitely worth it, for the security it gives you when refactoring.

I believe we need to build up two layers of tests:
 *Integration tests: black-box tests which test the APIs of all the services and entities.  I am already using the OFBiz TestContainer framework for this.  I suggested some tweaks to it a few months back but didn't get any feedback at that time.
 *Web Tests: white box tests which exercise/simulate a browser and test core use cases (e.g. create invoice, receive order, etc, etc).  I am already using Watir for this but there are other frameworks.  I would be happy to write up a little tutorial for how to do this on the OFBiz wiki.

3. SVN policy
I believe we SHOULD use branching, because it allows for a stable release in that it receives bugfixes ONLY, which can be backported to the trunk if necessary.  So basically at any one time, the community is supporting 3 streams: the trunk + last release branch + upcoming release branch.

4. Modules
I agree with David that we should NOT try to separate modules.  At most releasing framework and applications as two separate chunks, as David suggests, but I think even that is a secondary priority to having stable supported releases.   There are several reasons for this....
 a) For Commercial ERPs, the "modules" are largely a way of justifying a larger bill to the client.  The boundaries between modules are often gerrymandered so that when you buy modules A and B, you have to buy C as well just because it has one little function that a "normal person" would say logically should be part of C.
 b) OFBiz modules are largely structures to facilitate team development.  They are not fully independent - there is a lot of interdependence at the entity and service level - and this is natural given that the whole point is an Integrated system.  Businesses are borne integrated and often departmentalize as a side-effect of growth.  Later on they spend huge efforts trying to reintegrate once more.
 c) I don't believe the community is big enough to support the additional effort of unpicking, specifying and maintain "clean interfaces" and data-flow consistency between all the modules.  I believe that effort would be better spend stabilizing the APIs at service and entity level as discussed above.
 d) David is right about the Linux packaging systems.  Whether RPM or DEB, they have a laudable ideal but in practice can make a nominally simple job inordinately complex.   So people have to write (very) clever helper tools on top of them (ex Synaptic on top of apt on top of dpkg on top of deb!!)

5. Documentation
I agree with Torsten that we need to lower the cost of entry to OFBiz, but I also agree that we need to ask "lower the cost of entry to what?".

In fact, contrary to what Jacopo suggests, I believe that there IS a set of core functions which I believe there is a huge target market for in much of the world, among people who could never afford SAP.  These functions are fairly consistent - and they don't need to come with "bells on".  And I would imagine its not a coincidence that OpenTAPS has chosen several of them as the focus for its Financials module.

Basic Accounting (Journal Entry with separate Posting, Balance Sheet, Trial Balance, Data export to Excel)
Client Account management (invoices, statements by age, payments, basic customer details)
Supplier management (basic supplier details, invoices, statements by age, payments)

A secondary set of priorities would be:
Integration between Client/Supplier managament and accounting
Payroll management
Stocks mgt (warehouse, orders in and out)
VAT or equivalent

An alternative core set, which OFBiz seems to have been quite a sucess at in terms of actual installations, is an ecommerce store backed by limited stock management.

A manual which had a first section dealing with the above issues, a second section dealing with setting up an ecommerce store, and a third section dealing with tech issues (basic setup, how to make a screen, and entity, a service, use the webtools etc), would be very handy.  My firm at least would buy a copy!!

As for who produces the manuals, I believe that the "centralized, benevolent dictator" approach works better here than a free-for-all Wiki.  I reckon the best way to produce a core manual would be via some kind of commercialized approach - the Pragmatic Programmers  managed to cover their costs and a wee bit more this way.  Spring also has excellent documentation and books available.

From the posts I have seen on this list, there are several core committers who have the knowledge and explanatory ability to produce a decent book, with the support of a technical writer.  What these people don't have is "quality time" to sit down and write the fecker!  And they never will unless you attach an income stream to it.

cameron

----- Original Message ----
From: Jacopo Cappellato <[hidden email]>
To: [hidden email]
Sent: Thursday, 28 December, 2006 11:09:27 AM
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz manuals]

David E Jones wrote:

>
> I guess it depends on what the goal of doing a release is. In my mind
> the goal should be to create (over time...) a stable set of artifacts
> that people can build and deploy on if they choose not to go with the
> latest/greatest.
>
> What you're describing is interesting, but how is that any different
> than just using the latest from SVN with a little timing based on
> knowing what is going on added in, and keeping a list somewhere of all
> non-backwards compatible changes and their revision numbers?
>

Yes, you have described pretty well what I'm suggesting; I'd only add to
these that we should also create the upgrade services (and/or upgrade
instructions) every time we commit a non-backwards compatible change in
svn. As you said, this is not so different from what we are (implicitly)
suggesting to do right now (as a best practice to stay up-to-date with
the trunk) but I think that it would be nice if the community will
officially support it for a few reasons:

1) it's often difficult for users to pick a 'stable' svn snapshot
2) it's often difficult for users to keep track of important changes
between their revision and the trunk
3) since it is not so different from what we are suggesting right now,
it will not add a huge cost maintaining these extra processes/releases

> On that last bit, whatever we do with the releases having an official
> wiki page with all non-backward-compatible changes listed on it with the
> revision number for each would be a good thing to do...
>

+1

> But, back to the main point: what is the goal of a release in your mind
> (and in the mind of anyone else reading in too)?
>

I'd like to get the opinions from others too.
Personally I think that releases (or release instructions/plans) should
at least help users to keep their system/data in sync with the main
trunk, minimizing the upgrade costs and simplifying the users' decisions
(i.e. "should I upgrade now?").
Of course it would also be great to have a real 'stable' releases (with
patches for them etc...) as you are suggesting (and I really think we
could implement the two approaches simultaneously since what I've
proposed could be the basis of a real release management) but I'm not
sure the community will really maintain them...

Jacopo

> -David
>





Send instant messages to your online friends http://uk.messenger.yahoo.com

[David E Jones-2]

Cameron,

This is a good message in general, though I'd like to clarify a few  
objectives we have already discussed related to this:

1. the first branch is coming up soon, mainly because we wanted to  
time it soon after the incubator graduation which has just recently  
happened

2. we do not plan to EVER freeze new development in the trunk;  
instead for "stable" releases we'll create a branch and probably a  
release from it _immediately_ in order to get a community boot-
strapped around it, and then hopefully after a few months of back-
patching bug fixes and fixing bugs unique to the branch it will be  
nice and stable and ready for anyone to real lean on in production  
(barring errors introduced in customization and configuration of  
course... ;) )

3. not only the data model and services should be considered in the  
backwards compatibility maintenance; people can (and should) create  
derivatives of artifacts up and down the layers of the architecture,  
even form and screen definitions and such... Of course, I don't think  
we'll ever "guarantee" backward compatibility, we instead plan to  
"manage" backward compatibility the best we can and try to help  
people with custom stuff depending on code in OFBiz to not get hit to  
hard when inevitably change (if anyone wants some that doesn't ever  
change, they should take a release branch and NEVER update, or  
something along those lines, or hire an omniscient being that will  
build something to handle everything they will need in the lifetime  
of their business)

-David



On Dec 29, 2006, at 2:41 AM, Cameron Smith wrote:

> My 2 metical after following all the other arguments....  I would  
> be happy to help with detailing and preparing the release  
> procedures and regression tests (see below).
>
> 1. Goal of a Release
> I agree with David that it should provide a stable set of  
> artifacts.  NOT just at the level of screens, but at the level of  
> services and entities because almost everyone who deploys OFBiz  
> customizes it in some way.  This is different from some end-user  
> apps which periodically do a complete rewrite of the internals but  
> keep the interface sufficiently recognizable so as not to alienate  
> the customer base (ex. MS Office, Tomcat 3 -> 4 -> 5).
>
> OFBiz has a great advantage here because all core funcionality  
> exposes an API which is basically the sum of the services and  
> Entities involved, plus a few other standard config structures  
> (ofbiz-component.xml and controller.xml). Therefore I believe we  
> should structure our compatibility objectives around services and  
> entities.  For instance, if we say that release B is "API backwards  
> compatible" with release A, that means extensions which depended on  
> services and/or entities from release A will still work with B.  
> Some of these services or entities may have added optional  
> parameters or new nullable columns, just as long as they keep  
> providing the old API.
>
> In contrast, if someone writes their extension to also depend on a  
> certain Util class or simple-method, the releases make no  
> compatibility guarantees here.
>
> For instance I am writing a module now, to do end-of-month VAT  
> reconciliation according to Mozambican regulations.  It uses  
> certain services in the accounting module as building blocks.  If a  
> future release removed or altered the API of those services, I  
> would be stuck.  If a future release added a few extra optional  
> parameters to those services, I would not be forced to alter anything.
>
> 2. Release versioning policy and testing
> Based on the above discussion and also the contributions made thus  
> far, I would suggest the following approach.
> a) We aim at ONE release per year, coming out every June or  
> thereabouts.   I think it is better to have ONE deliverable per  
> year and meet it than two or three which immediately slip.  The  
> Ubuntu project has a larger community, a rich private backer (Mark  
> Shuttleworth), started with a much more established set of release  
> tools and procedures (from Debian), and still slipped Dapper from  
> being 6.04 to 6.06.   Note that only 6.06 is LTS (long term  
> support), and 6.10 is not.
>
> b) The SysPro argument for continuous updates is interesting but  
> rings completely false with the target market I have in mind -  
> small bricks and mortar commercial enterprises.  From my experience  
> both in UK and MZ, these places know their businesses and once they  
> have got ERP support for their core processes, they prefer to get  
> on with business instead of constantly looking for new features.  
> They prefer to workaround minor feature incompatibilities than risk  
> disruption and instability.
>
> c) So an annual release in the middle of each year gives us this  
> rhythm:
>  *At the start of the year, start stabilizing any new or reworked  
> functionality.
>  *In May or thereabouts, core commiters insitutue a freeze on big  
> changes and only let in bugfixes
>  *In June, make the new branch, test it and commit fixes to the  
> branch.
>  *End of June, version the branch and announce it as a release.
>  *At this point, commiters let big changes back into the trunk
>  *In parallel, the release maintainers do bugfixes ONLY on the  
> release and merge them back into trunk wherever it makes sense.
>  *By December, anyone who takes the latest version of the release,  
> should be guaranteed that it is pretty stable.  If they want any  
> features they go for the SVN trunk.
>
> d) Using the definitions here: http://apr.apache.org/versioning.html
>  *A release from year N should be minor version compatible with the  
> release from year N-1
>  *Once the release from year N is out, it should only suffer patch  
> versions
>
> e) Testing.   David makes a good point about the vastness of OFBiz  
> and the difficulty of guaranteeing that a certain version is  
> stable.  I believe that in the long term, the only solution is to  
> build up a suite of regression tests.  Its a lot of work but it is  
> definitely worth it, for the security it gives you when refactoring.
>
> I believe we need to build up two layers of tests:
>  *Integration tests: black-box tests which test the APIs of all the  
> services and entities.  I am already using the OFBiz TestContainer  
> framework for this.  I suggested some tweaks to it a few months  
> back but didn't get any feedback at that time.
>  *Web Tests: white box tests which exercise/simulate a browser and  
> test core use cases (e.g. create invoice, receive order, etc,  
> etc).  I am already using Watir for this but there are other  
> frameworks.  I would be happy to write up a little tutorial for how  
> to do this on the OFBiz wiki.
>
> 3. SVN policy
> I believe we SHOULD use branching, because it allows for a stable  
> release in that it receives bugfixes ONLY, which can be backported  
> to the trunk if necessary.  So basically at any one time, the  
> community is supporting 3 streams: the trunk + last release branch  
> + upcoming release branch.
>
> 4. Modules
> I agree with David that we should NOT try to separate modules.  At  
> most releasing framework and applications as two separate chunks,  
> as David suggests, but I think even that is a secondary priority to  
> having stable supported releases.   There are several reasons for  
> this....
>  a) For Commercial ERPs, the "modules" are largely a way of  
> justifying a larger bill to the client.  The boundaries between  
> modules are often gerrymandered so that when you buy modules A and  
> B, you have to buy C as well just because it has one little  
> function that a "normal person" would say logically should be part  
> of C.
>  b) OFBiz modules are largely structures to facilitate team  
> development.  They are not fully independent - there is a lot of  
> interdependence at the entity and service level - and this is  
> natural given that the whole point is an Integrated system.  
> Businesses are borne integrated and often departmentalize as a side-
> effect of growth.  Later on they spend huge efforts trying to  
> reintegrate once more.
>  c) I don't believe the community is big enough to support the  
> additional effort of unpicking, specifying and maintain "clean  
> interfaces" and data-flow consistency between all the modules.  I  
> believe that effort would be better spend stabilizing the APIs at  
> service and entity level as discussed above.
>  d) David is right about the Linux packaging systems.  Whether RPM  
> or DEB, they have a laudable ideal but in practice can make a  
> nominally simple job inordinately complex.   So people have to  
> write (very) clever helper tools on top of them (ex Synaptic on top  
> of apt on top of dpkg on top of deb!!)
>
> 5. Documentation
> I agree with Torsten that we need to lower the cost of entry to  
> OFBiz, but I also agree that we need to ask "lower the cost of  
> entry to what?".
>
> In fact, contrary to what Jacopo suggests, I believe that there IS  
> a set of core functions which I believe there is a huge target  
> market for in much of the world, among people who could never  
> afford SAP.  These functions are fairly consistent - and they don't  
> need to come with "bells on".  And I would imagine its not a  
> coincidence that OpenTAPS has chosen several of them as the focus  
> for its Financials module.
>
> Basic Accounting (Journal Entry with separate Posting, Balance  
> Sheet, Trial Balance, Data export to Excel)
> Client Account management (invoices, statements by age, payments,  
> basic customer details)
> Supplier management (basic supplier details, invoices, statements  
> by age, payments)
>
> A secondary set of priorities would be:
> Integration between Client/Supplier managament and accounting
> Payroll management
> Stocks mgt (warehouse, orders in and out)
> VAT or equivalent
>
> An alternative core set, which OFBiz seems to have been quite a  
> sucess at in terms of actual installations, is an ecommerce store  
> backed by limited stock management.
>
> A manual which had a first section dealing with the above issues, a  
> second section dealing with setting up an ecommerce store, and a  
> third section dealing with tech issues (basic setup, how to make a  
> screen, and entity, a service, use the webtools etc), would be very  
> handy.  My firm at least would buy a copy!!
>
> As for who produces the manuals, I believe that the "centralized,  
> benevolent dictator" approach works better here than a free-for-all  
> Wiki.  I reckon the best way to produce a core manual would be via  
> some kind of commercialized approach - the Pragmatic Programmers  
> managed to cover their costs and a wee bit more this way.  Spring  
> also has excellent documentation and books available.
>
> From the posts I have seen on this list, there are several core  
> committers who have the knowledge and explanatory ability to  
> produce a decent book, with the support of a technical writer.  
> What these people don't have is "quality time" to sit down and  
> write the fecker!  And they never will unless you attach an income  
> stream to it.
>
> cameron
>
> ----- Original Message ----
> From: Jacopo Cappellato <[hidden email]>
> To: [hidden email]
> Sent: Thursday, 28 December, 2006 11:09:27 AM
> Subject: Re: Community supported releases WAS [Re: Properly edited  
> OFBiz manuals]
>
> David E Jones wrote:
>>
>> I guess it depends on what the goal of doing a release is. In my mind
>> the goal should be to create (over time...) a stable set of artifacts
>> that people can build and deploy on if they choose not to go with the
>> latest/greatest.
>>
>> What you're describing is interesting, but how is that any different
>> than just using the latest from SVN with a little timing based on
>> knowing what is going on added in, and keeping a list somewhere of  
>> all
>> non-backwards compatible changes and their revision numbers?
>>
>
> Yes, you have described pretty well what I'm suggesting; I'd only  
> add to
> these that we should also create the upgrade services (and/or upgrade
> instructions) every time we commit a non-backwards compatible  
> change in
> svn. As you said, this is not so different from what we are  
> (implicitly)
> suggesting to do right now (as a best practice to stay up-to-date with
> the trunk) but I think that it would be nice if the community will
> officially support it for a few reasons:
>
> 1) it's often difficult for users to pick a 'stable' svn snapshot
> 2) it's often difficult for users to keep track of important changes
> between their revision and the trunk
> 3) since it is not so different from what we are suggesting right now,
> it will not add a huge cost maintaining these extra processes/releases
>
>> On that last bit, whatever we do with the releases having an official
>> wiki page with all non-backward-compatible changes listed on it  
>> with the
>> revision number for each would be a good thing to do...
>>
>
> +1
>
>> But, back to the main point: what is the goal of a release in your  
>> mind
>> (and in the mind of anyone else reading in too)?
>>
>
> I'd like to get the opinions from others too.
> Personally I think that releases (or release instructions/plans)  
> should
> at least help users to keep their system/data in sync with the main
> trunk, minimizing the upgrade costs and simplifying the users'  
> decisions
> (i.e. "should I upgrade now?").
> Of course it would also be great to have a real 'stable' releases  
> (with
> patches for them etc...) as you are suggesting (and I really think we
> could implement the two approaches simultaneously since what I've
> proposed could be the basis of a real release management) but I'm not
> sure the community will really maintain them...
>
> Jacopo
>
>> -David
>>
>
>
>
>
>
> Send instant messages to your online friends http://
> uk.messenger.yahoo.com

[Andrew Ballantine]

Hi,

Continual update is fine as long as the update process is:
a) Automatic ( like MS Windows updates)
b) Controllable ( Administrator decides when to implement)
c) Reversable (when the update causes a problem)

In order to do that you need a very strict testing program of all updates,
which I do not believe your community, though enthusiastic, can manage.

You will also come to a point where you want to implement something that
breaks previous compatibility and the only way to do that is to have a new
version. In the history of computing all projects reach a point where new
stuff cannot be implemented under the old rules/methods of the project and a
new version is created which has little compatibility with the last version.
There are various reasons for this, but I won't go into them here for the
sake of brevity.

My own personal experience of downloading from the latest SVN of ofbiz is of
failure to build. Maybe I have been unlucky, but I would prefer there to be
a current release that has all major bugs resolved as a working whole.
Revisions to the major release should be made available as updates to the
current stable release, but also added to a newer revised release that will
become the next stable release.

The updates could also be graded so that administrators of production
systems could gain confidence as to whether the update is safe to install.
Any update must be reversible in order to quickly undo an update which gave
unpredicted results.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Walter Vaughan [mailto:[hidden email]]
Sent: 29 December 2006 01:54
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
manuals]


[..snip..]

Golly, what a can of worms is open here. Actually what drew me to ofBiz was
the
amount of updates to the system.

The last commercial ERP solution we considered was SYSPRO. The folks at
Syspro
PRIDE themselves on weekly ports to their software. I have/had an .iso of a
marketing DVD they have with almost two hours of non-stop preaching how ERP
systems must and should be updated on a continuous basis, and that point
release
updates are evil. (e.g. 5.0 -> 6.0 on done every 18 months)

I was sold. Couldn't justify the seat costs for the number I needed, but I
was
sold on the concept. During our courting period I also got a weekly email
that
was similar to what Si Chen does with his blog listing the dozen or so
improvements to the system in the past week, and this in an ERP system with
15,000 current installs.

As a end user, what I am looking for is non-failure. Thus far I have more
than
enough trust in the core developers to always do the right thing.

--
Walter





--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************

[Jacopo Cappellato]

Andrew,

Andrew Ballantine wrote:
> ...
> My own personal experience of downloading from the latest SVN of ofbiz is of
> failure to build. Maybe I have been unlucky, but I would prefer there to be
> a current release that has all major bugs resolved as a working whole.


You have been really unlucky... I update the system mostly every day and
very few times I failed to build the system.

Jacopo

[Andrew Ballantine]

I second all of that and would like to add a request that each new release
provides an automated installation procedure on MS Windows and one flavour
of Linux, say Ubuntu 6.06.

Kind regards,

Andrew Ballantine

-----Original Message-----
From: Cameron Smith [mailto:[hidden email]]
Sent: 29 December 2006 09:42
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
manuals]


My 2 metical after following all the other arguments....  I would be happy
to help with detailing and preparing the release procedures and regression
tests (see below).

1. Goal of a Release
I agree with David that it should provide a stable set of artifacts.  NOT
just at the level of screens, but at the level of services and entities
because almost everyone who deploys OFBiz customizes it in some way.  This
is different from some end-user apps which periodically do a complete
rewrite of the internals but keep the interface sufficiently recognizable so
as not to alienate the customer base (ex. MS Office, Tomcat 3 -> 4 -> 5).

OFBiz has a great advantage here because all core funcionality exposes an
API which is basically the sum of the services and Entities involved, plus a
few other standard config structures (ofbiz-component.xml and
controller.xml). Therefore I believe we should structure our compatibility
objectives around services and entities.  For instance, if we say that
release B is "API backwards compatible" with release A, that means
extensions which depended on services and/or entities from release A will
still work with B.  Some of these services or entities may have added
optional parameters or new nullable columns, just as long as they keep
providing the old API.

In contrast, if someone writes their extension to also depend on a certain
Util class or simple-method, the releases make no compatibility guarantees
here.

For instance I am writing a module now, to do end-of-month VAT
reconciliation according to Mozambican regulations.  It uses certain
services in the accounting module as building blocks.  If a future release
removed or altered the API of those services, I would be stuck.  If a future
release added a few extra optional parameters to those services, I would not
be forced to alter anything.

2. Release versioning policy and testing
Based on the above discussion and also the contributions made thus far, I
would suggest the following approach.
a) We aim at ONE release per year, coming out every June or thereabouts.   I
think it is better to have ONE deliverable per year and meet it than two or
three which immediately slip.  The Ubuntu project has a larger community, a
rich private backer (Mark Shuttleworth), started with a much more
established set of release tools and procedures (from Debian), and still
slipped Dapper from being 6.04 to 6.06.   Note that only 6.06 is LTS (long
term support), and 6.10 is not.

b) The SysPro argument for continuous updates is interesting but rings
completely false with the target market I have in mind - small bricks and
mortar commercial enterprises.  From my experience both in UK and MZ, these
places know their businesses and once they have got ERP support for their
core processes, they prefer to get on with business instead of constantly
looking for new features.  They prefer to workaround minor feature
incompatibilities than risk disruption and instability.

c) So an annual release in the middle of each year gives us this rhythm:
 *At the start of the year, start stabilizing any new or reworked
functionality.
 *In May or thereabouts, core commiters insitutue a freeze on big changes
and only let in bugfixes
 *In June, make the new branch, test it and commit fixes to the branch.
 *End of June, version the branch and announce it as a release.
 *At this point, commiters let big changes back into the trunk
 *In parallel, the release maintainers do bugfixes ONLY on the release and
merge them back into trunk wherever it makes sense.
 *By December, anyone who takes the latest version of the release, should be
guaranteed that it is pretty stable.  If they want any features they go for
the SVN trunk.

d) Using the definitions here: http://apr.apache.org/versioning.html
 *A release from year N should be minor version compatible with the release
from year N-1
 *Once the release from year N is out, it should only suffer patch versions

e) Testing.   David makes a good point about the vastness of OFBiz and the
difficulty of guaranteeing that a certain version is stable.  I believe that
in the long term, the only solution is to build up a suite of regression
tests.  Its a lot of work but it is definitely worth it, for the security it
gives you when refactoring.

I believe we need to build up two layers of tests:
 *Integration tests: black-box tests which test the APIs of all the services
and entities.  I am already using the OFBiz TestContainer framework for
this.  I suggested some tweaks to it a few months back but didn't get any
feedback at that time.
 *Web Tests: white box tests which exercise/simulate a browser and test core
use cases (e.g. create invoice, receive order, etc, etc).  I am already
using Watir for this but there are other frameworks.  I would be happy to
write up a little tutorial for how to do this on the OFBiz wiki.

3. SVN policy
I believe we SHOULD use branching, because it allows for a stable release in
that it receives bugfixes ONLY, which can be backported to the trunk if
necessary.  So basically at any one time, the community is supporting 3
streams: the trunk + last release branch + upcoming release branch.

4. Modules
I agree with David that we should NOT try to separate modules.  At most
releasing framework and applications as two separate chunks, as David
suggests, but I think even that is a secondary priority to having stable
supported releases.   There are several reasons for this....
 a) For Commercial ERPs, the "modules" are largely a way of justifying a
larger bill to the client.  The boundaries between modules are often
gerrymandered so that when you buy modules A and B, you have to buy C as
well just because it has one little function that a "normal person" would
say logically should be part of C.
 b) OFBiz modules are largely structures to facilitate team development.
They are not fully independent - there is a lot of interdependence at the
entity and service level - and this is natural given that the whole point is
an Integrated system.  Businesses are borne integrated and often
departmentalize as a side-effect of growth.  Later on they spend huge
efforts trying to reintegrate once more.
 c) I don't believe the community is big enough to support the additional
effort of unpicking, specifying and maintain "clean interfaces" and
data-flow consistency between all the modules.  I believe that effort would
be better spend stabilizing the APIs at service and entity level as
discussed above.
 d) David is right about the Linux packaging systems.  Whether RPM or DEB,
they have a laudable ideal but in practice can make a nominally simple job
inordinately complex.   So people have to write (very) clever helper tools
on top of them (ex Synaptic on top of apt on top of dpkg on top of deb!!)

5. Documentation
I agree with Torsten that we need to lower the cost of entry to OFBiz, but I
also agree that we need to ask "lower the cost of entry to what?".

In fact, contrary to what Jacopo suggests, I believe that there IS a set of
core functions which I believe there is a huge target market for in much of
the world, among people who could never afford SAP.  These functions are
fairly consistent - and they don't need to come with "bells on".  And I
would imagine its not a coincidence that OpenTAPS has chosen several of them
as the focus for its Financials module.

Basic Accounting (Journal Entry with separate Posting, Balance Sheet, Trial
Balance, Data export to Excel)
Client Account management (invoices, statements by age, payments, basic
customer details)
Supplier management (basic supplier details, invoices, statements by age,
payments)

A secondary set of priorities would be:
Integration between Client/Supplier managament and accounting
Payroll management
Stocks mgt (warehouse, orders in and out)
VAT or equivalent

An alternative core set, which OFBiz seems to have been quite a sucess at in
terms of actual installations, is an ecommerce store backed by limited stock
management.

A manual which had a first section dealing with the above issues, a second
section dealing with setting up an ecommerce store, and a third section
dealing with tech issues (basic setup, how to make a screen, and entity, a
service, use the webtools etc), would be very handy.  My firm at least would
buy a copy!!

As for who produces the manuals, I believe that the "centralized, benevolent
dictator" approach works better here than a free-for-all Wiki.  I reckon the
best way to produce a core manual would be via some kind of commercialized
approach - the Pragmatic Programmers  managed to cover their costs and a wee
bit more this way.  Spring also has excellent documentation and books
available.

From the posts I have seen on this list, there are several core committers
who have the knowledge and explanatory ability to produce a decent book,
with the support of a technical writer.  What these people don't have is
"quality time" to sit down and write the fecker!  And they never will unless
you attach an income stream to it.

cameron

----- Original Message ----
From: Jacopo Cappellato <[hidden email]>
To: [hidden email]
Sent: Thursday, 28 December, 2006 11:09:27 AM
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
manuals]

David E Jones wrote:

>
> I guess it depends on what the goal of doing a release is. In my mind
> the goal should be to create (over time...) a stable set of artifacts
> that people can build and deploy on if they choose not to go with the
> latest/greatest.
>
> What you're describing is interesting, but how is that any different
> than just using the latest from SVN with a little timing based on
> knowing what is going on added in, and keeping a list somewhere of all
> non-backwards compatible changes and their revision numbers?
>

Yes, you have described pretty well what I'm suggesting; I'd only add to
these that we should also create the upgrade services (and/or upgrade
instructions) every time we commit a non-backwards compatible change in
svn. As you said, this is not so different from what we are (implicitly)
suggesting to do right now (as a best practice to stay up-to-date with
the trunk) but I think that it would be nice if the community will
officially support it for a few reasons:

1) it's often difficult for users to pick a 'stable' svn snapshot
2) it's often difficult for users to keep track of important changes
between their revision and the trunk
3) since it is not so different from what we are suggesting right now,
it will not add a huge cost maintaining these extra processes/releases

> On that last bit, whatever we do with the releases having an official
> wiki page with all non-backward-compatible changes listed on it with the
> revision number for each would be a good thing to do...
>

+1

> But, back to the main point: what is the goal of a release in your mind
> (and in the mind of anyone else reading in too)?
>

I'd like to get the opinions from others too.
Personally I think that releases (or release instructions/plans) should
at least help users to keep their system/data in sync with the main
trunk, minimizing the upgrade costs and simplifying the users' decisions
(i.e. "should I upgrade now?").
Of course it would also be great to have a real 'stable' releases (with
patches for them etc...) as you are suggesting (and I really think we
could implement the two approaches simultaneously since what I've
proposed could be the basis of a real release management) but I'm not
sure the community will really maintain them...

Jacopo

> -David
>





Send instant messages to your online friends http://uk.messenger.yahoo.com


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************

[Jacques Le Roux]

I agree with Jacopo,

I have put in place a task that update OFBiz automatically. Actually I have 3 versions of OFBiz :
  std trunk
  for POS - I do most of my modifications there
  with Opentaps modules

I run by hand ant or ant run-install for each of them suiving if they are new data or not. It takes me less than 10' per day (and
during this elapse most of this time I do other tasks)

If someone is interested here is the batch I use on XP for that

__________________________________________________________________________________________________
@Echo off
d:
cd \WorkspaceNew\ofbiz
ECHO ofbiz======================================================================
call svn up
ECHO ofbiz======================================================================
ECHO                                                                           *
ECHO                                                                           *
cd \WorkspaceNew\ofbiz.pos
ECHO ofbiz.pos==================================================================
call svn up
ECHO ofbiz.pos==================================================================
ECHO                                                                           *
ECHO                                                                           *
cd \WorkspaceNew\opentaps
ECHO opentaps===================================================================
call svn up
cd \WorkspaceNew\opentaps\hot-deploy\crmsfa
call svn up
cd \WorkspaceNew\opentaps\hot-deploy\financials
call svn up
ECHO opentaps===================================================================
ECHO                                                                           *
ECHO                                                                           *

:menu
echo a) ant
echo b) install
echo q) quitter
choice /c:abq Quelle option ?
if errorlevel = 3 goto fin
if errorlevel = 2 goto install
if errorlevel = 1 goto ant

:ant
cd \WorkspaceNew\ofbiz
call ant
pause ofbiz ok ?
cd \WorkspaceNew\ofbiz.pos
call ant
pause ofbiz.pos ok ?
cd \WorkspaceNew\opentaps
call ant
pause opentaps ok ?
goto fin

:install
cd \WorkspaceNew\ofbiz
call ant run-install
pause ofbiz ok ?
cd \WorkspaceNew\ofbiz.pos
call ant run-install
pause ofbiz.pos ok ?
cd \WorkspaceNew\opentaps
call ant run-install
pause opentaps ok ?

:fin
__________________________________________________________________________________________________

Before the choise I have only to search for the token "data" and that's it.
This may be adapted easily even in a .sh I guess.

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> Andrew,
>
> Andrew Ballantine wrote:
> > ...
> > My own personal experience of downloading from the latest SVN of ofbiz is of
> > failure to build. Maybe I have been unlucky, but I would prefer there to be
> > a current release that has all major bugs resolved as a working whole.
>
>
> You have been really unlucky... I update the system mostly every day and
> very few times I failed to build the system.
>
> Jacopo

[Walter Vaughan]

Andrew Ballantine wrote:

> I second all of that and would like to add a request that each new release
> provides an automated installation procedure on MS Windows and one flavour
> of Linux, say Ubuntu 6.06.

As a strategy, that's an excellent idea. Curing world hunger is another, but
executing is another thing.

Where we have a failure as a community right now it the document we have at
http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
which probably is an old version, with incorrect links
(it points to http://svn.ofbiz.org/ which tosses a 403 error page),
(it points to
http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical+Production+Setup+Guide 
which needs a little more hand holding, and as well points to
http://svn.ofbiz.org/ which tosses a 403 error page),
(it points to http://www.sequoiaerp.org/ which hasn't been around in 10 months).

This page is slightly better http://incubator.apache.org/ofbiz/docs/setup.html
but it sill suffers from non-linear thought process

As soon as the dust settles on getting us out of the "incubator" I am completely
confident we'll have bulletproof installation, startup, and next step guides in
place.

--
Walter

[Andrew Ballantine]

Walter Vaughan wrote:
"As a strategy, that's an excellent idea. Curing world hunger is another,
but
executing is another thing."

Well, you can choose to make facetious remarks if you must, but I consider
this very important.

If you look back over the user mailing list you will find it littered with
requests for help just getting ofbiz up and running. I would bet that a lot
of them loose interest fairly quickly and we loose a potential
user/contributor. Since no one can evaluate the framework without getting it
working, that makes it very important that new users get a really painless
and easy automated installation process.

About 2 years ago I was evaluating ofbiz and used the Windows install that
was available then. It wasn't completely automated or that easy, but I got
through it. I tried the same thing in Linux, because the final production
system must run on Linux, and got totally bogged down.

I know that the history of Open Source has tended not to provide easy
installation procedures or documentation, but the trend is changing. You
will find that many of the projects that support multiple operating systems
have excellent automated installation procedures. OK it needs a bit of
effort to set up, but once done it should be easy to maintain and keep
working.

I deliberately specified ONLY one Linux distribution, Ubuntu 6.06 LTS, to
simplify the job and chose a distribution with a 5 year support plan.

I have to confess that I have looked at other ERP Open Source projects to
see if I could find one that was easier to use than ofbiz. I am sorry if
this hurts, but it is true. However I keep coming back to ofbiz because of
its excellent architecture and true open source community.

I think it essential that the new user be at least accorded a decent
automated install process to avoid loosing them at the first hurdle. I
primarily want to USE the framework to drive my client's business processes
and then contribute any patches that I feel are needed to improve the
framework. I do not want to spend hours or days fiddling about with all
sorts of things just to get the thing working without producing error
messages all over the place.

We also should remember that newcomers to Open Source are also new to Linux
which only adds to the learning curve. Faced with a huge learning curve
there is a strong tendency to give up and stick with the trash we have grown
to hate e.g. Microsoft.

Is it really so difficult to create two automated install procedure? I would
like to see a single executable download file which will then do everything
that is needed to install a running ofbiz framework. That includes
installing the correct versions of any products needed to support the
installation e.g. Java Ant Postgres etc

I am interested in helping put together such procedures given some help from
your good selves.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Walter Vaughan [mailto:[hidden email]]
Sent: 02 January 2007 13:30
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
manuals]


Andrew Ballantine wrote:

> I second all of that and would like to add a request that each new release
> provides an automated installation procedure on MS Windows and one flavour
> of Linux, say Ubuntu 6.06.

As a strategy, that's an excellent idea. Curing world hunger is another, but
executing is another thing.

Where we have a failure as a community right now it the document we have at
http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
which probably is an old version, with incorrect links
(it points to http://svn.ofbiz.org/ which tosses a 403 error page),
(it points to
http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical+Production+Setup+Guide
which needs a little more hand holding, and as well points to
http://svn.ofbiz.org/ which tosses a 403 error page),
(it points to http://www.sequoiaerp.org/ which hasn't been around in 10
months).

This page is slightly better
http://incubator.apache.org/ofbiz/docs/setup.html
but it sill suffers from non-linear thought process

As soon as the dust settles on getting us out of the "incubator" I am
completely
confident we'll have bulletproof installation, startup, and next step guides
in
place.

--
Walter


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50



*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************

[cjhowe]

Perhaps my mind is a bit faded as it's been a long
while since I've done a new installation on a
completely clean box.  Isn't this the install
procedure:

1) Install Java JDK 1.4.2 or 1.5
2) Install Apache Ant
3) Set environment variables for Java and Ant
4) run: ant run-install
5) run: startofbiz.bat or startofbiz.sh for linux

Personally, I would be upset if a piece of software
tried to install a different project (1 or 2) on its
own.  (I'm not even sure if Sun's Java license would
allow such a script) So, on the assumption that
auto-installation of 1 or 2 shouldn't be done by an
Apache Ofbiz installer, the best that an installation
script can do is auto-discover Java JDK and Apache Ant
locations and set the environment variables
(temporarily?) and then go into the ant run-install
procedure?  

Additionally, seeing that OOTB Apache OFBiz is setup
with Derby Database, I don't think any
auto-installation would cover installation with
Postgresql.  I also don't think your DBA would like a
software program installing databases on its own and
creating users with permissions (user:ofbiz).  So,
aside from the 5 steps listed above (which by memory
is in an installation document - most likely the one
docs.ofbiz.org) what would you like to see from an
auto-installer? Perhaps a splash screen to hide the
console spit-out?

[David E Jones-2]

First a couple of general thoughts on this:

1. we are still working through the process of establishing policies  
and procedures for community supported binary releases, and we  
haven't done a binary release in years (but will hopefully get a  
branch going soon, and a stable version of that branch in a couple of  
months)

2. my guess as to why this doesn't exist already is that Apache OFBiz  
is server-side software and such installers are not as common for  
this sort of thing (yes, they do of course exist); there are SO SO SO  
many configuration options that an automated install would have to be  
a huge piece of software, or address a simple case, like a demo/test  
install

That said, and to follow up on Chris's reply to this with the install  
steps, the installation of OFBiz is super-easy OOTB, especially for a  
binary build which would look like this:

1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE) installed
2. download OFBiz binary build, and unzip to a directory
3. go into that directory and run the executable jar file  
(ofbiz.jar), or one of the startup scripts

And that's IT, PERIOD. Installing Ant is not necessary because OFBiz  
includes the libraries and a script for that. A build from SVN  
procedure is almost as easy:

1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE) installed
2. make sure you have an SVN client installed
3. with the SVN client, checkout http://svn.apache.org/repos/asf/ 
ofbiz/trunk in a new directory
4. go into that directory run "ant run-install", or in Linux/Unix "./
ant run-install"
5. still in that directory run the executable jar file (ofbiz.jar),  
or one of the startup scripts

If that's too complex for a server side application demo/test  
install, I don't know what to say... or how much more we can really  
do about it. What else would an automated install do? I guess it  
could check the one and only dependency there is: the JDK  
installation. That is where most people run into problems. The best  
way to avoid that: use a Mac. ;)

Seriously though, this world is quite #$%^ed up and there are so many  
different variations in operating systems, versions of Java (OFBiz  
does NOT work with gcj and other such things), and so on that I don't  
know that we can do a lot in this area. Say we chose a version of  
Linux to support: now people have to install THAT version of Linux in  
order to easily use OFBiz... hmmm...

Still, if someone wanted to work on this, I certainly wouldn't  
complain... ;)

-David


On Jan 2, 2007, at 9:04 AM, Andrew Ballantine wrote:

> Walter Vaughan wrote:
> "As a strategy, that's an excellent idea. Curing world hunger is  
> another,
> but
> executing is another thing."
>
> Well, you can choose to make facetious remarks if you must, but I  
> consider
> this very important.
>
> If you look back over the user mailing list you will find it  
> littered with
> requests for help just getting ofbiz up and running. I would bet  
> that a lot
> of them loose interest fairly quickly and we loose a potential
> user/contributor. Since no one can evaluate the framework without  
> getting it
> working, that makes it very important that new users get a really  
> painless
> and easy automated installation process.
>
> About 2 years ago I was evaluating ofbiz and used the Windows  
> install that
> was available then. It wasn't completely automated or that easy,  
> but I got
> through it. I tried the same thing in Linux, because the final  
> production
> system must run on Linux, and got totally bogged down.
>
> I know that the history of Open Source has tended not to provide easy
> installation procedures or documentation, but the trend is  
> changing. You
> will find that many of the projects that support multiple operating  
> systems
> have excellent automated installation procedures. OK it needs a bit of
> effort to set up, but once done it should be easy to maintain and keep
> working.
>
> I deliberately specified ONLY one Linux distribution, Ubuntu 6.06  
> LTS, to
> simplify the job and chose a distribution with a 5 year support plan.
>
> I have to confess that I have looked at other ERP Open Source  
> projects to
> see if I could find one that was easier to use than ofbiz. I am  
> sorry if
> this hurts, but it is true. However I keep coming back to ofbiz  
> because of
> its excellent architecture and true open source community.
>
> I think it essential that the new user be at least accorded a decent
> automated install process to avoid loosing them at the first hurdle. I
> primarily want to USE the framework to drive my client's business  
> processes
> and then contribute any patches that I feel are needed to improve the
> framework. I do not want to spend hours or days fiddling about with  
> all
> sorts of things just to get the thing working without producing error
> messages all over the place.
>
> We also should remember that newcomers to Open Source are also new  
> to Linux
> which only adds to the learning curve. Faced with a huge learning  
> curve
> there is a strong tendency to give up and stick with the trash we  
> have grown
> to hate e.g. Microsoft.
>
> Is it really so difficult to create two automated install  
> procedure? I would
> like to see a single executable download file which will then do  
> everything
> that is needed to install a running ofbiz framework. That includes
> installing the correct versions of any products needed to support the
> installation e.g. Java Ant Postgres etc
>
> I am interested in helping put together such procedures given some  
> help from
> your good selves.
>
> Kind regards,
>
> Andrew Ballantine.
>
> -----Original Message-----
> From: Walter Vaughan [mailto:[hidden email]]
> Sent: 02 January 2007 13:30
> To: [hidden email]
> Subject: Re: Community supported releases WAS [Re: Properly edited  
> OFBiz
> manuals]
>
>
> Andrew Ballantine wrote:
>
>> I second all of that and would like to add a request that each new  
>> release
>> provides an automated installation procedure on MS Windows and one  
>> flavour
>> of Linux, say Ubuntu 6.06.
>
> As a strategy, that's an excellent idea. Curing world hunger is  
> another, but
> executing is another thing.
>
> Where we have a failure as a community right now it the document we  
> have at
> http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
> which probably is an old version, with incorrect links
> (it points to http://svn.ofbiz.org/ which tosses a 403 error page),
> (it points to
> http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical+Production 
> +Setup+Guide
> which needs a little more hand holding, and as well points to
> http://svn.ofbiz.org/ which tosses a 403 error page),
> (it points to http://www.sequoiaerp.org/ which hasn't been around  
> in 10
> months).
>
> This page is slightly better
> http://incubator.apache.org/ofbiz/docs/setup.html
> but it sill suffers from non-linear thought process
>
> As soon as the dust settles on getting us out of the "incubator" I am
> completely
> confident we'll have bulletproof installation, startup, and next  
> step guides
> in
> place.
>
> --
> Walter
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:  
> 01/01/2007
> 14:50
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:  
> 01/01/2007
> 14:50
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:  
> 01/01/2007
> 14:50
>
>
>
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************

[David E Jones-2]

I see a couple of possible solutions for this:

1. be patient and give us a break
2. get involved and help out

Right now we are in the process of a few major migrations, including  
(but not limited to):

1. total refactoring and reorganizing of documentation and moving  
from the old site html files to pages on the docs.ofbiz.org  
Confluence site

2. migrating from the ASF incubator resources to the ASF top level  
project resources

3. we recently moved the old OFBiz server to a new box at Contegix  
(this is my guess as to why svn.ofbiz.org no longer goes anywhere  
useful; that was a bad idea from the beginning and we will be  
changing links going forward instead of trying to keep that going)

-David


On Jan 2, 2007, at 6:30 AM, Walter Vaughan wrote:

> Andrew Ballantine wrote:
>
>> I second all of that and would like to add a request that each new  
>> release
>> provides an automated installation procedure on MS Windows and one  
>> flavour
>> of Linux, say Ubuntu 6.06.
>
> As a strategy, that's an excellent idea. Curing world hunger is  
> another, but executing is another thing.
>
> Where we have a failure as a community right now it the document we  
> have at
> http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
> which probably is an old version, with incorrect links
> (it points to http://svn.ofbiz.org/ which tosses a 403 error page),
> (it points to http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical 
> +Production+Setup+Guide which needs a little more hand holding, and  
> as well points to http://svn.ofbiz.org/ which tosses a 403 error  
> page),
> (it points to http://www.sequoiaerp.org/ which hasn't been around  
> in 10 months).
>
> This page is slightly better http://incubator.apache.org/ofbiz/docs/ 
> setup.html
> but it sill suffers from non-linear thought process
>
> As soon as the dust settles on getting us out of the "incubator" I  
> am completely confident we'll have bulletproof installation,  
> startup, and next step guides in place.
>
> --
> Walter

[Daniel Kunkel]

Hi

The steps for an OFBiz demo are pretty straight forward, and works
quite
well most of time.

The main stumbling block I ran into was setting up OFBiz for
production.
Granted, I did it before the Production Setup Guide existed, but it was
a truly onerous task with huge gotcha's since I was trying to run it on
a popular virtual private server, a mistake since it caused unique
challenging errors that no one had ever seen.

However, it seems that all that is in the past, and now we have a number
of great opportunties:

1.) What about creating a "Production Patch" with instructions.

People could just go through that with Search and Replace to customize
it for their needs, run it, and be off.

This system seems like it would be pretty easy to create and keep up to
date.
The one gotcha I've seen here is to make sure the user runs the patch
against a certain release to avoid conflicts during the patch.

2.) Would there be a need for a live CD? It could even be possible to
set
one up a complete running OFBiz system with a database, apache, etc.

3.) A VMware image.  VMware seems to be taking the server world by
storm,
and virtual OFBiz instance might be really popular.

Does this spark any other ideas?



On Tue, 2007-01-02 at 12:20 -0700, David E Jones wrote:

> First a couple of general thoughts on this:
>
> 1. we are still working through the process of establishing policies  
> and procedures for community supported binary releases, and we  
> haven't done a binary release in years (but will hopefully get a  
> branch going soon, and a stable version of that branch in a couple of  
> months)
>
> 2. my guess as to why this doesn't exist already is that Apache OFBiz  
> is server-side software and such installers are not as common for  
> this sort of thing (yes, they do of course exist); there are SO SO SO  
> many configuration options that an automated install would have to be  
> a huge piece of software, or address a simple case, like a demo/test  
> install
>
> That said, and to follow up on Chris's reply to this with the install  
> steps, the installation of OFBiz is super-easy OOTB, especially for a  
> binary build which would look like this:
>
> 1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE) installed
> 2. download OFBiz binary build, and unzip to a directory
> 3. go into that directory and run the executable jar file  
> (ofbiz.jar), or one of the startup scripts
>
> And that's IT, PERIOD. Installing Ant is not necessary because OFBiz  
> includes the libraries and a script for that. A build from SVN  
> procedure is almost as easy:
>
> 1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE) installed
> 2. make sure you have an SVN client installed
> 3. with the SVN client, checkout http://svn.apache.org/repos/asf/ 
> ofbiz/trunk in a new directory
> 4. go into that directory run "ant run-install", or in Linux/Unix "./
> ant run-install"
> 5. still in that directory run the executable jar file (ofbiz.jar),  
> or one of the startup scripts
>
> If that's too complex for a server side application demo/test  
> install, I don't know what to say... or how much more we can really  
> do about it. What else would an automated install do? I guess it  
> could check the one and only dependency there is: the JDK  
> installation. That is where most people run into problems. The best  
> way to avoid that: use a Mac. ;)
>
> Seriously though, this world is quite #$%^ed up and there are so many  
> different variations in operating systems, versions of Java (OFBiz  
> does NOT work with gcj and other such things), and so on that I don't  
> know that we can do a lot in this area. Say we chose a version of  
> Linux to support: now people have to install THAT version of Linux in  
> order to easily use OFBiz... hmmm...
>
> Still, if someone wanted to work on this, I certainly wouldn't  
> complain... ;)
>
> -David
>
>
> On Jan 2, 2007, at 9:04 AM, Andrew Ballantine wrote:
>
> > Walter Vaughan wrote:
> > "As a strategy, that's an excellent idea. Curing world hunger is  
> > another,
> > but
> > executing is another thing."
> >
> > Well, you can choose to make facetious remarks if you must, but I  
> > consider
> > this very important.
> >
> > If you look back over the user mailing list you will find it  
> > littered with
> > requests for help just getting ofbiz up and running. I would bet  
> > that a lot
> > of them loose interest fairly quickly and we loose a potential
> > user/contributor. Since no one can evaluate the framework without  
> > getting it
> > working, that makes it very important that new users get a really  
> > painless
> > and easy automated installation process.
> >
> > About 2 years ago I was evaluating ofbiz and used the Windows  
> > install that
> > was available then. It wasn't completely automated or that easy,  
> > but I got
> > through it. I tried the same thing in Linux, because the final  
> > production
> > system must run on Linux, and got totally bogged down.
> >
> > I know that the history of Open Source has tended not to provide easy
> > installation procedures or documentation, but the trend is  
> > changing. You
> > will find that many of the projects that support multiple operating  
> > systems
> > have excellent automated installation procedures. OK it needs a bit of
> > effort to set up, but once done it should be easy to maintain and keep
> > working.
> >
> > I deliberately specified ONLY one Linux distribution, Ubuntu 6.06  
> > LTS, to
> > simplify the job and chose a distribution with a 5 year support plan.
> >
> > I have to confess that I have looked at other ERP Open Source  
> > projects to
> > see if I could find one that was easier to use than ofbiz. I am  
> > sorry if
> > this hurts, but it is true. However I keep coming back to ofbiz  
> > because of
> > its excellent architecture and true open source community.
> >
> > I think it essential that the new user be at least accorded a decent
> > automated install process to avoid loosing them at the first hurdle. I
> > primarily want to USE the framework to drive my client's business  
> > processes
> > and then contribute any patches that I feel are needed to improve the
> > framework. I do not want to spend hours or days fiddling about with  
> > all
> > sorts of things just to get the thing working without producing error
> > messages all over the place.
> >
> > We also should remember that newcomers to Open Source are also new  
> > to Linux
> > which only adds to the learning curve. Faced with a huge learning  
> > curve
> > there is a strong tendency to give up and stick with the trash we  
> > have grown
> > to hate e.g. Microsoft.
> >
> > Is it really so difficult to create two automated install  
> > procedure? I would
> > like to see a single executable download file which will then do  
> > everything
> > that is needed to install a running ofbiz framework. That includes
> > installing the correct versions of any products needed to support the
> > installation e.g. Java Ant Postgres etc
> >
> > I am interested in helping put together such procedures given some  
> > help from
> > your good selves.
> >
> > Kind regards,
> >
> > Andrew Ballantine.
> >
> > -----Original Message-----
> > From: Walter Vaughan [mailto:[hidden email]]
> > Sent: 02 January 2007 13:30
> > To: [hidden email]
> > Subject: Re: Community supported releases WAS [Re: Properly edited  
> > OFBiz
> > manuals]
> >
> >
> > Andrew Ballantine wrote:
> >
> >> I second all of that and would like to add a request that each new  
> >> release
> >> provides an automated installation procedure on MS Windows and one  
> >> flavour
> >> of Linux, say Ubuntu 6.06.
> >
> > As a strategy, that's an excellent idea. Curing world hunger is  
> > another, but
> > executing is another thing.
> >
> > Where we have a failure as a community right now it the document we  
> > have at
> > http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
> > which probably is an old version, with incorrect links
> > (it points to http://svn.ofbiz.org/ which tosses a 403 error page),
> > (it points to
> > http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical+Production 
> > +Setup+Guide
> > which needs a little more hand holding, and as well points to
> > http://svn.ofbiz.org/ which tosses a 403 error page),
> > (it points to http://www.sequoiaerp.org/ which hasn't been around  
> > in 10
> > months).
> >
> > This page is slightly better
> > http://incubator.apache.org/ofbiz/docs/setup.html
> > but it sill suffers from non-linear thought process
> >
> > As soon as the dust settles on getting us out of the "incubator" I am
> > completely
> > confident we'll have bulletproof installation, startup, and next  
> > step guides
> > in
> > place.
> >
> > --
> > Walter
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:  
> > 01/01/2007
> > 14:50
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:  
> > 01/01/2007
> > 14:50
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:  
> > 01/01/2007
> > 14:50
> >
> >
> >
> > *****************************************************************
> > This email has been checked by the altohiway Mailcontroller Service
> > *****************************************************************
>

[David E Jones-2]

Daniel,

These are some good ideas. The live CD thing is actually being done,  
if I understand correctly, right now by Anil Patel and his group. It  
would be cool to get an image of that hosted somewhere, and would  
make sense especially once we have a release branch that is pretty  
stable and clean. The VMWare image would be cool too, again  
especially once we have a good binary from a stabilized release branch.

Getting things going in production is always tricky, no matter how  
you look at it. Unless you keep things super-simple it's going to be  
messy, and much of it has to do with stuff totally outside of OFBiz,  
and there are so many options for that stuff that I think the only  
thing that makes any sense is wiki pages where people describe their  
experiences with various infrastructure software.

A production patch might be interesting, but I'm worried about the  
redundancy and how well it would "naturally" be maintained... Right  
now the production setup guides go through where various things are  
located and what to change in each spot. This means looking at  
multiple files, but I kind of think that's better than only having to  
go to a single file because people will start to get an idea about  
how things are organized, and about where related options might be.

BTW: as part of the ongoing doc reorg effort I just moved the old  
Setup Guide to docs.ofbiz.org, renaming it the Demo and Test Setup  
Guide to clarify the intent. It is under a new page that I'm hoping  
will be the landing page for people to start at, and that is here:

http://docs.ofbiz.org/x/rwM

-David


On Jan 2, 2007, at 12:51 PM, Daniel Kunkel wrote:

> Hi
>
> The steps for an OFBiz demo are pretty straight forward, and works
> quite
> well most of time.
>
> The main stumbling block I ran into was setting up OFBiz for
> production.
> Granted, I did it before the Production Setup Guide existed, but it  
> was
> a truly onerous task with huge gotcha's since I was trying to run  
> it on
> a popular virtual private server, a mistake since it caused unique
> challenging errors that no one had ever seen.
>
> However, it seems that all that is in the past, and now we have a  
> number
> of great opportunties:
>
> 1.) What about creating a "Production Patch" with instructions.
>
> People could just go through that with Search and Replace to customize
> it for their needs, run it, and be off.
>
> This system seems like it would be pretty easy to create and keep  
> up to
> date.
> The one gotcha I've seen here is to make sure the user runs the patch
> against a certain release to avoid conflicts during the patch.
>
> 2.) Would there be a need for a live CD? It could even be possible to
> set
> one up a complete running OFBiz system with a database, apache, etc.
>
> 3.) A VMware image.  VMware seems to be taking the server world by
> storm,
> and virtual OFBiz instance might be really popular.
>
> Does this spark any other ideas?
>
>
>
> On Tue, 2007-01-02 at 12:20 -0700, David E Jones wrote:
>> First a couple of general thoughts on this:
>>
>> 1. we are still working through the process of establishing policies
>> and procedures for community supported binary releases, and we
>> haven't done a binary release in years (but will hopefully get a
>> branch going soon, and a stable version of that branch in a couple of
>> months)
>>
>> 2. my guess as to why this doesn't exist already is that Apache OFBiz
>> is server-side software and such installers are not as common for
>> this sort of thing (yes, they do of course exist); there are SO SO SO
>> many configuration options that an automated install would have to be
>> a huge piece of software, or address a simple case, like a demo/test
>> install
>>
>> That said, and to follow up on Chris's reply to this with the install
>> steps, the installation of OFBiz is super-easy OOTB, especially for a
>> binary build which would look like this:
>>
>> 1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE)  
>> installed
>> 2. download OFBiz binary build, and unzip to a directory
>> 3. go into that directory and run the executable jar file
>> (ofbiz.jar), or one of the startup scripts
>>
>> And that's IT, PERIOD. Installing Ant is not necessary because OFBiz
>> includes the libraries and a script for that. A build from SVN
>> procedure is almost as easy:
>>
>> 1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE)  
>> installed
>> 2. make sure you have an SVN client installed
>> 3. with the SVN client, checkout http://svn.apache.org/repos/asf/
>> ofbiz/trunk in a new directory
>> 4. go into that directory run "ant run-install", or in Linux/Unix "./
>> ant run-install"
>> 5. still in that directory run the executable jar file (ofbiz.jar),
>> or one of the startup scripts
>>
>> If that's too complex for a server side application demo/test
>> install, I don't know what to say... or how much more we can really
>> do about it. What else would an automated install do? I guess it
>> could check the one and only dependency there is: the JDK
>> installation. That is where most people run into problems. The best
>> way to avoid that: use a Mac. ;)
>>
>> Seriously though, this world is quite #$%^ed up and there are so many
>> different variations in operating systems, versions of Java (OFBiz
>> does NOT work with gcj and other such things), and so on that I don't
>> know that we can do a lot in this area. Say we chose a version of
>> Linux to support: now people have to install THAT version of Linux in
>> order to easily use OFBiz... hmmm...
>>
>> Still, if someone wanted to work on this, I certainly wouldn't
>> complain... ;)
>>
>> -David
>>
>>
>> On Jan 2, 2007, at 9:04 AM, Andrew Ballantine wrote:
>>
>>> Walter Vaughan wrote:
>>> "As a strategy, that's an excellent idea. Curing world hunger is
>>> another,
>>> but
>>> executing is another thing."
>>>
>>> Well, you can choose to make facetious remarks if you must, but I
>>> consider
>>> this very important.
>>>
>>> If you look back over the user mailing list you will find it
>>> littered with
>>> requests for help just getting ofbiz up and running. I would bet
>>> that a lot
>>> of them loose interest fairly quickly and we loose a potential
>>> user/contributor. Since no one can evaluate the framework without
>>> getting it
>>> working, that makes it very important that new users get a really
>>> painless
>>> and easy automated installation process.
>>>
>>> About 2 years ago I was evaluating ofbiz and used the Windows
>>> install that
>>> was available then. It wasn't completely automated or that easy,
>>> but I got
>>> through it. I tried the same thing in Linux, because the final
>>> production
>>> system must run on Linux, and got totally bogged down.
>>>
>>> I know that the history of Open Source has tended not to provide  
>>> easy
>>> installation procedures or documentation, but the trend is
>>> changing. You
>>> will find that many of the projects that support multiple operating
>>> systems
>>> have excellent automated installation procedures. OK it needs a  
>>> bit of
>>> effort to set up, but once done it should be easy to maintain and  
>>> keep
>>> working.
>>>
>>> I deliberately specified ONLY one Linux distribution, Ubuntu 6.06
>>> LTS, to
>>> simplify the job and chose a distribution with a 5 year support  
>>> plan.
>>>
>>> I have to confess that I have looked at other ERP Open Source
>>> projects to
>>> see if I could find one that was easier to use than ofbiz. I am
>>> sorry if
>>> this hurts, but it is true. However I keep coming back to ofbiz
>>> because of
>>> its excellent architecture and true open source community.
>>>
>>> I think it essential that the new user be at least accorded a decent
>>> automated install process to avoid loosing them at the first  
>>> hurdle. I
>>> primarily want to USE the framework to drive my client's business
>>> processes
>>> and then contribute any patches that I feel are needed to improve  
>>> the
>>> framework. I do not want to spend hours or days fiddling about with
>>> all
>>> sorts of things just to get the thing working without producing  
>>> error
>>> messages all over the place.
>>>
>>> We also should remember that newcomers to Open Source are also new
>>> to Linux
>>> which only adds to the learning curve. Faced with a huge learning
>>> curve
>>> there is a strong tendency to give up and stick with the trash we
>>> have grown
>>> to hate e.g. Microsoft.
>>>
>>> Is it really so difficult to create two automated install
>>> procedure? I would
>>> like to see a single executable download file which will then do
>>> everything
>>> that is needed to install a running ofbiz framework. That includes
>>> installing the correct versions of any products needed to support  
>>> the
>>> installation e.g. Java Ant Postgres etc
>>>
>>> I am interested in helping put together such procedures given some
>>> help from
>>> your good selves.
>>>
>>> Kind regards,
>>>
>>> Andrew Ballantine.
>>>
>>> -----Original Message-----
>>> From: Walter Vaughan [mailto:[hidden email]]
>>> Sent: 02 January 2007 13:30
>>> To: [hidden email]
>>> Subject: Re: Community supported releases WAS [Re: Properly edited
>>> OFBiz
>>> manuals]
>>>
>>>
>>> Andrew Ballantine wrote:
>>>
>>>> I second all of that and would like to add a request that each new
>>>> release
>>>> provides an automated installation procedure on MS Windows and one
>>>> flavour
>>>> of Linux, say Ubuntu 6.06.
>>>
>>> As a strategy, that's an excellent idea. Curing world hunger is
>>> another, but
>>> executing is another thing.
>>>
>>> Where we have a failure as a community right now it the document we
>>> have at
>>> http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
>>> which probably is an old version, with incorrect links
>>> (it points to http://svn.ofbiz.org/ which tosses a 403 error page),
>>> (it points to
>>> http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical+Production
>>> +Setup+Guide
>>> which needs a little more hand holding, and as well points to
>>> http://svn.ofbiz.org/ which tosses a 403 error page),
>>> (it points to http://www.sequoiaerp.org/ which hasn't been around
>>> in 10
>>> months).
>>>
>>> This page is slightly better
>>> http://incubator.apache.org/ofbiz/docs/setup.html
>>> but it sill suffers from non-linear thought process
>>>
>>> As soon as the dust settles on getting us out of the "incubator"  
>>> I am
>>> completely
>>> confident we'll have bulletproof installation, startup, and next
>>> step guides
>>> in
>>> place.
>>>
>>> --
>>> Walter
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:
>>> 01/01/2007
>>> 14:50
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:
>>> 01/01/2007
>>> 14:50
>>>
>>> --
>>> No virus found in this outgoing message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:
>>> 01/01/2007
>>> 14:50
>>>
>>>
>>>
>>> *****************************************************************
>>> This email has been checked by the altohiway Mailcontroller Service
>>> *****************************************************************
>>
>

[Andrew Ballantine]

Daniel,

Thanks for the non-destructive response.

your suggestions
1. Excellent idea for the production install

2. Seriously good idea. I would be willing to have a crack at it with some
support from the community.

3. VMware might be slow unless on state of the art hardware.

Although several of you have stated that its really easy to install ofbiz.
It isn't for the uninitiated. My experience of installing Java is fraught
with problems. This is mainly due to the layout of Sun's database. OK if you
install java JDK every other day, but here's a sample of what happens:

Type java into google
choose Download java software (www.java.com/getjava/)
Just spot in time that this for the runtime version
No sign of JDK on this web page, go back to google
try Java technology(java.sun.com)
Still no sign of JDK, is it perhaps JAVA EE 5 SDK?
Still not confident that I am at the right location of the correct version.
If I am downloading afresh is it best to load 1.5 or 1.4, one must be a
better choice than the other.

OK I have already spent 30 mins, slowed down slightly by writing this at the
same time, and I still haven't completed step 1.

Therefore if the writer of "make sure you have Sun Java 1.4 or 1.5 (JDK, not
just JRE) installed" knew the correct location of the download page for the
correct download, quoting it would be most helpful.

Summary lists of what to do are exceedingly frustrating if they are vague
and unclear.

I am new to Java although I have programmed in quite a number of languages
so I have only done this loading of JDK once before and that was 2 years
ago.

I am sorry if you find this message irritating, but it is born out of
frustration to complete what should be a simple task, but is made difficult
because I do not have half the information that I need to do something I am
not familiar with.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Daniel Kunkel [mailto:[hidden email]]
Sent: 02 January 2007 19:51
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited
OFBizmanuals]


Hi

The steps for an OFBiz demo are pretty straight forward, and works
quite
well most of time.

The main stumbling block I ran into was setting up OFBiz for
production.
Granted, I did it before the Production Setup Guide existed, but it was
a truly onerous task with huge gotcha's since I was trying to run it on
a popular virtual private server, a mistake since it caused unique
challenging errors that no one had ever seen.

However, it seems that all that is in the past, and now we have a number
of great opportunties:

1.) What about creating a "Production Patch" with instructions.

People could just go through that with Search and Replace to customize
it for their needs, run it, and be off.

This system seems like it would be pretty easy to create and keep up to
date.
The one gotcha I've seen here is to make sure the user runs the patch
against a certain release to avoid conflicts during the patch.

2.) Would there be a need for a live CD? It could even be possible to
set
one up a complete running OFBiz system with a database, apache, etc.

3.) A VMware image.  VMware seems to be taking the server world by
storm,
and virtual OFBiz instance might be really popular.

Does this spark any other ideas?



On Tue, 2007-01-02 at 12:20 -0700, David E Jones wrote:

> First a couple of general thoughts on this:
>
> 1. we are still working through the process of establishing policies
> and procedures for community supported binary releases, and we
> haven't done a binary release in years (but will hopefully get a
> branch going soon, and a stable version of that branch in a couple of
> months)
>
> 2. my guess as to why this doesn't exist already is that Apache OFBiz
> is server-side software and such installers are not as common for
> this sort of thing (yes, they do of course exist); there are SO SO SO
> many configuration options that an automated install would have to be
> a huge piece of software, or address a simple case, like a demo/test
> install
>
> That said, and to follow up on Chris's reply to this with the install
> steps, the installation of OFBiz is super-easy OOTB, especially for a
> binary build which would look like this:
>
> 1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE) installed
> 2. download OFBiz binary build, and unzip to a directory
> 3. go into that directory and run the executable jar file
> (ofbiz.jar), or one of the startup scripts
>
> And that's IT, PERIOD. Installing Ant is not necessary because OFBiz
> includes the libraries and a script for that. A build from SVN
> procedure is almost as easy:
>
> 1. make sure you have Sun Java 1.4 or 1.5 (JDK, not just JRE) installed
> 2. make sure you have an SVN client installed
> 3. with the SVN client, checkout http://svn.apache.org/repos/asf/
> ofbiz/trunk in a new directory
> 4. go into that directory run "ant run-install", or in Linux/Unix "./
> ant run-install"
> 5. still in that directory run the executable jar file (ofbiz.jar),
> or one of the startup scripts
>
> If that's too complex for a server side application demo/test
> install, I don't know what to say... or how much more we can really
> do about it. What else would an automated install do? I guess it
> could check the one and only dependency there is: the JDK
> installation. That is where most people run into problems. The best
> way to avoid that: use a Mac. ;)
>
> Seriously though, this world is quite #$%^ed up and there are so many
> different variations in operating systems, versions of Java (OFBiz
> does NOT work with gcj and other such things), and so on that I don't
> know that we can do a lot in this area. Say we chose a version of
> Linux to support: now people have to install THAT version of Linux in
> order to easily use OFBiz... hmmm...
>
> Still, if someone wanted to work on this, I certainly wouldn't
> complain... ;)
>
> -David
>
>
> On Jan 2, 2007, at 9:04 AM, Andrew Ballantine wrote:
>
> > Walter Vaughan wrote:
> > "As a strategy, that's an excellent idea. Curing world hunger is
> > another,
> > but
> > executing is another thing."
> >
> > Well, you can choose to make facetious remarks if you must, but I
> > consider
> > this very important.
> >
> > If you look back over the user mailing list you will find it
> > littered with
> > requests for help just getting ofbiz up and running. I would bet
> > that a lot
> > of them loose interest fairly quickly and we loose a potential
> > user/contributor. Since no one can evaluate the framework without
> > getting it
> > working, that makes it very important that new users get a really
> > painless
> > and easy automated installation process.
> >
> > About 2 years ago I was evaluating ofbiz and used the Windows
> > install that
> > was available then. It wasn't completely automated or that easy,
> > but I got
> > through it. I tried the same thing in Linux, because the final
> > production
> > system must run on Linux, and got totally bogged down.
> >
> > I know that the history of Open Source has tended not to provide easy
> > installation procedures or documentation, but the trend is
> > changing. You
> > will find that many of the projects that support multiple operating
> > systems
> > have excellent automated installation procedures. OK it needs a bit of
> > effort to set up, but once done it should be easy to maintain and keep
> > working.
> >
> > I deliberately specified ONLY one Linux distribution, Ubuntu 6.06
> > LTS, to
> > simplify the job and chose a distribution with a 5 year support plan.
> >
> > I have to confess that I have looked at other ERP Open Source
> > projects to
> > see if I could find one that was easier to use than ofbiz. I am
> > sorry if
> > this hurts, but it is true. However I keep coming back to ofbiz
> > because of
> > its excellent architecture and true open source community.
> >
> > I think it essential that the new user be at least accorded a decent
> > automated install process to avoid loosing them at the first hurdle. I
> > primarily want to USE the framework to drive my client's business
> > processes
> > and then contribute any patches that I feel are needed to improve the
> > framework. I do not want to spend hours or days fiddling about with
> > all
> > sorts of things just to get the thing working without producing error
> > messages all over the place.
> >
> > We also should remember that newcomers to Open Source are also new
> > to Linux
> > which only adds to the learning curve. Faced with a huge learning
> > curve
> > there is a strong tendency to give up and stick with the trash we
> > have grown
> > to hate e.g. Microsoft.
> >
> > Is it really so difficult to create two automated install
> > procedure? I would
> > like to see a single executable download file which will then do
> > everything
> > that is needed to install a running ofbiz framework. That includes
> > installing the correct versions of any products needed to support the
> > installation e.g. Java Ant Postgres etc
> >
> > I am interested in helping put together such procedures given some
> > help from
> > your good selves.
> >
> > Kind regards,
> >
> > Andrew Ballantine.
> >
> > -----Original Message-----
> > From: Walter Vaughan [mailto:[hidden email]]
> > Sent: 02 January 2007 13:30
> > To: [hidden email]
> > Subject: Re: Community supported releases WAS [Re: Properly edited
> > OFBiz
> > manuals]
> >
> >
> > Andrew Ballantine wrote:
> >
> >> I second all of that and would like to add a request that each new
> >> release
> >> provides an automated installation procedure on MS Windows and one
> >> flavour
> >> of Linux, say Ubuntu 6.06.
> >
> > As a strategy, that's an excellent idea. Curing world hunger is
> > another, but
> > executing is another thing.
> >
> > Where we have a failure as a community right now it the document we
> > have at
> > http://incubator.apache.org/ofbiz/docs/GettingAndUsingOFBiz.pdf
> > which probably is an old version, with incorrect links
> > (it points to http://svn.ofbiz.org/ which tosses a 403 error page),
> > (it points to
> > http://docs.ofbiz.org/display/OFBTECH/OFBiz+Technical+Production
> > +Setup+Guide
> > which needs a little more hand holding, and as well points to
> > http://svn.ofbiz.org/ which tosses a 403 error page),
> > (it points to http://www.sequoiaerp.org/ which hasn't been around
> > in 10
> > months).
> >
> > This page is slightly better
> > http://incubator.apache.org/ofbiz/docs/setup.html
> > but it sill suffers from non-linear thought process
> >
> > As soon as the dust settles on getting us out of the "incubator" I am
> > completely
> > confident we'll have bulletproof installation, startup, and next
> > step guides
> > in
> > place.
> >
> > --
> > Walter
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:
> > 01/01/2007
> > 14:50
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:
> > 01/01/2007
> > 14:50
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date:
> > 01/01/2007
> > 14:50
> >
> >
> >
> > *****************************************************************
> > This email has been checked by the altohiway Mailcontroller Service
> > *****************************************************************
>

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.3/614 - Release Date: 02/01/2007
14:58


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.3/614 - Release Date: 02/01/2007
14:58

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.3/614 - Release Date: 02/01/2007
14:58

[Jacopo Cappellato]

Andrew Ballantine wrote:

> ...
> Although several of you have stated that its really easy to install ofbiz.
> It isn't for the uninitiated. My experience of installing Java is fraught
> with problems. This is mainly due to the layout of Sun's database. OK if you
> install java JDK every other day, but here's a sample of what happens:
>
> Type java into google
> choose Download java software (www.java.com/getjava/)
> Just spot in time that this for the runtime version
> No sign of JDK on this web page, go back to google
> try Java technology(java.sun.com)
> Still no sign of JDK, is it perhaps JAVA EE 5 SDK?
> Still not confident that I am at the right location of the correct version.
> If I am downloading afresh is it best to load 1.5 or 1.4, one must be a
> better choice than the other.
>
> OK I have already spent 30 mins, slowed down slightly by writing this at the
> same time, and I still haven't completed step 1.
>
> Therefore if the writer of "make sure you have Sun Java 1.4 or 1.5 (JDK, not
> just JRE) installed" knew the correct location of the download page for the
> correct download, quoting it would be most helpful.
>
> Summary lists of what to do are exceedingly frustrating if they are vague
> and unclear.
>
> I am new to Java although I have programmed in quite a number of languages
> so I have only done this loading of JDK once before and that was 2 years
> ago.
>
> I am sorry if you find this message irritating, but it is born out of
> frustration to complete what should be a simple task, but is made difficult
> because I do not have half the information that I need to do something I am
> not familiar with.
>
> Kind regards,
>
> Andrew Ballantine.
>

Start from:

http://java.sun.com/javase/downloads/index_jdk5.jsp

then click on the "Dowload" button near "JDK 5.0 Update 10"

Jacopo