Re: Component locations (was: Contributor branch Proposal)

[Adrian Crum <ad...@hlmksw.com>]

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

Re: Component locations (was: Contributor branch Proposal)

[David E Jones <de...@me.com>]

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