Attaching files to a product

[BJ Freeman]

ofbiz, now has three basic layers, as I see it.

first is the framework, which should stand alone from the other layers.

Next is your basic Business layer needed for all businesses, to manage
relationships, cash flow, products. This level can have interdependence
and dependence on the framework.

the top layer is the type of business one has, manufacturing, Ecommerce,
Travel. these don't really depended on each other, unless you have a
multidivisional organization and are driven by different Business plans
as to how to implement.

True the Data model of manufacturing has some that lend itself to
products, but the manufacturing industry as such is different than
selling products, say retail and takes into different consideration.

I can see the benefit of having the auto integration of the toplevel
addons by your means, as well as added setup setup in the setup module.
These would be a typical business plan process as described in the
SBA.Gov site.




Bruno Busco sent the following on 7/15/2010 10:51 PM:

> Having these extensions managed as add-on modules in a separate repository
> will be beneficial to the OFBiz trunk.
>
> I mean that this way of managing extensions will probabily require
> improvements in the trunk itself to better manage extensions. (i.e.
> https://issues.apache.org/jira/browse/OFBIZ-3373)
>
> Having the extensions in the trunk could generate new dependency problems
> (like we have now with many of OFBiz components) and will not help setting
> in place a powerfull, community-wide method of managing extensions.
>
> My two cents,
>
> -Bruno
>
>
> 2010/7/15 BJ Freeman<[hidden email]>
>
>> Inlne:
>>
>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>
>>
>>> This looks like more of a separate repository than a branch of OFBiz.
>>>
>> yes and no.
>> since it would usually not be merged back to ofbiz, yes, being able to sync
>> trunk to branch that all in the branch work with no.
>>
>>
>>
>>> First off, the term "branch" just doesn't apply. A branch of a source
>>> repository is
>>>
>>
>> effectively a copy of the repo that can be changed separately
>> that was the intention.
>>
>>
>> and is meant to eventually be merged back into the trunk.
>> If a branch is not meant to be merged back into the trunk, it is a fork.
>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>> or are they now Forks?
>>
>>
>>> What you're describing isn't even a fork as it doesn't sound like it would
>>> be a copy of OFBiz that is changed separately,
>>>
>> matter of perspective
>>
>> but rather a repository for add-on modules.
>> of course they are addons.
>> for instance the manufacturing, travel and Eccommerce would be defined as
>> addon, Just as the finacial Services, telecommunication, Proffiessional
>> services, Insurance and HealthCare are in the vol II of data model book.
>> so why limit it to just those vertical markets. there are many.
>> By having the trunk brought into the Contributors "section" they would
>> could access it and pull down everything at once to work with or use.
>>
>>
>>
>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>
>> the reason to keep it was the ability to move the truck into it.
>>
>>
>> if you don't want a vote where PMC votes are binding... that's all there is
>> at the ASF.
>> clarification  it was meant to communicate the popular vote is meant as an
>> indicatore, but the PMC would be the deciding vote.
>>
>>
>>> For those interested, why not just create a sourceforge or google code
>>> project and share commit access with others who are interested? There is
>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>> that people can't create separate projects to do such things. If various
>>> people want to work together to do so, from the community spirit
>>> perspective... all the better!
>>>
>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>> vertical market.
>> and it does not stop  any current developer from learning and offering
>> these.
>>
>>
>>> -David
>>>
>>>
>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>
>>>
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>
>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>
>>>>>
>>>>> Hans,
>>>>>
>>>>> How would you create such a branch, or what would that look like? Who
>>>>> would be able to commit to it?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>
>>>>>   Shouldn't we do a proof of concept?
>>>>>>
>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>> say they are ready we can judge what is there and/or provide
>>>>>> suggestions
>>>>>> for enhancement.
>>>>>>
>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>
>>>>>> Any comments?
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>
>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>
>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>> some of the points are:
>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>> down if they want to work on it.
>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>> contributions.
>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>> trunk.
>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>> with
>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>
>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>> elsewhere
>>>>>>>> why not do the same for Hippo.
>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>> elsewhere.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>
>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>
>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>> so
>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>> own
>>>>>>>>> contribution to them.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>
>>>>>>>>>   I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>> much
>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>> the
>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>> system
>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>
>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>> Adrian and
>>>>>>>>>> me is a good example.
>>>>>>>>>>
>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>> PMC
>>>>>>>>>> members who would support this?
>>>>>>>>>>
>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>> know
>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hans
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>> been my
>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>> resources.
>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>> mine.
>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>> would be
>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>> work
>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>
>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>   a product is more of a marketing item
>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>> not
>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>> list
>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>> Please
>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   [snip]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>

[David E. Jones-2]

This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:

* framework
* applications (base applications)
* specialpurpose (special purpose application)

-David


On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:

> ofbiz, now has three basic layers, as I see it.
>
> first is the framework, which should stand alone from the other layers.
>
> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have interdependence and dependence on the framework.
>
> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other, unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>
> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different than selling products, say retail and takes into different consideration.
>
> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the setup module.
> These would be a typical business plan process as described in the SBA.Gov site.
>
>
>
>
> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>> Having these extensions managed as add-on modules in a separate repository
>> will be beneficial to the OFBiz trunk.
>>
>> I mean that this way of managing extensions will probabily require
>> improvements in the trunk itself to better manage extensions. (i.e.
>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>
>> Having the extensions in the trunk could generate new dependency problems
>> (like we have now with many of OFBiz components) and will not help setting
>> in place a powerfull, community-wide method of managing extensions.
>>
>> My two cents,
>>
>> -Bruno
>>
>>
>> 2010/7/15 BJ Freeman<[hidden email]>
>>
>>> Inlne:
>>>
>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>
>>>
>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>
>>> yes and no.
>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>> trunk to branch that all in the branch work with no.
>>>
>>>
>>>
>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>> repository is
>>>>
>>>
>>> effectively a copy of the repo that can be changed separately
>>> that was the intention.
>>>
>>>
>>> and is meant to eventually be merged back into the trunk.
>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>> or are they now Forks?
>>>
>>>
>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>> be a copy of OFBiz that is changed separately,
>>>>
>>> matter of perspective
>>>
>>> but rather a repository for add-on modules.
>>> of course they are addons.
>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>> services, Insurance and HealthCare are in the vol II of data model book.
>>> so why limit it to just those vertical markets. there are many.
>>> By having the trunk brought into the Contributors "section" they would
>>> could access it and pull down everything at once to work with or use.
>>>
>>>
>>>
>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>
>>> the reason to keep it was the ability to move the truck into it.
>>>
>>>
>>> if you don't want a vote where PMC votes are binding... that's all there is
>>> at the ASF.
>>> clarification  it was meant to communicate the popular vote is meant as an
>>> indicatore, but the PMC would be the deciding vote.
>>>
>>>
>>>> For those interested, why not just create a sourceforge or google code
>>>> project and share commit access with others who are interested? There is
>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>> that people can't create separate projects to do such things. If various
>>>> people want to work together to do so, from the community spirit
>>>> perspective... all the better!
>>>>
>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>> vertical market.
>>> and it does not stop  any current developer from learning and offering
>>> these.
>>>
>>>
>>>> -David
>>>>
>>>>
>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>
>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>
>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>
>>>>>>
>>>>>> Hans,
>>>>>>
>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>> would be able to commit to it?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>
>>>>>>  Shouldn't we do a proof of concept?
>>>>>>>
>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>> suggestions
>>>>>>> for enhancement.
>>>>>>>
>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>
>>>>>>> Any comments?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>
>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>
>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>> some of the points are:
>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>> down if they want to work on it.
>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>> contributions.
>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>> trunk.
>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>> with
>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>
>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>> elsewhere
>>>>>>>>> why not do the same for Hippo.
>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>> elsewhere.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>
>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>
>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>> so
>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>> own
>>>>>>>>>> contribution to them.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>>
>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>
>>>>>>>>>>  I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>> much
>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>> the
>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>> system
>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>
>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>> Adrian and
>>>>>>>>>>> me is a good example.
>>>>>>>>>>>
>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>> PMC
>>>>>>>>>>> members who would support this?
>>>>>>>>>>>
>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>> know
>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Hans
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>
>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>> been my
>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>> resources.
>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>> mine.
>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>> would be
>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>> work
>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  a product is more of a marketing item
>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>> list
>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>> Please
>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  [snip]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>

[BJ Freeman]

a matter of perspective.
manufacturing is a unique industry and being in the base applications,
does not meet the definition I stated. Just like ecommerce got moved to
specialpurposes so should manufacturing to meet the criteria I stated.

this would require a large re-factoring having to do with orders, and
products, so I doubt it will be done.
however by taking Manufacturing out of the basic apps and the order flow
would make for a cleaner way to implement other vertical markets.

David E Jones sent the following on 7/20/2010 9:31 AM:

>
> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>
> * framework
> * applications (base applications)
> * specialpurpose (special purpose application)
>
> -David
>
>
> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>
>> ofbiz, now has three basic layers, as I see it.
>>
>> first is the framework, which should stand alone from the other layers.
>>
>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have interdependence and dependence on the framework.
>>
>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other, unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>
>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different than selling products, say retail and takes into different consideration.
>>
>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the setup module.
>> These would be a typical business plan process as described in the SBA.Gov site.
>>
>>
>>
>>
>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>> Having these extensions managed as add-on modules in a separate repository
>>> will be beneficial to the OFBiz trunk.
>>>
>>> I mean that this way of managing extensions will probabily require
>>> improvements in the trunk itself to better manage extensions. (i.e.
>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>
>>> Having the extensions in the trunk could generate new dependency problems
>>> (like we have now with many of OFBiz components) and will not help setting
>>> in place a powerfull, community-wide method of managing extensions.
>>>
>>> My two cents,
>>>
>>> -Bruno
>>>
>>>
>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>
>>>> Inlne:
>>>>
>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>
>>>>
>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>
>>>> yes and no.
>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>> trunk to branch that all in the branch work with no.
>>>>
>>>>
>>>>
>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>> repository is
>>>>>
>>>>
>>>> effectively a copy of the repo that can be changed separately
>>>> that was the intention.
>>>>
>>>>
>>>> and is meant to eventually be merged back into the trunk.
>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>> or are they now Forks?
>>>>
>>>>
>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>> be a copy of OFBiz that is changed separately,
>>>>>
>>>> matter of perspective
>>>>
>>>> but rather a repository for add-on modules.
>>>> of course they are addons.
>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>> so why limit it to just those vertical markets. there are many.
>>>> By having the trunk brought into the Contributors "section" they would
>>>> could access it and pull down everything at once to work with or use.
>>>>
>>>>
>>>>
>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>
>>>> the reason to keep it was the ability to move the truck into it.
>>>>
>>>>
>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>> at the ASF.
>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>> indicatore, but the PMC would be the deciding vote.
>>>>
>>>>
>>>>> For those interested, why not just create a sourceforge or google code
>>>>> project and share commit access with others who are interested? There is
>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>> that people can't create separate projects to do such things. If various
>>>>> people want to work together to do so, from the community spirit
>>>>> perspective... all the better!
>>>>>
>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>> vertical market.
>>>> and it does not stop  any current developer from learning and offering
>>>> these.
>>>>
>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>
>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>
>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>
>>>>>>>
>>>>>>> Hans,
>>>>>>>
>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>> would be able to commit to it?
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>
>>>>>>>   Shouldn't we do a proof of concept?
>>>>>>>>
>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>> suggestions
>>>>>>>> for enhancement.
>>>>>>>>
>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>
>>>>>>>> Any comments?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>
>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>
>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>> some of the points are:
>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>> down if they want to work on it.
>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>> contributions.
>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>> trunk.
>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>> with
>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>
>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>> elsewhere
>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>> elsewhere.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>
>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>
>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>> so
>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>> own
>>>>>>>>>>> contribution to them.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>
>>>>>>>>>>>   I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>> much
>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>> the
>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>> system
>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>> Adrian and
>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>
>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>> PMC
>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>
>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>> know
>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Hans
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>> been my
>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>> resources.
>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>> mine.
>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>> would be
>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>> work
>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   a product is more of a marketing item
>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   [snip]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
>

[Jacques Le Roux]

Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!

Jacques

From: "BJ Freeman" <[hidden email]>

>a matter of perspective.
> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like ecommerce
> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
>
> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other vertical
> markets.
>
> David E Jones sent the following on 7/20/2010 9:31 AM:
>>
>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>>
>> * framework
>> * applications (base applications)
>> * specialpurpose (special purpose application)
>>
>> -David
>>
>>
>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>>
>>> ofbiz, now has three basic layers, as I see it.
>>>
>>> first is the framework, which should stand alone from the other layers.
>>>
>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
>>> interdependence and dependence on the framework.
>>>
>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>>
>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different
>>> than selling products, say retail and takes into different consideration.
>>>
>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
>>> setup module.
>>> These would be a typical business plan process as described in the SBA.Gov site.
>>>
>>>
>>>
>>>
>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>>> Having these extensions managed as add-on modules in a separate repository
>>>> will be beneficial to the OFBiz trunk.
>>>>
>>>> I mean that this way of managing extensions will probabily require
>>>> improvements in the trunk itself to better manage extensions. (i.e.
>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>>
>>>> Having the extensions in the trunk could generate new dependency problems
>>>> (like we have now with many of OFBiz components) and will not help setting
>>>> in place a powerfull, community-wide method of managing extensions.
>>>>
>>>> My two cents,
>>>>
>>>> -Bruno
>>>>
>>>>
>>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>>
>>>>> Inlne:
>>>>>
>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>>
>>>>>
>>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>>
>>>>> yes and no.
>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>>> trunk to branch that all in the branch work with no.
>>>>>
>>>>>
>>>>>
>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>>> repository is
>>>>>>
>>>>>
>>>>> effectively a copy of the repo that can be changed separately
>>>>> that was the intention.
>>>>>
>>>>>
>>>>> and is meant to eventually be merged back into the trunk.
>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>>> or are they now Forks?
>>>>>
>>>>>
>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>>> be a copy of OFBiz that is changed separately,
>>>>>>
>>>>> matter of perspective
>>>>>
>>>>> but rather a repository for add-on modules.
>>>>> of course they are addons.
>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>>> so why limit it to just those vertical markets. there are many.
>>>>> By having the trunk brought into the Contributors "section" they would
>>>>> could access it and pull down everything at once to work with or use.
>>>>>
>>>>>
>>>>>
>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>>
>>>>> the reason to keep it was the ability to move the truck into it.
>>>>>
>>>>>
>>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>>> at the ASF.
>>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>>> indicatore, but the PMC would be the deciding vote.
>>>>>
>>>>>
>>>>>> For those interested, why not just create a sourceforge or google code
>>>>>> project and share commit access with others who are interested? There is
>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>>> that people can't create separate projects to do such things. If various
>>>>>> people want to work together to do so, from the community spirit
>>>>>> perspective... all the better!
>>>>>>
>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>>> vertical market.
>>>>> and it does not stop  any current developer from learning and offering
>>>>> these.
>>>>>
>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>>
>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>
>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>>
>>>>>>>>
>>>>>>>> Hans,
>>>>>>>>
>>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>>> would be able to commit to it?
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>>
>>>>>>>>   Shouldn't we do a proof of concept?
>>>>>>>>>
>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>>> suggestions
>>>>>>>>> for enhancement.
>>>>>>>>>
>>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>>
>>>>>>>>> Any comments?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>
>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>>
>>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>>> some of the points are:
>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>>> down if they want to work on it.
>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>>> contributions.
>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>>> trunk.
>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>>> with
>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>>
>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>>> elsewhere
>>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>>> elsewhere.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>>
>>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>>> so
>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>>> own
>>>>>>>>>>>> contribution to them.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Scott
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>   I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>>> much
>>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>>> system
>>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>>> Adrian and
>>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>>> PMC
>>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>>> know
>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>>> been my
>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>>> resources.
>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>>> mine.
>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>>> work
>>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   a product is more of a marketing item
>>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   [snip]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
>

[Erwan de FERRIERES]

Le 20/07/2010 22:29, Jacques Le Roux a écrit :
> Sounds logical, but I guess history will not permit us to do that, or as
> you said with a rather big effort!
>
couldn't the sourceforge project be reused as a contributor branch ?
Maybe this would help OFBiz to regain popularity on it.
Or the creation of a highly synchronised googlecode project could also
be a solution for the contributor branch.


--
Erwan de FERRIERES
www.nereide.biz

[David E. Jones-2]

For my part I think it's good to have manufacturing data structures and services in base applications, and then different types of mfg apps as specialpurpose apps. There are many different types of manufacturing, varying by what is being made, and they can benefit from sharing underlying structures and services.

-David


On Jul 20, 2010, at 2:29 PM, Jacques Le Roux wrote:

> Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> a matter of perspective.
>> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like ecommerce
>> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
>>
>> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
>> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other vertical
>> markets.
>>
>> David E Jones sent the following on 7/20/2010 9:31 AM:
>>>
>>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>>>
>>> * framework
>>> * applications (base applications)
>>> * specialpurpose (special purpose application)
>>>
>>> -David
>>>
>>>
>>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>>>
>>>> ofbiz, now has three basic layers, as I see it.
>>>>
>>>> first is the framework, which should stand alone from the other layers.
>>>>
>>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
>>>> interdependence and dependence on the framework.
>>>>
>>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
>>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>>>
>>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different
>>>> than selling products, say retail and takes into different consideration.
>>>>
>>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
>>>> setup module.
>>>> These would be a typical business plan process as described in the SBA.Gov site.
>>>>
>>>>
>>>>
>>>>
>>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>>>> Having these extensions managed as add-on modules in a separate repository
>>>>> will be beneficial to the OFBiz trunk.
>>>>>
>>>>> I mean that this way of managing extensions will probabily require
>>>>> improvements in the trunk itself to better manage extensions. (i.e.
>>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>>>
>>>>> Having the extensions in the trunk could generate new dependency problems
>>>>> (like we have now with many of OFBiz components) and will not help setting
>>>>> in place a powerfull, community-wide method of managing extensions.
>>>>>
>>>>> My two cents,
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>>>
>>>>>> Inlne:
>>>>>>
>>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>>>
>>>>>>
>>>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>>>
>>>>>> yes and no.
>>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>>>> trunk to branch that all in the branch work with no.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>>>> repository is
>>>>>>>
>>>>>>
>>>>>> effectively a copy of the repo that can be changed separately
>>>>>> that was the intention.
>>>>>>
>>>>>>
>>>>>> and is meant to eventually be merged back into the trunk.
>>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>>>> or are they now Forks?
>>>>>>
>>>>>>
>>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>>>> be a copy of OFBiz that is changed separately,
>>>>>>>
>>>>>> matter of perspective
>>>>>>
>>>>>> but rather a repository for add-on modules.
>>>>>> of course they are addons.
>>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>>>> so why limit it to just those vertical markets. there are many.
>>>>>> By having the trunk brought into the Contributors "section" they would
>>>>>> could access it and pull down everything at once to work with or use.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>>>
>>>>>> the reason to keep it was the ability to move the truck into it.
>>>>>>
>>>>>>
>>>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>>>> at the ASF.
>>>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>>>> indicatore, but the PMC would be the deciding vote.
>>>>>>
>>>>>>
>>>>>>> For those interested, why not just create a sourceforge or google code
>>>>>>> project and share commit access with others who are interested? There is
>>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>>>> that people can't create separate projects to do such things. If various
>>>>>>> people want to work together to do so, from the community spirit
>>>>>>> perspective... all the better!
>>>>>>>
>>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>>>> vertical market.
>>>>>> and it does not stop  any current developer from learning and offering
>>>>>> these.
>>>>>>
>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>>>
>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>
>>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hans,
>>>>>>>>>
>>>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>>>> would be able to commit to it?
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>>>
>>>>>>>>>  Shouldn't we do a proof of concept?
>>>>>>>>>>
>>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>>>> suggestions
>>>>>>>>>> for enhancement.
>>>>>>>>>>
>>>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>>>
>>>>>>>>>> Any comments?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hans
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>>
>>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>>>
>>>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>>>> some of the points are:
>>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>>>> down if they want to work on it.
>>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>>>> contributions.
>>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>>>> trunk.
>>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>>>> with
>>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>>>
>>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>>>> elsewhere
>>>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>>>> elsewhere.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>>>> so
>>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>>>> own
>>>>>>>>>>>>> contribution to them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>>>> much
>>>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>>>> system
>>>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>>>> Adrian and
>>>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>>>> know
>>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>>>> been my
>>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>>>> resources.
>>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>>>> mine.
>>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  a product is more of a marketing item
>>>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  [snip]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>
>
>

[BJ Freeman]

you can use that logic for a lot of industries.
it would make ofbiz as a global application unwieldy.
so have the manufacturing as it is now part of the specialpurpose and
others can append to it per thier specific manufacture business requires.
you still have what you state as the reason for having it in the base
apps, but can be disconnected easily without effecting order flow or
products.



David E Jones sent the following on 7/20/2010 1:45 PM:

>
> For my part I think it's good to have manufacturing data structures and services in base applications, and then different types of mfg apps as specialpurpose apps. There are many different types of manufacturing, varying by what is being made, and they can benefit from sharing underlying structures and services.
>
> -David
>
>
> On Jul 20, 2010, at 2:29 PM, Jacques Le Roux wrote:
>
>> Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!
>>
>> Jacques
>>
>> From: "BJ Freeman"<[hidden email]>
>>> a matter of perspective.
>>> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like ecommerce
>>> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
>>>
>>> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
>>> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other vertical
>>> markets.
>>>
>>> David E Jones sent the following on 7/20/2010 9:31 AM:
>>>>
>>>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>>>>
>>>> * framework
>>>> * applications (base applications)
>>>> * specialpurpose (special purpose application)
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>>>>
>>>>> ofbiz, now has three basic layers, as I see it.
>>>>>
>>>>> first is the framework, which should stand alone from the other layers.
>>>>>
>>>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
>>>>> interdependence and dependence on the framework.
>>>>>
>>>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
>>>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>>>>
>>>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different
>>>>> than selling products, say retail and takes into different consideration.
>>>>>
>>>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
>>>>> setup module.
>>>>> These would be a typical business plan process as described in the SBA.Gov site.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>>>>> Having these extensions managed as add-on modules in a separate repository
>>>>>> will be beneficial to the OFBiz trunk.
>>>>>>
>>>>>> I mean that this way of managing extensions will probabily require
>>>>>> improvements in the trunk itself to better manage extensions. (i.e.
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>>>>
>>>>>> Having the extensions in the trunk could generate new dependency problems
>>>>>> (like we have now with many of OFBiz components) and will not help setting
>>>>>> in place a powerfull, community-wide method of managing extensions.
>>>>>>
>>>>>> My two cents,
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>>>>
>>>>>>> Inlne:
>>>>>>>
>>>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>>>>
>>>>>>>
>>>>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>>>>
>>>>>>> yes and no.
>>>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>>>>> trunk to branch that all in the branch work with no.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>>>>> repository is
>>>>>>>>
>>>>>>>
>>>>>>> effectively a copy of the repo that can be changed separately
>>>>>>> that was the intention.
>>>>>>>
>>>>>>>
>>>>>>> and is meant to eventually be merged back into the trunk.
>>>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>>>>> or are they now Forks?
>>>>>>>
>>>>>>>
>>>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>>>>> be a copy of OFBiz that is changed separately,
>>>>>>>>
>>>>>>> matter of perspective
>>>>>>>
>>>>>>> but rather a repository for add-on modules.
>>>>>>> of course they are addons.
>>>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>>>>> so why limit it to just those vertical markets. there are many.
>>>>>>> By having the trunk brought into the Contributors "section" they would
>>>>>>> could access it and pull down everything at once to work with or use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>>>>
>>>>>>> the reason to keep it was the ability to move the truck into it.
>>>>>>>
>>>>>>>
>>>>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>>>>> at the ASF.
>>>>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>>>>> indicatore, but the PMC would be the deciding vote.
>>>>>>>
>>>>>>>
>>>>>>>> For those interested, why not just create a sourceforge or google code
>>>>>>>> project and share commit access with others who are interested? There is
>>>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>>>>> that people can't create separate projects to do such things. If various
>>>>>>>> people want to work together to do so, from the community spirit
>>>>>>>> perspective... all the better!
>>>>>>>>
>>>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>>>>> vertical market.
>>>>>>> and it does not stop  any current developer from learning and offering
>>>>>>> these.
>>>>>>>
>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>
>>>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hans,
>>>>>>>>>>
>>>>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>>>>> would be able to commit to it?
>>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>>>>
>>>>>>>>>>   Shouldn't we do a proof of concept?
>>>>>>>>>>>
>>>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>>>>> suggestions
>>>>>>>>>>> for enhancement.
>>>>>>>>>>>
>>>>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>>>>
>>>>>>>>>>> Any comments?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Hans
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>>>
>>>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>>>>> some of the points are:
>>>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>>>>> down if they want to work on it.
>>>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>>>>> contributions.
>>>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>>>>
>>>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>>>>> elsewhere
>>>>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>>>>> elsewhere.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>>>>> own
>>>>>>>>>>>>>> contribution to them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>>>>> Adrian and
>>>>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>>>>> been my
>>>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>>>>> resources.
>>>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>>>>> mine.
>>>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   a product is more of a marketing item
>>>>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   [snip]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

[David E. Jones-2]

Don't be silly. Manufacturing is not an industry, it is a type of industry. Having shared manufacturing data structures and services and generic screens is just as helpful as having any sort of product or inventory or order handling artifacts.

For shared artifacts the original intent of the organization of the project (which has been watered down by many committers not playing along) is that if specialpurpose applications EVER need to share something, it is probably generic enough to put in a base applications. In other words, as a rule of thumb, special purpose applications should NEVER use something from another special purpose app and if something exists in a special purpose app that another special purpose app could reuse then it should be moved from the first special purpose app to a base application, which is meant to be shared, reused, and built upon.

You can disagree all you want, but without this sort of distinction things would be much more disorganized and difficult to reuse, and the intent of OFBiz is to make things as easy as possible to reuse and extend, so organization is critically important.

Unfortunately many committers don't feel it is so important which is why we have hundreds of ridiculous dependencies from the framework to the base apps, from the base apps the special purpose apps, and from one special purpose app to another, and NONE of that should be allowed. That is why in my effort to right the wrongs of OFBiz with the Moqui framework, the framework will be a SEPARATE PROJECT so that no backwards dependencies are possible. Also, another separate project will be data structures (like the data model resource book, basically the OFBiz data model cleaned up and made more consistent and removing a lot of stuff that isn't used or is a bad idea) and common business-process oriented services (following patterns in OAGIS or something similar). That will be separate from ANY application that an end-user can use.

IMO going in that direction is necessary because people just don't generally accept how critical it is to organize things well in large software. Drawing certain clear lines like this helps a lot and will make it far easier for those customizing and extending existing artifacts.

-David


On Jul 20, 2010, at 2:58 PM, BJ Freeman wrote:

> you can use that logic for a lot of industries.
> it would make ofbiz as a global application unwieldy.
> so have the manufacturing as it is now part of the specialpurpose and others can append to it per thier specific manufacture business requires.
> you still have what you state as the reason for having it in the base apps, but can be disconnected easily without effecting order flow or products.
>
>
>
> David E Jones sent the following on 7/20/2010 1:45 PM:
>>
>> For my part I think it's good to have manufacturing data structures and services in base applications, and then different types of mfg apps as specialpurpose apps. There are many different types of manufacturing, varying by what is being made, and they can benefit from sharing underlying structures and services.
>>
>> -David
>>
>>
>> On Jul 20, 2010, at 2:29 PM, Jacques Le Roux wrote:
>>
>>> Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman"<[hidden email]>
>>>> a matter of perspective.
>>>> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like ecommerce
>>>> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
>>>>
>>>> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
>>>> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other vertical
>>>> markets.
>>>>
>>>> David E Jones sent the following on 7/20/2010 9:31 AM:
>>>>>
>>>>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>>>>>
>>>>> * framework
>>>>> * applications (base applications)
>>>>> * specialpurpose (special purpose application)
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>>>>>
>>>>>> ofbiz, now has three basic layers, as I see it.
>>>>>>
>>>>>> first is the framework, which should stand alone from the other layers.
>>>>>>
>>>>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
>>>>>> interdependence and dependence on the framework.
>>>>>>
>>>>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
>>>>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>>>>>
>>>>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different
>>>>>> than selling products, say retail and takes into different consideration.
>>>>>>
>>>>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
>>>>>> setup module.
>>>>>> These would be a typical business plan process as described in the SBA.Gov site.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>>>>>> Having these extensions managed as add-on modules in a separate repository
>>>>>>> will be beneficial to the OFBiz trunk.
>>>>>>>
>>>>>>> I mean that this way of managing extensions will probabily require
>>>>>>> improvements in the trunk itself to better manage extensions. (i.e.
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>>>>>
>>>>>>> Having the extensions in the trunk could generate new dependency problems
>>>>>>> (like we have now with many of OFBiz components) and will not help setting
>>>>>>> in place a powerfull, community-wide method of managing extensions.
>>>>>>>
>>>>>>> My two cents,
>>>>>>>
>>>>>>> -Bruno
>>>>>>>
>>>>>>>
>>>>>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>>>>>
>>>>>>>> Inlne:
>>>>>>>>
>>>>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>>>>>
>>>>>>>>
>>>>>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>>>>>
>>>>>>>> yes and no.
>>>>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>>>>>> trunk to branch that all in the branch work with no.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>>>>>> repository is
>>>>>>>>>
>>>>>>>>
>>>>>>>> effectively a copy of the repo that can be changed separately
>>>>>>>> that was the intention.
>>>>>>>>
>>>>>>>>
>>>>>>>> and is meant to eventually be merged back into the trunk.
>>>>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>>>>>> or are they now Forks?
>>>>>>>>
>>>>>>>>
>>>>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>>>>>> be a copy of OFBiz that is changed separately,
>>>>>>>>>
>>>>>>>> matter of perspective
>>>>>>>>
>>>>>>>> but rather a repository for add-on modules.
>>>>>>>> of course they are addons.
>>>>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>>>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>>>>>> so why limit it to just those vertical markets. there are many.
>>>>>>>> By having the trunk brought into the Contributors "section" they would
>>>>>>>> could access it and pull down everything at once to work with or use.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>>>>>
>>>>>>>> the reason to keep it was the ability to move the truck into it.
>>>>>>>>
>>>>>>>>
>>>>>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>>>>>> at the ASF.
>>>>>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>>>>>> indicatore, but the PMC would be the deciding vote.
>>>>>>>>
>>>>>>>>
>>>>>>>>> For those interested, why not just create a sourceforge or google code
>>>>>>>>> project and share commit access with others who are interested? There is
>>>>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>>>>>> that people can't create separate projects to do such things. If various
>>>>>>>>> people want to work together to do so, from the community spirit
>>>>>>>>> perspective... all the better!
>>>>>>>>>
>>>>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>>>>>> vertical market.
>>>>>>>> and it does not stop  any current developer from learning and offering
>>>>>>>> these.
>>>>>>>>
>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>
>>>>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hans,
>>>>>>>>>>>
>>>>>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>>>>>> would be able to commit to it?
>>>>>>>>>>>
>>>>>>>>>>> -David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>>>>>
>>>>>>>>>>>  Shouldn't we do a proof of concept?
>>>>>>>>>>>>
>>>>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>>>>>> suggestions
>>>>>>>>>>>> for enhancement.
>>>>>>>>>>>>
>>>>>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>>>>>
>>>>>>>>>>>> Any comments?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Hans
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>>>>
>>>>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>>>>>> some of the points are:
>>>>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>>>>>> down if they want to work on it.
>>>>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>>>>>> contributions.
>>>>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>>>>>> elsewhere
>>>>>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>>>>>> elsewhere.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>> contribution to them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>>>>>> Adrian and
>>>>>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>>>>>> been my
>>>>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>>>>>> resources.
>>>>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>>>>>> mine.
>>>>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  a product is more of a marketing item
>>>>>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  [snip]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>

[BJ Freeman]

Ok so The manufacturing sector is part of the goods-producing
industries. I concede on that point.

and I agree with you mostly on the rest of what you say. except having
manufacturing in the base apps.



David E Jones sent the following on 7/20/2010 2:10 PM:

>
> Don't be silly. Manufacturing is not an industry, it is a type of industry. Having shared manufacturing data structures and services and generic screens is just as helpful as having any sort of product or inventory or order handling artifacts.
>
> For shared artifacts the original intent of the organization of the project (which has been watered down by many committers not playing along) is that if specialpurpose applications EVER need to share something, it is probably generic enough to put in a base applications. In other words, as a rule of thumb, special purpose applications should NEVER use something from another special purpose app and if something exists in a special purpose app that another special purpose app could reuse then it should be moved from the first special purpose app to a base application, which is meant to be shared, reused, and built upon.
>
> You can disagree all you want, but without this sort of distinction things would be much more disorganized and difficult to reuse, and the intent of OFBiz is to make things as easy as possible to reuse and extend, so organization is critically important.
>
> Unfortunately many committers don't feel it is so important which is why we have hundreds of ridiculous dependencies from the framework to the base apps, from the base apps the special purpose apps, and from one special purpose app to another, and NONE of that should be allowed. That is why in my effort to right the wrongs of OFBiz with the Moqui framework, the framework will be a SEPARATE PROJECT so that no backwards dependencies are possible. Also, another separate project will be data structures (like the data model resource book, basically the OFBiz data model cleaned up and made more consistent and removing a lot of stuff that isn't used or is a bad idea) and common business-process oriented services (following patterns in OAGIS or something similar). That will be separate from ANY application that an end-user can use.
>
> IMO going in that direction is necessary because people just don't generally accept how critical it is to organize things well in large software. Drawing certain clear lines like this helps a lot and will make it far easier for those customizing and extending existing artifacts.
>
> -David
>
>
> On Jul 20, 2010, at 2:58 PM, BJ Freeman wrote:
>
>> you can use that logic for a lot of industries.
>> it would make ofbiz as a global application unwieldy.
>> so have the manufacturing as it is now part of the specialpurpose and others can append to it per thier specific manufacture business requires.
>> you still have what you state as the reason for having it in the base apps, but can be disconnected easily without effecting order flow or products.
>>
>>
>>
>> David E Jones sent the following on 7/20/2010 1:45 PM:
>>>
>>> For my part I think it's good to have manufacturing data structures and services in base applications, and then different types of mfg apps as specialpurpose apps. There are many different types of manufacturing, varying by what is being made, and they can benefit from sharing underlying structures and services.
>>>
>>> -David
>>>
>>>
>>> On Jul 20, 2010, at 2:29 PM, Jacques Le Roux wrote:
>>>
>>>> Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman"<[hidden email]>
>>>>> a matter of perspective.
>>>>> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like ecommerce
>>>>> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
>>>>>
>>>>> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
>>>>> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other vertical
>>>>> markets.
>>>>>
>>>>> David E Jones sent the following on 7/20/2010 9:31 AM:
>>>>>>
>>>>>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>>>>>>
>>>>>> * framework
>>>>>> * applications (base applications)
>>>>>> * specialpurpose (special purpose application)
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>>>>>>
>>>>>>> ofbiz, now has three basic layers, as I see it.
>>>>>>>
>>>>>>> first is the framework, which should stand alone from the other layers.
>>>>>>>
>>>>>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
>>>>>>> interdependence and dependence on the framework.
>>>>>>>
>>>>>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
>>>>>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>>>>>>
>>>>>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different
>>>>>>> than selling products, say retail and takes into different consideration.
>>>>>>>
>>>>>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
>>>>>>> setup module.
>>>>>>> These would be a typical business plan process as described in the SBA.Gov site.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>>>>>>> Having these extensions managed as add-on modules in a separate repository
>>>>>>>> will be beneficial to the OFBiz trunk.
>>>>>>>>
>>>>>>>> I mean that this way of managing extensions will probabily require
>>>>>>>> improvements in the trunk itself to better manage extensions. (i.e.
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>>>>>>
>>>>>>>> Having the extensions in the trunk could generate new dependency problems
>>>>>>>> (like we have now with many of OFBiz components) and will not help setting
>>>>>>>> in place a powerfull, community-wide method of managing extensions.
>>>>>>>>
>>>>>>>> My two cents,
>>>>>>>>
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>>>>>>
>>>>>>>>> Inlne:
>>>>>>>>>
>>>>>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>>>>>>
>>>>>>>>> yes and no.
>>>>>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>>>>>>> trunk to branch that all in the branch work with no.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>>>>>>> repository is
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> effectively a copy of the repo that can be changed separately
>>>>>>>>> that was the intention.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and is meant to eventually be merged back into the trunk.
>>>>>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>>>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>>>>>>> or are they now Forks?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>>>>>>> be a copy of OFBiz that is changed separately,
>>>>>>>>>>
>>>>>>>>> matter of perspective
>>>>>>>>>
>>>>>>>>> but rather a repository for add-on modules.
>>>>>>>>> of course they are addons.
>>>>>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>>>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>>>>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>>>>>>> so why limit it to just those vertical markets. there are many.
>>>>>>>>> By having the trunk brought into the Contributors "section" they would
>>>>>>>>> could access it and pull down everything at once to work with or use.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>>>>>>
>>>>>>>>> the reason to keep it was the ability to move the truck into it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>>>>>>> at the ASF.
>>>>>>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>>>>>>> indicatore, but the PMC would be the deciding vote.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> For those interested, why not just create a sourceforge or google code
>>>>>>>>>> project and share commit access with others who are interested? There is
>>>>>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>>>>>>> that people can't create separate projects to do such things. If various
>>>>>>>>>> people want to work together to do so, from the community spirit
>>>>>>>>>> perspective... all the better!
>>>>>>>>>>
>>>>>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>>>>>>> vertical market.
>>>>>>>>> and it does not stop  any current developer from learning and offering
>>>>>>>>> these.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>>
>>>>>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hans,
>>>>>>>>>>>>
>>>>>>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>>>>>>> would be able to commit to it?
>>>>>>>>>>>>
>>>>>>>>>>>> -David
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>   Shouldn't we do a proof of concept?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>>>>>>> suggestions
>>>>>>>>>>>>> for enhancement.
>>>>>>>>>>>>>
>>>>>>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any comments?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>>>>>>> some of the points are:
>>>>>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>>>>>>> down if they want to work on it.
>>>>>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>>>>>>> contributions.
>>>>>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>>>>>>> elsewhere
>>>>>>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>>>>>>> elsewhere.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>>> contribution to them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>>>>>>> Adrian and
>>>>>>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>>>>>>> been my
>>>>>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>>>>>>> resources.
>>>>>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>>>>>>> mine.
>>>>>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   a product is more of a marketing item
>>>>>>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   [snip]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>

[Adrian Crum]

On 7/20/2010 2:10 PM, David E Jones wrote:
> Unfortunately many committers don't feel it is so important which is why we have hundreds of ridiculous dependencies from the framework to the base apps, from the base apps the special purpose apps, and from one special purpose app to another, and NONE of that should be allowed.

Are you sure many committers don't feel it is important? From my
perspective it seems to be more like a misunderstanding of the
distinction. When bad dependencies are pointed out, most committers fix
them.

> That is why in my effort to right the wrongs of OFBiz with the Moqui framework, the framework will be a SEPARATE PROJECT so that no backwards dependencies are possible.

How is that project going, btw?

> Also, another separate project will be data structures (like the data model resource book, basically the OFBiz data model cleaned up and made more consistent and removing a lot of stuff that isn't used or is a bad idea) and common business-process oriented services (following patterns in OAGIS or something similar). That will be separate from ANY application that an end-user can use.

Data structures without an application - that would be interesting to see.

> IMO going in that direction is necessary because people just don't generally accept how critical it is to organize things well in large software. Drawing certain clear lines like this helps a lot and will make it far easier for those customizing and extending existing artifacts.

Again, this is a generalization that doesn't ring true. I don't know of
any OFBiz developer who is *against* organizing things. Is the
organizational structure you have in mind documented anywhere?

-Adrian

[Matt Warnock]

+1.

Our company sits right at the intersection of two industries,
distribution and manufacturing.  We outsource our manufacturing, but we
still have to manage it quite a bit, and ordering more product requires
printing approved labels, etc.  So in some ways we look more like a
distributor/warehouse with a very small number of SKUs, and in others
more like a rather simple manufacturing operation.  

Silverston does a great job of laying out what both the manufacturing
and distribution business models should include.  But I don't need to
use most of either one.  At some point (far in the future) we may use
more of the manufacturing.  But having the shared data in the entities
means I don't need to worry about whether the distribution set will talk
properly to the manufacturing set, and whether the database structure
that I use now will integrate properly later on as our needs may change.

I probably would not use most of the features of either a distribution
or manufacturing special-purpose app in its entirety, but seamless
integration of both is critical to me.  That's why David's model of
keeping the data structure entities in the core is important, IMHO.

I don't (and probably never will) use time billing, job costing, or POS
features at all, but it certainly doesn't bother me that the data
structures are defined in the core for those whose models will include
those common functions.

Just my 2 cents.

--
Matt Warnock <[hidden email]>
RidgeCrest Herbals, Inc.

On Tue, 2010-07-20 at 15:10 -0600, David E Jones wrote:

> Don't be silly. Manufacturing is not an industry, it is a type of
>  industry. Having shared manufacturing data structures and services and
>  generic screens is just as helpful as having any sort of product or
>  inventory or order handling artifacts.
>
> For shared artifacts the original intent of the organization of the
>  project (which has been watered down by many committers not playing
>  along) is that if specialpurpose applications EVER need to share
>  something, it is probably generic enough to put in a base
>  applications. In other words, as a rule of thumb, special purpose
>  applications should NEVER use something from another special purpose
>  app and if something exists in a special purpose app that another
>  special purpose app could reuse then it should be moved from the first
>  special purpose app to a base application, which is meant to be
>  shared, reused, and built upon.
>
> You can disagree all you want, but without this sort of distinction
>  things would be much more disorganized and difficult to reuse, and the
>  intent of OFBiz is to make things as easy as possible to reuse and
>  extend, so organization is critically important.
>
> Unfortunately many committers don't feel it is so important which is
>  why we have hundreds of ridiculous dependencies from the framework to
>  the base apps, from the base apps the special purpose apps, and from
>  one special purpose app to another, and NONE of that should be
>  allowed. That is why in my effort to right the wrongs of OFBiz with
>  the Moqui framework, the framework will be a SEPARATE PROJECT so that
>  no backwards dependencies are possible. Also, another separate project
>  will be data structures (like the data model resource book, basically
>  the OFBiz data model cleaned up and made more consistent and removing
>  a lot of stuff that isn't used or is a bad idea) and common
>  business-process oriented services (following patterns in OAGIS or
>  something similar). That will be separate from ANY application that an
>  end-user can use.
>
> IMO going in that direction is necessary because people just don't
>  generally accept how critical it is to organize things well in large
>  software. Drawing certain clear lines like this helps a lot and will
>  make it far easier for those customizing and extending existing
>  artifacts.
>
> -David
>
>
> On Jul 20, 2010, at 2:58 PM, BJ Freeman wrote:
>
> > you can use that logic for a lot of industries.
> > it would make ofbiz as a global application unwieldy.
> > so have the manufacturing as it is now part of the specialpurpose and others can append to it per thier specific manufacture business requires.
> > you still have what you state as the reason for having it in the base apps, but can be disconnected easily without effecting order flow or products.
> >
> >
> >
> > David E Jones sent the following on 7/20/2010 1:45 PM:
> >>
> >> For my part I think it's good to have manufacturing data structures and services in base applications, and then different types of mfg apps as specialpurpose apps. There are many different types of manufacturing, varying by what is being made, and they can benefit from sharing underlying structures and services.
> >>
> >> -David
> >>
> >>
> >> On Jul 20, 2010, at 2:29 PM, Jacques Le Roux wrote:
> >>
> >>> Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!
> >>>
> >>> Jacques
> >>>
> >>> From: "BJ Freeman"<[hidden email]>
> >>>> a matter of perspective.
> >>>> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like ecommerce
> >>>> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
> >>>>
> >>>> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
> >>>> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other vertical
> >>>> markets.
> >>>>
> >>>> David E Jones sent the following on 7/20/2010 9:31 AM:
> >>>>>
> >>>>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
> >>>>>
> >>>>> * framework
> >>>>> * applications (base applications)
> >>>>> * specialpurpose (special purpose application)
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
> >>>>>
> >>>>>> ofbiz, now has three basic layers, as I see it.
> >>>>>>
> >>>>>> first is the framework, which should stand alone from the other layers.
> >>>>>>
> >>>>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
> >>>>>> interdependence and dependence on the framework.
> >>>>>>
> >>>>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
> >>>>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
> >>>>>>
> >>>>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is different
> >>>>>> than selling products, say retail and takes into different consideration.
> >>>>>>
> >>>>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
> >>>>>> setup module.
> >>>>>> These would be a typical business plan process as described in the SBA.Gov site.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
> >>>>>>> Having these extensions managed as add-on modules in a separate repository
> >>>>>>> will be beneficial to the OFBiz trunk.
> >>>>>>>
> >>>>>>> I mean that this way of managing extensions will probabily require
> >>>>>>> improvements in the trunk itself to better manage extensions. (i.e.
> >>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
> >>>>>>>
> >>>>>>> Having the extensions in the trunk could generate new dependency problems
> >>>>>>> (like we have now with many of OFBiz components) and will not help setting
> >>>>>>> in place a powerfull, community-wide method of managing extensions.
> >>>>>>>
> >>>>>>> My two cents,
> >>>>>>>
> >>>>>>> -Bruno
> >>>>>>>
> >>>>>>>
> >>>>>>> 2010/7/15 BJ Freeman<[hidden email]>
> >>>>>>>
> >>>>>>>> Inlne:
> >>>>>>>>
> >>>>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> This looks like more of a separate repository than a branch of OFBiz.
> >>>>>>>>>
> >>>>>>>> yes and no.
> >>>>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
> >>>>>>>> trunk to branch that all in the branch work with no.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
> >>>>>>>>> repository is
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> effectively a copy of the repo that can be changed separately
> >>>>>>>> that was the intention.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> and is meant to eventually be merged back into the trunk.
> >>>>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
> >>>>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
> >>>>>>>> or are they now Forks?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
> >>>>>>>>> be a copy of OFBiz that is changed separately,
> >>>>>>>>>
> >>>>>>>> matter of perspective
> >>>>>>>>
> >>>>>>>> but rather a repository for add-on modules.
> >>>>>>>> of course they are addons.
> >>>>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
> >>>>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
> >>>>>>>> services, Insurance and HealthCare are in the vol II of data model book.
> >>>>>>>> so why limit it to just those vertical markets. there are many.
> >>>>>>>> By having the trunk brought into the Contributors "section" they would
> >>>>>>>> could access it and pull down everything at once to work with or use.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
> >>>>>>>>>
> >>>>>>>> the reason to keep it was the ability to move the truck into it.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> if you don't want a vote where PMC votes are binding... that's all there is
> >>>>>>>> at the ASF.
> >>>>>>>> clarification  it was meant to communicate the popular vote is meant as an
> >>>>>>>> indicatore, but the PMC would be the deciding vote.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> For those interested, why not just create a sourceforge or google code
> >>>>>>>>> project and share commit access with others who are interested? There is
> >>>>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
> >>>>>>>>> that people can't create separate projects to do such things. If various
> >>>>>>>>> people want to work together to do so, from the community spirit
> >>>>>>>>> perspective... all the better!
> >>>>>>>>>
> >>>>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
> >>>>>>>> vertical market.
> >>>>>>>> and it does not stop  any current developer from learning and offering
> >>>>>>>> these.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -David
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
> >>>>>>>>>>
> >>>>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Hans,
> >>>>>>>>>>>
> >>>>>>>>>>> How would you create such a branch, or what would that look like? Who
> >>>>>>>>>>> would be able to commit to it?
> >>>>>>>>>>>
> >>>>>>>>>>> -David
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>  Shouldn't we do a proof of concept?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
> >>>>>>>>>>>> everyone who would like to contribute. When the people on this branch
> >>>>>>>>>>>> say they are ready we can judge what is there and/or provide
> >>>>>>>>>>>> suggestions
> >>>>>>>>>>>> for enhancement.
> >>>>>>>>>>>>
> >>>>>>>>>>>> After general consensus the branch will be merged into the trunk.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Any comments?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards,
> >>>>>>>>>>>> Hans
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I am writing a proposal for Contributors branch.
> >>>>>>>>>>>>>> some of the points are:
> >>>>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
> >>>>>>>>>>>>>> move to the contributors branch till interest is renewed.
> >>>>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
> >>>>>>>>>>>>>> down if they want to work on it.
> >>>>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
> >>>>>>>>>>>>>> contributions.
> >>>>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
> >>>>>>>>>>>>>> trunk.
> >>>>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
> >>>>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
> >>>>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
> >>>>>>>>>>>>>> elsewhere
> >>>>>>>>>>>>>> why not do the same for Hippo.
> >>>>>>>>>>>>>> I would be interested in your reasons why besides it can be
> >>>>>>>>>>>>>> elsewhere.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> What need would contributor branches meet that can't already be met
> >>>>>>>>>>>>>>> using the likes of sourceforge, google code or github?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
> >>>>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
> >>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
> >>>>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
> >>>>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
> >>>>>>>>>>>>>>> own
> >>>>>>>>>>>>>>> contribution to them.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>> Scott
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>  I have the same opinion as you BJ, even as a committer it is too
> >>>>>>>>>>>>>>>> much
> >>>>>>>>>>>>>>>> problem contributing because of the number of technical people in
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
> >>>>>>>>>>>>>>>> system
> >>>>>>>>>>>>>>>> technically as difficult as possible.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
> >>>>>>>>>>>>>>>> Adrian and
> >>>>>>>>>>>>>>>> me is a good example.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
> >>>>>>>>>>>>>>>> PMC
> >>>>>>>>>>>>>>>> members who would support this?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
> >>>>>>>>>>>>>>>> know
> >>>>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>> Hans
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
> >>>>>>>>>>>>>>>>> been my
> >>>>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
> >>>>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
> >>>>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
> >>>>>>>>>>>>>>>>> resources.
> >>>>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
> >>>>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
> >>>>>>>>>>>>>>>>> mine.
> >>>>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
> >>>>>>>>>>>>>>>>> Current Hippo branch.
> >>>>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
> >>>>>>>>>>>>>>>>> would be
> >>>>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
> >>>>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
> >>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>> the same as the one I have.
> >>>>>>>>>>>>>>>>> Note my first major move to accomplish this
> >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>  a product is more of a marketing item
> >>>>>>>>>>>>>>>>>>> a part is a description of a function
> >>>>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
> >>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
> >>>>>>>>>>>>>>>>>>> list
> >>>>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
> >>>>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
> >>>>>>>>>>>>>>>>>>> and more extensive model.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
> >>>>>>>>>>>>>>>>>> Please
> >>>>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
> >>>>>>>>>>>>>>>>>> list, not your derivative of it.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>>> Scott
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> HotWax Media
> >>>>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>  I wish to be able to have our engineers link plans to parts
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> =========================
> >>>>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>  [snip]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
> >>>>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
> >>>>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
> >>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
> >>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>

[Jacques Le Roux]

Yes, that sounds even better, still a lot of work though....

Jacques

From: "David E Jones" <[hidden email]>

> For my part I think it's good to have manufacturing data structures and services in base applications, and then different types of
> mfg apps as specialpurpose apps. There are many different types of manufacturing, varying by what is being made, and they can
> benefit from sharing underlying structures and services.
>
> -David
>
>
> On Jul 20, 2010, at 2:29 PM, Jacques Le Roux wrote:
>
>> Sounds logical, but I guess history will not permit us to do that, or as you said with a rather big effort!
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> a matter of perspective.
>>> manufacturing is a unique industry and being in the base applications, does not meet the definition I stated. Just like
>>> ecommerce
>>> got moved to specialpurposes so should manufacturing to meet the criteria I stated.
>>>
>>> this would require a large re-factoring having to do with orders, and products, so I doubt it will be done.
>>> however by taking Manufacturing out of the basic apps and the order flow would make for a cleaner way to implement other
>>> vertical
>>> markets.
>>>
>>> David E Jones sent the following on 7/20/2010 9:31 AM:
>>>>
>>>> This is pretty much how OFBiz has been organized for a long time. These three layers are in the following directories:
>>>>
>>>> * framework
>>>> * applications (base applications)
>>>> * specialpurpose (special purpose application)
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jul 16, 2010, at 12:07 PM, BJ Freeman wrote:
>>>>
>>>>> ofbiz, now has three basic layers, as I see it.
>>>>>
>>>>> first is the framework, which should stand alone from the other layers.
>>>>>
>>>>> Next is your basic Business layer needed for all businesses, to manage relationships, cash flow, products. This level can have
>>>>> interdependence and dependence on the framework.
>>>>>
>>>>> the top layer is the type of business one has, manufacturing, Ecommerce, Travel. these don't really depended on each other,
>>>>> unless you have a multidivisional organization and are driven by different Business plans as to how to implement.
>>>>>
>>>>> True the Data model of manufacturing has some that lend itself to products, but the manufacturing industry as such is
>>>>> different
>>>>> than selling products, say retail and takes into different consideration.
>>>>>
>>>>> I can see the benefit of having the auto integration of the toplevel addons by your means, as well as added setup setup in the
>>>>> setup module.
>>>>> These would be a typical business plan process as described in the SBA.Gov site.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bruno Busco sent the following on 7/15/2010 10:51 PM:
>>>>>> Having these extensions managed as add-on modules in a separate repository
>>>>>> will be beneficial to the OFBiz trunk.
>>>>>>
>>>>>> I mean that this way of managing extensions will probabily require
>>>>>> improvements in the trunk itself to better manage extensions. (i.e.
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3373)
>>>>>>
>>>>>> Having the extensions in the trunk could generate new dependency problems
>>>>>> (like we have now with many of OFBiz components) and will not help setting
>>>>>> in place a powerfull, community-wide method of managing extensions.
>>>>>>
>>>>>> My two cents,
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2010/7/15 BJ Freeman<[hidden email]>
>>>>>>
>>>>>>> Inlne:
>>>>>>>
>>>>>>> David E Jones sent the following on 7/15/2010 10:39 AM:
>>>>>>>
>>>>>>>
>>>>>>>> This looks like more of a separate repository than a branch of OFBiz.
>>>>>>>>
>>>>>>> yes and no.
>>>>>>> since it would usually not be merged back to ofbiz, yes, being able to sync
>>>>>>> trunk to branch that all in the branch work with no.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> First off, the term "branch" just doesn't apply. A branch of a source
>>>>>>>> repository is
>>>>>>>>
>>>>>>>
>>>>>>> effectively a copy of the repo that can be changed separately
>>>>>>> that was the intention.
>>>>>>>
>>>>>>>
>>>>>>> and is meant to eventually be merged back into the trunk.
>>>>>>> If a branch is not meant to be merged back into the trunk, it is a fork.
>>>>>>> So version 4.0 9.04, 10.4 will be merged back to the trunk?
>>>>>>> or are they now Forks?
>>>>>>>
>>>>>>>
>>>>>>>> What you're describing isn't even a fork as it doesn't sound like it would
>>>>>>>> be a copy of OFBiz that is changed separately,
>>>>>>>>
>>>>>>> matter of perspective
>>>>>>>
>>>>>>> but rather a repository for add-on modules.
>>>>>>> of course they are addons.
>>>>>>> for instance the manufacturing, travel and Eccommerce would be defined as
>>>>>>> addon, Just as the finacial Services, telecommunication, Proffiessional
>>>>>>> services, Insurance and HealthCare are in the vol II of data model book.
>>>>>>> so why limit it to just those vertical markets. there are many.
>>>>>>> By having the trunk brought into the Contributors "section" they would
>>>>>>> could access it and pull down everything at once to work with or use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Also, it sounds like it would best be done outside of the ASF, especially
>>>>>>>>
>>>>>>> the reason to keep it was the ability to move the truck into it.
>>>>>>>
>>>>>>>
>>>>>>> if you don't want a vote where PMC votes are binding... that's all there is
>>>>>>> at the ASF.
>>>>>>> clarification  it was meant to communicate the popular vote is meant as an
>>>>>>> indicatore, but the PMC would be the deciding vote.
>>>>>>>
>>>>>>>
>>>>>>>> For those interested, why not just create a sourceforge or google code
>>>>>>>> project and share commit access with others who are interested? There is
>>>>>>>> nothing that says OFBiz add-on modules have to be part of the project, or
>>>>>>>> that people can't create separate projects to do such things. If various
>>>>>>>> people want to work together to do so, from the community spirit
>>>>>>>> perspective... all the better!
>>>>>>>>
>>>>>>> it also gives ofbiz a greater appeal to the users that may use ofbiz in a
>>>>>>> vertical market.
>>>>>>> and it does not stop  any current developer from learning and offering
>>>>>>> these.
>>>>>>>
>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 15, 2010, at 10:11 AM, BJ Freeman wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>
>>>>>>>>> David E Jones sent the following on 7/15/2010 9:03 AM:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hans,
>>>>>>>>>>
>>>>>>>>>> How would you create such a branch, or what would that look like? Who
>>>>>>>>>> would be able to commit to it?
>>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 15, 2010, at 2:59 AM, Hans Bakker wrote:
>>>>>>>>>>
>>>>>>>>>>  Shouldn't we do a proof of concept?
>>>>>>>>>>>
>>>>>>>>>>> I will volunteer to create and update a new branch for BJ to start and
>>>>>>>>>>> everyone who would like to contribute. When the people on this branch
>>>>>>>>>>> say they are ready we can judge what is there and/or provide
>>>>>>>>>>> suggestions
>>>>>>>>>>> for enhancement.
>>>>>>>>>>>
>>>>>>>>>>> After general consensus the branch will be merged into the trunk.
>>>>>>>>>>>
>>>>>>>>>>> Any comments?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Hans
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, 2010-07-10 at 18:21 -0700, BJ Freeman wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributors+Branch+proposal
>>>>>>>>>>>>
>>>>>>>>>>>> BJ Freeman sent the following on 7/9/2010 11:07 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>> I am writing a proposal for Contributors branch.
>>>>>>>>>>>>> some of the points are:
>>>>>>>>>>>>> 1)components not continued to be supported in the specialpurpose get
>>>>>>>>>>>>> move to the contributors branch till interest is renewed.
>>>>>>>>>>>>> this would simplify maintaining the trunk but allow people to pull it
>>>>>>>>>>>>> down if they want to work on it.
>>>>>>>>>>>>> 2)there is no guarantee of the ofbiz community support of the
>>>>>>>>>>>>> contributions.
>>>>>>>>>>>>> 3)people can test the contribution and may vote to include it in the
>>>>>>>>>>>>> trunk.
>>>>>>>>>>>>> 4)it gives one place to make sure all contributions are integrated
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the latest trunk and each other without effecting the trunk.
>>>>>>>>>>>>>
>>>>>>>>>>>>> it puzzles me that it is ok open a branch to collorate, but when
>>>>>>>>>>>>> opportunity to have a lot of contributions avalible that would spread
>>>>>>>>>>>>> Ofbiz acceptance you bulk. under you logic that it can be done
>>>>>>>>>>>>> elsewhere
>>>>>>>>>>>>> why not do the same for Hippo.
>>>>>>>>>>>>> I would be interested in your reasons why besides it can be
>>>>>>>>>>>>> elsewhere.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 10:27 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What need would contributor branches meet that can't already be met
>>>>>>>>>>>>>> using the likes of sourceforge, google code or github?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding your other statements, at some point Hans you are going to
>>>>>>>>>>>>>> need to ask yourself why it is mostly only your commits that cause
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> much negative discussion. Everyone else seems to work together just
>>>>>>>>>>>>>> fine for the most part. I'm not saying it's all your fault but you
>>>>>>>>>>>>>> can't just blame everyone else for these problems and ignore your
>>>>>>>>>>>>>> own
>>>>>>>>>>>>>> contribution to them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/07/2010, at 2:54 PM, Hans Bakker wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  I have the same opinion as you BJ, even as a committer it is too
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>> problem contributing because of the number of technical people in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> PMC which often only judge on technical qualities and making the
>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>> technically as difficult as possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The current discussion (not really sure if it is one) between
>>>>>>>>>>>>>>> Adrian and
>>>>>>>>>>>>>>> me is a good example.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think it would be a good idea to have contributor branches. Other
>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>> members who would support this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To be honest i think that you should try to become a committer, i
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>> why you did not accept in the past, but please reconsider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, 2010-07-09 at 18:33 -0700, BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> my goal has always been to have this ofbiz do this. it has never
>>>>>>>>>>>>>>>> been my
>>>>>>>>>>>>>>>> intent to have a seperate ofbiz. Nor am I promoting mine.
>>>>>>>>>>>>>>>> my problem up to now has been acceptance and resources.
>>>>>>>>>>>>>>>> I see the winds changing on acceptance and I have gotten the
>>>>>>>>>>>>>>>> resources.
>>>>>>>>>>>>>>>> if you note I suggest years ago to have contributor branches.
>>>>>>>>>>>>>>>> Had that happened I would have contributed to it instead of create
>>>>>>>>>>>>>>>> mine.
>>>>>>>>>>>>>>>> I see the equivalent of contributor branch happening more like the
>>>>>>>>>>>>>>>> Current Hippo branch.
>>>>>>>>>>>>>>>> so if someone wants to open a branch I can just submit to, it
>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>> faster, however i am happy to provide Jiras.
>>>>>>>>>>>>>>>> so if the Jiras I put patches in are accepted then the ofbiz will
>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>> the same as the one I have.
>>>>>>>>>>>>>>>> Note my first major move to accomplish this
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3852
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/9/2010 5:18 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/07/2010, at 1:06 AM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  a product is more of a marketing item
>>>>>>>>>>>>>>>>>> a part is a description of a function
>>>>>>>>>>>>>>>>>> they vary for engineering and manufacturing. Engineering does
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> assign a commercial product to the part where manufacture may
>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>> many actual purchase parts that will never be sold individually.
>>>>>>>>>>>>>>>>>> I see in the model book the one I implemented is the alternative
>>>>>>>>>>>>>>>>>> and more extensive model.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Congratulations, where can I download a copy of this BJBiz?
>>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>>> try and keep in mind that we are discussing OFBiz in this mailing
>>>>>>>>>>>>>>>>> list, not your derivative of it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:53 PM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In OFBiz a Part is a Product, so what is your point?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> HotWax Media
>>>>>>>>>>>>>>>>>>> http://www.hotwaxmedia.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/07/2010, at 12:16 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> =========================
>>>>>>>>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  [snip]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> BTW your quoting is terrible, I never made the statement below
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Scott Gray sent the following on 7/5/2010 5:02 PM:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I wish to be able to have our engineers link plans to parts
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ofbiz on twitter: http://twitter.com/apache_ofbiz
>>>>>>>>>>> Myself on twitter: http://twitter.com/hansbak
>>>>>>>>>>> Antwebsystems.com: Quality services for competitive rates.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>

[BJ Freeman]

Matt:
  from a users perspective it would not be any different.

However from a developers perspective, if the manufacturing is of no
use, like in a retail outlet, then it should be able to be  deactivated
with no ill effect to the base applications.

Matt Warnock sent the following on 7/20/2010 2:47 PM:

> +1.
>
> Our company sits right at the intersection of two industries,
> distribution and manufacturing.  We outsource our manufacturing, but we
> still have to manage it quite a bit, and ordering more product requires
> printing approved labels, etc.  So in some ways we look more like a
> distributor/warehouse with a very small number of SKUs, and in others
> more like a rather simple manufacturing operation.
>
> Silverston does a great job of laying out what both the manufacturing
> and distribution business models should include.  But I don't need to
> use most of either one.  At some point (far in the future) we may use
> more of the manufacturing.  But having the shared data in the entities
> means I don't need to worry about whether the distribution set will talk
> properly to the manufacturing set, and whether the database structure
> that I use now will integrate properly later on as our needs may change.
>
> I probably would not use most of the features of either a distribution
> or manufacturing special-purpose app in its entirety, but seamless
> integration of both is critical to me.  That's why David's model of
> keeping the data structure entities in the core is important, IMHO.
>
> I don't (and probably never will) use time billing, job costing, or POS
> features at all, but it certainly doesn't bother me that the data
> structures are defined in the core for those whose models will include
> those common functions.
>
> Just my 2 cents.
>

[David E. Jones-2]

That is an interesting argument, but complicated to solve. You should be able to disable the manufacturing manager app without affecting other apps. You should even be able to get rid of the services, if no other component is calling them (I don't know about that). Getting rid of the data model is more difficult as there is more chance of dependency, and you'll have a nice graph of foreign keys to deal with.

In a way it would be nice to remove any part of the data model and have things "gracefully degrade", but that would require a lot of work, and a lot more clear definition of how entities are grouped, and possibly the need to change how entities are grouped based on sets of entities most commonly used in different circumstances. Anyway, there are lots of things people would like to remove. Sometimes it's accounting, sometimes not just manufacturing but also all types of WorkEffort (projects, tasks, etc), or perhaps they only want to use warehouse and shipping management and they don't want to track orders or anything. You could probably come up with thousands of subsets of the entities that would make good sense to use separately from the rest.

-David


On Jul 20, 2010, at 6:11 PM, BJ Freeman wrote:

> Matt:
> from a users perspective it would not be any different.
>
> However from a developers perspective, if the manufacturing is of no use, like in a retail outlet, then it should be able to be  deactivated with no ill effect to the base applications.
>
> Matt Warnock sent the following on 7/20/2010 2:47 PM:
>> +1.
>>
>> Our company sits right at the intersection of two industries,
>> distribution and manufacturing.  We outsource our manufacturing, but we
>> still have to manage it quite a bit, and ordering more product requires
>> printing approved labels, etc.  So in some ways we look more like a
>> distributor/warehouse with a very small number of SKUs, and in others
>> more like a rather simple manufacturing operation.
>>
>> Silverston does a great job of laying out what both the manufacturing
>> and distribution business models should include.  But I don't need to
>> use most of either one.  At some point (far in the future) we may use
>> more of the manufacturing.  But having the shared data in the entities
>> means I don't need to worry about whether the distribution set will talk
>> properly to the manufacturing set, and whether the database structure
>> that I use now will integrate properly later on as our needs may change.
>>
>> I probably would not use most of the features of either a distribution
>> or manufacturing special-purpose app in its entirety, but seamless
>> integration of both is critical to me.  That's why David's model of
>> keeping the data structure entities in the core is important, IMHO.
>>
>> I don't (and probably never will) use time billing, job costing, or POS
>> features at all, but it certainly doesn't bother me that the data
>> structures are defined in the core for those whose models will include
>> those common functions.
>>
>> Just my 2 cents.
>>

[David E. Jones-2]

On Jul 20, 2010, at 3:40 PM, Adrian Crum wrote:

> On 7/20/2010 2:10 PM, David E Jones wrote:
>> Unfortunately many committers don't feel it is so important which is why we have hundreds of ridiculous dependencies from the framework to the base apps, from the base apps the special purpose apps, and from one special purpose app to another, and NONE of that should be allowed.
>
> Are you sure many committers don't feel it is important? From my perspective it seems to be more like a misunderstanding of the distinction. When bad dependencies are pointed out, most committers fix them.

You got me, I don't really know how many committers feel. I was guessing at feelings based on actions, which I agree is not a good way to go, kind of like guessing motives based on actions. In general though, if it were considered more important I would expect more discussion of it and more research and effort into proposals, and at least more research into understanding what has already been discussed and where the ideas came from (searching the mailing lists for "specialpurpose" perhaps).

>> That is why in my effort to right the wrongs of OFBiz with the Moqui framework, the framework will be a SEPARATE PROJECT so that no backwards dependencies are possible.
>
> How is that project going, btw?

For now it's not going, I have better things to do while the weather is good (or of a higher priority for now). I'll probably get back around to it as things get colder, or as I finish some of these other projects, or if I can't find work and it's too hot outside or something. ;)

>> Also, another separate project will be data structures (like the data model resource book, basically the OFBiz data model cleaned up and made more consistent and removing a lot of stuff that isn't used or is a bad idea) and common business-process oriented services (following patterns in OAGIS or something similar). That will be separate from ANY application that an end-user can use.
>
> Data structures without an application - that would be interesting to see.

Yeah, I wouldn't have tried that years ago before getting into OFBiz, but now I think a project that is just data structures and service definitions (and perhaps some service implementations), all as standards-friendly as possible (ie ability to map various standards to them), would be a great project and based on all of the real-world input that has gone into the OFBiz data model it should be pretty doable now.

>> IMO going in that direction is necessary because people just don't generally accept how critical it is to organize things well in large software. Drawing certain clear lines like this helps a lot and will make it far easier for those customizing and extending existing artifacts.
>
> Again, this is a generalization that doesn't ring true. I don't know of any OFBiz developer who is *against* organizing things. Is the organizational structure you have in mind documented anywhere?

I didn't say anyone was against organizing things, just that they don't place a very high priority on it. And yes, the general organization and guidelines for dependencies have been both discussed on the mailing list, and are documented on cwiki (and have been for years).

-David

[Matt Warnock]

I understand that.  But Dave's point (if I understood his post
correctly) was that the separation into modules was in fact made at the
application level, not the database level.  All the entities, their
storage mechanisms, and data translation code for those, are defined in
the base.

Keeping the database layer intact in the base reduces the likelihood of
incompatible design and interface between competing and/or cooperating
modules.  The user interface is easy to change, but keeping the database
design 1) monolithic and 2) close to Silverston serves to keep the whole
project design cohesive.  I think those goals are more important than
complete modularity.  

Of course, there could be a solid middle ground, where the entities are
defined in the base, but only actually *created* if the modules that use
them are being built.  That way a DBM administrator would not have to
rifle through empty tables.  However, that might also tempt people to
assume what tables are or are not in use, and make conflicting design
decisions.  This at least forces people to understand the
Silverston-based OFBiz best practices model.  

--
Matt Warnock <[hidden email]>
RidgeCrest Herbals, Inc.

On Tue, 2010-07-20 at 17:11 -0700, BJ Freeman wrote:

> Matt:
>   from a users perspective it would not be any different.
>
> However from a developers perspective, if the manufacturing is of no
> use, like in a retail outlet, then it should be able to be  deactivated
> with no ill effect to the base applications.
>
> Matt Warnock sent the following on 7/20/2010 2:47 PM:
> > +1.
> >
> > Our company sits right at the intersection of two industries,
> > distribution and manufacturing.  We outsource our manufacturing, but we
> > still have to manage it quite a bit, and ordering more product requires
> > printing approved labels, etc.  So in some ways we look more like a
> > distributor/warehouse with a very small number of SKUs, and in others
> > more like a rather simple manufacturing operation.
> >
> > Silverston does a great job of laying out what both the manufacturing
> > and distribution business models should include.  But I don't need to
> > use most of either one.  At some point (far in the future) we may use
> > more of the manufacturing.  But having the shared data in the entities
> > means I don't need to worry about whether the distribution set will talk
> > properly to the manufacturing set, and whether the database structure
> > that I use now will integrate properly later on as our needs may change.
> >
> > I probably would not use most of the features of either a distribution
> > or manufacturing special-purpose app in its entirety, but seamless
> > integration of both is critical to me.  That's why David's model of
> > keeping the data structure entities in the core is important, IMHO.
> >
> > I don't (and probably never will) use time billing, job costing, or POS
> > features at all, but it certainly doesn't bother me that the data
> > structures are defined in the core for those whose models will include
> > those common functions.
> >
> > Just my 2 cents.
> >

[BJ Freeman]

my orginal statement that got this part of the thread going was
 >ofbiz, now has three basic layers, as I see it.
 >
 > first is the framework, which should stand alone from the other layers.
 >
 > Next is your basic Business layer needed for all businesses, to
manage relationships, cash flow, products. This level can have
interdependence and dependence on the framework.
 >
 > the top layer is the type of business one has, manufacturing,
Ecommerce, Travel. these don't really depended on each other, unless you
have a multidivisional organization and are driven by different Business
plans as to how to implement.
 >


Matt Warnock sent the following on 7/20/2010 5:52 PM:

> I understand that.  But Dave's point (if I understood his post
> correctly) was that the separation into modules was in fact made at the
> application level, not the database level.  All the entities, their
> storage mechanisms, and data translation code for those, are defined in
> the base.
>
> Keeping the database layer intact in the base reduces the likelihood of
> incompatible design and interface between competing and/or cooperating
> modules.  The user interface is easy to change, but keeping the database
> design 1) monolithic and 2) close to Silverston serves to keep the whole
> project design cohesive.  I think those goals are more important than
> complete modularity.
>
> Of course, there could be a solid middle ground, where the entities are
> defined in the base, but only actually *created* if the modules that use
> them are being built.  That way a DBM administrator would not have to
> rifle through empty tables.  However, that might also tempt people to
> assume what tables are or are not in use, and make conflicting design
> decisions.  This at least forces people to understand the
> Silverston-based OFBiz best practices model.
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> That is an interesting argument, but complicated to solve. You should be able to disable the manufacturing manager app without
> affecting other apps. You should even be able to get rid of the services, if no other component is calling them (I don't know
> about that).

Not quite sure about that too, but there is clearly a (maybe indirectly from workeffort through ROU_TASK) dependence from this demo
data DemoConfigurator.xml, hence from any AGGREGATED Product. I don't say it's bad, only that it exists.

Jacques

Getting rid of the data model is more difficult as there is more chance of dependency, and you'll have a nice graph of foreign keys
to deal with.

>
> In a way it would be nice to remove any part of the data model and have things "gracefully degrade", but that would require a lot
> of work, and a lot more clear definition of how entities are grouped, and possibly the need to change how entities are grouped
> based on sets of entities most commonly used in different circumstances. Anyway, there are lots of things people would like to
> remove. Sometimes it's accounting, sometimes not just manufacturing but also all types of WorkEffort (projects, tasks, etc), or
> perhaps they only want to use warehouse and shipping management and they don't want to track orders or anything. You could
> probably come up with thousands of subsets of the entities that would make good sense to use separately from the rest.
>
> -David
>
>
> On Jul 20, 2010, at 6:11 PM, BJ Freeman wrote:
>
>> Matt:
>> from a users perspective it would not be any different.
>>
>> However from a developers perspective, if the manufacturing is of no use, like in a retail outlet, then it should be able to be
>> deactivated with no ill effect to the base applications.
>>
>> Matt Warnock sent the following on 7/20/2010 2:47 PM:
>>> +1.
>>>
>>> Our company sits right at the intersection of two industries,
>>> distribution and manufacturing.  We outsource our manufacturing, but we
>>> still have to manage it quite a bit, and ordering more product requires
>>> printing approved labels, etc.  So in some ways we look more like a
>>> distributor/warehouse with a very small number of SKUs, and in others
>>> more like a rather simple manufacturing operation.
>>>
>>> Silverston does a great job of laying out what both the manufacturing
>>> and distribution business models should include.  But I don't need to
>>> use most of either one.  At some point (far in the future) we may use
>>> more of the manufacturing.  But having the shared data in the entities
>>> means I don't need to worry about whether the distribution set will talk
>>> properly to the manufacturing set, and whether the database structure
>>> that I use now will integrate properly later on as our needs may change.
>>>
>>> I probably would not use most of the features of either a distribution
>>> or manufacturing special-purpose app in its entirety, but seamless
>>> integration of both is critical to me.  That's why David's model of
>>> keeping the data structure entities in the core is important, IMHO.
>>>
>>> I don't (and probably never will) use time billing, job costing, or POS
>>> features at all, but it certainly doesn't bother me that the data
>>> structures are defined in the core for those whose models will include
>>> those common functions.
>>>
>>> Just my 2 cents.
>>>
>