what a mess! is framework independence ever going to be possible?

[Christopher Snow <sn...@snowconsulting.co.uk>]

I'm back to the process of working out how to get a standalone framework 
running based on trunk, but I have found that the dependencies have got 
out of hand (if I've understood the code right):

Framework  depends on Themes
Themes depends on Content
Content depends on Party

The questions I'm starting to ask myself are:

"Is is ever going to be possible to have framework independence in 
trunk?  Independence in 9.04 is relatively trivial (rewrite security 
screens) perhaps the most sensible thing would be to do a fork of 9.04 
and then back port all framework related commits from trunk? "

Any ideas anyone?

Many thanks,

Chris

Re: what a mess! is framework independence ever going to be possible?

[Bruno Busco <br...@gmail.com>]

Chris,
I think we have not moved very forward.
We still have at least this page:

http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution

and the page you have written:

http://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework

some comments in the DEV ML and not much more.

I am ready to restart!
I suggest to collect here:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution

all the points we are able to agree and then start with the implementation.

-Bruno

2010/2/6 Christopher Snow <sn...@snowconsulting.co.uk>:
> Hi Bruno,
>
> What are the current points of view on what should be included in the
> framework?
>
> Many thanks,
>
> Chris
>
> Bruno Busco wrote:
>>
>> This is something we discussed in the DEV ML:
>> http://www.mail-archive.com/dev@ofbiz.apache.org/msg36156.html
>>
>> -Bruno
>>
>> 2010/2/6 Adrian Crum <ad...@yahoo.com>:
>>
>>>
>>> Yes, follow Jacopo's suggestion: create an ant task to build framework
>>> only, then "run the framework only"
>>>
>>> *shrug* I don't know what that means.
>>>
>>> Maybe have a Selenium task that checks to see if it actually runs on its
>>> own.
>>>
>>> I'm not real clear on how that would work, but it would definitely be
>>> worth a try!
>>>
>>> -Adrian
>>>
>>>
>
>

Re: what a mess! is framework independence ever going to be possible?

[Christopher Snow <sn...@snowconsulting.co.uk>]

Hi Bruno,

What are the current points of view on what should be included in the 
framework?

Many thanks,

Chris

Bruno Busco wrote:
> This is something we discussed in the DEV ML:
> http://www.mail-archive.com/dev@ofbiz.apache.org/msg36156.html
>
> -Bruno
>
> 2010/2/6 Adrian Crum <ad...@yahoo.com>:
>   
>> Yes, follow Jacopo's suggestion: create an ant task to build framework only, then "run the framework only"
>>
>> *shrug* I don't know what that means.
>>
>> Maybe have a Selenium task that checks to see if it actually runs on its own.
>>
>> I'm not real clear on how that would work, but it would definitely be worth a try!
>>
>> -Adrian
>>
>>     

Re: what a mess! is framework independence ever going to be possible?

[Bruno Busco <br...@gmail.com>]

This is something we discussed in the DEV ML:
http://www.mail-archive.com/dev@ofbiz.apache.org/msg36156.html

-Bruno

2010/2/6 Adrian Crum <ad...@yahoo.com>:
> Yes, follow Jacopo's suggestion: create an ant task to build framework only, then "run the framework only"
>
> *shrug* I don't know what that means.
>
> Maybe have a Selenium task that checks to see if it actually runs on its own.
>
> I'm not real clear on how that would work, but it would definitely be worth a try!
>
> -Adrian
>
> --- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk> wrote:
>
>> From: Chris Snow <sn...@snowconsulting.co.uk>
>> Subject: Re: what a mess! is framework independence ever going to be           possible?
>> To: user@ofbiz.apache.org
>> Date: Saturday, February 6, 2010, 12:49 AM
>> Shall I raise a jira for this? Is
>> there any documentation on the build and
>> test process for ofbiz? e.g. does buildbot run ofbiz and
>> run any tests?
>>
>> > We can probably start with something simple: add an
>> ant task that simply
>> > builds the framework (applications and specialpurpose
>> will be ignored) and
>> > then an ant task to run the framework only.
>> > This will require some minor tweaks to the base
>> component loading
>> > mechanism, but it should be trivial. Right now the
>> only way (I am aware
>> > of) of building a framework only distro is to remove
>> (or similar) the
>> > application and specialpurpose folders.
>> >
>> > Jacopo
>> >
>> >
>> > On Feb 6, 2010, at 9:09 AM, Adrian Crum wrote:
>> >
>> >> A tool would certainly help. If such a tool was
>> included in OFBiz, then
>> >> it would have to be compatible with the Apache
>> license.
>> >>
>> >> -Adrian
>> >>
>> >> --- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk>
>> wrote:
>> >>
>> >>> From: Chris Snow <sn...@snowconsulting.co.uk>
>> >>> Subject: Re: what a mess! is framework
>> independence ever going to be
>> >>>   possible?
>> >>> To: user@ofbiz.apache.org
>> >>> Date: Saturday, February 6, 2010, 12:02 AM
>> >>> Thanks for the feedback Adrian.
>> >>> Would it be worth me writing a tool that
>> >>> runs as part of the build process that reports
>> on the
>> >>> dependencies?  It
>> >>> could throw a warning/error when a new invalid
>> dependency
>> >>> is checked in?
>> >>>
>> >>>> Chris,
>> >>>>
>> >>>> Framework independence has been a goal for
>> quite a
>> >>> while. There is no
>> >>>> disagreement that the framework should run
>> on its own.
>> >>> The disagreements
>> >>>> arise in what constitutes the framework.
>> >>>>
>> >>>> Let's assume for a moment that framework
>> independence
>> >>> means running the
>> >>>> components in the framework folder
>> independently from
>> >>> anything else in
>> >>>> OFBiz. Right away the problem with that
>> idea is that
>> >>> visual themes are in
>> >>>> a separate folder outside the framework
>> folder. Does
>> >>> framework
>> >>>> independence include the visual themes
>> folder? That
>> >>> has not been
>> >>>> discussed. Then there are the multitude
>> of
>> >>> dependencies upon the
>> >>>> applications folder.
>> >>>>
>> >>>> From my perspective, achieving this
>> objective will
>> >>> require a two pronged
>> >>>> approach: 1) Identify the framework
>> dependencies on
>> >>> outside components,
>> >>>> and 2) avoid introducing new framework
>> dependencies on
>> >>> outside components.
>> >>>>
>> >>>> The first prong can be accomplished
>> through
>> >>> contributions from people like
>> >>>> you - find the dependencies and create
>> patches to fix
>> >>> them.
>> >>>>
>> >>>> The responsibility of the second prong is
>> up to the
>> >>> committers. We need to
>> >>>> be more vigilant to guard against
>> introducing new
>> >>> dependencies.
>> >>>>
>> >>>> Personally I believe it will be possible,
>> BUT it won't
>> >>> be easy. The
>> >>>> obstacles to overcome will be getting
>> people to
>> >>> contribute to the effort,
>> >>>> and getting committers to avoid
>> introducing new
>> >>> dependencies.
>> >>>>
>> >>>> -Adrian
>> >>>>
>> >>>>
>> >>>> --- On Fri, 2/5/10, Christopher Snow
>> <sn...@snowconsulting.co.uk>
>> >>> wrote:
>> >>>>
>> >>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>> >>>>> Subject: what a mess! is framework
>> independence
>> >>> ever going to be
>> >>>>> possible?
>> >>>>> To: user@ofbiz.apache.org
>> >>>>> Date: Friday, February 5, 2010, 10:58
>> PM
>> >>>>> I'm back to the process of working
>> >>>>> out how to get a standalone framework
>> running
>> >>> based on
>> >>>>> trunk, but I have found that the
>> dependencies have
>> >>> got out
>> >>>>> of hand (if I've understood the code
>> right):
>> >>>>>
>> >>>>> Framework  depends on Themes
>> >>>>> Themes depends on Content
>> >>>>> Content depends on Party
>> >>>>>
>> >>>>> The questions I'm starting to ask
>> myself are:
>> >>>>>
>> >>>>> "Is is ever going to be possible to
>> have
>> >>> framework
>> >>>>> independence in trunk?
>> Independence in 9.04 is
>> >>>>> relatively trivial (rewrite security
>> screens)
>> >>> perhaps the
>> >>>>> most sensible thing would be to do a
>> fork of 9.04
>> >>> and then
>> >>>>> back port all framework related
>> commits from
>> >>> trunk? "
>> >>>>>
>> >>>>> Any ideas anyone?
>> >>>>>
>> >>>>> Many thanks,
>> >>>>>
>> >>>>> Chris
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt)
>> (Open) CISSP
>> >>>
>> >>> Tel: 01453 890660
>> >>> Mob: 07944 880950
>> >>> Www: www.snowconsulting.co.uk
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>>
>> Tel: 01453 890660
>> Mob: 07944 880950
>> Www: www.snowconsulting.co.uk
>>
>>
>
>
>
>

Re: what a mess! is framework independence ever going to be possible?

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

Yes, follow Jacopo's suggestion: create an ant task to build framework only, then "run the framework only"

*shrug* I don't know what that means.

Maybe have a Selenium task that checks to see if it actually runs on its own.

I'm not real clear on how that would work, but it would definitely be worth a try!

-Adrian

--- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk> wrote:

> From: Chris Snow <sn...@snowconsulting.co.uk>
> Subject: Re: what a mess! is framework independence ever going to be           possible?
> To: user@ofbiz.apache.org
> Date: Saturday, February 6, 2010, 12:49 AM
> Shall I raise a jira for this? Is
> there any documentation on the build and
> test process for ofbiz? e.g. does buildbot run ofbiz and
> run any tests?
> 
> > We can probably start with something simple: add an
> ant task that simply
> > builds the framework (applications and specialpurpose
> will be ignored) and
> > then an ant task to run the framework only.
> > This will require some minor tweaks to the base
> component loading
> > mechanism, but it should be trivial. Right now the
> only way (I am aware
> > of) of building a framework only distro is to remove
> (or similar) the
> > application and specialpurpose folders.
> >
> > Jacopo
> >
> >
> > On Feb 6, 2010, at 9:09 AM, Adrian Crum wrote:
> >
> >> A tool would certainly help. If such a tool was
> included in OFBiz, then
> >> it would have to be compatible with the Apache
> license.
> >>
> >> -Adrian
> >>
> >> --- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk>
> wrote:
> >>
> >>> From: Chris Snow <sn...@snowconsulting.co.uk>
> >>> Subject: Re: what a mess! is framework
> independence ever going to be
> >>>   possible?
> >>> To: user@ofbiz.apache.org
> >>> Date: Saturday, February 6, 2010, 12:02 AM
> >>> Thanks for the feedback Adrian.
> >>> Would it be worth me writing a tool that
> >>> runs as part of the build process that reports
> on the
> >>> dependencies?  It
> >>> could throw a warning/error when a new invalid
> dependency
> >>> is checked in?
> >>>
> >>>> Chris,
> >>>>
> >>>> Framework independence has been a goal for
> quite a
> >>> while. There is no
> >>>> disagreement that the framework should run
> on its own.
> >>> The disagreements
> >>>> arise in what constitutes the framework.
> >>>>
> >>>> Let's assume for a moment that framework
> independence
> >>> means running the
> >>>> components in the framework folder
> independently from
> >>> anything else in
> >>>> OFBiz. Right away the problem with that
> idea is that
> >>> visual themes are in
> >>>> a separate folder outside the framework
> folder. Does
> >>> framework
> >>>> independence include the visual themes
> folder? That
> >>> has not been
> >>>> discussed. Then there are the multitude
> of
> >>> dependencies upon the
> >>>> applications folder.
> >>>>
> >>>> From my perspective, achieving this
> objective will
> >>> require a two pronged
> >>>> approach: 1) Identify the framework
> dependencies on
> >>> outside components,
> >>>> and 2) avoid introducing new framework
> dependencies on
> >>> outside components.
> >>>>
> >>>> The first prong can be accomplished
> through
> >>> contributions from people like
> >>>> you - find the dependencies and create
> patches to fix
> >>> them.
> >>>>
> >>>> The responsibility of the second prong is
> up to the
> >>> committers. We need to
> >>>> be more vigilant to guard against
> introducing new
> >>> dependencies.
> >>>>
> >>>> Personally I believe it will be possible,
> BUT it won't
> >>> be easy. The
> >>>> obstacles to overcome will be getting
> people to
> >>> contribute to the effort,
> >>>> and getting committers to avoid
> introducing new
> >>> dependencies.
> >>>>
> >>>> -Adrian
> >>>>
> >>>>
> >>>> --- On Fri, 2/5/10, Christopher Snow
> <sn...@snowconsulting.co.uk>
> >>> wrote:
> >>>>
> >>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
> >>>>> Subject: what a mess! is framework
> independence
> >>> ever going to be
> >>>>> possible?
> >>>>> To: user@ofbiz.apache.org
> >>>>> Date: Friday, February 5, 2010, 10:58
> PM
> >>>>> I'm back to the process of working
> >>>>> out how to get a standalone framework
> running
> >>> based on
> >>>>> trunk, but I have found that the
> dependencies have
> >>> got out
> >>>>> of hand (if I've understood the code
> right):
> >>>>>
> >>>>> Framework  depends on Themes
> >>>>> Themes depends on Content
> >>>>> Content depends on Party
> >>>>>
> >>>>> The questions I'm starting to ask
> myself are:
> >>>>>
> >>>>> "Is is ever going to be possible to
> have
> >>> framework
> >>>>> independence in trunk? 
> Independence in 9.04 is
> >>>>> relatively trivial (rewrite security
> screens)
> >>> perhaps the
> >>>>> most sensible thing would be to do a
> fork of 9.04
> >>> and then
> >>>>> back port all framework related
> commits from
> >>> trunk? "
> >>>>>
> >>>>> Any ideas anyone?
> >>>>>
> >>>>> Many thanks,
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt)
> (Open) CISSP
> >>>
> >>> Tel: 01453 890660
> >>> Mob: 07944 880950
> >>> Www: www.snowconsulting.co.uk
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> 
> 
> -- 
> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
> 
> Tel: 01453 890660
> Mob: 07944 880950
> Www: www.snowconsulting.co.uk
> 
> 


      

Re: what a mess! is framework independence ever going to be possible?

[Chris Snow <sn...@snowconsulting.co.uk>]

Shall I raise a jira for this? Is there any documentation on the build and
test process for ofbiz? e.g. does buildbot run ofbiz and run any tests?

> We can probably start with something simple: add an ant task that simply
> builds the framework (applications and specialpurpose will be ignored) and
> then an ant task to run the framework only.
> This will require some minor tweaks to the base component loading
> mechanism, but it should be trivial. Right now the only way (I am aware
> of) of building a framework only distro is to remove (or similar) the
> application and specialpurpose folders.
>
> Jacopo
>
>
> On Feb 6, 2010, at 9:09 AM, Adrian Crum wrote:
>
>> A tool would certainly help. If such a tool was included in OFBiz, then
>> it would have to be compatible with the Apache license.
>>
>> -Adrian
>>
>> --- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk> wrote:
>>
>>> From: Chris Snow <sn...@snowconsulting.co.uk>
>>> Subject: Re: what a mess! is framework independence ever going to be
>>>   possible?
>>> To: user@ofbiz.apache.org
>>> Date: Saturday, February 6, 2010, 12:02 AM
>>> Thanks for the feedback Adrian.
>>> Would it be worth me writing a tool that
>>> runs as part of the build process that reports on the
>>> dependencies?  It
>>> could throw a warning/error when a new invalid dependency
>>> is checked in?
>>>
>>>> Chris,
>>>>
>>>> Framework independence has been a goal for quite a
>>> while. There is no
>>>> disagreement that the framework should run on its own.
>>> The disagreements
>>>> arise in what constitutes the framework.
>>>>
>>>> Let's assume for a moment that framework independence
>>> means running the
>>>> components in the framework folder independently from
>>> anything else in
>>>> OFBiz. Right away the problem with that idea is that
>>> visual themes are in
>>>> a separate folder outside the framework folder. Does
>>> framework
>>>> independence include the visual themes folder? That
>>> has not been
>>>> discussed. Then there are the multitude of
>>> dependencies upon the
>>>> applications folder.
>>>>
>>>> From my perspective, achieving this objective will
>>> require a two pronged
>>>> approach: 1) Identify the framework dependencies on
>>> outside components,
>>>> and 2) avoid introducing new framework dependencies on
>>> outside components.
>>>>
>>>> The first prong can be accomplished through
>>> contributions from people like
>>>> you - find the dependencies and create patches to fix
>>> them.
>>>>
>>>> The responsibility of the second prong is up to the
>>> committers. We need to
>>>> be more vigilant to guard against introducing new
>>> dependencies.
>>>>
>>>> Personally I believe it will be possible, BUT it won't
>>> be easy. The
>>>> obstacles to overcome will be getting people to
>>> contribute to the effort,
>>>> and getting committers to avoid introducing new
>>> dependencies.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>> wrote:
>>>>
>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>> Subject: what a mess! is framework independence
>>> ever going to be
>>>>> possible?
>>>>> To: user@ofbiz.apache.org
>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>> I'm back to the process of working
>>>>> out how to get a standalone framework running
>>> based on
>>>>> trunk, but I have found that the dependencies have
>>> got out
>>>>> of hand (if I've understood the code right):
>>>>>
>>>>> Framework  depends on Themes
>>>>> Themes depends on Content
>>>>> Content depends on Party
>>>>>
>>>>> The questions I'm starting to ask myself are:
>>>>>
>>>>> "Is is ever going to be possible to have
>>> framework
>>>>> independence in trunk?  Independence in 9.04 is
>>>>> relatively trivial (rewrite security screens)
>>> perhaps the
>>>>> most sensible thing would be to do a fork of 9.04
>>> and then
>>>>> back port all framework related commits from
>>> trunk? "
>>>>>
>>>>> Any ideas anyone?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>>>
>>> Tel: 01453 890660
>>> Mob: 07944 880950
>>> Www: www.snowconsulting.co.uk
>>>
>>>
>>
>>
>>
>
>


-- 
Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP

Tel: 01453 890660
Mob: 07944 880950
Www: www.snowconsulting.co.uk

Re: what a mess! is framework independence ever going to be possible?

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

We can probably start with something simple: add an ant task that simply builds the framework (applications and specialpurpose will be ignored) and then an ant task to run the framework only.
This will require some minor tweaks to the base component loading mechanism, but it should be trivial. Right now the only way (I am aware of) of building a framework only distro is to remove (or similar) the application and specialpurpose folders.

Jacopo


On Feb 6, 2010, at 9:09 AM, Adrian Crum wrote:

> A tool would certainly help. If such a tool was included in OFBiz, then it would have to be compatible with the Apache license.
> 
> -Adrian
> 
> --- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk> wrote:
> 
>> From: Chris Snow <sn...@snowconsulting.co.uk>
>> Subject: Re: what a mess! is framework independence ever going to be      possible?
>> To: user@ofbiz.apache.org
>> Date: Saturday, February 6, 2010, 12:02 AM
>> Thanks for the feedback Adrian. 
>> Would it be worth me writing a tool that
>> runs as part of the build process that reports on the
>> dependencies?  It
>> could throw a warning/error when a new invalid dependency
>> is checked in?
>> 
>>> Chris,
>>> 
>>> Framework independence has been a goal for quite a
>> while. There is no
>>> disagreement that the framework should run on its own.
>> The disagreements
>>> arise in what constitutes the framework.
>>> 
>>> Let's assume for a moment that framework independence
>> means running the
>>> components in the framework folder independently from
>> anything else in
>>> OFBiz. Right away the problem with that idea is that
>> visual themes are in
>>> a separate folder outside the framework folder. Does
>> framework
>>> independence include the visual themes folder? That
>> has not been
>>> discussed. Then there are the multitude of
>> dependencies upon the
>>> applications folder.
>>> 
>>> From my perspective, achieving this objective will
>> require a two pronged
>>> approach: 1) Identify the framework dependencies on
>> outside components,
>>> and 2) avoid introducing new framework dependencies on
>> outside components.
>>> 
>>> The first prong can be accomplished through
>> contributions from people like
>>> you - find the dependencies and create patches to fix
>> them.
>>> 
>>> The responsibility of the second prong is up to the
>> committers. We need to
>>> be more vigilant to guard against introducing new
>> dependencies.
>>> 
>>> Personally I believe it will be possible, BUT it won't
>> be easy. The
>>> obstacles to overcome will be getting people to
>> contribute to the effort,
>>> and getting committers to avoid introducing new
>> dependencies.
>>> 
>>> -Adrian
>>> 
>>> 
>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>> wrote:
>>> 
>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>> Subject: what a mess! is framework independence
>> ever going to be
>>>> possible?
>>>> To: user@ofbiz.apache.org
>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>> I'm back to the process of working
>>>> out how to get a standalone framework running
>> based on
>>>> trunk, but I have found that the dependencies have
>> got out
>>>> of hand (if I've understood the code right):
>>>> 
>>>> Framework  depends on Themes
>>>> Themes depends on Content
>>>> Content depends on Party
>>>> 
>>>> The questions I'm starting to ask myself are:
>>>> 
>>>> "Is is ever going to be possible to have
>> framework
>>>> independence in trunk?  Independence in 9.04 is
>>>> relatively trivial (rewrite security screens)
>> perhaps the
>>>> most sensible thing would be to do a fork of 9.04
>> and then
>>>> back port all framework related commits from
>> trunk? "
>>>> 
>>>> Any ideas anyone?
>>>> 
>>>> Many thanks,
>>>> 
>>>> Chris
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>> 
>> Tel: 01453 890660
>> Mob: 07944 880950
>> Www: www.snowconsulting.co.uk
>> 
>> 
> 
> 
> 

Re: what a mess! is framework independence ever going to be possible?

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

A tool would certainly help. If such a tool was included in OFBiz, then it would have to be compatible with the Apache license.

-Adrian

--- On Sat, 2/6/10, Chris Snow <sn...@snowconsulting.co.uk> wrote:

> From: Chris Snow <sn...@snowconsulting.co.uk>
> Subject: Re: what a mess! is framework independence ever going to be      possible?
> To: user@ofbiz.apache.org
> Date: Saturday, February 6, 2010, 12:02 AM
> Thanks for the feedback Adrian. 
> Would it be worth me writing a tool that
> runs as part of the build process that reports on the
> dependencies?  It
> could throw a warning/error when a new invalid dependency
> is checked in?
> 
> > Chris,
> >
> > Framework independence has been a goal for quite a
> while. There is no
> > disagreement that the framework should run on its own.
> The disagreements
> > arise in what constitutes the framework.
> >
> > Let's assume for a moment that framework independence
> means running the
> > components in the framework folder independently from
> anything else in
> > OFBiz. Right away the problem with that idea is that
> visual themes are in
> > a separate folder outside the framework folder. Does
> framework
> > independence include the visual themes folder? That
> has not been
> > discussed. Then there are the multitude of
> dependencies upon the
> > applications folder.
> >
> > From my perspective, achieving this objective will
> require a two pronged
> > approach: 1) Identify the framework dependencies on
> outside components,
> > and 2) avoid introducing new framework dependencies on
> outside components.
> >
> > The first prong can be accomplished through
> contributions from people like
> > you - find the dependencies and create patches to fix
> them.
> >
> > The responsibility of the second prong is up to the
> committers. We need to
> > be more vigilant to guard against introducing new
> dependencies.
> >
> > Personally I believe it will be possible, BUT it won't
> be easy. The
> > obstacles to overcome will be getting people to
> contribute to the effort,
> > and getting committers to avoid introducing new
> dependencies.
> >
> > -Adrian
> >
> >
> > --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
> wrote:
> >
> >> From: Christopher Snow <sn...@snowconsulting.co.uk>
> >> Subject: what a mess! is framework independence
> ever going to be
> >> possible?
> >> To: user@ofbiz.apache.org
> >> Date: Friday, February 5, 2010, 10:58 PM
> >> I'm back to the process of working
> >> out how to get a standalone framework running
> based on
> >> trunk, but I have found that the dependencies have
> got out
> >> of hand (if I've understood the code right):
> >>
> >> Framework  depends on Themes
> >> Themes depends on Content
> >> Content depends on Party
> >>
> >> The questions I'm starting to ask myself are:
> >>
> >> "Is is ever going to be possible to have
> framework
> >> independence in trunk?  Independence in 9.04 is
> >> relatively trivial (rewrite security screens)
> perhaps the
> >> most sensible thing would be to do a fork of 9.04
> and then
> >> back port all framework related commits from
> trunk? "
> >>
> >> Any ideas anyone?
> >>
> >> Many thanks,
> >>
> >> Chris
> >>
> >
> >
> >
> >
> 
> 
> -- 
> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
> 
> Tel: 01453 890660
> Mob: 07944 880950
> Www: www.snowconsulting.co.uk
> 
> 


      

Re: what a mess! is framework independence ever going to be possible?

[Chris Snow <sn...@snowconsulting.co.uk>]

Thanks for the feedback Adrian.  Would it be worth me writing a tool that
runs as part of the build process that reports on the dependencies?  It
could throw a warning/error when a new invalid dependency is checked in?

> Chris,
>
> Framework independence has been a goal for quite a while. There is no
> disagreement that the framework should run on its own. The disagreements
> arise in what constitutes the framework.
>
> Let's assume for a moment that framework independence means running the
> components in the framework folder independently from anything else in
> OFBiz. Right away the problem with that idea is that visual themes are in
> a separate folder outside the framework folder. Does framework
> independence include the visual themes folder? That has not been
> discussed. Then there are the multitude of dependencies upon the
> applications folder.
>
> From my perspective, achieving this objective will require a two pronged
> approach: 1) Identify the framework dependencies on outside components,
> and 2) avoid introducing new framework dependencies on outside components.
>
> The first prong can be accomplished through contributions from people like
> you - find the dependencies and create patches to fix them.
>
> The responsibility of the second prong is up to the committers. We need to
> be more vigilant to guard against introducing new dependencies.
>
> Personally I believe it will be possible, BUT it won't be easy. The
> obstacles to overcome will be getting people to contribute to the effort,
> and getting committers to avoid introducing new dependencies.
>
> -Adrian
>
>
> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
>
>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>> Subject: what a mess! is framework independence ever going to be
>> possible?
>> To: user@ofbiz.apache.org
>> Date: Friday, February 5, 2010, 10:58 PM
>> I'm back to the process of working
>> out how to get a standalone framework running based on
>> trunk, but I have found that the dependencies have got out
>> of hand (if I've understood the code right):
>>
>> Framework  depends on Themes
>> Themes depends on Content
>> Content depends on Party
>>
>> The questions I'm starting to ask myself are:
>>
>> "Is is ever going to be possible to have framework
>> independence in trunk?  Independence in 9.04 is
>> relatively trivial (rewrite security screens) perhaps the
>> most sensible thing would be to do a fork of 9.04 and then
>> back port all framework related commits from trunk? "
>>
>> Any ideas anyone?
>>
>> Many thanks,
>>
>> Chris
>>
>
>
>
>


-- 
Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP

Tel: 01453 890660
Mob: 07944 880950
Www: www.snowconsulting.co.uk

Re: what a mess! is framework independence ever going to be possible?

[Christopher Snow <sn...@snowconsulting.co.uk>]

Hi Bruno,

I think your plan makes a lot of sense and I also agree with your 
spreadsheet. 

We should work on the buildbot to report and enforce correct dependencies.

Cheers,

Chris

Bruno Busco wrote:
> Chris,
> I think we should at first concentrate into enforcing a components
> dependency hierarchy.
>
> This is my plan:
>
> We should select  "core" or "framework" components that are the
> minimum must be installed in order to have a running OFBiz.
>
> Then we should say: "additional component A can be installed if
> componentd B is installed also", "component C can be installed if A
> and B are installed"
>
> Having this in place will let us define some "OFBiz configurations"
> that should run properly according to the design.
>
> For instance:
> Configuration 1 -> Only the "core" components
> Configuration 2 -> Core components + component A and B
> Configuration 3 -> Core components + components A, B and C
>
> Every configuration should be automatically built by BuildBot so that
> we continuously check if unwanted dependencies are added in the
> codebase.
>
> When all this will be in place we can further work to a greater
> components separation.
> If we agree with this could we work toghether identifying the configurations?
>
> The excel sheet I have uploaded here
> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
> can be used as a tool for this.
>
> What do you think about?
>
>
> -Bruno
>
> 2010/2/7 Christopher Snow <sn...@snowconsulting.co.uk>:
>   
>> Also, splitting components down into small functional areas could have the
>> benefit that if you just want WorkEffort core + parties, you wouldn't get
>> the UI contributions from WorkEffort fixed assets.
>>
>> Development would be more difficult as you would be working across multiple
>> files.  However, maybe the eclipse ofbiz IDE could provide a consolidated
>> view?
>>
>> Cheers,
>>
>> Chris
>>
>> Christopher Snow wrote:
>>     
>>> Good work Bruno!  I'm putting some thought into the dependency issues - I
>>> will provide some more feedback when I have a clearer view.  However, my
>>> current view is this:
>>> 1) Developers should be able have a standalone framework
>>> 2) Developers should be able to install components to meet certain
>>> functional areas without having to install most of the other components.
>>>  E.g. install WorkEffort as a standalone component without having to install
>>> Accounting, Party management, etc.
>>>
>>> The current implementation of ofbiz does not support (2) without breaking
>>> each component up into a number of smaller modules such as:
>>>
>>> WorkEffortCore module (has no external dependency)
>>> WorkEffortFixedAsset module (requires FixedAsset core module)
>>> WorkEffortParties module (requires Party core module)
>>>
>>> Option (2) would give maximum reuse of code and would facilitate
>>> developers in learning ofbiz as they would only need to focus on the
>>> business processes within those modules.
>>>
>>> Anyway, I'm going to play around with the above concept when I have
>>> time...
>>>
>>>
>>> Bruno Busco wrote:
>>>       
>>>> The complete url for the confluence page is:
>>>>
>>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>>
>>>>
>>>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>>>
>>>>         
>>>>> I have updated the framework-only confluence page with an excel sheet
>>>>> that we could use to track the dependecies issue down.
>>>>>
>>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>>
>>>>> Hope this helps. It is not yet completed.
>>>>> Please fille free to contribute to update it.
>>>>> The black "X" are dependecies that we want in the code base.
>>>>> The red "X" are dependencies that are there but should not.
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>>>
>>>>>           
>>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>>
>>>>>>             
>>>>>>> Chris,
>>>>>>>
>>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>>  disagreement that the framework should run on its own. The
>>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>>
>>>>>>> Let's assume for a moment that framework independence means running
>>>>>>> the
>>>>>>>  components in the framework folder independently from anything else
>>>>>>> in
>>>>>>>  OFBiz. Right away the problem with that idea is that visual themes
>>>>>>> are
>>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>>  independence include the visual themes folder? That has not been
>>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>>  applications folder.
>>>>>>>
>>>>>>>               
>>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>>>>> separate dependencies by folder or subject matter is an exercise doomed
>>>>>> to failure.
>>>>>>
>>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>>> means to map IP addresses to hostnames at the application layer--
>>>>>> TCP/IP
>>>>>> doesn't care.
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> From my perspective, achieving this objective will require a two
>>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>>  outside components.
>>>>>>>
>>>>>>>               
>>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>>>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>>> describe.
>>>>>>
>>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>>> is very detailed charts that seem to obfuscate, rather than clarify,
>>>>>> the
>>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> The first prong can be accomplished through contributions from people
>>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>>
>>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>>> need
>>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>>
>>>>>>>               
>>>>>> Which requires a clear model of what layer the code under consideration
>>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>>> dependencies.
>>>>>>
>>>>>>             
>>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>>>>
>>>>>>>               
>>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>>> meaningful and error-free code.
>>>>>>
>>>>>>             
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>>> possible?
>>>>>>>> To: user@ofbiz.apache.org
>>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>>> I'm back to the process of working
>>>>>>>> out how to get a standalone framework running based on
>>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>>> of hand (if I've understood the code right):
>>>>>>>>
>>>>>>>> Framework  depends on Themes
>>>>>>>> Themes depends on Content
>>>>>>>> Content depends on Party
>>>>>>>>
>>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>>
>>>>>>>> "Is is ever going to be possible to have framework
>>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>>> back port all framework related commits from trunk? "
>>>>>>>>
>>>>>>>> Any ideas anyone?
>>>>>>>>
>>>>>>>> Many thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>               
>>>>>> --
>>>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>>>> RidgeCrest Herbals, Inc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>     

Re: what a mess! is framework independence ever going to be possible?

[Bruno Busco <br...@gmail.com>]

Chris,
I think we should at first concentrate into enforcing a components
dependency hierarchy.

This is my plan:

We should select  "core" or "framework" components that are the
minimum must be installed in order to have a running OFBiz.

Then we should say: "additional component A can be installed if
componentd B is installed also", "component C can be installed if A
and B are installed"

Having this in place will let us define some "OFBiz configurations"
that should run properly according to the design.

For instance:
Configuration 1 -> Only the "core" components
Configuration 2 -> Core components + component A and B
Configuration 3 -> Core components + components A, B and C

Every configuration should be automatically built by BuildBot so that
we continuously check if unwanted dependencies are added in the
codebase.

When all this will be in place we can further work to a greater
components separation.
If we agree with this could we work toghether identifying the configurations?

The excel sheet I have uploaded here
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
can be used as a tool for this.

What do you think about?


-Bruno

2010/2/7 Christopher Snow <sn...@snowconsulting.co.uk>:
> Also, splitting components down into small functional areas could have the
> benefit that if you just want WorkEffort core + parties, you wouldn't get
> the UI contributions from WorkEffort fixed assets.
>
> Development would be more difficult as you would be working across multiple
> files.  However, maybe the eclipse ofbiz IDE could provide a consolidated
> view?
>
> Cheers,
>
> Chris
>
> Christopher Snow wrote:
>>
>> Good work Bruno!  I'm putting some thought into the dependency issues - I
>> will provide some more feedback when I have a clearer view.  However, my
>> current view is this:
>> 1) Developers should be able have a standalone framework
>> 2) Developers should be able to install components to meet certain
>> functional areas without having to install most of the other components.
>>  E.g. install WorkEffort as a standalone component without having to install
>> Accounting, Party management, etc.
>>
>> The current implementation of ofbiz does not support (2) without breaking
>> each component up into a number of smaller modules such as:
>>
>> WorkEffortCore module (has no external dependency)
>> WorkEffortFixedAsset module (requires FixedAsset core module)
>> WorkEffortParties module (requires Party core module)
>>
>> Option (2) would give maximum reuse of code and would facilitate
>> developers in learning ofbiz as they would only need to focus on the
>> business processes within those modules.
>>
>> Anyway, I'm going to play around with the above concept when I have
>> time...
>>
>>
>> Bruno Busco wrote:
>>>
>>> The complete url for the confluence page is:
>>>
>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>
>>>
>>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>>
>>>>
>>>> I have updated the framework-only confluence page with an excel sheet
>>>> that we could use to track the dependecies issue down.
>>>>
>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>
>>>> Hope this helps. It is not yet completed.
>>>> Please fille free to contribute to update it.
>>>> The black "X" are dependecies that we want in the code base.
>>>> The red "X" are dependencies that are there but should not.
>>>>
>>>> -Bruno
>>>>
>>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>>
>>>>>
>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>
>>>>>>
>>>>>> Chris,
>>>>>>
>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>  disagreement that the framework should run on its own. The
>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>
>>>>>> Let's assume for a moment that framework independence means running
>>>>>> the
>>>>>>  components in the framework folder independently from anything else
>>>>>> in
>>>>>>  OFBiz. Right away the problem with that idea is that visual themes
>>>>>> are
>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>  independence include the visual themes folder? That has not been
>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>  applications folder.
>>>>>>
>>>>>
>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>>>> separate dependencies by folder or subject matter is an exercise doomed
>>>>> to failure.
>>>>>
>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>> means to map IP addresses to hostnames at the application layer--
>>>>> TCP/IP
>>>>> doesn't care.
>>>>>
>>>>>
>>>>>>
>>>>>> From my perspective, achieving this objective will require a two
>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>  outside components.
>>>>>>
>>>>>
>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>> describe.
>>>>>
>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>> is very detailed charts that seem to obfuscate, rather than clarify,
>>>>> the
>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>
>>>>>
>>>>>>
>>>>>> The first prong can be accomplished through contributions from people
>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>
>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>> need
>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>
>>>>>
>>>>> Which requires a clear model of what layer the code under consideration
>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>> dependencies.
>>>>>
>>>>>>
>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>>>
>>>>>
>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>> meaningful and error-free code.
>>>>>
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>> possible?
>>>>>>> To: user@ofbiz.apache.org
>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>> I'm back to the process of working
>>>>>>> out how to get a standalone framework running based on
>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>> of hand (if I've understood the code right):
>>>>>>>
>>>>>>> Framework  depends on Themes
>>>>>>> Themes depends on Content
>>>>>>> Content depends on Party
>>>>>>>
>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>
>>>>>>> "Is is ever going to be possible to have framework
>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>> back port all framework related commits from trunk? "
>>>>>>>
>>>>>>> Any ideas anyone?
>>>>>>>
>>>>>>> Many thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>>> RidgeCrest Herbals, Inc.
>>>>>
>>>>>
>>>>>
>>
>
>

Re: what a mess! is framework independence ever going to be possible?

[Bruno Busco <br...@gmail.com>]

Hi BJ,
sorry but what I meant for "configuration" is different from what I
see you addressed in these jiras.
For configuration I mean a defined set of components that are supposed
to work without any other component in the installation.

-Bruno


2010/2/7 BJ Freeman <bj...@free-man.net>:
> both Hans and I have been working on configuration
> Hans is in the trunk. I have yet to get mine put in the Jira.
> https://issues.apache.org/jira/browse/OFBIZ-636
> https://issues.apache.org/jira/browse/OFBIZ-635
>
> Bruno Busco sent the following on 2/7/2010 12:38 AM:
>> Chris,
>> I think we should at first concentrate into enforcing a components
>> dependency hierarchy.
>>
>> This is my plan:
>>
>> We should select  "core" or "framework" components that are the
>> minimum must be installed in order to have a running OFBiz.
>>
>> Then we should say: "additional component A can be installed if
>> componentd B is installed also", "component C can be installed if A
>> and B are installed"
>>
>> Having this in place will let us define some "OFBiz configurations"
>> that should run properly according to the design.
>>
>> For instance:
>> Configuration 1 -> Only the "core" components
>> Configuration 2 -> Core components + component A and B
>> Configuration 3 -> Core components + components A, B and C
>>
>> Every configuration should be automatically built by BuildBot so that
>> we continuously check if unwanted dependencies are added in the
>> codebase.
>>
>> When all this will be in place we can further work to a greater
>> components separation.
>> If we agree with this could we work toghether identifying the configurations?
>>
>> The excel sheet I have uploaded here
>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>> can be used as a tool for this.
>>
>> What do you think about?
>>
>>
>> -Bruno
>>
>> 2010/2/7 Christopher Snow <sn...@snowconsulting.co.uk>:
>>> Also, splitting components down into small functional areas could have the
>>> benefit that if you just want WorkEffort core + parties, you wouldn't get
>>> the UI contributions from WorkEffort fixed assets.
>>>
>>> Development would be more difficult as you would be working across multiple
>>> files.  However, maybe the eclipse ofbiz IDE could provide a consolidated
>>> view?
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>> Christopher Snow wrote:
>>>> Good work Bruno!  I'm putting some thought into the dependency issues - I
>>>> will provide some more feedback when I have a clearer view.  However, my
>>>> current view is this:
>>>> 1) Developers should be able have a standalone framework
>>>> 2) Developers should be able to install components to meet certain
>>>> functional areas without having to install most of the other components.
>>>>  E.g. install WorkEffort as a standalone component without having to install
>>>> Accounting, Party management, etc.
>>>>
>>>> The current implementation of ofbiz does not support (2) without breaking
>>>> each component up into a number of smaller modules such as:
>>>>
>>>> WorkEffortCore module (has no external dependency)
>>>> WorkEffortFixedAsset module (requires FixedAsset core module)
>>>> WorkEffortParties module (requires Party core module)
>>>>
>>>> Option (2) would give maximum reuse of code and would facilitate
>>>> developers in learning ofbiz as they would only need to focus on the
>>>> business processes within those modules.
>>>>
>>>> Anyway, I'm going to play around with the above concept when I have
>>>> time...
>>>>
>>>>
>>>> Bruno Busco wrote:
>>>>> The complete url for the confluence page is:
>>>>>
>>>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>>>
>>>>>
>>>>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>>>>
>>>>>> I have updated the framework-only confluence page with an excel sheet
>>>>>> that we could use to track the dependecies issue down.
>>>>>>
>>>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>>>
>>>>>> Hope this helps. It is not yet completed.
>>>>>> Please fille free to contribute to update it.
>>>>>> The black "X" are dependecies that we want in the code base.
>>>>>> The red "X" are dependencies that are there but should not.
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>>>>
>>>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Chris,
>>>>>>>>
>>>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>>>  disagreement that the framework should run on its own. The
>>>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>>>
>>>>>>>> Let's assume for a moment that framework independence means running
>>>>>>>> the
>>>>>>>>  components in the framework folder independently from anything else
>>>>>>>> in
>>>>>>>>  OFBiz. Right away the problem with that idea is that visual themes
>>>>>>>> are
>>>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>>>  independence include the visual themes folder? That has not been
>>>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>>>  applications folder.
>>>>>>>>
>>>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>>>>>> separate dependencies by folder or subject matter is an exercise doomed
>>>>>>> to failure.
>>>>>>>
>>>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>>>> means to map IP addresses to hostnames at the application layer--
>>>>>>> TCP/IP
>>>>>>> doesn't care.
>>>>>>>
>>>>>>>
>>>>>>>> From my perspective, achieving this objective will require a two
>>>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>>>  outside components.
>>>>>>>>
>>>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>>>>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>>>> describe.
>>>>>>>
>>>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>>>> is very detailed charts that seem to obfuscate, rather than clarify,
>>>>>>> the
>>>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>>>
>>>>>>>
>>>>>>>> The first prong can be accomplished through contributions from people
>>>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>>>
>>>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>>>> need
>>>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>>>
>>>>>>> Which requires a clear model of what layer the code under consideration
>>>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>>>> dependencies.
>>>>>>>
>>>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>>>>>
>>>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>>>> meaningful and error-free code.
>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>>>> possible?
>>>>>>>>> To: user@ofbiz.apache.org
>>>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>>>> I'm back to the process of working
>>>>>>>>> out how to get a standalone framework running based on
>>>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>>>> of hand (if I've understood the code right):
>>>>>>>>>
>>>>>>>>> Framework  depends on Themes
>>>>>>>>> Themes depends on Content
>>>>>>>>> Content depends on Party
>>>>>>>>>
>>>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>>>
>>>>>>>>> "Is is ever going to be possible to have framework
>>>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>>>> back port all framework related commits from trunk? "
>>>>>>>>>
>>>>>>>>> Any ideas anyone?
>>>>>>>>>
>>>>>>>>> Many thanks,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>>>>> RidgeCrest Herbals, Inc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>
>

Re: what a mess! is framework independence ever going to be possible?

[BJ Freeman <bj...@free-man.net>]

for that use the datamodel books and look at the data in each
application and see if it uses data from other applications.
if it does there is a dependency.

Bruno Busco sent the following on 2/7/2010 1:57 AM:
> Hi BJ,
> sorry but what I meant for "configfoation" is different from what I
> see you addressed in these jiras.
> For configuration I mean a defined set of components that are supposed
> to work without any other component in the installation.
> 
> -Bruno
> 
> 
> 2010/2/7 BJ Freeman <bj...@free-man.net>:
>> both Hans and I have been working on configuration
>> Hans is in the trunk. I have yet to get mine put in the Jira.
>> https://issues.apache.org/jira/browse/OFBIZ-636
>> https://issues.apache.org/jira/browse/OFBIZ-635
>>
>> Bruno Busco sent the following on 2/7/2010 12:38 AM:
>>> Chris,
>>> I think we should at first concentrate into enforcing a components
>>> dependency hierarchy.
>>>
>>> This is my plan:
>>>
>>> We should select  "core" or "framework" components that are the
>>> minimum must be installed in order to have a running OFBiz.
>>>
>>> Then we should say: "additional component A can be installed if
>>> componentd B is installed also", "component C can be installed if A
>>> and B are installed"
>>>
>>> Having this in place will let us define some "OFBiz configurations"
>>> that should run properly according to the design.
>>>
>>> For instance:
>>> Configuration 1 -> Only the "core" components
>>> Configuration 2 -> Core components + component A and B
>>> Configuration 3 -> Core components + components A, B and C
>>>
>>> Every configuration should be automatically built by BuildBot so that
>>> we continuously check if unwanted dependencies are added in the
>>> codebase.
>>>
>>> When all this will be in place we can further work to a greater
>>> components separation.
>>> If we agree with this could we work toghether identifying the configurations?
>>>
>>> The excel sheet I have uploaded here
>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>> can be used as a tool for this.
>>>
>>> What do you think about?
>>>
>>>
>>> -Bruno
>>>
>>> 2010/2/7 Christopher Snow <sn...@snowconsulting.co.uk>:
>>>> Also, splitting components down into small functional areas could have the
>>>> benefit that if you just want WorkEffort core + parties, you wouldn't get
>>>> the UI contributions from WorkEffort fixed assets.
>>>>
>>>> Development would be more difficult as you would be working across multiple
>>>> files.  However, maybe the eclipse ofbiz IDE could provide a consolidated
>>>> view?
>>>>
>>>> Cheers,
>>>>
>>>> Chris
>>>>
>>>> Christopher Snow wrote:
>>>>> Good work Bruno!  I'm putting some thought into the dependency issues - I
>>>>> will provide some more feedback when I have a clearer view.  However, my
>>>>> current view is this:
>>>>> 1) Developers should be able have a standalone framework
>>>>> 2) Developers should be able to install components to meet certain
>>>>> functional areas without having to install most of the other components.
>>>>>  E.g. install WorkEffort as a standalone component without having to install
>>>>> Accounting, Party management, etc.
>>>>>
>>>>> The current implementation of ofbiz does not support (2) without breaking
>>>>> each component up into a number of smaller modules such as:
>>>>>
>>>>> WorkEffortCore module (has no external dependency)
>>>>> WorkEffortFixedAsset module (requires FixedAsset core module)
>>>>> WorkEffortParties module (requires Party core module)
>>>>>
>>>>> Option (2) would give maximum reuse of code and would facilitate
>>>>> developers in learning ofbiz as they would only need to focus on the
>>>>> business processes within those modules.
>>>>>
>>>>> Anyway, I'm going to play around with the above concept when I have
>>>>> time...
>>>>>
>>>>>
>>>>> Bruno Busco wrote:
>>>>>> The complete url for the confluence page is:
>>>>>>
>>>>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>>>>
>>>>>>
>>>>>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>>>>>
>>>>>>> I have updated the framework-only confluence page with an excel sheet
>>>>>>> that we could use to track the dependecies issue down.
>>>>>>>
>>>>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>>>>
>>>>>>> Hope this helps. It is not yet completed.
>>>>>>> Please fille free to contribute to update it.
>>>>>>> The black "X" are dependecies that we want in the code base.
>>>>>>> The red "X" are dependencies that are there but should not.
>>>>>>>
>>>>>>> -Bruno
>>>>>>>
>>>>>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>>>>>
>>>>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>>>>
>>>>>>>>> Chris,
>>>>>>>>>
>>>>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>>>>  disagreement that the framework should run on its own. The
>>>>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>>>>
>>>>>>>>> Let's assume for a moment that framework independence means running
>>>>>>>>> the
>>>>>>>>>  components in the framework folder independently from anything else
>>>>>>>>> in
>>>>>>>>>  OFBiz. Right away the problem with that idea is that visual themes
>>>>>>>>> are
>>>>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>>>>  independence include the visual themes folder? That has not been
>>>>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>>>>  applications folder.
>>>>>>>>>
>>>>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>>>>>>> separate dependencies by folder or subject matter is an exercise doomed
>>>>>>>> to failure.
>>>>>>>>
>>>>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>>>>> means to map IP addresses to hostnames at the application layer--
>>>>>>>> TCP/IP
>>>>>>>> doesn't care.
>>>>>>>>
>>>>>>>>
>>>>>>>>> From my perspective, achieving this objective will require a two
>>>>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>>>>  outside components.
>>>>>>>>>
>>>>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>>>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>>>>>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>>>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>>>>> describe.
>>>>>>>>
>>>>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>>>>> is very detailed charts that seem to obfuscate, rather than clarify,
>>>>>>>> the
>>>>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>>>>
>>>>>>>>
>>>>>>>>> The first prong can be accomplished through contributions from people
>>>>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>>>>
>>>>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>>>>> need
>>>>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>>>>
>>>>>>>> Which requires a clear model of what layer the code under consideration
>>>>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>>>>>>
>>>>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>>>>> meaningful and error-free code.
>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>>>>> possible?
>>>>>>>>>> To: user@ofbiz.apache.org
>>>>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>>>>> I'm back to the process of working
>>>>>>>>>> out how to get a standalone framework running based on
>>>>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>>>>> of hand (if I've understood the code right):
>>>>>>>>>>
>>>>>>>>>> Framework  depends on Themes
>>>>>>>>>> Themes depends on Content
>>>>>>>>>> Content depends on Party
>>>>>>>>>>
>>>>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>>>>
>>>>>>>>>> "Is is ever going to be possible to have framework
>>>>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>>>>> back port all framework related commits from trunk? "
>>>>>>>>>>
>>>>>>>>>> Any ideas anyone?
>>>>>>>>>>
>>>>>>>>>> Many thanks,
>>>>>>>>>>
>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>>>>>> RidgeCrest Herbals, Inc.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
> 

Re: what a mess! is framework independence ever going to be possible?

[BJ Freeman <bj...@free-man.net>]

both Hans and I have been working on configuration
Hans is in the trunk. I have yet to get mine put in the Jira.
https://issues.apache.org/jira/browse/OFBIZ-636
https://issues.apache.org/jira/browse/OFBIZ-635

Bruno Busco sent the following on 2/7/2010 12:38 AM:
> Chris,
> I think we should at first concentrate into enforcing a components
> dependency hierarchy.
> 
> This is my plan:
> 
> We should select  "core" or "framework" components that are the
> minimum must be installed in order to have a running OFBiz.
> 
> Then we should say: "additional component A can be installed if
> componentd B is installed also", "component C can be installed if A
> and B are installed"
> 
> Having this in place will let us define some "OFBiz configurations"
> that should run properly according to the design.
> 
> For instance:
> Configuration 1 -> Only the "core" components
> Configuration 2 -> Core components + component A and B
> Configuration 3 -> Core components + components A, B and C
> 
> Every configuration should be automatically built by BuildBot so that
> we continuously check if unwanted dependencies are added in the
> codebase.
> 
> When all this will be in place we can further work to a greater
> components separation.
> If we agree with this could we work toghether identifying the configurations?
> 
> The excel sheet I have uploaded here
> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
> can be used as a tool for this.
> 
> What do you think about?
> 
> 
> -Bruno
> 
> 2010/2/7 Christopher Snow <sn...@snowconsulting.co.uk>:
>> Also, splitting components down into small functional areas could have the
>> benefit that if you just want WorkEffort core + parties, you wouldn't get
>> the UI contributions from WorkEffort fixed assets.
>>
>> Development would be more difficult as you would be working across multiple
>> files.  However, maybe the eclipse ofbiz IDE could provide a consolidated
>> view?
>>
>> Cheers,
>>
>> Chris
>>
>> Christopher Snow wrote:
>>> Good work Bruno!  I'm putting some thought into the dependency issues - I
>>> will provide some more feedback when I have a clearer view.  However, my
>>> current view is this:
>>> 1) Developers should be able have a standalone framework
>>> 2) Developers should be able to install components to meet certain
>>> functional areas without having to install most of the other components.
>>>  E.g. install WorkEffort as a standalone component without having to install
>>> Accounting, Party management, etc.
>>>
>>> The current implementation of ofbiz does not support (2) without breaking
>>> each component up into a number of smaller modules such as:
>>>
>>> WorkEffortCore module (has no external dependency)
>>> WorkEffortFixedAsset module (requires FixedAsset core module)
>>> WorkEffortParties module (requires Party core module)
>>>
>>> Option (2) would give maximum reuse of code and would facilitate
>>> developers in learning ofbiz as they would only need to focus on the
>>> business processes within those modules.
>>>
>>> Anyway, I'm going to play around with the above concept when I have
>>> time...
>>>
>>>
>>> Bruno Busco wrote:
>>>> The complete url for the confluence page is:
>>>>
>>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>>
>>>>
>>>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>>>
>>>>> I have updated the framework-only confluence page with an excel sheet
>>>>> that we could use to track the dependecies issue down.
>>>>>
>>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>>
>>>>> Hope this helps. It is not yet completed.
>>>>> Please fille free to contribute to update it.
>>>>> The black "X" are dependecies that we want in the code base.
>>>>> The red "X" are dependencies that are there but should not.
>>>>>
>>>>> -Bruno
>>>>>
>>>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>>>
>>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>>
>>>>>>> Chris,
>>>>>>>
>>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>>  disagreement that the framework should run on its own. The
>>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>>
>>>>>>> Let's assume for a moment that framework independence means running
>>>>>>> the
>>>>>>>  components in the framework folder independently from anything else
>>>>>>> in
>>>>>>>  OFBiz. Right away the problem with that idea is that visual themes
>>>>>>> are
>>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>>  independence include the visual themes folder? That has not been
>>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>>  applications folder.
>>>>>>>
>>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>>>>> separate dependencies by folder or subject matter is an exercise doomed
>>>>>> to failure.
>>>>>>
>>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>>> means to map IP addresses to hostnames at the application layer--
>>>>>> TCP/IP
>>>>>> doesn't care.
>>>>>>
>>>>>>
>>>>>>> From my perspective, achieving this objective will require a two
>>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>>  outside components.
>>>>>>>
>>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>>>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>>> describe.
>>>>>>
>>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>>> is very detailed charts that seem to obfuscate, rather than clarify,
>>>>>> the
>>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>>
>>>>>>
>>>>>>> The first prong can be accomplished through contributions from people
>>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>>
>>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>>> need
>>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>>
>>>>>> Which requires a clear model of what layer the code under consideration
>>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>>> dependencies.
>>>>>>
>>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>>>>
>>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>>> meaningful and error-free code.
>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>>> possible?
>>>>>>>> To: user@ofbiz.apache.org
>>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>>> I'm back to the process of working
>>>>>>>> out how to get a standalone framework running based on
>>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>>> of hand (if I've understood the code right):
>>>>>>>>
>>>>>>>> Framework  depends on Themes
>>>>>>>> Themes depends on Content
>>>>>>>> Content depends on Party
>>>>>>>>
>>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>>
>>>>>>>> "Is is ever going to be possible to have framework
>>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>>> back port all framework related commits from trunk? "
>>>>>>>>
>>>>>>>> Any ideas anyone?
>>>>>>>>
>>>>>>>> Many thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>>>> RidgeCrest Herbals, Inc.
>>>>>>
>>>>>>
>>>>>>
>>
> 

Re: what a mess! is framework independence ever going to be possible?

[Christopher Snow <sn...@snowconsulting.co.uk>]

Also, splitting components down into small functional areas could have 
the benefit that if you just want WorkEffort core + parties, you 
wouldn't get the UI contributions from WorkEffort fixed assets.

Development would be more difficult as you would be working across 
multiple files.  However, maybe the eclipse ofbiz IDE could provide a 
consolidated view?

Cheers,

Chris

Christopher Snow wrote:
> Good work Bruno!  I'm putting some thought into the dependency issues 
> - I will provide some more feedback when I have a clearer view.  
> However, my current view is this:
> 1) Developers should be able have a standalone framework
> 2) Developers should be able to install components to meet certain 
> functional areas without having to install most of the other 
> components.  E.g. install WorkEffort as a standalone component without 
> having to install Accounting, Party management, etc.
>
> The current implementation of ofbiz does not support (2) without 
> breaking each component up into a number of smaller modules such as:
>
> WorkEffortCore module (has no external dependency)
> WorkEffortFixedAsset module (requires FixedAsset core module)
> WorkEffortParties module (requires Party core module)
>
> Option (2) would give maximum reuse of code and would facilitate 
> developers in learning ofbiz as they would only need to focus on the 
> business processes within those modules.
>
> Anyway, I'm going to play around with the above concept when I have 
> time...
>
>
> Bruno Busco wrote:
>> The complete url for the confluence page is:
>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution 
>>
>>
>>
>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>  
>>> I have updated the framework-only confluence page with an excel sheet
>>> that we could use to track the dependecies issue down.
>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1 
>>>
>>>
>>> Hope this helps. It is not yet completed.
>>> Please fille free to contribute to update it.
>>> The black "X" are dependecies that we want in the code base.
>>> The red "X" are dependencies that are there but should not.
>>>
>>> -Bruno
>>>
>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>    
>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>      
>>>>> Chris,
>>>>>
>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>  disagreement that the framework should run on its own. The
>>>>>  disagreements arise in what constitutes the framework.
>>>>>
>>>>> Let's assume for a moment that framework independence means 
>>>>> running the
>>>>>  components in the framework folder independently from anything 
>>>>> else in
>>>>>  OFBiz. Right away the problem with that idea is that visual 
>>>>> themes are
>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>  independence include the visual themes folder? That has not been
>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>  applications folder.
>>>>>         
>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like 
>>>> trying to
>>>> separate dependencies by folder or subject matter is an exercise 
>>>> doomed
>>>> to failure.
>>>>
>>>> TCP/IP has taken over the world because it has a clear model based on
>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>> means to map IP addresses to hostnames at the application layer-- 
>>>> TCP/IP
>>>> doesn't care.
>>>>
>>>>      
>>>>> From my perspective, achieving this objective will require a two
>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>  outside components.
>>>>>         
>>>> This assumes the "framework" is the lowest level.  If the framework
>>>> depends on outside components, then the hierarchy has been upset, and
>>>> spaghetti dependencies are the inevitable result.  Dependencies 
>>>> HAVE to
>>>> be unidirectional, or you never get out of the maze.  IMHO, the 
>>>> biggest
>>>> problem with MVC is that it has never seemed to me that the layers are
>>>> very well defined.  Everything seems pretty interdependent, and you
>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>> describe.
>>>>
>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>> is very detailed charts that seem to obfuscate, rather than 
>>>> clarify, the
>>>> relationships of the various modules.  But I'm sure I have not seen
>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>
>>>>      
>>>>> The first prong can be accomplished through contributions from people
>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>
>>>>> The responsibility of the second prong is up to the committers. We 
>>>>> need
>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>         
>>>> Which requires a clear model of what layer the code under 
>>>> consideration
>>>> belongs to, and what are the well-defined layers below it that can be
>>>> dependencies.
>>>>      
>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>  effort, and getting committers to avoid introducing new 
>>>>> dependencies.
>>>>>         
>>>> Again, I think we need to reduce the learning curve by providing clear
>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>> meaningful and error-free code.
>>>>      
>>>>> -Adrian
>>>>>
>>>>>
>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> 
>>>>> wrote:
>>>>>
>>>>>        
>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>> Subject: what a mess! is framework independence ever going to be 
>>>>>> possible?
>>>>>> To: user@ofbiz.apache.org
>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>> I'm back to the process of working
>>>>>> out how to get a standalone framework running based on
>>>>>> trunk, but I have found that the dependencies have got out
>>>>>> of hand (if I've understood the code right):
>>>>>>
>>>>>> Framework  depends on Themes
>>>>>> Themes depends on Content
>>>>>> Content depends on Party
>>>>>>
>>>>>> The questions I'm starting to ask myself are:
>>>>>>
>>>>>> "Is is ever going to be possible to have framework
>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>> back port all framework related commits from trunk? "
>>>>>>
>>>>>> Any ideas anyone?
>>>>>>
>>>>>> Many thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>           
>>>>>
>>>>>         
>>>> -- 
>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>> RidgeCrest Herbals, Inc.
>>>>
>>>>
>>>>       
>

Re: what a mess! is framework independence ever going to be possible?

[BJ Freeman <bj...@free-man.net>]

not sure if you look at the UI but there are permission you can use for
which UI are available to which login via permissions and roles.
as far as components you can hide a whole component in the web.xml and
still have access to it.

The artifact in webtools lets you see association with services, eca,
controller, UI

the basic design is the entity controls the database and UI data.


Christopher Snow sent the following on 2/7/2010 12:17 AM:
> Also, splitting components down into small functional areas could have
> the benefit that if you just want WorkEffort core + parties, you
> wouldn't get the UI contributions from WorkEffort fixed assets.
> 
> Development would be more difficult as you would be working across
> multiple files.  However, maybe the eclipse ofbiz IDE could provide a
> consolidated view?
> 
> Cheers,
> 
> Chris
> 
> Christopher Snow wrote:
>> Good work Bruno!  I'm putting some thought into the dependency issues
>> - I will provide some more feedback when I have a clearer view. 
>> However, my current view is this:
>> 1) Developers should be able have a standalone framework
>> 2) Developers should be able to install components to meet certain
>> functional areas without having to install most of the other
>> components.  E.g. install WorkEffort as a standalone component without
>> having to install Accounting, Party management, etc.
>>
>> The current implementation of ofbiz does not support (2) without
>> breaking each component up into a number of smaller modules such as:
>>
>> WorkEffortCore module (has no external dependency)
>> WorkEffortFixedAsset module (requires FixedAsset core module)
>> WorkEffortParties module (requires Party core module)
>>
>> Option (2) would give maximum reuse of code and would facilitate
>> developers in learning ofbiz as they would only need to focus on the
>> business processes within those modules.
>>
>> Anyway, I'm going to play around with the above concept when I have
>> time...
>>
>>
>> Bruno Busco wrote:
>>> The complete url for the confluence page is:
>>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>>>
>>>
>>>
>>> 2010/2/6 Bruno Busco <br...@gmail.com>:
>>>  
>>>> I have updated the framework-only confluence page with an excel sheet
>>>> that we could use to track the dependecies issue down.
>>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>>>
>>>>
>>>> Hope this helps. It is not yet completed.
>>>> Please fille free to contribute to update it.
>>>> The black "X" are dependecies that we want in the code base.
>>>> The red "X" are dependencies that are there but should not.
>>>>
>>>> -Bruno
>>>>
>>>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>>>   
>>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>>>     
>>>>>> Chris,
>>>>>>
>>>>>> Framework independence has been a goal for quite a while. There is no
>>>>>>  disagreement that the framework should run on its own. The
>>>>>>  disagreements arise in what constitutes the framework.
>>>>>>
>>>>>> Let's assume for a moment that framework independence means
>>>>>> running the
>>>>>>  components in the framework folder independently from anything
>>>>>> else in
>>>>>>  OFBiz. Right away the problem with that idea is that visual
>>>>>> themes are
>>>>>>  in a separate folder outside the framework folder. Does framework
>>>>>>  independence include the visual themes folder? That has not been
>>>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>>>  applications folder.
>>>>>>         
>>>>> I'm a newbie here, but I have a lot of gray hair.  Seems like
>>>>> trying to
>>>>> separate dependencies by folder or subject matter is an exercise
>>>>> doomed
>>>>> to failure.
>>>>>
>>>>> TCP/IP has taken over the world because it has a clear model based on
>>>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>>>> means to map IP addresses to hostnames at the application layer--
>>>>> TCP/IP
>>>>> doesn't care.
>>>>>
>>>>>     
>>>>>> From my perspective, achieving this objective will require a two
>>>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>>>  outside components.
>>>>>>         
>>>>> This assumes the "framework" is the lowest level.  If the framework
>>>>> depends on outside components, then the hierarchy has been upset, and
>>>>> spaghetti dependencies are the inevitable result.  Dependencies
>>>>> HAVE to
>>>>> be unidirectional, or you never get out of the maze.  IMHO, the
>>>>> biggest
>>>>> problem with MVC is that it has never seemed to me that the layers are
>>>>> very well defined.  Everything seems pretty interdependent, and you
>>>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>>>> describe.
>>>>>
>>>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>>>> is very detailed charts that seem to obfuscate, rather than
>>>>> clarify, the
>>>>> relationships of the various modules.  But I'm sure I have not seen
>>>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>>>
>>>>>     
>>>>>> The first prong can be accomplished through contributions from people
>>>>>>  like you - find the dependencies and create patches to fix them.
>>>>>>
>>>>>> The responsibility of the second prong is up to the committers. We
>>>>>> need
>>>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>>>         
>>>>> Which requires a clear model of what layer the code under
>>>>> consideration
>>>>> belongs to, and what are the well-defined layers below it that can be
>>>>> dependencies.
>>>>>     
>>>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>>>  obstacles to overcome will be getting people to contribute to the
>>>>>>  effort, and getting committers to avoid introducing new
>>>>>> dependencies.
>>>>>>         
>>>>> Again, I think we need to reduce the learning curve by providing clear
>>>>> maps.  You shouldn't need to know everything to be able to contribute
>>>>> meaningful and error-free code.
>>>>>     
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>       
>>>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>>>> Subject: what a mess! is framework independence ever going to be
>>>>>>> possible?
>>>>>>> To: user@ofbiz.apache.org
>>>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>>>> I'm back to the process of working
>>>>>>> out how to get a standalone framework running based on
>>>>>>> trunk, but I have found that the dependencies have got out
>>>>>>> of hand (if I've understood the code right):
>>>>>>>
>>>>>>> Framework  depends on Themes
>>>>>>> Themes depends on Content
>>>>>>> Content depends on Party
>>>>>>>
>>>>>>> The questions I'm starting to ask myself are:
>>>>>>>
>>>>>>> "Is is ever going to be possible to have framework
>>>>>>> independence in trunk?  Independence in 9.04 is
>>>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>>>> back port all framework related commits from trunk? "
>>>>>>>
>>>>>>> Any ideas anyone?
>>>>>>>
>>>>>>> Many thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>>         
>>>>> -- 
>>>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>>>> RidgeCrest Herbals, Inc.
>>>>>
>>>>>
>>>>>       
>>
> 
> 

Re: what a mess! is framework independence ever going to be possible?

[Christopher Snow <sn...@snowconsulting.co.uk>]

Good work Bruno!  I'm putting some thought into the dependency issues - 
I will provide some more feedback when I have a clearer view.  However, 
my current view is this: 

1) Developers should be able have a standalone framework
2) Developers should be able to install components to meet certain 
functional areas without having to install most of the other 
components.  E.g. install WorkEffort as a standalone component without 
having to install Accounting, Party management, etc.

The current implementation of ofbiz does not support (2) without 
breaking each component up into a number of smaller modules such as:

WorkEffortCore module (has no external dependency)
WorkEffortFixedAsset module (requires FixedAsset core module)
WorkEffortParties module (requires Party core module)

Option (2) would give maximum reuse of code and would facilitate 
developers in learning ofbiz as they would only need to focus on the 
business processes within those modules.

Anyway, I'm going to play around with the above concept when I have time...


Bruno Busco wrote:
> The complete url for the confluence page is:
> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
>
>
> 2010/2/6 Bruno Busco <br...@gmail.com>:
>   
>> I have updated the framework-only confluence page with an excel sheet
>> that we could use to track the dependecies issue down.
>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>>
>> Hope this helps. It is not yet completed.
>> Please fille free to contribute to update it.
>> The black "X" are dependecies that we want in the code base.
>> The red "X" are dependencies that are there but should not.
>>
>> -Bruno
>>
>> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>>     
>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>>       
>>>> Chris,
>>>>
>>>> Framework independence has been a goal for quite a while. There is no
>>>>  disagreement that the framework should run on its own. The
>>>>  disagreements arise in what constitutes the framework.
>>>>
>>>> Let's assume for a moment that framework independence means running the
>>>>  components in the framework folder independently from anything else in
>>>>  OFBiz. Right away the problem with that idea is that visual themes are
>>>>  in a separate folder outside the framework folder. Does framework
>>>>  independence include the visual themes folder? That has not been
>>>>  discussed. Then there are the multitude of dependencies upon the
>>>>  applications folder.
>>>>         
>>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>>> separate dependencies by folder or subject matter is an exercise doomed
>>> to failure.
>>>
>>> TCP/IP has taken over the world because it has a clear model based on
>>> separate layers (the 7-layer OSI model).  Changes on one level (like
>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>>> means to map IP addresses to hostnames at the application layer-- TCP/IP
>>> doesn't care.
>>>
>>>       
>>>> From my perspective, achieving this objective will require a two
>>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>>  components, and 2) avoid introducing new framework dependencies on
>>>>  outside components.
>>>>         
>>> This assumes the "framework" is the lowest level.  If the framework
>>> depends on outside components, then the hierarchy has been upset, and
>>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>>> problem with MVC is that it has never seemed to me that the layers are
>>> very well defined.  Everything seems pretty interdependent, and you
>>> quickly get into a rock/paper/scissors kind of analysis, as you
>>> describe.
>>>
>>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>>> is very detailed charts that seem to obfuscate, rather than clarify, the
>>> relationships of the various modules.  But I'm sure I have not seen
>>> everything.  Is there a 30,000-foot overview of the software levels?
>>>
>>>       
>>>> The first prong can be accomplished through contributions from people
>>>>  like you - find the dependencies and create patches to fix them.
>>>>
>>>> The responsibility of the second prong is up to the committers. We need
>>>>  to be more vigilant to guard against introducing new dependencies.
>>>>         
>>> Which requires a clear model of what layer the code under consideration
>>> belongs to, and what are the well-defined layers below it that can be
>>> dependencies.
>>>       
>>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>>  obstacles to overcome will be getting people to contribute to the
>>>>  effort, and getting committers to avoid introducing new dependencies.
>>>>         
>>> Again, I think we need to reduce the learning curve by providing clear
>>> maps.  You shouldn't need to know everything to be able to contribute
>>> meaningful and error-free code.
>>>       
>>>> -Adrian
>>>>
>>>>
>>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
>>>>
>>>>         
>>>>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>>>>> Subject: what a mess! is framework independence ever going to be possible?
>>>>> To: user@ofbiz.apache.org
>>>>> Date: Friday, February 5, 2010, 10:58 PM
>>>>> I'm back to the process of working
>>>>> out how to get a standalone framework running based on
>>>>> trunk, but I have found that the dependencies have got out
>>>>> of hand (if I've understood the code right):
>>>>>
>>>>> Framework  depends on Themes
>>>>> Themes depends on Content
>>>>> Content depends on Party
>>>>>
>>>>> The questions I'm starting to ask myself are:
>>>>>
>>>>> "Is is ever going to be possible to have framework
>>>>> independence in trunk?  Independence in 9.04 is
>>>>> relatively trivial (rewrite security screens) perhaps the
>>>>> most sensible thing would be to do a fork of 9.04 and then
>>>>> back port all framework related commits from trunk? "
>>>>>
>>>>> Any ideas anyone?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>>           
>>>>
>>>>         
>>> --
>>> Matt Warnock <mw...@ridgecrestherbals.com>
>>> RidgeCrest Herbals, Inc.
>>>
>>>
>>>       

Re: what a mess! is framework independence ever going to be possible?

[Bruno Busco <br...@gmail.com>]

The complete url for the confluence page is:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution


2010/2/6 Bruno Busco <br...@gmail.com>:
> I have updated the framework-only confluence page with an excel sheet
> that we could use to track the dependecies issue down.
> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1
>
> Hope this helps. It is not yet completed.
> Please fille free to contribute to update it.
> The black "X" are dependecies that we want in the code base.
> The red "X" are dependencies that are there but should not.
>
> -Bruno
>
> 2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>>> Chris,
>>>
>>> Framework independence has been a goal for quite a while. There is no
>>>  disagreement that the framework should run on its own. The
>>>  disagreements arise in what constitutes the framework.
>>>
>>> Let's assume for a moment that framework independence means running the
>>>  components in the framework folder independently from anything else in
>>>  OFBiz. Right away the problem with that idea is that visual themes are
>>>  in a separate folder outside the framework folder. Does framework
>>>  independence include the visual themes folder? That has not been
>>>  discussed. Then there are the multitude of dependencies upon the
>>>  applications folder.
>>
>> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
>> separate dependencies by folder or subject matter is an exercise doomed
>> to failure.
>>
>> TCP/IP has taken over the world because it has a clear model based on
>> separate layers (the 7-layer OSI model).  Changes on one level (like
>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
>> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
>> means to map IP addresses to hostnames at the application layer-- TCP/IP
>> doesn't care.
>>
>>> From my perspective, achieving this objective will require a two
>>>  pronged approach: 1) Identify the framework dependencies on outside
>>>  components, and 2) avoid introducing new framework dependencies on
>>>  outside components.
>>
>> This assumes the "framework" is the lowest level.  If the framework
>> depends on outside components, then the hierarchy has been upset, and
>> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
>> be unidirectional, or you never get out of the maze.  IMHO, the biggest
>> problem with MVC is that it has never seemed to me that the layers are
>> very well defined.  Everything seems pretty interdependent, and you
>> quickly get into a rock/paper/scissors kind of analysis, as you
>> describe.
>>
>> Is there a comprehensible map of the layers in OFBiz?  All I have seen
>> is very detailed charts that seem to obfuscate, rather than clarify, the
>> relationships of the various modules.  But I'm sure I have not seen
>> everything.  Is there a 30,000-foot overview of the software levels?
>>
>>> The first prong can be accomplished through contributions from people
>>>  like you - find the dependencies and create patches to fix them.
>>>
>>> The responsibility of the second prong is up to the committers. We need
>>>  to be more vigilant to guard against introducing new dependencies.
>>
>> Which requires a clear model of what layer the code under consideration
>> belongs to, and what are the well-defined layers below it that can be
>> dependencies.
>>>
>>> Personally I believe it will be possible, BUT it won't be easy. The
>>>  obstacles to overcome will be getting people to contribute to the
>>>  effort, and getting committers to avoid introducing new dependencies.
>>
>> Again, I think we need to reduce the learning curve by providing clear
>> maps.  You shouldn't need to know everything to be able to contribute
>> meaningful and error-free code.
>>>
>>> -Adrian
>>>
>>>
>>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
>>>
>>> > From: Christopher Snow <sn...@snowconsulting.co.uk>
>>> > Subject: what a mess! is framework independence ever going to be possible?
>>> > To: user@ofbiz.apache.org
>>> > Date: Friday, February 5, 2010, 10:58 PM
>>> > I'm back to the process of working
>>> > out how to get a standalone framework running based on
>>> > trunk, but I have found that the dependencies have got out
>>> > of hand (if I've understood the code right):
>>> >
>>> > Framework  depends on Themes
>>> > Themes depends on Content
>>> > Content depends on Party
>>> >
>>> > The questions I'm starting to ask myself are:
>>> >
>>> > "Is is ever going to be possible to have framework
>>> > independence in trunk?  Independence in 9.04 is
>>> > relatively trivial (rewrite security screens) perhaps the
>>> > most sensible thing would be to do a fork of 9.04 and then
>>> > back port all framework related commits from trunk? "
>>> >
>>> > Any ideas anyone?
>>> >
>>> > Many thanks,
>>> >
>>> > Chris
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> Matt Warnock <mw...@ridgecrestherbals.com>
>> RidgeCrest Herbals, Inc.
>>
>>
>

Re: what a mess! is framework independence ever going to be possible?

[Bruno Busco <br...@gmail.com>]

I have updated the framework-only confluence page with an excel sheet
that we could use to track the dependecies issue down.
http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1

Hope this helps. It is not yet completed.
Please fille free to contribute to update it.
The black "X" are dependecies that we want in the code base.
The red "X" are dependencies that are there but should not.

-Bruno

2010/2/6 Matt Warnock <mw...@ridgecrestherbals.com>:
> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
>> Chris,
>>
>> Framework independence has been a goal for quite a while. There is no
>>  disagreement that the framework should run on its own. The
>>  disagreements arise in what constitutes the framework.
>>
>> Let's assume for a moment that framework independence means running the
>>  components in the framework folder independently from anything else in
>>  OFBiz. Right away the problem with that idea is that visual themes are
>>  in a separate folder outside the framework folder. Does framework
>>  independence include the visual themes folder? That has not been
>>  discussed. Then there are the multitude of dependencies upon the
>>  applications folder.
>
> I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
> separate dependencies by folder or subject matter is an exercise doomed
> to failure.
>
> TCP/IP has taken over the world because it has a clear model based on
> separate layers (the 7-layer OSI model).  Changes on one level (like
> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
> rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
> means to map IP addresses to hostnames at the application layer-- TCP/IP
> doesn't care.
>
>> From my perspective, achieving this objective will require a two
>>  pronged approach: 1) Identify the framework dependencies on outside
>>  components, and 2) avoid introducing new framework dependencies on
>>  outside components.
>
> This assumes the "framework" is the lowest level.  If the framework
> depends on outside components, then the hierarchy has been upset, and
> spaghetti dependencies are the inevitable result.  Dependencies HAVE to
> be unidirectional, or you never get out of the maze.  IMHO, the biggest
> problem with MVC is that it has never seemed to me that the layers are
> very well defined.  Everything seems pretty interdependent, and you
> quickly get into a rock/paper/scissors kind of analysis, as you
> describe.
>
> Is there a comprehensible map of the layers in OFBiz?  All I have seen
> is very detailed charts that seem to obfuscate, rather than clarify, the
> relationships of the various modules.  But I'm sure I have not seen
> everything.  Is there a 30,000-foot overview of the software levels?
>
>> The first prong can be accomplished through contributions from people
>>  like you - find the dependencies and create patches to fix them.
>>
>> The responsibility of the second prong is up to the committers. We need
>>  to be more vigilant to guard against introducing new dependencies.
>
> Which requires a clear model of what layer the code under consideration
> belongs to, and what are the well-defined layers below it that can be
> dependencies.
>>
>> Personally I believe it will be possible, BUT it won't be easy. The
>>  obstacles to overcome will be getting people to contribute to the
>>  effort, and getting committers to avoid introducing new dependencies.
>
> Again, I think we need to reduce the learning curve by providing clear
> maps.  You shouldn't need to know everything to be able to contribute
> meaningful and error-free code.
>>
>> -Adrian
>>
>>
>> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
>>
>> > From: Christopher Snow <sn...@snowconsulting.co.uk>
>> > Subject: what a mess! is framework independence ever going to be possible?
>> > To: user@ofbiz.apache.org
>> > Date: Friday, February 5, 2010, 10:58 PM
>> > I'm back to the process of working
>> > out how to get a standalone framework running based on
>> > trunk, but I have found that the dependencies have got out
>> > of hand (if I've understood the code right):
>> >
>> > Framework  depends on Themes
>> > Themes depends on Content
>> > Content depends on Party
>> >
>> > The questions I'm starting to ask myself are:
>> >
>> > "Is is ever going to be possible to have framework
>> > independence in trunk?  Independence in 9.04 is
>> > relatively trivial (rewrite security screens) perhaps the
>> > most sensible thing would be to do a fork of 9.04 and then
>> > back port all framework related commits from trunk? "
>> >
>> > Any ideas anyone?
>> >
>> > Many thanks,
>> >
>> > Chris
>> >
>>
>>
>>
>
>
> --
> Matt Warnock <mw...@ridgecrestherbals.com>
> RidgeCrest Herbals, Inc.
>
>

Re: what a mess! is framework independence ever going to be possible?

[Matt Warnock <mw...@ridgecrestherbals.com>]

On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote:
> Chris,
> 
> Framework independence has been a goal for quite a while. There is no
>  disagreement that the framework should run on its own. The
>  disagreements arise in what constitutes the framework.
> 
> Let's assume for a moment that framework independence means running the
>  components in the framework folder independently from anything else in
>  OFBiz. Right away the problem with that idea is that visual themes are
>  in a separate folder outside the framework folder. Does framework
>  independence include the visual themes folder? That has not been
>  discussed. Then there are the multitude of dependencies upon the
>  applications folder.

I'm a newbie here, but I have a lot of gray hair.  Seems like trying to
separate dependencies by folder or subject matter is an exercise doomed
to failure.  

TCP/IP has taken over the world because it has a clear model based on
separate layers (the 7-layer OSI model).  Changes on one level (like
10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the
rest.  Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other
means to map IP addresses to hostnames at the application layer-- TCP/IP
doesn't care.

> From my perspective, achieving this objective will require a two
>  pronged approach: 1) Identify the framework dependencies on outside
>  components, and 2) avoid introducing new framework dependencies on
>  outside components. 

This assumes the "framework" is the lowest level.  If the framework
depends on outside components, then the hierarchy has been upset, and
spaghetti dependencies are the inevitable result.  Dependencies HAVE to
be unidirectional, or you never get out of the maze.  IMHO, the biggest
problem with MVC is that it has never seemed to me that the layers are
very well defined.  Everything seems pretty interdependent, and you
quickly get into a rock/paper/scissors kind of analysis, as you
describe.

Is there a comprehensible map of the layers in OFBiz?  All I have seen
is very detailed charts that seem to obfuscate, rather than clarify, the
relationships of the various modules.  But I'm sure I have not seen
everything.  Is there a 30,000-foot overview of the software levels?
 
> The first prong can be accomplished through contributions from people
>  like you - find the dependencies and create patches to fix them.
> 
> The responsibility of the second prong is up to the committers. We need
>  to be more vigilant to guard against introducing new dependencies.

Which requires a clear model of what layer the code under consideration
belongs to, and what are the well-defined layers below it that can be
dependencies.
> 
> Personally I believe it will be possible, BUT it won't be easy. The
>  obstacles to overcome will be getting people to contribute to the
>  effort, and getting committers to avoid introducing new dependencies.

Again, I think we need to reduce the learning curve by providing clear
maps.  You shouldn't need to know everything to be able to contribute
meaningful and error-free code.
> 
> -Adrian
> 
> 
> --- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
> 
> > From: Christopher Snow <sn...@snowconsulting.co.uk>
> > Subject: what a mess! is framework independence ever going to be possible?
> > To: user@ofbiz.apache.org
> > Date: Friday, February 5, 2010, 10:58 PM
> > I'm back to the process of working
> > out how to get a standalone framework running based on
> > trunk, but I have found that the dependencies have got out
> > of hand (if I've understood the code right):
> > 
> > Framework  depends on Themes
> > Themes depends on Content
> > Content depends on Party
> > 
> > The questions I'm starting to ask myself are:
> > 
> > "Is is ever going to be possible to have framework
> > independence in trunk?  Independence in 9.04 is
> > relatively trivial (rewrite security screens) perhaps the
> > most sensible thing would be to do a fork of 9.04 and then
> > back port all framework related commits from trunk? "
> > 
> > Any ideas anyone?
> > 
> > Many thanks,
> > 
> > Chris
> > 
> 
> 
>       


-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

Re: what a mess! is framework independence ever going to be possible?

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

Chris,

Framework independence has been a goal for quite a while. There is no disagreement that the framework should run on its own. The disagreements arise in what constitutes the framework.

Let's assume for a moment that framework independence means running the components in the framework folder independently from anything else in OFBiz. Right away the problem with that idea is that visual themes are in a separate folder outside the framework folder. Does framework independence include the visual themes folder? That has not been discussed. Then there are the multitude of dependencies upon the applications folder.

From my perspective, achieving this objective will require a two pronged approach: 1) Identify the framework dependencies on outside components, and 2) avoid introducing new framework dependencies on outside components. 

The first prong can be accomplished through contributions from people like you - find the dependencies and create patches to fix them.

The responsibility of the second prong is up to the committers. We need to be more vigilant to guard against introducing new dependencies.

Personally I believe it will be possible, BUT it won't be easy. The obstacles to overcome will be getting people to contribute to the effort, and getting committers to avoid introducing new dependencies.

-Adrian


--- On Fri, 2/5/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:

> From: Christopher Snow <sn...@snowconsulting.co.uk>
> Subject: what a mess! is framework independence ever going to be possible?
> To: user@ofbiz.apache.org
> Date: Friday, February 5, 2010, 10:58 PM
> I'm back to the process of working
> out how to get a standalone framework running based on
> trunk, but I have found that the dependencies have got out
> of hand (if I've understood the code right):
> 
> Framework  depends on Themes
> Themes depends on Content
> Content depends on Party
> 
> The questions I'm starting to ask myself are:
> 
> "Is is ever going to be possible to have framework
> independence in trunk?  Independence in 9.04 is
> relatively trivial (rewrite security screens) perhaps the
> most sensible thing would be to do a fork of 9.04 and then
> back port all framework related commits from trunk? "
> 
> Any ideas anyone?
> 
> Many thanks,
> 
> Chris
>