Properly edited OFBiz manuals

[davidnwelton]

> 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:

.... problems installing java ...

> 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.

This should improve dramatically now that java is open source.  Even
now, on a properly configured Ubuntu system, you can do:

apt-get install j2sdk1.4

and be up and ready to go in a few minutes.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[Andrew Ballantine]

Jacopo,

Thank you very much.

I will incorporate this into a full and details set of instructions when I
have figured it all out.

Thanks again for responding so quickly.

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: 03 January 2007 15:15
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited
OFBizmanuals]


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




--
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



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

[Andrew Sykes]

Andrew,

I'd agree with this, about 95% of the time everything builds just fine.

If you are getting a problem like this make sure you post here, such
problems are normally fixed VERY quickly!

- Andrew (Sykes)

On Tue, 2007-01-02 at 11:59 +0100, Jacopo Cappellato wrote:

> 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

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Andrew Ballantine]

David,

Thank you for that also. I will incorporate into a set of instructions for
Ubuntu.

Is your note a recommendation to use version 1.4?

Kind regards,

Andrew Ballantine.

-----Original Message-----
From: David Welton [mailto:[hidden email]]
Sent: 03 January 2007 15:27
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited
OFBizmanuals]


> 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:

.... problems installing java ...

> 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.

This should improve dramatically now that java is open source.  Even
now, on a properly configured Ubuntu system, you can do:

apt-get install j2sdk1.4

and be up and ready to go in a few minutes.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/


--
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



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

[Andrew Sykes]

Andrew,

Automated installs are probably a bad idea, because they assume you are
just going to use OfBiz straight out of the box.

I am yet to come across anyone who uses OfBiz in this way unless it's a
very small hobby project of the like.

I'd encourage people to do their best to get to grips with some of the
fundamentals of installing/modifying, the extra knowledge is worth its
weight in gold!

- Andrew (Sykes)

On Tue, 2007-01-02 at 11:07 +0000, 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.
>
> 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
> *****************************************************************

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Tim Ruppert]

Java 1.5 works great on all platforms.  I would recommend sticking  
with that my friend.  We are using it with NO problems on Mac OSX  
(Intel and PowerPC), Windows, Fedora Core 5/6 & Red Hat Enterprise  
Edition at the moment.

Stay as up to date as you can.

Cheers
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 3, 2007, at 8:33 AM, Andrew Ballantine wrote:

> David,
>
> Thank you for that also. I will incorporate into a set of  
> instructions for
> Ubuntu.
>
> Is your note a recommendation to use version 1.4?
>
> Kind regards,
>
> Andrew Ballantine.
>
> -----Original Message-----
> From: David Welton [mailto:[hidden email]]
> Sent: 03 January 2007 15:27
> To: [hidden email]
> Subject: Re: Community supported releases WAS [Re: Properly edited
> OFBizmanuals]
>
>
>> 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:
>
> .... problems installing java ...
>
>> 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.
>
> This should improve dramatically now that java is open source.  Even
> now, on a properly configured Ubuntu system, you can do:
>
> apt-get install j2sdk1.4
>
> and be up and ready to go in a few minutes.
>
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>
>
> --
> 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
>
>
>
> *****************************************************************
> This email has been checked by the altohiway Mailcontroller Service
> *****************************************************************

[Jacques Le Roux]

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

> 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

The problem is that this kind of links tends to be very changeable...
But that's right that Sun is not facilitates the task !

Anyway I tried a Google search with "java sdk" and my second choice was
http://java.sun.com/j2se/1.4.2/download.html

After that I tried to slighlty change the above link to
http://java.sun.com/j2se/1.5.0/download.html
and I come automaitcally to this page
http://java.sun.com/javase/downloads/index_jdk5.jsp

So maybe a way is to recommend to try to use/adapt this link
http://java.sun.com/j2se/1.4.2/download.html

Jacques

[Jacques Le Roux]

I plenty agree with Tim, but if you want use *POS on Linux* you might have a look at
https://issues.apache.org/jira/browse/OFBIZ-567
where it seems that for the moment 1.4 do the best (ie the least worst ;o)

Jacques

----- Original Message -----
From: "Tim Ruppert" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 03, 2007 4:38 PM
Subject: Re: Community supported releases WAS [Re: Properly edited OFBizmanuals]

> Java 1.5 works great on all platforms.  I would recommend sticking  
> with that my friend.  We are using it with NO problems on Mac OSX  
> (Intel and PowerPC), Windows, Fedora Core 5/6 & Red Hat Enterprise  
> Edition at the moment.
>
> Stay as up to date as you can.
>
> Cheers
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Jan 3, 2007, at 8:33 AM, Andrew Ballantine wrote:
>
> > David,
> >
> > Thank you for that also. I will incorporate into a set of  
> > instructions for
> > Ubuntu.
> >
> > Is your note a recommendation to use version 1.4?
> >
> > Kind regards,
> >
> > Andrew Ballantine.
> >
> > -----Original Message-----
> > From: David Welton [mailto:[hidden email]]
> > Sent: 03 January 2007 15:27
> > To: [hidden email]
> > Subject: Re: Community supported releases WAS [Re: Properly edited
> > OFBizmanuals]
> >
> >
> >> 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:
> >
> > .... problems installing java ...
> >
> >> 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.
> >
> > This should improve dramatically now that java is open source.  Even
> > now, on a properly configured Ubuntu system, you can do:
> >
> > apt-get install j2sdk1.4
> >
> > and be up and ready to go in a few minutes.
> >
> > --
> > David N. Welton
> >  - http://www.dedasys.com/davidw/
> >
> > Linux, Open Source Consulting
> >  - http://www.dedasys.com/
> >
> >
> > --
> > 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
> >
> >
> >
> > *****************************************************************
> > This email has been checked by the altohiway Mailcontroller Service
> > *****************************************************************
>
>

[Andrew Ballantine]

Thanks Jacques,

I had noticed the comments over the POS problem.

Kind regards,

Andrew.

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: 03 January 2007 16:01
To: [hidden email]
Subject: Re: Community supported releases WAS [Re: Properly edited
OFBizmanuals]


I plenty agree with Tim, but if you want use *POS on Linux* you might have a
look at
https://issues.apache.org/jira/browse/OFBIZ-567
where it seems that for the moment 1.4 do the best (ie the least worst ;o)

Jacques

----- Original Message -----
From: "Tim Ruppert" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 03, 2007 4:38 PM
Subject: Re: Community supported releases WAS [Re: Properly edited
OFBizmanuals]

> Java 1.5 works great on all platforms.  I would recommend sticking
> with that my friend.  We are using it with NO problems on Mac OSX
> (Intel and PowerPC), Windows, Fedora Core 5/6 & Red Hat Enterprise
> Edition at the moment.
>
> Stay as up to date as you can.
>
> Cheers
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Jan 3, 2007, at 8:33 AM, Andrew Ballantine wrote:
>
> > David,
> >
> > Thank you for that also. I will incorporate into a set of
> > instructions for
> > Ubuntu.
> >
> > Is your note a recommendation to use version 1.4?
> >
> > Kind regards,
> >
> > Andrew Ballantine.
> >
> > -----Original Message-----
> > From: David Welton [mailto:[hidden email]]
> > Sent: 03 January 2007 15:27
> > To: [hidden email]
> > Subject: Re: Community supported releases WAS [Re: Properly edited
> > OFBizmanuals]
> >
> >
> >> 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:
> >
> > .... problems installing java ...
> >
> >> 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.
> >
> > This should improve dramatically now that java is open source.  Even
> > now, on a properly configured Ubuntu system, you can do:
> >
> > apt-get install j2sdk1.4
> >
> > and be up and ready to go in a few minutes.
> >
> > --
> > David N. Welton
> >  - http://www.dedasys.com/davidw/
> >
> > Linux, Open Source Consulting
> >  - http://www.dedasys.com/
> >
> >
> > --
> > 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
> >
> >
> >
> > *****************************************************************
> > 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

[Ian McNulty]

Andrew (Sykes),

Might you not be putting the cart before the horse here?

Maybe the reason you have yet to encounter anyone who uses OFBiz in this
way is precisely because there are no automated installs you can use
straight out of the box. And if there were, you would!

The extra knowledge that comes from getting to grips with the
fundamentals may be worth its weight in gold in terms of deepening the
knowledge of the existing user base. But that does not prove that it is
not also the major obstacle to widening it.

Just because one proposition is true, does not necessarily mean that
others are not also equally true!

Ian


Andrew Sykes wrote:

> Andrew,
>
> Automated installs are probably a bad idea, because they assume you are
> just going to use OfBiz straight out of the box.
>
> I am yet to come across anyone who uses OfBiz in this way unless it's a
> very small hobby project of the like.
>
> I'd encourage people to do their best to get to grips with some of the
> fundamentals of installing/modifying, the extra knowledge is worth its
> weight in gold!
>
> - Andrew (Sykes)
>
> On Tue, 2007-01-02 at 11:07 +0000, 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.
>>
>> 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
>> *****************************************************************
>>    

--
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL

t: [phone]
e: [hidden email]
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on [phone]

This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment.
==============================================================================================

[Andrew Sykes]

Ian,

Yes, I'd agree, that's pretty fair comment, having used OfBiz from the
very early days, one of the things that has appealed to me is that there
always seemed to be a fairly clear idea of who the system was being
written for.

As you'll no doubt be aware OfBiz is a big and complex system, I'd hate
to see the code get even more complex in an effort to make it applicable
to those with less complex requirements (hope that makes sense!?).

As Jacopo mentioned a little while ago the territory you are talking
about is already pretty well staked out. At present for a smaller entity
to commit to OfBiz takes a lot of vision on the part of the person with
their hands on the purse strings but I have personally seen some of
these people make OfBiz a big success.

I'm not convinced that simply providing an installer etc would make
OfBiz much more accessible as you'd still need to wade through a never-
ending mass of options for every little thing you wanted to do, that
takes a lot of study, or input from an experienced OfBizer.

I do however see your point, and would love to see OfBiz become more
accessible, but I really think this would involve writing a lightweight
little brother with a lot of prescriptive OOTB pre-configuration.

- Andrew


On Wed, 2007-01-03 at 17:21 +0000, Ian McNulty wrote:

> Andrew (Sykes),
>
> Might you not be putting the cart before the horse here?
>
> Maybe the reason you have yet to encounter anyone who uses OFBiz in this
> way is precisely because there are no automated installs you can use
> straight out of the box. And if there were, you would!
>
> The extra knowledge that comes from getting to grips with the
> fundamentals may be worth its weight in gold in terms of deepening the
> knowledge of the existing user base. But that does not prove that it is
> not also the major obstacle to widening it.
>
> Just because one proposition is true, does not necessarily mean that
> others are not also equally true!
>
> Ian
>
>
> Andrew Sykes wrote:
> > Andrew,
> >
> > Automated installs are probably a bad idea, because they assume you are
> > just going to use OfBiz straight out of the box.
> >
> > I am yet to come across anyone who uses OfBiz in this way unless it's a
> > very small hobby project of the like.
> >
> > I'd encourage people to do their best to get to grips with some of the
> > fundamentals of installing/modifying, the extra knowledge is worth its
> > weight in gold!
> >
> > - Andrew (Sykes)
> >
> > On Tue, 2007-01-02 at 11:07 +0000, 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.
> >>
> >> 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
> >> *****************************************************************
> >>    
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[David E Jones-2]

Andrew,

Just a quick note as I'm catching up with all of these messages: this  
is the _perfect_ kind of feedback we need, and thanks for sending it  
over.

It's great because it identifies a specific problem based on a real  
experience, and it is hopefully something we can fix with  
documentation (even if Sun doesn't make it easy for us at ALL).

-David


On Jan 3, 2007, at 8:06 AM, Andrew Ballantine wrote:

> 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
>

[Scott Gray]

As a side note David, I'm no longer receiving change notifications from
the confluence server, is this something you could look into?  I think I
remember something about a server change?

Thanks
Scott

David E Jones wrote:

>
> Andrew,
>
> Just a quick note as I'm catching up with all of these messages: this
> is the _perfect_ kind of feedback we need, and thanks for sending it
> over.
>
> It's great because it identifies a specific problem based on a real
> experience, and it is hopefully something we can fix with
> documentation (even if Sun doesn't make it easy for us at ALL).
>
> -David
>
>
> On Jan 3, 2007, at 8:06 AM, Andrew Ballantine wrote:
>
>> 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
>>
>
>

[David E Jones-2]

Scott,

I'm not quite sure what you mean... are you sure you _ever_ got an  
email from Confluence? I don't believe I've ever seen such a thing...

If you have, could you forward it to me and I'll see what it is and  
what's up with it?

If it was working a while back something could have been broken as  
Confluence was moved to another server last week.

-David


On Jan 3, 2007, at 4:08 PM, Scott Gray wrote:

> As a side note David, I'm no longer receiving change notifications  
> from the confluence server, is this something you could look into?  
> I think I remember something about a server change?
>
> Thanks
> Scott
>
> David E Jones wrote:
>>
>> Andrew,
>>
>> Just a quick note as I'm catching up with all of these messages:  
>> this is the _perfect_ kind of feedback we need, and thanks for  
>> sending it over.
>>
>> It's great because it identifies a specific problem based on a  
>> real experience, and it is hopefully something we can fix with  
>> documentation (even if Sun doesn't make it easy for us at ALL).
>>
>> -David
>>
>>
>> On Jan 3, 2007, at 8:06 AM, Andrew Ballantine wrote:
>>
>>> 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
>>>
>>
>>
>

[Ian McNulty]

Andrew,

>
> As you'll no doubt be aware OfBiz is a big and complex system, I'd hate
> to see the code get even more complex in an effort to make it applicable
> to those with less complex requirements (hope that makes sense!?).
>  

It makes absolute sense and I couldn't agree more.

One of the criterion I would propose would be simplification at every level.

> As Jacopo mentioned a little while ago the territory you are talking
> about is already pretty well staked out.

It certainly is. And that's what Henry Ford thought too :)

>  At present for a smaller entity
> to commit to OfBiz takes a lot of vision on the part of the person with
> their hands on the purse strings but I have personally seen some of
> these people make OfBiz a big success.
>  

You've put your finger right on it. The person controlling the purse
strings needs a lot of vision!

My proposition is to put some resources into making that less of a
vision they have to generate themselves, and more a working model of
exactly what that vision could be.

> I'm not convinced that simply providing an installer etc would make
> OfBiz much more accessible as you'd still need to wade through a never-
> ending mass of options for every little thing you wanted to do, that
> takes a lot of study, or input from an experienced OfBizer.
>  

I completely agree. Not the way to go at all.

But we already have excellent models of how it can work.

Firefox and Thunderbird are shining examples. OOTB. Does exactly what it
says on the tin. Even your grandmother could learn how to use it!

But much more complicated installations like Apache, MySQL and even
Linux have all been made accessible for installation and maintenance by
engineers with basic back-street garage skills and a basic kit of tools
at prices the average user might be able to afford.

> I do however see your point, and would love to see OfBiz become more
> accessible, but I really think this would involve writing a lightweight
> little brother with a lot of prescriptive OOTB pre-configuration.
>  

That may be true. But it also ought not be too difficult to do.

Much more important, in my view, is the organisation of whatever lies
behind any kind of release.

If it goes wrong, who you gonna call? What kind of response will you
get? How much will it cost? These are things most people need to know
before they even think of opening the box.

That's the first point of contact with the interface.

If that can be made to run smooth as silk, then all the rest can fall
nicely into place behind!

Ian

> - Andrew
>  



Andrew Sykes wrote:

> Ian,
>
> Yes, I'd agree, that's pretty fair comment, having used OfBiz from the
> very early days, one of the things that has appealed to me is that there
> always seemed to be a fairly clear idea of who the system was being
> written for.
>
> As you'll no doubt be aware OfBiz is a big and complex system, I'd hate
> to see the code get even more complex in an effort to make it applicable
> to those with less complex requirements (hope that makes sense!?).
>
> As Jacopo mentioned a little while ago the territory you are talking
> about is already pretty well staked out. At present for a smaller entity
> to commit to OfBiz takes a lot of vision on the part of the person with
> their hands on the purse strings but I have personally seen some of
> these people make OfBiz a big success.
>
> I'm not convinced that simply providing an installer etc would make
> OfBiz much more accessible as you'd still need to wade through a never-
> ending mass of options for every little thing you wanted to do, that
> takes a lot of study, or input from an experienced OfBizer.
>
> I do however see your point, and would love to see OfBiz become more
> accessible, but I really think this would involve writing a lightweight
> little brother with a lot of prescriptive OOTB pre-configuration.
>
> - Andrew
>
>
> On Wed, 2007-01-03 at 17:21 +0000, Ian McNulty wrote:
>  
>> Andrew (Sykes),
>>
>> Might you not be putting the cart before the horse here?
>>
>> Maybe the reason you have yet to encounter anyone who uses OFBiz in this
>> way is precisely because there are no automated installs you can use
>> straight out of the box. And if there were, you would!
>>
>> The extra knowledge that comes from getting to grips with the
>> fundamentals may be worth its weight in gold in terms of deepening the
>> knowledge of the existing user base. But that does not prove that it is
>> not also the major obstacle to widening it.
>>
>> Just because one proposition is true, does not necessarily mean that
>> others are not also equally true!
>>
>> Ian
>>
>>
>> Andrew Sykes wrote:
>>    
>>> Andrew,
>>>
>>> Automated installs are probably a bad idea, because they assume you are
>>> just going to use OfBiz straight out of the box.
>>>
>>> I am yet to come across anyone who uses OfBiz in this way unless it's a
>>> very small hobby project of the like.
>>>
>>> I'd encourage people to do their best to get to grips with some of the
>>> fundamentals of installing/modifying, the extra knowledge is worth its
>>> weight in gold!
>>>
>>> - Andrew (Sykes)
>>>
>>> On Tue, 2007-01-02 at 11:07 +0000, 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.
>>>>
>>>> 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
>>>> *****************************************************************
>>>>    
>>>>        

--
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL

t: [phone]
e: [hidden email]
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on [phone]

This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment.
==============================================================================================