Re: Compoinent locatinos was Contributor branch Proposal,

[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"<bjf...@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<bjf...@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.