Moving commonext from applycations to specialpurpose

[Jacopo Cappellato-4]

Do you agree that specialpurpose would be a better fit for the commonext component that is currently under the applications folder?
It extends the default data model adding new fields to the NoteData entity and provides some special purpose features.

Jacopo

[taher]

Hi Jacopo,

Almost all applications including core applications use the
ApplicationDecorator screen found in CommonExt. I believe many items depend
on CommonExt and you will find the below code snippet pretty much in all
CommonScreens.xml files.

<widgets>
    <include-screen name="ApplicationDecorator"
location="component://commonext/widget/CommonScreens.xml"/>
</widgets>

It also provides data essential to theme headers and footers, and provides
additional resources including UI labels for all components and it is also
responsible for the contextual help system. I think removing it will break
your applications unless you do a lot of rewiring. I think this is not a
simple folder move.

Taher Alkhateeb

On Sun, Nov 23, 2014 at 10:26 AM, Jacopo Cappellato <
[hidden email]> wrote:

> Do you agree that specialpurpose would be a better fit for the commonext
> component that is currently under the applications folder?
> It extends the default data model adding new fields to the NoteData entity
> and provides some special purpose features.
>
> Jacopo
>
>

[Jacques Le Roux]

I agree with Taher, I already gave my thought here https://issues.apache.org/jira/browse/OFBIZ-3329?focusedCommentId=14151214

BTW this also reminds me about http://markmail.org/message/7m5afdqhrszxuv3q I hope someone will take care of it, Anil, Ashish?

Jacques

Le 23/11/2014 08:48, Taher Alkhateeb a écrit :

> Hi Jacopo,
>
> Almost all applications including core applications use the
> ApplicationDecorator screen found in CommonExt. I believe many items depend
> on CommonExt and you will find the below code snippet pretty much in all
> CommonScreens.xml files.
>
> <widgets>
>      <include-screen name="ApplicationDecorator"
> location="component://commonext/widget/CommonScreens.xml"/>
> </widgets>
>
> It also provides data essential to theme headers and footers, and provides
> additional resources including UI labels for all components and it is also
> responsible for the contextual help system. I think removing it will break
> your applications unless you do a lot of rewiring. I think this is not a
> simple folder move.
>
> Taher Alkhateeb
>
> On Sun, Nov 23, 2014 at 10:26 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Do you agree that specialpurpose would be a better fit for the commonext
>> component that is currently under the applications folder?
>> It extends the default data model adding new fields to the NoteData entity
>> and provides some special purpose features.
>>
>> Jacopo
>>
>>

[Pierre Smits]

Hi all,

IIRW, components like commonext, securityext and entityext were constructed
and implemented by the community to enable developers (users/contributors)
to extend the functionalities in lower level components (services et al)
and create commonalities that can be shared between components on the same
and/or higher level, so that the lower level functionalities change as
little as possible.

Thus leading to:

   -  hot--deploy extends (and/or uses) hot-deploy, special purpose, apps &
   framework components
   - special purpose extends (and/or uses) special purpose,  apps &
   framework components
   - apps extends (and/or uses) apps & framework components
   - framework extends (and/or uses) framework components

Examples are:
Manufacturing extends workeffort, party, etc
ProjectMgr extends workeffort, party, etc

Such a paradigm is easy to understand, and creates the least amount of
confusion (for the developer, tester, etc) when having to resolve issues
relating to dependencies. If and when we move a lower level component to a
higher lever, we increase this confusion. This should be avoided as much as
possible, because removing the confusion leads to (more) rework.

As Taher explained in his posting there are same and higher level
dependencies on commonext. Reworking that, in order to maintain the
paradigm described above, will require a lot of effort and takes a lot of
time to have it completed. Are we willing to go there? Can we achieve that
in a reasonable amount of time? Is that needed?

We haven't seen many contributions to this component. That is true. It is a
placeholder, provided by this community, that enables each users to extend
for their own purposes. Period.
That no enhancements/improvements to this component make their way back
into the project may indicate two things:

   1. The component works perfectly regarding its intent.
   2. People don't feel the need to share what they have in their own
   version

Re 1: Kudos to all who have come up with the paradigm and have it
implemented in OFBiz.

Re 2: Maybe that is because what is share regarding this is included in the
OFBiz code as an enhancement to a component on a lower level. Maybe that is
because what the individual user has in his component is subject to an NDA.
Or the user believes that what he has is so specific that he considers that
functionality of totally no use for others.
Such are the facts of life, and I accept that. This is the prerogative that
each of us has!

So, let it be where it is and don't worry about it. Cost of maintenance (as
it is) is low.

And the above applies to securityext as well.

Now, if there is a dependency on a higher level component (and there is one
in this component, IIRW), we - as the community - should fix this specific
issue. That would indicate that we move stuff from lower to higher.
If the component has stuff that we feel is better to have in another
component on the same level, we can fix that too. When talking about the
NoteData entity (and accompanying functions), I believe we should have this
moved to content.

But what about entityext?
Following the paradigm outlined above, this shouldn't be in framework, but
at the next higher level (apps). Shouldn't we move that one?

And what about the other components in framework, that enables users to
interact with OFBiz? We have webtools containing stuff regarding base data
manipulation feature, and more. Shouldn't that move to apps (or higher) as
well? Like I initiated with

On the other hand, we have a component in special purpose that extends base
authentication and integration. This component is called ldap. Shouldn't
functionalities in there move to the lowest level?

And shouldn't we move the functionalities in the lucene component in
special purpose move to the apps level? It seems to be a better fit there.

My apologies for the lengthiness of this post. Couldn't do it in a shorter
way. Anyway, a clear and shared vision helps us all. Discussing pros and
cons of viewpoints help to get there.

Regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
[hidden email]> wrote:

> Do you agree that specialpurpose would be a better fit for the commonext
> component that is currently under the applications folder?
> It extends the default data model adding new fields to the NoteData entity
> and provides some special purpose features.
>
> Jacopo
>
>

[Pierre Smits]

Somewhere in my previous post I started a sentence with:

Like I initiated


This was incomplete and should have been:

Like I initiated with https://issues.apache.org/jira/browse/OFBIZ-5812

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sun, Nov 23, 2014 at 10:52 AM, Jacques Le Roux <
[hidden email]> wrote:

> I agree with Taher, I already gave my thought here
> https://issues.apache.org/jira/browse/OFBIZ-3329?focusedCommentId=14151214
>
> BTW this also reminds me about http://markmail.org/message/
> 7m5afdqhrszxuv3q I hope someone will take care of it, Anil, Ashish?
>
> Jacques
>
> Le 23/11/2014 08:48, Taher Alkhateeb a écrit :
>
>  Hi Jacopo,
>>
>> Almost all applications including core applications use the
>> ApplicationDecorator screen found in CommonExt. I believe many items
>> depend
>> on CommonExt and you will find the below code snippet pretty much in all
>> CommonScreens.xml files.
>>
>> <widgets>
>>      <include-screen name="ApplicationDecorator"
>> location="component://commonext/widget/CommonScreens.xml"/>
>> </widgets>
>>
>> It also provides data essential to theme headers and footers, and provides
>> additional resources including UI labels for all components and it is also
>> responsible for the contextual help system. I think removing it will break
>> your applications unless you do a lot of rewiring. I think this is not a
>> simple folder move.
>>
>> Taher Alkhateeb
>>
>> On Sun, Nov 23, 2014 at 10:26 AM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>>  Do you agree that specialpurpose would be a better fit for the commonext
>>> component that is currently under the applications folder?
>>> It extends the default data model adding new fields to the NoteData
>>> entity
>>> and provides some special purpose features.
>>>
>>> Jacopo
>>>
>>>
>>>

[Jacopo Cappellato-4]

Thank you Taher,

you are right about these dependencies and it is important that we keep the artifact that you have mentioned under applications.
What confuses me is the fact that this commonext component should be loaded before the other application components (because it is used by them) but it is instead loaded as last; and in fact it extends some of the code from other application components: I suspect that the component contains some artifacts that we should moved elsewhere (e.g. to specialpurpose or to other applications, as mentioned by Pierre).
This goal should be rather easy to achieve (but I still need to study the details of it) and we should be able to implement an architecture like the following (some stupid ascii art):

accounting | order | product | ...
------------------------------------------
                commonext
------------------------------------------
                framework

The above should be inline with your description of it.

Regards,

Jacopo


On Nov 23, 2014, at 8:48 AM, Taher Alkhateeb <[hidden email]> wrote:

> Hi Jacopo,
>
> Almost all applications including core applications use the
> ApplicationDecorator screen found in CommonExt. I believe many items depend
> on CommonExt and you will find the below code snippet pretty much in all
> CommonScreens.xml files.
>
> <widgets>
>    <include-screen name="ApplicationDecorator"
> location="component://commonext/widget/CommonScreens.xml"/>
> </widgets>
>
> It also provides data essential to theme headers and footers, and provides
> additional resources including UI labels for all components and it is also
> responsible for the contextual help system. I think removing it will break
> your applications unless you do a lot of rewiring. I think this is not a
> simple folder move.
>
> Taher Alkhateeb
>
> On Sun, Nov 23, 2014 at 10:26 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Do you agree that specialpurpose would be a better fit for the commonext
>> component that is currently under the applications folder?
>> It extends the default data model adding new fields to the NoteData entity
>> and provides some special purpose features.
>>
>> Jacopo
>>
>>

[Jacopo Cappellato-4]

Thanks Pierre for the description.

My goal is not actually that of removing an unused component, but instead trying to come up with an architecture that with little effort and no major changes would let us deliver the following products:

*OFBiz framework*
Structure: it includes only the framework components, the tools, hot-deploy and runtime folders; only a few entities are defined (the ones declared by the framework components, of course); no applications, no specialpurpose; the only user interface available ootb is WebTools.
Purpose: provide a framework to build ERP-like applications from scratch; typically a developer will start by running the "ant create-component" task and will then declare the entities, services and screens in the custom component

*OFBiz core*
Structure: it contains one application component (this could be the commonext component, after it has been cleaned up) that only contains all the entity definitions (the whole data model) that are currently defined in the various applications; it will also include CRUD or basic and very global/generic services; no user interfaces
Purpose: to be used with the "OFBiz framework" by users interested in building from scratch user interfaces based on the OFBiz data model and crud services

*OFBiz applications*
Structure: it contains all the existing applications (except the component delivered as "OFBiz core") with their special services and user interfaces
Purpose: to be used by users interested to running a mostly-ready out of the box solution; to be used with the "OFBiz framework" and "OFBiz core"

*OFBiz specialpurpose*
Structure: it contains all the existing specialpurpose components with their special services and user interfaces
Purpose: to be used by users interested in specific integrations/solutions solution; to be used with the "OFBiz framework" and (maybe) "OFBiz core"; the user could use a subset of the specialpurpose components

What we currently call "Apache OFBiz" would be the sum of the following products:
"OFBiz framework" +
"OFBiz core" +
"OFBiz applications" +
"OFBiz specialpurpose"

We could even merge together "OFBiz applications" and "OFBiz specialpurpose" into one group, the applications, if we can provide some good way to represent the dependencies among them: we could let the user decide which components should be enabled.

I am convinced that we could achieve this goal with a reasonable effort and this could be a first step in the direction of making OFBiz more modular; we could then design and implement further improvements.

Jacopo


On Nov 23, 2014, at 1:01 PM, Pierre Smits <[hidden email]> wrote:

> Hi all,
>
> IIRW, components like commonext, securityext and entityext were constructed
> and implemented by the community to enable developers (users/contributors)
> to extend the functionalities in lower level components (services et al)
> and create commonalities that can be shared between components on the same
> and/or higher level, so that the lower level functionalities change as
> little as possible.
>
> Thus leading to:
>
>   -  hot--deploy extends (and/or uses) hot-deploy, special purpose, apps &
>   framework components
>   - special purpose extends (and/or uses) special purpose,  apps &
>   framework components
>   - apps extends (and/or uses) apps & framework components
>   - framework extends (and/or uses) framework components
>
> Examples are:
> Manufacturing extends workeffort, party, etc
> ProjectMgr extends workeffort, party, etc
>
> Such a paradigm is easy to understand, and creates the least amount of
> confusion (for the developer, tester, etc) when having to resolve issues
> relating to dependencies. If and when we move a lower level component to a
> higher lever, we increase this confusion. This should be avoided as much as
> possible, because removing the confusion leads to (more) rework.
>
> As Taher explained in his posting there are same and higher level
> dependencies on commonext. Reworking that, in order to maintain the
> paradigm described above, will require a lot of effort and takes a lot of
> time to have it completed. Are we willing to go there? Can we achieve that
> in a reasonable amount of time? Is that needed?
>
> We haven't seen many contributions to this component. That is true. It is a
> placeholder, provided by this community, that enables each users to extend
> for their own purposes. Period.
> That no enhancements/improvements to this component make their way back
> into the project may indicate two things:
>
>   1. The component works perfectly regarding its intent.
>   2. People don't feel the need to share what they have in their own
>   version
>
> Re 1: Kudos to all who have come up with the paradigm and have it
> implemented in OFBiz.
>
> Re 2: Maybe that is because what is share regarding this is included in the
> OFBiz code as an enhancement to a component on a lower level. Maybe that is
> because what the individual user has in his component is subject to an NDA.
> Or the user believes that what he has is so specific that he considers that
> functionality of totally no use for others.
> Such are the facts of life, and I accept that. This is the prerogative that
> each of us has!
>
> So, let it be where it is and don't worry about it. Cost of maintenance (as
> it is) is low.
>
> And the above applies to securityext as well.
>
> Now, if there is a dependency on a higher level component (and there is one
> in this component, IIRW), we - as the community - should fix this specific
> issue. That would indicate that we move stuff from lower to higher.
> If the component has stuff that we feel is better to have in another
> component on the same level, we can fix that too. When talking about the
> NoteData entity (and accompanying functions), I believe we should have this
> moved to content.
>
> But what about entityext?
> Following the paradigm outlined above, this shouldn't be in framework, but
> at the next higher level (apps). Shouldn't we move that one?
>
> And what about the other components in framework, that enables users to
> interact with OFBiz? We have webtools containing stuff regarding base data
> manipulation feature, and more. Shouldn't that move to apps (or higher) as
> well? Like I initiated with
>
> On the other hand, we have a component in special purpose that extends base
> authentication and integration. This component is called ldap. Shouldn't
> functionalities in there move to the lowest level?
>
> And shouldn't we move the functionalities in the lucene component in
> special purpose move to the apps level? It seems to be a better fit there.
>
> My apologies for the lengthiness of this post. Couldn't do it in a shorter
> way. Anyway, a clear and shared vision helps us all. Discussing pros and
> cons of viewpoints help to get there.
>
> Regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Do you agree that specialpurpose would be a better fit for the commonext
>> component that is currently under the applications folder?
>> It extends the default data model adding new fields to the NoteData entity
>> and provides some special purpose features.
>>
>> Jacopo
>>
>>

[Pierre Smits]

Jacopo, All,

You and I are in sync here, with respect to how the components in the
various levels stack up to be the primary work of the OFBiz project. I also
agree that this can be achieved in a reasonable amount of time and effort
spent.

Having svn repositories per layer plays into this approach. That also helps
to attract more committers (regarding code) so that this project retains
the level of quality it requires. And it seems to be inline to what Ron is
trying to bring across.

But this approach will only work if we all consent to it.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sun, Nov 23, 2014 at 7:37 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Thanks Pierre for the description.
>
> My goal is not actually that of removing an unused component, but instead
> trying to come up with an architecture that with little effort and no major
> changes would let us deliver the following products:
>
> *OFBiz framework*
> Structure: it includes only the framework components, the tools,
> hot-deploy and runtime folders; only a few entities are defined (the ones
> declared by the framework components, of course); no applications, no
> specialpurpose; the only user interface available ootb is WebTools.
> Purpose: provide a framework to build ERP-like applications from scratch;
> typically a developer will start by running the "ant create-component" task
> and will then declare the entities, services and screens in the custom
> component
>
> *OFBiz core*
> Structure: it contains one application component (this could be the
> commonext component, after it has been cleaned up) that only contains all
> the entity definitions (the whole data model) that are currently defined in
> the various applications; it will also include CRUD or basic and very
> global/generic services; no user interfaces
> Purpose: to be used with the "OFBiz framework" by users interested in
> building from scratch user interfaces based on the OFBiz data model and
> crud services
>
> *OFBiz applications*
> Structure: it contains all the existing applications (except the component
> delivered as "OFBiz core") with their special services and user interfaces
> Purpose: to be used by users interested to running a mostly-ready out of
> the box solution; to be used with the "OFBiz framework" and "OFBiz core"
>
> *OFBiz specialpurpose*
> Structure: it contains all the existing specialpurpose components with
> their special services and user interfaces
> Purpose: to be used by users interested in specific integrations/solutions
> solution; to be used with the "OFBiz framework" and (maybe) "OFBiz core";
> the user could use a subset of the specialpurpose components
>
> What we currently call "Apache OFBiz" would be the sum of the following
> products:
> "OFBiz framework" +
> "OFBiz core" +
> "OFBiz applications" +
> "OFBiz specialpurpose"
>
> We could even merge together "OFBiz applications" and "OFBiz
> specialpurpose" into one group, the applications, if we can provide some
> good way to represent the dependencies among them: we could let the user
> decide which components should be enabled.
>
> I am convinced that we could achieve this goal with a reasonable effort
> and this could be a first step in the direction of making OFBiz more
> modular; we could then design and implement further improvements.
>
> Jacopo
>
>
> On Nov 23, 2014, at 1:01 PM, Pierre Smits <[hidden email]> wrote:
>
> > Hi all,
> >
> > IIRW, components like commonext, securityext and entityext were
> constructed
> > and implemented by the community to enable developers
> (users/contributors)
> > to extend the functionalities in lower level components (services et al)
> > and create commonalities that can be shared between components on the
> same
> > and/or higher level, so that the lower level functionalities change as
> > little as possible.
> >
> > Thus leading to:
> >
> >   -  hot--deploy extends (and/or uses) hot-deploy, special purpose, apps
> &
> >   framework components
> >   - special purpose extends (and/or uses) special purpose,  apps &
> >   framework components
> >   - apps extends (and/or uses) apps & framework components
> >   - framework extends (and/or uses) framework components
> >
> > Examples are:
> > Manufacturing extends workeffort, party, etc
> > ProjectMgr extends workeffort, party, etc
> >
> > Such a paradigm is easy to understand, and creates the least amount of
> > confusion (for the developer, tester, etc) when having to resolve issues
> > relating to dependencies. If and when we move a lower level component to
> a
> > higher lever, we increase this confusion. This should be avoided as much
> as
> > possible, because removing the confusion leads to (more) rework.
> >
> > As Taher explained in his posting there are same and higher level
> > dependencies on commonext. Reworking that, in order to maintain the
> > paradigm described above, will require a lot of effort and takes a lot of
> > time to have it completed. Are we willing to go there? Can we achieve
> that
> > in a reasonable amount of time? Is that needed?
> >
> > We haven't seen many contributions to this component. That is true. It
> is a
> > placeholder, provided by this community, that enables each users to
> extend
> > for their own purposes. Period.
> > That no enhancements/improvements to this component make their way back
> > into the project may indicate two things:
> >
> >   1. The component works perfectly regarding its intent.
> >   2. People don't feel the need to share what they have in their own
> >   version
> >
> > Re 1: Kudos to all who have come up with the paradigm and have it
> > implemented in OFBiz.
> >
> > Re 2: Maybe that is because what is share regarding this is included in
> the
> > OFBiz code as an enhancement to a component on a lower level. Maybe that
> is
> > because what the individual user has in his component is subject to an
> NDA.
> > Or the user believes that what he has is so specific that he considers
> that
> > functionality of totally no use for others.
> > Such are the facts of life, and I accept that. This is the prerogative
> that
> > each of us has!
> >
> > So, let it be where it is and don't worry about it. Cost of maintenance
> (as
> > it is) is low.
> >
> > And the above applies to securityext as well.
> >
> > Now, if there is a dependency on a higher level component (and there is
> one
> > in this component, IIRW), we - as the community - should fix this
> specific
> > issue. That would indicate that we move stuff from lower to higher.
> > If the component has stuff that we feel is better to have in another
> > component on the same level, we can fix that too. When talking about the
> > NoteData entity (and accompanying functions), I believe we should have
> this
> > moved to content.
> >
> > But what about entityext?
> > Following the paradigm outlined above, this shouldn't be in framework,
> but
> > at the next higher level (apps). Shouldn't we move that one?
> >
> > And what about the other components in framework, that enables users to
> > interact with OFBiz? We have webtools containing stuff regarding base
> data
> > manipulation feature, and more. Shouldn't that move to apps (or higher)
> as
> > well? Like I initiated with
> >
> > On the other hand, we have a component in special purpose that extends
> base
> > authentication and integration. This component is called ldap. Shouldn't
> > functionalities in there move to the lowest level?
> >
> > And shouldn't we move the functionalities in the lucene component in
> > special purpose move to the apps level? It seems to be a better fit
> there.
> >
> > My apologies for the lengthiness of this post. Couldn't do it in a
> shorter
> > way. Anyway, a clear and shared vision helps us all. Discussing pros and
> > cons of viewpoints help to get there.
> >
> > Regards,
> >
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
> > [hidden email]> wrote:
> >
> >> Do you agree that specialpurpose would be a better fit for the commonext
> >> component that is currently under the applications folder?
> >> It extends the default data model adding new fields to the NoteData
> entity
> >> and provides some special purpose features.
> >>
> >> Jacopo
> >>
> >>
>
>

[Jacopo Cappellato-4]

On Nov 23, 2014, at 8:44 PM, Pierre Smits <[hidden email]> wrote:

> Jacopo, All,
>
> You and I are in sync here, with respect to how the components in the
> various levels stack up to be the primary work of the OFBiz project. I also
> agree that this can be achieved in a reasonable amount of time and effort
> spent.

+1

>
> Having svn repositories per layer plays into this approach.

The main advantage is that initially there is no need to modify the layout of the current svn (trunk and branches):
* the work required will be only that of fixing the dependencies between components
* then users should be able to checkout the branch they like and remove the layers they do not want and then build OFBiz successfully (e.g. with framework only OR framework+core OR framework+core+applications/specialpurpose)
* at a later time we could discuss if we also want to provide separate releases/download for the framework, the core, the applications/specialpurpose but until that time we will continue to release the whole package as it happens now

> That also helps
> to attract more committers (regarding code) so that this project retains
> the level of quality it requires. And it seems to be inline to what Ron is
> trying to bring across.
>
> But this approach will only work if we all consent to it.

+1

Best regards,

Jacopo

>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sun, Nov 23, 2014 at 7:37 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Thanks Pierre for the description.
>>
>> My goal is not actually that of removing an unused component, but instead
>> trying to come up with an architecture that with little effort and no major
>> changes would let us deliver the following products:
>>
>> *OFBiz framework*
>> Structure: it includes only the framework components, the tools,
>> hot-deploy and runtime folders; only a few entities are defined (the ones
>> declared by the framework components, of course); no applications, no
>> specialpurpose; the only user interface available ootb is WebTools.
>> Purpose: provide a framework to build ERP-like applications from scratch;
>> typically a developer will start by running the "ant create-component" task
>> and will then declare the entities, services and screens in the custom
>> component
>>
>> *OFBiz core*
>> Structure: it contains one application component (this could be the
>> commonext component, after it has been cleaned up) that only contains all
>> the entity definitions (the whole data model) that are currently defined in
>> the various applications; it will also include CRUD or basic and very
>> global/generic services; no user interfaces
>> Purpose: to be used with the "OFBiz framework" by users interested in
>> building from scratch user interfaces based on the OFBiz data model and
>> crud services
>>
>> *OFBiz applications*
>> Structure: it contains all the existing applications (except the component
>> delivered as "OFBiz core") with their special services and user interfaces
>> Purpose: to be used by users interested to running a mostly-ready out of
>> the box solution; to be used with the "OFBiz framework" and "OFBiz core"
>>
>> *OFBiz specialpurpose*
>> Structure: it contains all the existing specialpurpose components with
>> their special services and user interfaces
>> Purpose: to be used by users interested in specific integrations/solutions
>> solution; to be used with the "OFBiz framework" and (maybe) "OFBiz core";
>> the user could use a subset of the specialpurpose components
>>
>> What we currently call "Apache OFBiz" would be the sum of the following
>> products:
>> "OFBiz framework" +
>> "OFBiz core" +
>> "OFBiz applications" +
>> "OFBiz specialpurpose"
>>
>> We could even merge together "OFBiz applications" and "OFBiz
>> specialpurpose" into one group, the applications, if we can provide some
>> good way to represent the dependencies among them: we could let the user
>> decide which components should be enabled.
>>
>> I am convinced that we could achieve this goal with a reasonable effort
>> and this could be a first step in the direction of making OFBiz more
>> modular; we could then design and implement further improvements.
>>
>> Jacopo
>>
>>
>> On Nov 23, 2014, at 1:01 PM, Pierre Smits <[hidden email]> wrote:
>>
>>> Hi all,
>>>
>>> IIRW, components like commonext, securityext and entityext were
>> constructed
>>> and implemented by the community to enable developers
>> (users/contributors)
>>> to extend the functionalities in lower level components (services et al)
>>> and create commonalities that can be shared between components on the
>> same
>>> and/or higher level, so that the lower level functionalities change as
>>> little as possible.
>>>
>>> Thus leading to:
>>>
>>>  -  hot--deploy extends (and/or uses) hot-deploy, special purpose, apps
>> &
>>>  framework components
>>>  - special purpose extends (and/or uses) special purpose,  apps &
>>>  framework components
>>>  - apps extends (and/or uses) apps & framework components
>>>  - framework extends (and/or uses) framework components
>>>
>>> Examples are:
>>> Manufacturing extends workeffort, party, etc
>>> ProjectMgr extends workeffort, party, etc
>>>
>>> Such a paradigm is easy to understand, and creates the least amount of
>>> confusion (for the developer, tester, etc) when having to resolve issues
>>> relating to dependencies. If and when we move a lower level component to
>> a
>>> higher lever, we increase this confusion. This should be avoided as much
>> as
>>> possible, because removing the confusion leads to (more) rework.
>>>
>>> As Taher explained in his posting there are same and higher level
>>> dependencies on commonext. Reworking that, in order to maintain the
>>> paradigm described above, will require a lot of effort and takes a lot of
>>> time to have it completed. Are we willing to go there? Can we achieve
>> that
>>> in a reasonable amount of time? Is that needed?
>>>
>>> We haven't seen many contributions to this component. That is true. It
>> is a
>>> placeholder, provided by this community, that enables each users to
>> extend
>>> for their own purposes. Period.
>>> That no enhancements/improvements to this component make their way back
>>> into the project may indicate two things:
>>>
>>>  1. The component works perfectly regarding its intent.
>>>  2. People don't feel the need to share what they have in their own
>>>  version
>>>
>>> Re 1: Kudos to all who have come up with the paradigm and have it
>>> implemented in OFBiz.
>>>
>>> Re 2: Maybe that is because what is share regarding this is included in
>> the
>>> OFBiz code as an enhancement to a component on a lower level. Maybe that
>> is
>>> because what the individual user has in his component is subject to an
>> NDA.
>>> Or the user believes that what he has is so specific that he considers
>> that
>>> functionality of totally no use for others.
>>> Such are the facts of life, and I accept that. This is the prerogative
>> that
>>> each of us has!
>>>
>>> So, let it be where it is and don't worry about it. Cost of maintenance
>> (as
>>> it is) is low.
>>>
>>> And the above applies to securityext as well.
>>>
>>> Now, if there is a dependency on a higher level component (and there is
>> one
>>> in this component, IIRW), we - as the community - should fix this
>> specific
>>> issue. That would indicate that we move stuff from lower to higher.
>>> If the component has stuff that we feel is better to have in another
>>> component on the same level, we can fix that too. When talking about the
>>> NoteData entity (and accompanying functions), I believe we should have
>> this
>>> moved to content.
>>>
>>> But what about entityext?
>>> Following the paradigm outlined above, this shouldn't be in framework,
>> but
>>> at the next higher level (apps). Shouldn't we move that one?
>>>
>>> And what about the other components in framework, that enables users to
>>> interact with OFBiz? We have webtools containing stuff regarding base
>> data
>>> manipulation feature, and more. Shouldn't that move to apps (or higher)
>> as
>>> well? Like I initiated with
>>>
>>> On the other hand, we have a component in special purpose that extends
>> base
>>> authentication and integration. This component is called ldap. Shouldn't
>>> functionalities in there move to the lowest level?
>>>
>>> And shouldn't we move the functionalities in the lucene component in
>>> special purpose move to the apps level? It seems to be a better fit
>> there.
>>>
>>> My apologies for the lengthiness of this post. Couldn't do it in a
>> shorter
>>> way. Anyway, a clear and shared vision helps us all. Discussing pros and
>>> cons of viewpoints help to get there.
>>>
>>> Regards,
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
>>> [hidden email]> wrote:
>>>
>>>> Do you agree that specialpurpose would be a better fit for the commonext
>>>> component that is currently under the applications folder?
>>>> It extends the default data model adding new fields to the NoteData
>> entity
>>>> and provides some special purpose features.
>>>>
>>>> Jacopo
>>>>
>>>>
>>
>>

[taher]

Hi Jacopo and Pierre,

I like the idea of the new design but it will represent some problems which
we need to think about. For example, the commonext prepares the UI labels
which are commonly used (content, party, etc ...) and makes them available
across all components. This makes a dependency from commonext to the
components. If you remove this dependency then you have to prepare the UI
labels for each component separately in its CommonScreens.xml. Not a lot of
work but you do end-up repeating yourself a bit.

So some code needs to be removed from commonext to the higher level
applications to allow for your vision described earlier in this thread.

Taher Alkhateeb

On Mon, Nov 24, 2014 at 9:05 AM, Jacopo Cappellato <
[hidden email]> wrote:

>
> On Nov 23, 2014, at 8:44 PM, Pierre Smits <[hidden email]> wrote:
>
> > Jacopo, All,
> >
> > You and I are in sync here, with respect to how the components in the
> > various levels stack up to be the primary work of the OFBiz project. I
> also
> > agree that this can be achieved in a reasonable amount of time and effort
> > spent.
>
> +1
>
> >
> > Having svn repositories per layer plays into this approach.
>
> The main advantage is that initially there is no need to modify the layout
> of the current svn (trunk and branches):
> * the work required will be only that of fixing the dependencies between
> components
> * then users should be able to checkout the branch they like and remove
> the layers they do not want and then build OFBiz successfully (e.g. with
> framework only OR framework+core OR
> framework+core+applications/specialpurpose)
> * at a later time we could discuss if we also want to provide separate
> releases/download for the framework, the core, the
> applications/specialpurpose but until that time we will continue to release
> the whole package as it happens now
>
> > That also helps
> > to attract more committers (regarding code) so that this project retains
> > the level of quality it requires. And it seems to be inline to what Ron
> is
> > trying to bring across.
> >
> > But this approach will only work if we all consent to it.
>
> +1
>
> Best regards,
>
> Jacopo
>
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Sun, Nov 23, 2014 at 7:37 PM, Jacopo Cappellato <
> > [hidden email]> wrote:
> >
> >> Thanks Pierre for the description.
> >>
> >> My goal is not actually that of removing an unused component, but
> instead
> >> trying to come up with an architecture that with little effort and no
> major
> >> changes would let us deliver the following products:
> >>
> >> *OFBiz framework*
> >> Structure: it includes only the framework components, the tools,
> >> hot-deploy and runtime folders; only a few entities are defined (the
> ones
> >> declared by the framework components, of course); no applications, no
> >> specialpurpose; the only user interface available ootb is WebTools.
> >> Purpose: provide a framework to build ERP-like applications from
> scratch;
> >> typically a developer will start by running the "ant create-component"
> task
> >> and will then declare the entities, services and screens in the custom
> >> component
> >>
> >> *OFBiz core*
> >> Structure: it contains one application component (this could be the
> >> commonext component, after it has been cleaned up) that only contains
> all
> >> the entity definitions (the whole data model) that are currently
> defined in
> >> the various applications; it will also include CRUD or basic and very
> >> global/generic services; no user interfaces
> >> Purpose: to be used with the "OFBiz framework" by users interested in
> >> building from scratch user interfaces based on the OFBiz data model and
> >> crud services
> >>
> >> *OFBiz applications*
> >> Structure: it contains all the existing applications (except the
> component
> >> delivered as "OFBiz core") with their special services and user
> interfaces
> >> Purpose: to be used by users interested to running a mostly-ready out of
> >> the box solution; to be used with the "OFBiz framework" and "OFBiz core"
> >>
> >> *OFBiz specialpurpose*
> >> Structure: it contains all the existing specialpurpose components with
> >> their special services and user interfaces
> >> Purpose: to be used by users interested in specific
> integrations/solutions
> >> solution; to be used with the "OFBiz framework" and (maybe) "OFBiz
> core";
> >> the user could use a subset of the specialpurpose components
> >>
> >> What we currently call "Apache OFBiz" would be the sum of the following
> >> products:
> >> "OFBiz framework" +
> >> "OFBiz core" +
> >> "OFBiz applications" +
> >> "OFBiz specialpurpose"
> >>
> >> We could even merge together "OFBiz applications" and "OFBiz
> >> specialpurpose" into one group, the applications, if we can provide some
> >> good way to represent the dependencies among them: we could let the user
> >> decide which components should be enabled.
> >>
> >> I am convinced that we could achieve this goal with a reasonable effort
> >> and this could be a first step in the direction of making OFBiz more
> >> modular; we could then design and implement further improvements.
> >>
> >> Jacopo
> >>
> >>
> >> On Nov 23, 2014, at 1:01 PM, Pierre Smits <[hidden email]>
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> IIRW, components like commonext, securityext and entityext were
> >> constructed
> >>> and implemented by the community to enable developers
> >> (users/contributors)
> >>> to extend the functionalities in lower level components (services et
> al)
> >>> and create commonalities that can be shared between components on the
> >> same
> >>> and/or higher level, so that the lower level functionalities change as
> >>> little as possible.
> >>>
> >>> Thus leading to:
> >>>
> >>>  -  hot--deploy extends (and/or uses) hot-deploy, special purpose, apps
> >> &
> >>>  framework components
> >>>  - special purpose extends (and/or uses) special purpose,  apps &
> >>>  framework components
> >>>  - apps extends (and/or uses) apps & framework components
> >>>  - framework extends (and/or uses) framework components
> >>>
> >>> Examples are:
> >>> Manufacturing extends workeffort, party, etc
> >>> ProjectMgr extends workeffort, party, etc
> >>>
> >>> Such a paradigm is easy to understand, and creates the least amount of
> >>> confusion (for the developer, tester, etc) when having to resolve
> issues
> >>> relating to dependencies. If and when we move a lower level component
> to
> >> a
> >>> higher lever, we increase this confusion. This should be avoided as
> much
> >> as
> >>> possible, because removing the confusion leads to (more) rework.
> >>>
> >>> As Taher explained in his posting there are same and higher level
> >>> dependencies on commonext. Reworking that, in order to maintain the
> >>> paradigm described above, will require a lot of effort and takes a lot
> of
> >>> time to have it completed. Are we willing to go there? Can we achieve
> >> that
> >>> in a reasonable amount of time? Is that needed?
> >>>
> >>> We haven't seen many contributions to this component. That is true. It
> >> is a
> >>> placeholder, provided by this community, that enables each users to
> >> extend
> >>> for their own purposes. Period.
> >>> That no enhancements/improvements to this component make their way back
> >>> into the project may indicate two things:
> >>>
> >>>  1. The component works perfectly regarding its intent.
> >>>  2. People don't feel the need to share what they have in their own
> >>>  version
> >>>
> >>> Re 1: Kudos to all who have come up with the paradigm and have it
> >>> implemented in OFBiz.
> >>>
> >>> Re 2: Maybe that is because what is share regarding this is included in
> >> the
> >>> OFBiz code as an enhancement to a component on a lower level. Maybe
> that
> >> is
> >>> because what the individual user has in his component is subject to an
> >> NDA.
> >>> Or the user believes that what he has is so specific that he considers
> >> that
> >>> functionality of totally no use for others.
> >>> Such are the facts of life, and I accept that. This is the prerogative
> >> that
> >>> each of us has!
> >>>
> >>> So, let it be where it is and don't worry about it. Cost of maintenance
> >> (as
> >>> it is) is low.
> >>>
> >>> And the above applies to securityext as well.
> >>>
> >>> Now, if there is a dependency on a higher level component (and there is
> >> one
> >>> in this component, IIRW), we - as the community - should fix this
> >> specific
> >>> issue. That would indicate that we move stuff from lower to higher.
> >>> If the component has stuff that we feel is better to have in another
> >>> component on the same level, we can fix that too. When talking about
> the
> >>> NoteData entity (and accompanying functions), I believe we should have
> >> this
> >>> moved to content.
> >>>
> >>> But what about entityext?
> >>> Following the paradigm outlined above, this shouldn't be in framework,
> >> but
> >>> at the next higher level (apps). Shouldn't we move that one?
> >>>
> >>> And what about the other components in framework, that enables users to
> >>> interact with OFBiz? We have webtools containing stuff regarding base
> >> data
> >>> manipulation feature, and more. Shouldn't that move to apps (or higher)
> >> as
> >>> well? Like I initiated with
> >>>
> >>> On the other hand, we have a component in special purpose that extends
> >> base
> >>> authentication and integration. This component is called ldap.
> Shouldn't
> >>> functionalities in there move to the lowest level?
> >>>
> >>> And shouldn't we move the functionalities in the lucene component in
> >>> special purpose move to the apps level? It seems to be a better fit
> >> there.
> >>>
> >>> My apologies for the lengthiness of this post. Couldn't do it in a
> >> shorter
> >>> way. Anyway, a clear and shared vision helps us all. Discussing pros
> and
> >>> cons of viewpoints help to get there.
> >>>
> >>> Regards,
> >>>
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM <http://www.orrtiz.com>*
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>> On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
> >>> [hidden email]> wrote:
> >>>
> >>>> Do you agree that specialpurpose would be a better fit for the
> commonext
> >>>> component that is currently under the applications folder?
> >>>> It extends the default data model adding new fields to the NoteData
> >> entity
> >>>> and provides some special purpose features.
> >>>>
> >>>> Jacopo
> >>>>
> >>>>
> >>
> >>
>
>

[Jacques Le Roux]

Le 23/11/2014 19:16, Jacopo Cappellato a écrit :
> Thank you Taher,
>
> you are right about these dependencies and it is important that we keep the artifact that you have mentioned under applications.
> What confuses me is the fact that this commonext component should be loaded before the other application components (because it is used by them) but it is instead loaded as last; and in fact it extends some of the code from other application components: I suspect that the component contains some artifacts that we should moved elsewhere (e.g. to specialpurpose or to other applications, as mentioned by Pierre).

I had the same questions sometimes ago http://markmail.org/message/pd5ouy64lxbybr2m

Jacques

> This goal should be rather easy to achieve (but I still need to study the details of it) and we should be able to implement an architecture like the following (some stupid ascii art):
>
> accounting | order | product | ...
> ------------------------------------------
>                  commonext
> ------------------------------------------
>                  framework
>
> The above should be inline with your description of it.
>
> Regards,
>
> Jacopo
>
>
> On Nov 23, 2014, at 8:48 AM, Taher Alkhateeb <[hidden email]> wrote:
>
>> Hi Jacopo,
>>
>> Almost all applications including core applications use the
>> ApplicationDecorator screen found in CommonExt. I believe many items depend
>> on CommonExt and you will find the below code snippet pretty much in all
>> CommonScreens.xml files.
>>
>> <widgets>
>>     <include-screen name="ApplicationDecorator"
>> location="component://commonext/widget/CommonScreens.xml"/>
>> </widgets>
>>
>> It also provides data essential to theme headers and footers, and provides
>> additional resources including UI labels for all components and it is also
>> responsible for the contextual help system. I think removing it will break
>> your applications unless you do a lot of rewiring. I think this is not a
>> simple folder move.
>>
>> Taher Alkhateeb
>>
>> On Sun, Nov 23, 2014 at 10:26 AM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>>> Do you agree that specialpurpose would be a better fit for the commonext
>>> component that is currently under the applications folder?
>>> It extends the default data model adding new fields to the NoteData entity
>>> and provides some special purpose features.
>>>
>>> Jacopo
>>>
>>>
>
>

[Jacopo Cappellato-4]

On Nov 24, 2014, at 10:21 AM, Jacques Le Roux <[hidden email]> wrote:

>
> Le 23/11/2014 19:16, Jacopo Cappellato a écrit :
>> Thank you Taher,
>>
>> you are right about these dependencies and it is important that we keep the artifact that you have mentioned under applications.
>> What confuses me is the fact that this commonext component should be loaded before the other application components (because it is used by them) but it is instead loaded as last; and in fact it extends some of the code from other application components: I suspect that the component contains some artifacts that we should moved elsewhere (e.g. to specialpurpose or to other applications, as mentioned by Pierre).
>
> I had the same questions sometimes ago http://markmail.org/message/pd5ouy64lxbybr2m

In that email there is also a question for me that it was in my todo list since a long time: the short answer is that when I will move the bi component to specialpurpose that dependency will go away from framework.

The best way to go in my opinion (and I think it is inline with your proposal in that email, if I understand it correctly) is to clean the commonext component from dependencies on other application components (moving the dependency in other components) and then load the commonext component as the first component after framework. This should clean up the architecture and should open up to options like the one of having a component where the data model is defined and where core services are defined (for setups where only the framework and data model are required).

Jacopo

[Jacopo Cappellato-4]

Hi Taher,

what you describe seems to be inline with the concept of having commonext as the base component for all the applications (i.e. loaded first): all applications will depend on it and would use (for example) its labels.
Am I missing something?

Jacopo

On Nov 24, 2014, at 10:19 AM, Taher Alkhateeb <[hidden email]> wrote:

> Hi Jacopo and Pierre,
>
> I like the idea of the new design but it will represent some problems which
> we need to think about. For example, the commonext prepares the UI labels
> which are commonly used (content, party, etc ...) and makes them available
> across all components. This makes a dependency from commonext to the
> components. If you remove this dependency then you have to prepare the UI
> labels for each component separately in its CommonScreens.xml. Not a lot of
> work but you do end-up repeating yourself a bit.
>
> So some code needs to be removed from commonext to the higher level
> applications to allow for your vision described earlier in this thread.
>
> Taher Alkhateeb
>
> On Mon, Nov 24, 2014 at 9:05 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>>
>> On Nov 23, 2014, at 8:44 PM, Pierre Smits <[hidden email]> wrote:
>>
>>> Jacopo, All,
>>>
>>> You and I are in sync here, with respect to how the components in the
>>> various levels stack up to be the primary work of the OFBiz project. I
>> also
>>> agree that this can be achieved in a reasonable amount of time and effort
>>> spent.
>>
>> +1
>>
>>>
>>> Having svn repositories per layer plays into this approach.
>>
>> The main advantage is that initially there is no need to modify the layout
>> of the current svn (trunk and branches):
>> * the work required will be only that of fixing the dependencies between
>> components
>> * then users should be able to checkout the branch they like and remove
>> the layers they do not want and then build OFBiz successfully (e.g. with
>> framework only OR framework+core OR
>> framework+core+applications/specialpurpose)
>> * at a later time we could discuss if we also want to provide separate
>> releases/download for the framework, the core, the
>> applications/specialpurpose but until that time we will continue to release
>> the whole package as it happens now
>>
>>> That also helps
>>> to attract more committers (regarding code) so that this project retains
>>> the level of quality it requires. And it seems to be inline to what Ron
>> is
>>> trying to bring across.
>>>
>>> But this approach will only work if we all consent to it.
>>
>> +1
>>
>> Best regards,
>>
>> Jacopo
>>
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sun, Nov 23, 2014 at 7:37 PM, Jacopo Cappellato <
>>> [hidden email]> wrote:
>>>
>>>> Thanks Pierre for the description.
>>>>
>>>> My goal is not actually that of removing an unused component, but
>> instead
>>>> trying to come up with an architecture that with little effort and no
>> major
>>>> changes would let us deliver the following products:
>>>>
>>>> *OFBiz framework*
>>>> Structure: it includes only the framework components, the tools,
>>>> hot-deploy and runtime folders; only a few entities are defined (the
>> ones
>>>> declared by the framework components, of course); no applications, no
>>>> specialpurpose; the only user interface available ootb is WebTools.
>>>> Purpose: provide a framework to build ERP-like applications from
>> scratch;
>>>> typically a developer will start by running the "ant create-component"
>> task
>>>> and will then declare the entities, services and screens in the custom
>>>> component
>>>>
>>>> *OFBiz core*
>>>> Structure: it contains one application component (this could be the
>>>> commonext component, after it has been cleaned up) that only contains
>> all
>>>> the entity definitions (the whole data model) that are currently
>> defined in
>>>> the various applications; it will also include CRUD or basic and very
>>>> global/generic services; no user interfaces
>>>> Purpose: to be used with the "OFBiz framework" by users interested in
>>>> building from scratch user interfaces based on the OFBiz data model and
>>>> crud services
>>>>
>>>> *OFBiz applications*
>>>> Structure: it contains all the existing applications (except the
>> component
>>>> delivered as "OFBiz core") with their special services and user
>> interfaces
>>>> Purpose: to be used by users interested to running a mostly-ready out of
>>>> the box solution; to be used with the "OFBiz framework" and "OFBiz core"
>>>>
>>>> *OFBiz specialpurpose*
>>>> Structure: it contains all the existing specialpurpose components with
>>>> their special services and user interfaces
>>>> Purpose: to be used by users interested in specific
>> integrations/solutions
>>>> solution; to be used with the "OFBiz framework" and (maybe) "OFBiz
>> core";
>>>> the user could use a subset of the specialpurpose components
>>>>
>>>> What we currently call "Apache OFBiz" would be the sum of the following
>>>> products:
>>>> "OFBiz framework" +
>>>> "OFBiz core" +
>>>> "OFBiz applications" +
>>>> "OFBiz specialpurpose"
>>>>
>>>> We could even merge together "OFBiz applications" and "OFBiz
>>>> specialpurpose" into one group, the applications, if we can provide some
>>>> good way to represent the dependencies among them: we could let the user
>>>> decide which components should be enabled.
>>>>
>>>> I am convinced that we could achieve this goal with a reasonable effort
>>>> and this could be a first step in the direction of making OFBiz more
>>>> modular; we could then design and implement further improvements.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> On Nov 23, 2014, at 1:01 PM, Pierre Smits <[hidden email]>
>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> IIRW, components like commonext, securityext and entityext were
>>>> constructed
>>>>> and implemented by the community to enable developers
>>>> (users/contributors)
>>>>> to extend the functionalities in lower level components (services et
>> al)
>>>>> and create commonalities that can be shared between components on the
>>>> same
>>>>> and/or higher level, so that the lower level functionalities change as
>>>>> little as possible.
>>>>>
>>>>> Thus leading to:
>>>>>
>>>>> -  hot--deploy extends (and/or uses) hot-deploy, special purpose, apps
>>>> &
>>>>> framework components
>>>>> - special purpose extends (and/or uses) special purpose,  apps &
>>>>> framework components
>>>>> - apps extends (and/or uses) apps & framework components
>>>>> - framework extends (and/or uses) framework components
>>>>>
>>>>> Examples are:
>>>>> Manufacturing extends workeffort, party, etc
>>>>> ProjectMgr extends workeffort, party, etc
>>>>>
>>>>> Such a paradigm is easy to understand, and creates the least amount of
>>>>> confusion (for the developer, tester, etc) when having to resolve
>> issues
>>>>> relating to dependencies. If and when we move a lower level component
>> to
>>>> a
>>>>> higher lever, we increase this confusion. This should be avoided as
>> much
>>>> as
>>>>> possible, because removing the confusion leads to (more) rework.
>>>>>
>>>>> As Taher explained in his posting there are same and higher level
>>>>> dependencies on commonext. Reworking that, in order to maintain the
>>>>> paradigm described above, will require a lot of effort and takes a lot
>> of
>>>>> time to have it completed. Are we willing to go there? Can we achieve
>>>> that
>>>>> in a reasonable amount of time? Is that needed?
>>>>>
>>>>> We haven't seen many contributions to this component. That is true. It
>>>> is a
>>>>> placeholder, provided by this community, that enables each users to
>>>> extend
>>>>> for their own purposes. Period.
>>>>> That no enhancements/improvements to this component make their way back
>>>>> into the project may indicate two things:
>>>>>
>>>>> 1. The component works perfectly regarding its intent.
>>>>> 2. People don't feel the need to share what they have in their own
>>>>> version
>>>>>
>>>>> Re 1: Kudos to all who have come up with the paradigm and have it
>>>>> implemented in OFBiz.
>>>>>
>>>>> Re 2: Maybe that is because what is share regarding this is included in
>>>> the
>>>>> OFBiz code as an enhancement to a component on a lower level. Maybe
>> that
>>>> is
>>>>> because what the individual user has in his component is subject to an
>>>> NDA.
>>>>> Or the user believes that what he has is so specific that he considers
>>>> that
>>>>> functionality of totally no use for others.
>>>>> Such are the facts of life, and I accept that. This is the prerogative
>>>> that
>>>>> each of us has!
>>>>>
>>>>> So, let it be where it is and don't worry about it. Cost of maintenance
>>>> (as
>>>>> it is) is low.
>>>>>
>>>>> And the above applies to securityext as well.
>>>>>
>>>>> Now, if there is a dependency on a higher level component (and there is
>>>> one
>>>>> in this component, IIRW), we - as the community - should fix this
>>>> specific
>>>>> issue. That would indicate that we move stuff from lower to higher.
>>>>> If the component has stuff that we feel is better to have in another
>>>>> component on the same level, we can fix that too. When talking about
>> the
>>>>> NoteData entity (and accompanying functions), I believe we should have
>>>> this
>>>>> moved to content.
>>>>>
>>>>> But what about entityext?
>>>>> Following the paradigm outlined above, this shouldn't be in framework,
>>>> but
>>>>> at the next higher level (apps). Shouldn't we move that one?
>>>>>
>>>>> And what about the other components in framework, that enables users to
>>>>> interact with OFBiz? We have webtools containing stuff regarding base
>>>> data
>>>>> manipulation feature, and more. Shouldn't that move to apps (or higher)
>>>> as
>>>>> well? Like I initiated with
>>>>>
>>>>> On the other hand, we have a component in special purpose that extends
>>>> base
>>>>> authentication and integration. This component is called ldap.
>> Shouldn't
>>>>> functionalities in there move to the lowest level?
>>>>>
>>>>> And shouldn't we move the functionalities in the lucene component in
>>>>> special purpose move to the apps level? It seems to be a better fit
>>>> there.
>>>>>
>>>>> My apologies for the lengthiness of this post. Couldn't do it in a
>>>> shorter
>>>>> way. Anyway, a clear and shared vision helps us all. Discussing pros
>> and
>>>>> cons of viewpoints help to get there.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> Do you agree that specialpurpose would be a better fit for the
>> commonext
>>>>>> component that is currently under the applications folder?
>>>>>> It extends the default data model adding new fields to the NoteData
>>>> entity
>>>>>> and provides some special purpose features.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

[taher]

Hi Jacopo,

You are not missing anything! I am just stating that work needs to be done
to help implementing your vision. One such example being removing the UI
Label loading from the commonext to the upper application components. In
fact, if you wish to open a JIRA to that effect I can help with some
patches if you need that.

Regards,

Taher Alkhateeb

On Mon, Nov 24, 2014 at 12:40 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Hi Taher,
>
> what you describe seems to be inline with the concept of having commonext
> as the base component for all the applications (i.e. loaded first): all
> applications will depend on it and would use (for example) its labels.
> Am I missing something?
>
> Jacopo
>
> On Nov 24, 2014, at 10:19 AM, Taher Alkhateeb <[hidden email]>
> wrote:
>
> > Hi Jacopo and Pierre,
> >
> > I like the idea of the new design but it will represent some problems
> which
> > we need to think about. For example, the commonext prepares the UI labels
> > which are commonly used (content, party, etc ...) and makes them
> available
> > across all components. This makes a dependency from commonext to the
> > components. If you remove this dependency then you have to prepare the UI
> > labels for each component separately in its CommonScreens.xml. Not a lot
> of
> > work but you do end-up repeating yourself a bit.
> >
> > So some code needs to be removed from commonext to the higher level
> > applications to allow for your vision described earlier in this thread.
> >
> > Taher Alkhateeb
> >
> > On Mon, Nov 24, 2014 at 9:05 AM, Jacopo Cappellato <
> > [hidden email]> wrote:
> >
> >>
> >> On Nov 23, 2014, at 8:44 PM, Pierre Smits <[hidden email]>
> wrote:
> >>
> >>> Jacopo, All,
> >>>
> >>> You and I are in sync here, with respect to how the components in the
> >>> various levels stack up to be the primary work of the OFBiz project. I
> >> also
> >>> agree that this can be achieved in a reasonable amount of time and
> effort
> >>> spent.
> >>
> >> +1
> >>
> >>>
> >>> Having svn repositories per layer plays into this approach.
> >>
> >> The main advantage is that initially there is no need to modify the
> layout
> >> of the current svn (trunk and branches):
> >> * the work required will be only that of fixing the dependencies between
> >> components
> >> * then users should be able to checkout the branch they like and remove
> >> the layers they do not want and then build OFBiz successfully (e.g. with
> >> framework only OR framework+core OR
> >> framework+core+applications/specialpurpose)
> >> * at a later time we could discuss if we also want to provide separate
> >> releases/download for the framework, the core, the
> >> applications/specialpurpose but until that time we will continue to
> release
> >> the whole package as it happens now
> >>
> >>> That also helps
> >>> to attract more committers (regarding code) so that this project
> retains
> >>> the level of quality it requires. And it seems to be inline to what Ron
> >> is
> >>> trying to bring across.
> >>>
> >>> But this approach will only work if we all consent to it.
> >>
> >> +1
> >>
> >> Best regards,
> >>
> >> Jacopo
> >>
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM <http://www.orrtiz.com>*
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>> On Sun, Nov 23, 2014 at 7:37 PM, Jacopo Cappellato <
> >>> [hidden email]> wrote:
> >>>
> >>>> Thanks Pierre for the description.
> >>>>
> >>>> My goal is not actually that of removing an unused component, but
> >> instead
> >>>> trying to come up with an architecture that with little effort and no
> >> major
> >>>> changes would let us deliver the following products:
> >>>>
> >>>> *OFBiz framework*
> >>>> Structure: it includes only the framework components, the tools,
> >>>> hot-deploy and runtime folders; only a few entities are defined (the
> >> ones
> >>>> declared by the framework components, of course); no applications, no
> >>>> specialpurpose; the only user interface available ootb is WebTools.
> >>>> Purpose: provide a framework to build ERP-like applications from
> >> scratch;
> >>>> typically a developer will start by running the "ant create-component"
> >> task
> >>>> and will then declare the entities, services and screens in the custom
> >>>> component
> >>>>
> >>>> *OFBiz core*
> >>>> Structure: it contains one application component (this could be the
> >>>> commonext component, after it has been cleaned up) that only contains
> >> all
> >>>> the entity definitions (the whole data model) that are currently
> >> defined in
> >>>> the various applications; it will also include CRUD or basic and very
> >>>> global/generic services; no user interfaces
> >>>> Purpose: to be used with the "OFBiz framework" by users interested in
> >>>> building from scratch user interfaces based on the OFBiz data model
> and
> >>>> crud services
> >>>>
> >>>> *OFBiz applications*
> >>>> Structure: it contains all the existing applications (except the
> >> component
> >>>> delivered as "OFBiz core") with their special services and user
> >> interfaces
> >>>> Purpose: to be used by users interested to running a mostly-ready out
> of
> >>>> the box solution; to be used with the "OFBiz framework" and "OFBiz
> core"
> >>>>
> >>>> *OFBiz specialpurpose*
> >>>> Structure: it contains all the existing specialpurpose components with
> >>>> their special services and user interfaces
> >>>> Purpose: to be used by users interested in specific
> >> integrations/solutions
> >>>> solution; to be used with the "OFBiz framework" and (maybe) "OFBiz
> >> core";
> >>>> the user could use a subset of the specialpurpose components
> >>>>
> >>>> What we currently call "Apache OFBiz" would be the sum of the
> following
> >>>> products:
> >>>> "OFBiz framework" +
> >>>> "OFBiz core" +
> >>>> "OFBiz applications" +
> >>>> "OFBiz specialpurpose"
> >>>>
> >>>> We could even merge together "OFBiz applications" and "OFBiz
> >>>> specialpurpose" into one group, the applications, if we can provide
> some
> >>>> good way to represent the dependencies among them: we could let the
> user
> >>>> decide which components should be enabled.
> >>>>
> >>>> I am convinced that we could achieve this goal with a reasonable
> effort
> >>>> and this could be a first step in the direction of making OFBiz more
> >>>> modular; we could then design and implement further improvements.
> >>>>
> >>>> Jacopo
> >>>>
> >>>>
> >>>> On Nov 23, 2014, at 1:01 PM, Pierre Smits <[hidden email]>
> >> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> IIRW, components like commonext, securityext and entityext were
> >>>> constructed
> >>>>> and implemented by the community to enable developers
> >>>> (users/contributors)
> >>>>> to extend the functionalities in lower level components (services et
> >> al)
> >>>>> and create commonalities that can be shared between components on the
> >>>> same
> >>>>> and/or higher level, so that the lower level functionalities change
> as
> >>>>> little as possible.
> >>>>>
> >>>>> Thus leading to:
> >>>>>
> >>>>> -  hot--deploy extends (and/or uses) hot-deploy, special purpose,
> apps
> >>>> &
> >>>>> framework components
> >>>>> - special purpose extends (and/or uses) special purpose,  apps &
> >>>>> framework components
> >>>>> - apps extends (and/or uses) apps & framework components
> >>>>> - framework extends (and/or uses) framework components
> >>>>>
> >>>>> Examples are:
> >>>>> Manufacturing extends workeffort, party, etc
> >>>>> ProjectMgr extends workeffort, party, etc
> >>>>>
> >>>>> Such a paradigm is easy to understand, and creates the least amount
> of
> >>>>> confusion (for the developer, tester, etc) when having to resolve
> >> issues
> >>>>> relating to dependencies. If and when we move a lower level component
> >> to
> >>>> a
> >>>>> higher lever, we increase this confusion. This should be avoided as
> >> much
> >>>> as
> >>>>> possible, because removing the confusion leads to (more) rework.
> >>>>>
> >>>>> As Taher explained in his posting there are same and higher level
> >>>>> dependencies on commonext. Reworking that, in order to maintain the
> >>>>> paradigm described above, will require a lot of effort and takes a
> lot
> >> of
> >>>>> time to have it completed. Are we willing to go there? Can we achieve
> >>>> that
> >>>>> in a reasonable amount of time? Is that needed?
> >>>>>
> >>>>> We haven't seen many contributions to this component. That is true.
> It
> >>>> is a
> >>>>> placeholder, provided by this community, that enables each users to
> >>>> extend
> >>>>> for their own purposes. Period.
> >>>>> That no enhancements/improvements to this component make their way
> back
> >>>>> into the project may indicate two things:
> >>>>>
> >>>>> 1. The component works perfectly regarding its intent.
> >>>>> 2. People don't feel the need to share what they have in their own
> >>>>> version
> >>>>>
> >>>>> Re 1: Kudos to all who have come up with the paradigm and have it
> >>>>> implemented in OFBiz.
> >>>>>
> >>>>> Re 2: Maybe that is because what is share regarding this is included
> in
> >>>> the
> >>>>> OFBiz code as an enhancement to a component on a lower level. Maybe
> >> that
> >>>> is
> >>>>> because what the individual user has in his component is subject to
> an
> >>>> NDA.
> >>>>> Or the user believes that what he has is so specific that he
> considers
> >>>> that
> >>>>> functionality of totally no use for others.
> >>>>> Such are the facts of life, and I accept that. This is the
> prerogative
> >>>> that
> >>>>> each of us has!
> >>>>>
> >>>>> So, let it be where it is and don't worry about it. Cost of
> maintenance
> >>>> (as
> >>>>> it is) is low.
> >>>>>
> >>>>> And the above applies to securityext as well.
> >>>>>
> >>>>> Now, if there is a dependency on a higher level component (and there
> is
> >>>> one
> >>>>> in this component, IIRW), we - as the community - should fix this
> >>>> specific
> >>>>> issue. That would indicate that we move stuff from lower to higher.
> >>>>> If the component has stuff that we feel is better to have in another
> >>>>> component on the same level, we can fix that too. When talking about
> >> the
> >>>>> NoteData entity (and accompanying functions), I believe we should
> have
> >>>> this
> >>>>> moved to content.
> >>>>>
> >>>>> But what about entityext?
> >>>>> Following the paradigm outlined above, this shouldn't be in
> framework,
> >>>> but
> >>>>> at the next higher level (apps). Shouldn't we move that one?
> >>>>>
> >>>>> And what about the other components in framework, that enables users
> to
> >>>>> interact with OFBiz? We have webtools containing stuff regarding base
> >>>> data
> >>>>> manipulation feature, and more. Shouldn't that move to apps (or
> higher)
> >>>> as
> >>>>> well? Like I initiated with
> >>>>>
> >>>>> On the other hand, we have a component in special purpose that
> extends
> >>>> base
> >>>>> authentication and integration. This component is called ldap.
> >> Shouldn't
> >>>>> functionalities in there move to the lowest level?
> >>>>>
> >>>>> And shouldn't we move the functionalities in the lucene component in
> >>>>> special purpose move to the apps level? It seems to be a better fit
> >>>> there.
> >>>>>
> >>>>> My apologies for the lengthiness of this post. Couldn't do it in a
> >>>> shorter
> >>>>> way. Anyway, a clear and shared vision helps us all. Discussing pros
> >> and
> >>>>> cons of viewpoints help to get there.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>
> >>>>> Pierre Smits
> >>>>>
> >>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
> >>>>> Services & Solutions for Cloud-
> >>>>> Based Manufacturing, Professional
> >>>>> Services and Retail & Trade
> >>>>> http://www.orrtiz.com
> >>>>>
> >>>>> On Sun, Nov 23, 2014 at 8:26 AM, Jacopo Cappellato <
> >>>>> [hidden email]> wrote:
> >>>>>
> >>>>>> Do you agree that specialpurpose would be a better fit for the
> >> commonext
> >>>>>> component that is currently under the applications folder?
> >>>>>> It extends the default data model adding new fields to the NoteData
> >>>> entity
> >>>>>> and provides some special purpose features.
> >>>>>>
> >>>>>> Jacopo
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

[Jacques Le Roux]

Le 24/11/2014 10:34, Jacopo Cappellato a écrit :

> On Nov 24, 2014, at 10:21 AM, Jacques Le Roux <[hidden email]> wrote:
>
>> Le 23/11/2014 19:16, Jacopo Cappellato a écrit :
>>> Thank you Taher,
>>>
>>> you are right about these dependencies and it is important that we keep the artifact that you have mentioned under applications.
>>> What confuses me is the fact that this commonext component should be loaded before the other application components (because it is used by them) but it is instead loaded as last; and in fact it extends some of the code from other application components: I suspect that the component contains some artifacts that we should moved elsewhere (e.g. to specialpurpose or to other applications, as mentioned by Pierre).
>> I had the same questions sometimes ago http://markmail.org/message/pd5ouy64lxbybr2m
> In that email there is also a question for me that it was in my todo list since a long time: the short answer is that when I will move the bi component to specialpurpose that dependency will go away from framework.
>
> The best way to go in my opinion (and I think it is inline with your proposal in that email, if I understand it correctly) is to clean the commonext component from dependencies on other application components (moving the dependency in other components) and then load the commonext component as the first component after framework. This should clean up the architecture and should open up to options like the one of having a component where the data model is defined and where core services are defined (for setups where only the framework and data model are required).

+1

Jacques
>
> Jacopo
>

[Ron Wheeler]

This is a really positive step.




On 24/11/2014 5:15 AM, Jacques Le Roux wrote:

>
> Le 24/11/2014 10:34, Jacopo Cappellato a écrit :
>> On Nov 24, 2014, at 10:21 AM, Jacques Le Roux
>> <[hidden email]> wrote:
>>
>>> Le 23/11/2014 19:16, Jacopo Cappellato a écrit :
>>>> Thank you Taher,
>>>>
>>>> you are right about these dependencies and it is important that we
>>>> keep the artifact that you have mentioned under applications.
>>>> What confuses me is the fact that this commonext component should
>>>> be loaded before the other application components (because it is
>>>> used by them) but it is instead loaded as last; and in fact it
>>>> extends some of the code from other application components: I
>>>> suspect that the component contains some artifacts that we should
>>>> moved elsewhere (e.g. to specialpurpose or to other applications,
>>>> as mentioned by Pierre).
>>> I had the same questions sometimes ago
>>> http://markmail.org/message/pd5ouy64lxbybr2m
>> In that email there is also a question for me that it was in my todo
>> list since a long time: the short answer is that when I will move the
>> bi component to specialpurpose that dependency will go away from
>> framework.
>>
>> The best way to go in my opinion (and I think it is inline with your
>> proposal in that email, if I understand it correctly) is to clean the
>> commonext component from dependencies on other application components
>> (moving the dependency in other components) and then load the
>> commonext component as the first component after framework. This
>> should clean up the architecture and should open up to options like
>> the one of having a component where the data model is defined and
>> where core services are defined (for setups where only the framework
>> and data model are required).
>
> +1
>
> Jacques
>>
>> Jacopo
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102