ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BJ Freeman <bjf...@free-man.net>
Subject Re: Compoinent locatinos was Contributor branch Proposal,
Date Tue, 20 Jul 2010 21:24:56 GMT
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"<bjfree@free-man.net>
>>>>> 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<bjfree@free-man.net>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>

Mime
View raw message