Apache OFBiz EZBiz

[Jacques Le Roux]

Yes, this has to be resolved 1st whatever the component, addons, OSGI bundles or what not is used
Remember that OFBiz was 1st written as an integrated ERP, that's why there are still some dependencies.
There were much more dependencies some years ago: WIP and, as ever, all good wills are welcome...

Jacques

From: "chris snow" <[hidden email]>

>
> Hi David,
>
> The problem that I have with the components is that they are an all or
> nothing proposition.  For example, due to dependencies, I have not been able
> to use the party management component on its own without first manually
> removing the dependencies to other application components.
>
> Cheers,
>
> Chris
>
>
> David E Jones-4 wrote:
>>
>>
>> On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote:
>>
>>> Having OFBiz splitted in a core framework and add-on modules seems to
>>> me like a must if we want to improve features.
>>> Add-on modules is how many large and popular projects are built.
>>> Even OpenERP says to have more that 350 modules and offers different
>>> flavours of it here http://www.openerp.com/discover/demonstration.html
>>
>> We already have a plugin, or add-on, or whatever you want to call it,
>> facility: components.
>>
>>> I think we should start discussing on the module add-on system that we
>>> want to implement in OFBiz.
>>> I have read that there is a plan from Neogia people to introduce what
>>> they have developed. Is there any schedule for this?
>>> Are you going to write a Confluence page where we can see how it works?
>>>
>>> Are we going to host the add-on modules on a separate SVN folder?
>>
>> It seems the whole point of add-on modules is to NOT have them be part of
>> the project. The intellectual property issues and concerns are totally
>> different from the main project, and the licensing may not be compatible
>> with what the ASF requires, so no I really don't think it would make sense
>> to have a place for more loosely managed stuff in SVN.
>>
>> On the other hand, we already have a place for add-on modules in SVN: the
>> specialpurpose directory.
>>
>> Consider that the framework and applications directories are the basis of
>> OFBiz, and everything else is an add-on of sorts. The applications are
>> important so that add-on components can use the common data model for
>> implicit integration, unless the add-on application won't be doing
>> anything with common business data, and then it only needs depend on the
>> framework.
>>
>> Now getting back to the point... I think you already know all of this
>> Bruno, so what is it that you'd like to see that OFBiz does not already
>> have?
>>
>> -David
>>
>>
>>> 2009/10/29 Tim Ruppert <[hidden email]>:
>>>> This sounds fantastic Marc - it's amazing to see many of the software
>>>> providers out there coming together to back this idea.  This has the
>>>> unique
>>>> opportunity of taking everything that OFBiz does to the next level.
>>>>
>>>> I guess the big question is, what's next to help get some of these
>>>> backend
>>>> ideas back into this newly refined mission?  We're more than happy to
>>>> devote
>>>> resources to making this happen.
>>>>
>>>> Cheers,
>>>> Ruppert
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>>>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote:
>>>>
>>>>> As many of you know, we at Emforium have been busy building out a full
>>>>> set
>>>>> of business software application to provide an "ALL-IN" comprehensive
>>>>> solution for the small business market.  When we started the evaluation
>>>>> over
>>>>> a year ago, Ofbiz was the selected platform of choice.  Other
>>>>> components are
>>>>> Zimbra for email and concrete5 for web.
>>>>>
>>>>> Over this time, we've spent our efforts providing an entirely new UI
>>>>> front
>>>>> end for the backend applications: sales order, inventory, CRM, admin,
>>>>> reports, multi tenancy, published datasets (makes solution targeted for
>>>>> any
>>>>> market or geography), etc...
>>>>>
>>>>> We have expressed privately that Ofbiz needs to have a new mission in
>>>>> order to really drive it's importance and relevance as an open source
>>>>> project.  As it stands, it's scope is very wide, and not targeted a
>>>>> providing and out-of-the box solution to any problem, save ecommerce
>>>>> (even
>>>>> then, lot's of styling work usually needed).
>>>>>
>>>>> We would be 100% behind this direction for Ofbiz.  We'd want to
>>>>> contribute
>>>>> back components now that are Emforium proprietary and would work to
>>>>> reduce
>>>>> the amount of deviation between our proprietary solution and this newly
>>>>> stated direction.
>>>>>
>>>>> Marc
>>>>
>>>>
>>
>>
>>
>
> --
> View this message in context: http://n4.nabble.com/Apache-OFBiz-EZBiz-tp277317p974666.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Erwan de FERRIERES-3]

Le 17/12/2009 22:46, Bruno Busco a écrit :

> Having OFBiz splitted in a core framework and add-on modules seems to
> me like a must if we want to improve features.
> Add-on modules is how many large and popular projects are built.
> Even OpenERP says to have more that 350 modules and offers different
> flavours of it here http://www.openerp.com/discover/demonstration.html
>
> I think we should start discussing on the module add-on system that we
> want to implement in OFBiz.
> I have read that there is a plan from Neogia people to introduce what
> they have developed. Is there any schedule for this?
> Are you going to write a Confluence page where we can see how it works?

Hi all,

What we have in Neogia for the addons is still under tests but available
for everyone.

Addons are a set of modifications to the OFBiz code (add/merge files)
which are grouped for a functional or technical purpose. For example, an
addon will allow to use a different process for receiving inventory.

The addon system is composed of two things : the core component, a jar
file which can be used from the command line to
create/(un)install/modify addons, and a GUI which uses this core and
which is accessible from the OFBiz interface.

Addons are managing dependencies and versions, via the Ivy project.

The core component (addon-manager) source code is here :
http://labs.libre-entreprise.org/scm/viewvc.php/addonmanager/?root=neogia

The admGui can be downloaded from here :
http://addons.neogia.org/
Just download the tar file, and untar it in your hot-deploy folder.

For the Gui, help files are in the data/helpdata folder, running a
run-install will make them visible in the help system.

To install an addon, there are two ways : from your local drive or from
the addon repository. For the first, you have to give the exact path to
the addon, for the second, you just have to give the addon name, so it
will go on http://addons.neogia.org/addons to download it.

Source code for the addons is here :
http://labs.libre-entreprise.org/projects/ofbizaddons/

You will find that for each addon, there are a help file (to define the
goal) and tests.

More information here (in English), but maybe a bit outdated :
http://neogia.org/OFBiz_add-on

I hope that this will explain a bit more what is the addon system the
Neogia team put in place. All comments are welcome !

--
Erwan de FERRIERES
www.nereide.biz

[Scott Gray-2]

So Neogia add ons are basically just managed patches?

Regards
Scott

On 18/12/2009, at 11:30 PM, Erwan de FERRIERES wrote:

>
>
> Le 17/12/2009 22:46, Bruno Busco a écrit :
>> Having OFBiz splitted in a core framework and add-on modules seems to
>> me like a must if we want to improve features.
>> Add-on modules is how many large and popular projects are built.
>> Even OpenERP says to have more that 350 modules and offers different
>> flavours of it here http://www.openerp.com/discover/ 
>> demonstration.html
>>
>> I think we should start discussing on the module add-on system that  
>> we
>> want to implement in OFBiz.
>> I have read that there is a plan from Neogia people to introduce what
>> they have developed. Is there any schedule for this?
>> Are you going to write a Confluence page where we can see how it  
>> works?
>
> Hi all,
>
> What we have in Neogia for the addons is still under tests but  
> available for everyone.
>
> Addons are a set of modifications to the OFBiz code (add/merge  
> files) which are grouped for a functional or technical purpose. For  
> example, an addon will allow to use a different process for  
> receiving inventory.
>
> The addon system is composed of two things : the core component, a  
> jar file which can be used from the command line to create/
> (un)install/modify addons, and a GUI which uses this core and which  
> is accessible from the OFBiz interface.
>
> Addons are managing dependencies and versions, via the Ivy project.
>
> The core component (addon-manager) source code is here :
> http://labs.libre-entreprise.org/scm/viewvc.php/addonmanager/?root=neogia
>
> The admGui can be downloaded from here :
> http://addons.neogia.org/
> Just download the tar file, and untar it in your hot-deploy folder.
>
> For the Gui, help files are in the data/helpdata folder, running a  
> run-install will make them visible in the help system.
>
> To install an addon, there are two ways : from your local drive or  
> from the addon repository. For the first, you have to give the exact  
> path to the addon, for the second, you just have to give the addon  
> name, so it will go on http://addons.neogia.org/addons to download it.
>
> Source code for the addons is here :
> http://labs.libre-entreprise.org/projects/ofbizaddons/
>
> You will find that for each addon, there are a help file (to define  
> the goal) and tests.
>
> More information here (in English), but maybe a bit outdated :
> http://neogia.org/OFBiz_add-on
>
> I hope that this will explain a bit more what is the addon system  
> the Neogia team put in place. All comments are welcome !
>
> --
> Erwan de FERRIERES
> www.nereide.biz

[Jacques Le Roux]

Something to note though. There is a strong difference between Neogia addons and OFBiz components, as Erwan did just explain

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Yes, this has to be resolved 1st whatever the component, addons, OSGI bundles or what not is used
> Remember that OFBiz was 1st written as an integrated ERP, that's why there are still some dependencies.
> There were much more dependencies some years ago: WIP and, as ever, all good wills are welcome...
>
> Jacques
>
> From: "chris snow" <[hidden email]>
>>
>> Hi David,
>>
>> The problem that I have with the components is that they are an all or
>> nothing proposition.  For example, due to dependencies, I have not been able
>> to use the party management component on its own without first manually
>> removing the dependencies to other application components.
>>
>> Cheers,
>>
>> Chris
>>
>>
>> David E Jones-4 wrote:
>>>
>>>
>>> On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote:
>>>
>>>> Having OFBiz splitted in a core framework and add-on modules seems to
>>>> me like a must if we want to improve features.
>>>> Add-on modules is how many large and popular projects are built.
>>>> Even OpenERP says to have more that 350 modules and offers different
>>>> flavours of it here http://www.openerp.com/discover/demonstration.html
>>>
>>> We already have a plugin, or add-on, or whatever you want to call it,
>>> facility: components.
>>>
>>>> I think we should start discussing on the module add-on system that we
>>>> want to implement in OFBiz.
>>>> I have read that there is a plan from Neogia people to introduce what
>>>> they have developed. Is there any schedule for this?
>>>> Are you going to write a Confluence page where we can see how it works?
>>>>
>>>> Are we going to host the add-on modules on a separate SVN folder?
>>>
>>> It seems the whole point of add-on modules is to NOT have them be part of
>>> the project. The intellectual property issues and concerns are totally
>>> different from the main project, and the licensing may not be compatible
>>> with what the ASF requires, so no I really don't think it would make sense
>>> to have a place for more loosely managed stuff in SVN.
>>>
>>> On the other hand, we already have a place for add-on modules in SVN: the
>>> specialpurpose directory.
>>>
>>> Consider that the framework and applications directories are the basis of
>>> OFBiz, and everything else is an add-on of sorts. The applications are
>>> important so that add-on components can use the common data model for
>>> implicit integration, unless the add-on application won't be doing
>>> anything with common business data, and then it only needs depend on the
>>> framework.
>>>
>>> Now getting back to the point... I think you already know all of this
>>> Bruno, so what is it that you'd like to see that OFBiz does not already
>>> have?
>>>
>>> -David
>>>
>>>
>>>> 2009/10/29 Tim Ruppert <[hidden email]>:
>>>>> This sounds fantastic Marc - it's amazing to see many of the software
>>>>> providers out there coming together to back this idea.  This has the
>>>>> unique
>>>>> opportunity of taking everything that OFBiz does to the next level.
>>>>>
>>>>> I guess the big question is, what's next to help get some of these
>>>>> backend
>>>>> ideas back into this newly refined mission?  We're more than happy to
>>>>> devote
>>>>> resources to making this happen.
>>>>>
>>>>> Cheers,
>>>>> Ruppert
>>>>> --
>>>>> Tim Ruppert
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> o:801.649.6594
>>>>> f:801.649.6595
>>>>>
>>>>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote:
>>>>>
>>>>>> As many of you know, we at Emforium have been busy building out a full
>>>>>> set
>>>>>> of business software application to provide an "ALL-IN" comprehensive
>>>>>> solution for the small business market.  When we started the evaluation
>>>>>> over
>>>>>> a year ago, Ofbiz was the selected platform of choice.  Other
>>>>>> components are
>>>>>> Zimbra for email and concrete5 for web.
>>>>>>
>>>>>> Over this time, we've spent our efforts providing an entirely new UI
>>>>>> front
>>>>>> end for the backend applications: sales order, inventory, CRM, admin,
>>>>>> reports, multi tenancy, published datasets (makes solution targeted for
>>>>>> any
>>>>>> market or geography), etc...
>>>>>>
>>>>>> We have expressed privately that Ofbiz needs to have a new mission in
>>>>>> order to really drive it's importance and relevance as an open source
>>>>>> project.  As it stands, it's scope is very wide, and not targeted a
>>>>>> providing and out-of-the box solution to any problem, save ecommerce
>>>>>> (even
>>>>>> then, lot's of styling work usually needed).
>>>>>>
>>>>>> We would be 100% behind this direction for Ofbiz.  We'd want to
>>>>>> contribute
>>>>>> back components now that are Emforium proprietary and would work to
>>>>>> reduce
>>>>>> the amount of deviation between our proprietary solution and this newly
>>>>>> stated direction.
>>>>>>
>>>>>> Marc
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://n4.nabble.com/Apache-OFBiz-EZBiz-tp277317p974666.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>

[Erwan de FERRIERES-3]

Le 18/12/2009 11:44, Scott Gray a écrit :
> So Neogia add ons are basically just managed patches?
Basically yes. But, if you go deeper in the addons, there are :
improved patchs : if two addons are modifying the same file, both
patches are applied one after the other.
versioning
dependancies
help
IC tests per addon

The main point which is guiding addon development is this one :
one addon = one function

There is also some research on semantic patches for the XML files done,
but not yet totally implemented.


Regards

--
Erwan de FERRIERES
www.nereide.biz

[Malin Nicolas]

Application patch is atomic to be sure that an addon don't break the
OFBiz file hierarchy.

Nicolas

Erwan de FERRIERES a écrit :

>
>
> Le 18/12/2009 11:44, Scott Gray a écrit :
>> So Neogia add ons are basically just managed patches?
> Basically yes. But, if you go deeper in the addons, there are :
> improved patchs : if two addons are modifying the same file, both
> patches are applied one after the other.
> versioning
> dependancies
> help
> IC tests per addon
>
> The main point which is guiding addon development is this one :
> one addon = one function
>
> There is also some research on semantic patches for the XML files
> done, but not yet totally implemented.
>
>
> Regards
>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[David E. Jones-2]

I think you misunderstand. The dependencies are not because of the component tools, but because of the components themselves. The components in the ofbiz/applications directory are inherently interdependent, mostly because of the data model. If someone wanted to they could certainly make these components less dependent, but there is not tool that could do so... you'd actually have to move parts of the data model around and use a lot of extend-entity stuff.

The idea that something like OSGi can manage any type of dependency is just plain incorrect. Yes, it has a feature called "dependency management", but it isn't what you're thinking of and simply wouldn't help with this.

Basically all you could possibly do is model somewhere the fact that the applications components are interdependent, but that won't help in eliminating the interdependency.

Is it possible to do? Yes (with certain exceptions, removing some dependencies would NEVER make sense). Is it a big enough deal that anyone has actually bothered to do it? No. It's that simple. It is simply not an objective that anyone has taken up yet.

-David


On Dec 18, 2009, at 3:41 AM, chris snow wrote:

>
> Hi David,
>
> The problem that I have with the components is that they are an all or
> nothing proposition.  For example, due to dependencies, I have not been able
> to use the party management component on its own without first manually
> removing the dependencies to other application components.
>
> Cheers,
>
> Chris
>
>
> David E Jones-4 wrote:
>>
>>
>> On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote:
>>
>>> Having OFBiz splitted in a core framework and add-on modules seems to
>>> me like a must if we want to improve features.
>>> Add-on modules is how many large and popular projects are built.
>>> Even OpenERP says to have more that 350 modules and offers different
>>> flavours of it here http://www.openerp.com/discover/demonstration.html
>>
>> We already have a plugin, or add-on, or whatever you want to call it,
>> facility: components.
>>
>>> I think we should start discussing on the module add-on system that we
>>> want to implement in OFBiz.
>>> I have read that there is a plan from Neogia people to introduce what
>>> they have developed. Is there any schedule for this?
>>> Are you going to write a Confluence page where we can see how it works?
>>>
>>> Are we going to host the add-on modules on a separate SVN folder?
>>
>> It seems the whole point of add-on modules is to NOT have them be part of
>> the project. The intellectual property issues and concerns are totally
>> different from the main project, and the licensing may not be compatible
>> with what the ASF requires, so no I really don't think it would make sense
>> to have a place for more loosely managed stuff in SVN.
>>
>> On the other hand, we already have a place for add-on modules in SVN: the
>> specialpurpose directory.
>>
>> Consider that the framework and applications directories are the basis of
>> OFBiz, and everything else is an add-on of sorts. The applications are
>> important so that add-on components can use the common data model for
>> implicit integration, unless the add-on application won't be doing
>> anything with common business data, and then it only needs depend on the
>> framework.
>>
>> Now getting back to the point... I think you already know all of this
>> Bruno, so what is it that you'd like to see that OFBiz does not already
>> have?
>>
>> -David
>>
>>
>>> 2009/10/29 Tim Ruppert <[hidden email]>:
>>>> This sounds fantastic Marc - it's amazing to see many of the software
>>>> providers out there coming together to back this idea.  This has the
>>>> unique
>>>> opportunity of taking everything that OFBiz does to the next level.
>>>>
>>>> I guess the big question is, what's next to help get some of these
>>>> backend
>>>> ideas back into this newly refined mission?  We're more than happy to
>>>> devote
>>>> resources to making this happen.
>>>>
>>>> Cheers,
>>>> Ruppert
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>>>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote:
>>>>
>>>>> As many of you know, we at Emforium have been busy building out a full
>>>>> set
>>>>> of business software application to provide an "ALL-IN" comprehensive
>>>>> solution for the small business market.  When we started the evaluation
>>>>> over
>>>>> a year ago, Ofbiz was the selected platform of choice.  Other
>>>>> components are
>>>>> Zimbra for email and concrete5 for web.
>>>>>
>>>>> Over this time, we've spent our efforts providing an entirely new UI
>>>>> front
>>>>> end for the backend applications: sales order, inventory, CRM, admin,
>>>>> reports, multi tenancy, published datasets (makes solution targeted for
>>>>> any
>>>>> market or geography), etc...
>>>>>
>>>>> We have expressed privately that Ofbiz needs to have a new mission in
>>>>> order to really drive it's importance and relevance as an open source
>>>>> project.  As it stands, it's scope is very wide, and not targeted a
>>>>> providing and out-of-the box solution to any problem, save ecommerce
>>>>> (even
>>>>> then, lot's of styling work usually needed).
>>>>>
>>>>> We would be 100% behind this direction for Ofbiz.  We'd want to
>>>>> contribute
>>>>> back components now that are Emforium proprietary and would work to
>>>>> reduce
>>>>> the amount of deviation between our proprietary solution and this newly
>>>>> stated direction.
>>>>>
>>>>> Marc
>>>>
>>>>
>>
>>
>>
>
> --
> View this message in context: http://n4.nabble.com/Apache-OFBiz-EZBiz-tp277317p974666.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[David E. Jones-2]

I forgot to mention one thing here... the fact that the applications components are interdependent is a GOOD thing. They represent a pretty complete base data model, services, and general UI elements. When these things are reused properly by higher level components it can (in most cases) completely eliminate dependencies between the higher level components. In other words, the higher level components can depend on the base applications components and avoid dependencies on eachother.

The total magic of that is that people can develop all sorts of crazy things in OFBiz extensions/addons/plugins, and as long as the use the existing data model property those crazy things should work together with other crazy things pretty well.

-David


On Dec 18, 2009, at 10:50 AM, David E Jones wrote:

>
> I think you misunderstand. The dependencies are not because of the component tools, but because of the components themselves. The components in the ofbiz/applications directory are inherently interdependent, mostly because of the data model. If someone wanted to they could certainly make these components less dependent, but there is not tool that could do so... you'd actually have to move parts of the data model around and use a lot of extend-entity stuff.
>
> The idea that something like OSGi can manage any type of dependency is just plain incorrect. Yes, it has a feature called "dependency management", but it isn't what you're thinking of and simply wouldn't help with this.
>
> Basically all you could possibly do is model somewhere the fact that the applications components are interdependent, but that won't help in eliminating the interdependency.
>
> Is it possible to do? Yes (with certain exceptions, removing some dependencies would NEVER make sense). Is it a big enough deal that anyone has actually bothered to do it? No. It's that simple. It is simply not an objective that anyone has taken up yet.
>
> -David
>
>
> On Dec 18, 2009, at 3:41 AM, chris snow wrote:
>
>>
>> Hi David,
>>
>> The problem that I have with the components is that they are an all or
>> nothing proposition.  For example, due to dependencies, I have not been able
>> to use the party management component on its own without first manually
>> removing the dependencies to other application components.
>>
>> Cheers,
>>
>> Chris
>>
>>
>> David E Jones-4 wrote:
>>>
>>>
>>> On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote:
>>>
>>>> Having OFBiz splitted in a core framework and add-on modules seems to
>>>> me like a must if we want to improve features.
>>>> Add-on modules is how many large and popular projects are built.
>>>> Even OpenERP says to have more that 350 modules and offers different
>>>> flavours of it here http://www.openerp.com/discover/demonstration.html
>>>
>>> We already have a plugin, or add-on, or whatever you want to call it,
>>> facility: components.
>>>
>>>> I think we should start discussing on the module add-on system that we
>>>> want to implement in OFBiz.
>>>> I have read that there is a plan from Neogia people to introduce what
>>>> they have developed. Is there any schedule for this?
>>>> Are you going to write a Confluence page where we can see how it works?
>>>>
>>>> Are we going to host the add-on modules on a separate SVN folder?
>>>
>>> It seems the whole point of add-on modules is to NOT have them be part of
>>> the project. The intellectual property issues and concerns are totally
>>> different from the main project, and the licensing may not be compatible
>>> with what the ASF requires, so no I really don't think it would make sense
>>> to have a place for more loosely managed stuff in SVN.
>>>
>>> On the other hand, we already have a place for add-on modules in SVN: the
>>> specialpurpose directory.
>>>
>>> Consider that the framework and applications directories are the basis of
>>> OFBiz, and everything else is an add-on of sorts. The applications are
>>> important so that add-on components can use the common data model for
>>> implicit integration, unless the add-on application won't be doing
>>> anything with common business data, and then it only needs depend on the
>>> framework.
>>>
>>> Now getting back to the point... I think you already know all of this
>>> Bruno, so what is it that you'd like to see that OFBiz does not already
>>> have?
>>>
>>> -David
>>>
>>>
>>>> 2009/10/29 Tim Ruppert <[hidden email]>:
>>>>> This sounds fantastic Marc - it's amazing to see many of the software
>>>>> providers out there coming together to back this idea.  This has the
>>>>> unique
>>>>> opportunity of taking everything that OFBiz does to the next level.
>>>>>
>>>>> I guess the big question is, what's next to help get some of these
>>>>> backend
>>>>> ideas back into this newly refined mission?  We're more than happy to
>>>>> devote
>>>>> resources to making this happen.
>>>>>
>>>>> Cheers,
>>>>> Ruppert
>>>>> --
>>>>> Tim Ruppert
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> o:801.649.6594
>>>>> f:801.649.6595
>>>>>
>>>>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote:
>>>>>
>>>>>> As many of you know, we at Emforium have been busy building out a full
>>>>>> set
>>>>>> of business software application to provide an "ALL-IN" comprehensive
>>>>>> solution for the small business market.  When we started the evaluation
>>>>>> over
>>>>>> a year ago, Ofbiz was the selected platform of choice.  Other
>>>>>> components are
>>>>>> Zimbra for email and concrete5 for web.
>>>>>>
>>>>>> Over this time, we've spent our efforts providing an entirely new UI
>>>>>> front
>>>>>> end for the backend applications: sales order, inventory, CRM, admin,
>>>>>> reports, multi tenancy, published datasets (makes solution targeted for
>>>>>> any
>>>>>> market or geography), etc...
>>>>>>
>>>>>> We have expressed privately that Ofbiz needs to have a new mission in
>>>>>> order to really drive it's importance and relevance as an open source
>>>>>> project.  As it stands, it's scope is very wide, and not targeted a
>>>>>> providing and out-of-the box solution to any problem, save ecommerce
>>>>>> (even
>>>>>> then, lot's of styling work usually needed).
>>>>>>
>>>>>> We would be 100% behind this direction for Ofbiz.  We'd want to
>>>>>> contribute
>>>>>> back components now that are Emforium proprietary and would work to
>>>>>> reduce
>>>>>> the amount of deviation between our proprietary solution and this newly
>>>>>> stated direction.
>>>>>>
>>>>>> Marc
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://n4.nabble.com/Apache-OFBiz-EZBiz-tp277317p974666.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Bruno Busco]

I try to write down some ideas I have on how I would like add-on
modules in OFBiz.

-- Add-on module management --
Every module should have a name, a version, a description, an author etc.
Every module should have a list of modules from which it depends.
A module should be added to the system using an add-on manager application.
The add-on manager should be able to list all the modules installed
with their version and dependencies.
The add-on manager should let a module installation (or activation)
only if all other required modules are installed and activated.

-- Module integration --
An "administration" application should be used to set all
configurations for all the modules (core and add-on). The
configuration fields or fieldgroups for all the modules should be
added to the admin configuration screens.
Additional modules, when added to the system, should be able to add
new features into other, pre-existent modules without requiring the
pre-existent modules to be aware of them.

Example:
In the catalog application, when looking at a product, there is a
button that allows to go to the ecommerce page for that product.
This is an example of how two applications are linked in a way that
ties them toghether so that it is not possible to install one without
the other.
The ecommerce application depends on the catalog but the other way
around should not be. This ecommerce page link (not only this of
course) is an example of the catalog dependence on the ecommerce that
should not be.
This ecommerce page link button should be, in some way, not
implemented in the catalog application but in the ecommerce one. The
catalog application should only allow a plug-in hosting features
(hooks ?) that allows other applications to add links, fields etc. to
the product page and in all other places.

While looking at a party, there are links in the menu that go to
"Shopping list", to "Employment applications", to "Billing and
financial accounts", "Orders", "Quotes" and even "Geolocation".
What happens if I want to use OFBiz to manage people that is not
supposed to buy things but, for instance, doing something else?
What happens if the users are not connected to the Internet and have
no possibility to access the Googlemap for the Geolocalization?

In these cases I would like to be able to disable (or not install) the
Geolocalization, the orders, the accounting and the human resources
modules.
All the links should be automatically removed from the UI.

I know that the entity, screen, form, menu extension system allows to
have a new application that extends some other but what I think would
be nice is a mechanism that allows a new application to change the
behaviour of an "old" application (without changing its code).

What about a system that allows to define a menu extension to a
pre-existent menu?
By this I mean that supposing to have an applicationA with a menuA, if
I install an additional applicationB, this application is able to add
a couple of menuitems to the menuA of the applicationA.
And what about if this would be done on screens also?

Thank you,
-Bruno


2009/12/17 David E Jones <[hidden email]>:

>
> On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote:
>
>> Having OFBiz splitted in a core framework and add-on modules seems to
>> me like a must if we want to improve features.
>> Add-on modules is how many large and popular projects are built.
>> Even OpenERP says to have more that 350 modules and offers different
>> flavours of it here http://www.openerp.com/discover/demonstration.html
>
> We already have a plugin, or add-on, or whatever you want to call it, facility: components.
>
>> I think we should start discussing on the module add-on system that we
>> want to implement in OFBiz.
>> I have read that there is a plan from Neogia people to introduce what
>> they have developed. Is there any schedule for this?
>> Are you going to write a Confluence page where we can see how it works?
>>
>> Are we going to host the add-on modules on a separate SVN folder?
>
> It seems the whole point of add-on modules is to NOT have them be part of the project. The intellectual property issues and concerns are totally different from the main project, and the licensing may not be compatible with what the ASF requires, so no I really don't think it would make sense to have a place for more loosely managed stuff in SVN.
>
> On the other hand, we already have a place for add-on modules in SVN: the specialpurpose directory.
>
> Consider that the framework and applications directories are the basis of OFBiz, and everything else is an add-on of sorts. The applications are important so that add-on components can use the common data model for implicit integration, unless the add-on application won't be doing anything with common business data, and then it only needs depend on the framework.
>
> Now getting back to the point... I think you already know all of this Bruno, so what is it that you'd like to see that OFBiz does not already have?
>
> -David
>
>
>> 2009/10/29 Tim Ruppert <[hidden email]>:
>>> This sounds fantastic Marc - it's amazing to see many of the software
>>> providers out there coming together to back this idea.  This has the unique
>>> opportunity of taking everything that OFBiz does to the next level.
>>>
>>> I guess the big question is, what's next to help get some of these backend
>>> ideas back into this newly refined mission?  We're more than happy to devote
>>> resources to making this happen.
>>>
>>> Cheers,
>>> Ruppert
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote:
>>>
>>>> As many of you know, we at Emforium have been busy building out a full set
>>>> of business software application to provide an "ALL-IN" comprehensive
>>>> solution for the small business market.  When we started the evaluation over
>>>> a year ago, Ofbiz was the selected platform of choice.  Other components are
>>>> Zimbra for email and concrete5 for web.
>>>>
>>>> Over this time, we've spent our efforts providing an entirely new UI front
>>>> end for the backend applications: sales order, inventory, CRM, admin,
>>>> reports, multi tenancy, published datasets (makes solution targeted for any
>>>> market or geography), etc...
>>>>
>>>> We have expressed privately that Ofbiz needs to have a new mission in
>>>> order to really drive it's importance and relevance as an open source
>>>> project.  As it stands, it's scope is very wide, and not targeted a
>>>> providing and out-of-the box solution to any problem, save ecommerce (even
>>>> then, lot's of styling work usually needed).
>>>>
>>>> We would be 100% behind this direction for Ofbiz.  We'd want to contribute
>>>> back components now that are Emforium proprietary and would work to reduce
>>>> the amount of deviation between our proprietary solution and this newly
>>>> stated direction.
>>>>
>>>> Marc
>>>
>>>
>
>

[Cimballi-2]

Drupal uses hooks : http://api.drupal.org/api/group/hooks/7

Maybe something to get inspired by. It seems to provide good
independance between modules.

Cimballi


On Fri, Dec 18, 2009 at 6:10 PM, Bruno Busco <[hidden email]> wrote:

> I try to write down some ideas I have on how I would like add-on
> modules in OFBiz.
>
> -- Add-on module management --
> Every module should have a name, a version, a description, an author etc.
> Every module should have a list of modules from which it depends.
> A module should be added to the system using an add-on manager application.
> The add-on manager should be able to list all the modules installed
> with their version and dependencies.
> The add-on manager should let a module installation (or activation)
> only if all other required modules are installed and activated.
>
> -- Module integration --
> An "administration" application should be used to set all
> configurations for all the modules (core and add-on). The
> configuration fields or fieldgroups for all the modules should be
> added to the admin configuration screens.
> Additional modules, when added to the system, should be able to add
> new features into other, pre-existent modules without requiring the
> pre-existent modules to be aware of them.
>
> Example:
> In the catalog application, when looking at a product, there is a
> button that allows to go to the ecommerce page for that product.
> This is an example of how two applications are linked in a way that
> ties them toghether so that it is not possible to install one without
> the other.
> The ecommerce application depends on the catalog but the other way
> around should not be. This ecommerce page link (not only this of
> course) is an example of the catalog dependence on the ecommerce that
> should not be.
> This ecommerce page link button should be, in some way, not
> implemented in the catalog application but in the ecommerce one. The
> catalog application should only allow a plug-in hosting features
> (hooks ?) that allows other applications to add links, fields etc. to
> the product page and in all other places.
>
> While looking at a party, there are links in the menu that go to
> "Shopping list", to "Employment applications", to "Billing and
> financial accounts", "Orders", "Quotes" and even "Geolocation".
> What happens if I want to use OFBiz to manage people that is not
> supposed to buy things but, for instance, doing something else?
> What happens if the users are not connected to the Internet and have
> no possibility to access the Googlemap for the Geolocalization?
>
> In these cases I would like to be able to disable (or not install) the
> Geolocalization, the orders, the accounting and the human resources
> modules.
> All the links should be automatically removed from the UI.
>
> I know that the entity, screen, form, menu extension system allows to
> have a new application that extends some other but what I think would
> be nice is a mechanism that allows a new application to change the
> behaviour of an "old" application (without changing its code).
>
> What about a system that allows to define a menu extension to a
> pre-existent menu?
> By this I mean that supposing to have an applicationA with a menuA, if
> I install an additional applicationB, this application is able to add
> a couple of menuitems to the menuA of the applicationA.
> And what about if this would be done on screens also?
>
> Thank you,
> -Bruno
>
>
> 2009/12/17 David E Jones <[hidden email]>:
>>
>> On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote:
>>
>>> Having OFBiz splitted in a core framework and add-on modules seems to
>>> me like a must if we want to improve features.
>>> Add-on modules is how many large and popular projects are built.
>>> Even OpenERP says to have more that 350 modules and offers different
>>> flavours of it here http://www.openerp.com/discover/demonstration.html
>>
>> We already have a plugin, or add-on, or whatever you want to call it, facility: components.
>>
>>> I think we should start discussing on the module add-on system that we
>>> want to implement in OFBiz.
>>> I have read that there is a plan from Neogia people to introduce what
>>> they have developed. Is there any schedule for this?
>>> Are you going to write a Confluence page where we can see how it works?
>>>
>>> Are we going to host the add-on modules on a separate SVN folder?
>>
>> It seems the whole point of add-on modules is to NOT have them be part of the project. The intellectual property issues and concerns are totally different from the main project, and the licensing may not be compatible with what the ASF requires, so no I really don't think it would make sense to have a place for more loosely managed stuff in SVN.
>>
>> On the other hand, we already have a place for add-on modules in SVN: the specialpurpose directory.
>>
>> Consider that the framework and applications directories are the basis of OFBiz, and everything else is an add-on of sorts. The applications are important so that add-on components can use the common data model for implicit integration, unless the add-on application won't be doing anything with common business data, and then it only needs depend on the framework.
>>
>> Now getting back to the point... I think you already know all of this Bruno, so what is it that you'd like to see that OFBiz does not already have?
>>
>> -David
>>
>>
>>> 2009/10/29 Tim Ruppert <[hidden email]>:
>>>> This sounds fantastic Marc - it's amazing to see many of the software
>>>> providers out there coming together to back this idea.  This has the unique
>>>> opportunity of taking everything that OFBiz does to the next level.
>>>>
>>>> I guess the big question is, what's next to help get some of these backend
>>>> ideas back into this newly refined mission?  We're more than happy to devote
>>>> resources to making this happen.
>>>>
>>>> Cheers,
>>>> Ruppert
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>>>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote:
>>>>
>>>>> As many of you know, we at Emforium have been busy building out a full set
>>>>> of business software application to provide an "ALL-IN" comprehensive
>>>>> solution for the small business market.  When we started the evaluation over
>>>>> a year ago, Ofbiz was the selected platform of choice.  Other components are
>>>>> Zimbra for email and concrete5 for web.
>>>>>
>>>>> Over this time, we've spent our efforts providing an entirely new UI front
>>>>> end for the backend applications: sales order, inventory, CRM, admin,
>>>>> reports, multi tenancy, published datasets (makes solution targeted for any
>>>>> market or geography), etc...
>>>>>
>>>>> We have expressed privately that Ofbiz needs to have a new mission in
>>>>> order to really drive it's importance and relevance as an open source
>>>>> project.  As it stands, it's scope is very wide, and not targeted a
>>>>> providing and out-of-the box solution to any problem, save ecommerce (even
>>>>> then, lot's of styling work usually needed).
>>>>>
>>>>> We would be 100% behind this direction for Ofbiz.  We'd want to contribute
>>>>> back components now that are Emforium proprietary and would work to reduce
>>>>> the amount of deviation between our proprietary solution and this newly
>>>>> stated direction.
>>>>>
>>>>> Marc
>>>>
>>>>
>>
>>
>

[Erwan de FERRIERES-3]

Hi Bruno,

here are some comments inline

Le 19/12/2009 00:10, Bruno Busco a écrit :

> I try to write down some ideas I have on how I would like add-on
> modules in OFBiz.
>
> -- Add-on module management --
> Every module should have a name, a version, a description, an author etc.
> Every module should have a list of modules from which it depends.
> A module should be added to the system using an add-on manager application.
> The add-on manager should be able to list all the modules installed
> with their version and dependencies.
> The add-on manager should let a module installation (or activation)
> only if all other required modules are installed and activated.

The neogia addon management is using the same requirements you are
talking about and is already used and implemented.
The addon should use of the 3 types listed here :
application : only business rules and "classic" screens
framework : as named
specialpurpose : for a dedicated UI, for specifics or business rules in
a company (eg. the addon sales-adm-b2b is a specific interface which is
using standard OFBiz services, but relooked for the sales administration
people in a B2B environment).
>
> -- Module integration --
> An "administration" application should be used to set all
> configurations for all the modules (core and add-on). The
> configuration fields or fieldgroups for all the modules should be
> added to the admin configuration screens.
> Additional modules, when added to the system, should be able to add
> new features into other, pre-existent modules without requiring the
> pre-existent modules to be aware of them.
We may start with all OFBiz components, a best pratice will be added in
addons.

>
> Example:
> In the catalog application, when looking at a product, there is a
> button that allows to go to the ecommerce page for that product.
> This is an example of how two applications are linked in a way that
> ties them toghether so that it is not possible to install one without
> the other.
> The ecommerce application depends on the catalog but the other way
> around should not be. This ecommerce page link (not only this of
> course) is an example of the catalog dependence on the ecommerce that
> should not be.
> This ecommerce page link button should be, in some way, not
> implemented in the catalog application but in the ecommerce one. The
> catalog application should only allow a plug-in hosting features
> (hooks ?) that allows other applications to add links, fields etc. to
> the product page and in all other places.

This type of requirement is managed via one addon "catalog-ecommerce",
which is dependant from ecommerce and catalog.

>
> While looking at a party, there are links in the menu that go to
> "Shopping list", to "Employment applications", to "Billing and
> financial accounts", "Orders", "Quotes" and even "Geolocation".
> What happens if I want to use OFBiz to manage people that is not
> supposed to buy things but, for instance, doing something else?
> What happens if the users are not connected to the Internet and have
> no possibility to access the Googlemap for the Geolocalization?
>
> In these cases I would like to be able to disable (or not install) the
> Geolocalization, the orders, the accounting and the human resources
> modules.
> All the links should be automatically removed from the UI.

Currently, some addons have been created and mandatory dependencies are
managed. The suggested ones are managed by hand. Adding a dedicated
screen is a good idea.

>
> I know that the entity, screen, form, menu extension system allows to
> have a new application that extends some other but what I think would
> be nice is a mechanism that allows a new application to change the
> behaviour of an "old" application (without changing its code).
>
> What about a system that allows to define a menu extension to a
> pre-existent menu?
> By this I mean that supposing to have an applicationA with a menuA, if
> I install an additional applicationB, this application is able to add
> a couple of menuitems to the menuA of the applicationA.
> And what about if this would be done on screens also?
>

Addons are now used since 6 months and this seems to be dependant from
addons.
What appeared during this 6 months is that :
* sometimes modifying existing files is more readable,
* one other time, using extends is better,
* another time, adding a component will be the solution,
* and sometimes, it's OFBiz which seems to be not enough modular...

HTH,

> Thank you,
> -Bruno
>

../..

--
Erwan de FERRIERES
www.nereide.biz

[Bruno Busco]

Thank you Erwan for this clause-by-clause to the Neogia addon manager.

To be sincere I was looking to something different from what seems to
be a patch manager.
I see that using patches is a solution that has no limit on what can
be done. (A patch can be even a complete remake of an application).
On the other hand since the patches can touch everything in the code
they can easily be outdated when the code improves.

A module that plugs-in using specific "connectors" is more robust and
it should work even if the code improves until the connectors remain
unchanged (and in this case also connectors improvement may be
compatible with old plugins).

If I understand well (but please correct me if I am wrong) basing on
SVN patches, the Neogia system should also be sensible on the
repository the code has been checked-out from. What happens to OFBiz
installation that is managed on a different SVN repository of even no
SVN repo at all?

-Bruno



2009/12/21 Erwan de FERRIERES <[hidden email]>:

> Hi Bruno,
>
> here are some comments inline
>
> Le 19/12/2009 00:10, Bruno Busco a écrit :
>>
>> I try to write down some ideas I have on how I would like add-on
>> modules in OFBiz.
>>
>> -- Add-on module management --
>> Every module should have a name, a version, a description, an author etc.
>> Every module should have a list of modules from which it depends.
>> A module should be added to the system using an add-on manager
>> application.
>> The add-on manager should be able to list all the modules installed
>> with their version and dependencies.
>> The add-on manager should let a module installation (or activation)
>> only if all other required modules are installed and activated.
>
> The neogia addon management is using the same requirements you are talking
> about and is already used and implemented.
> The addon should use of the 3 types listed here :
> application : only business rules and "classic" screens
> framework : as named
> specialpurpose : for a dedicated UI, for specifics or business rules in a
> company (eg. the addon sales-adm-b2b is a specific interface which is using
> standard OFBiz services, but relooked for the sales administration people in
> a B2B environment).
>>
>> -- Module integration --
>> An "administration" application should be used to set all
>> configurations for all the modules (core and add-on). The
>> configuration fields or fieldgroups for all the modules should be
>> added to the admin configuration screens.
>> Additional modules, when added to the system, should be able to add
>> new features into other, pre-existent modules without requiring the
>> pre-existent modules to be aware of them.
>
> We may start with all OFBiz components, a best pratice will be added in
> addons.
>>
>> Example:
>> In the catalog application, when looking at a product, there is a
>> button that allows to go to the ecommerce page for that product.
>> This is an example of how two applications are linked in a way that
>> ties them toghether so that it is not possible to install one without
>> the other.
>> The ecommerce application depends on the catalog but the other way
>> around should not be. This ecommerce page link (not only this of
>> course) is an example of the catalog dependence on the ecommerce that
>> should not be.
>> This ecommerce page link button should be, in some way, not
>> implemented in the catalog application but in the ecommerce one. The
>> catalog application should only allow a plug-in hosting features
>> (hooks ?) that allows other applications to add links, fields etc. to
>> the product page and in all other places.
>
> This type of requirement is managed via one addon "catalog-ecommerce", which
> is dependant from ecommerce and catalog.
>>
>> While looking at a party, there are links in the menu that go to
>> "Shopping list", to "Employment applications", to "Billing and
>> financial accounts", "Orders", "Quotes" and even "Geolocation".
>> What happens if I want to use OFBiz to manage people that is not
>> supposed to buy things but, for instance, doing something else?
>> What happens if the users are not connected to the Internet and have
>> no possibility to access the Googlemap for the Geolocalization?
>>
>> In these cases I would like to be able to disable (or not install) the
>> Geolocalization, the orders, the accounting and the human resources
>> modules.
>> All the links should be automatically removed from the UI.
>
> Currently, some addons have been created and mandatory dependencies are
> managed. The suggested ones are managed by hand. Adding a dedicated screen
> is a good idea.
>>
>> I know that the entity, screen, form, menu extension system allows to
>> have a new application that extends some other but what I think would
>> be nice is a mechanism that allows a new application to change the
>> behaviour of an "old" application (without changing its code).
>>
>> What about a system that allows to define a menu extension to a
>> pre-existent menu?
>> By this I mean that supposing to have an applicationA with a menuA, if
>> I install an additional applicationB, this application is able to add
>> a couple of menuitems to the menuA of the applicationA.
>> And what about if this would be done on screens also?
>>
> Addons are now used since 6 months and this seems to be dependant from
> addons.
> What appeared during this 6 months is that :
> * sometimes modifying existing files is more readable,
> * one other time, using extends is better,
> * another time, adding a component will be the solution,
> * and sometimes, it's OFBiz which seems to be not enough modular...
>
> HTH,
>
>> Thank you,
>> -Bruno
>>
>
> ../..
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>

[Malin Nicolas]

Hi Bruno,

With addons you don't use a svn for manage OFBiz customer instance.

Here is process that I use for my customer :
 1. Take a fix OFBiz revision
 2. Install addons that I need for manage the specific customer process
who not support by OFBiz
 3. Create and install addon specific for my customer
(data/config/standard process modification ...)

For a new OFBiz revision :
 1. Take new OFBiz revision on customer integration serveur
 2. Install addons that haven't send to OFBiz by Jira and commited ;)
 3. Update and install customer addon
 4. Do new installation on prod server.

Addon manager use patch system for update OFBiz file but you can also
manage component's for specialpurpose as module. After it's just a
technical solution, we continue to improve good practice to manage the
improvements made to OFBiz and all comment are fine ;)

Nicolas
 

Bruno Busco a écrit :

> Thank you Erwan for this clause-by-clause to the Neogia addon manager.
>
> To be sincere I was looking to something different from what seems to
> be a patch manager.
> I see that using patches is a solution that has no limit on what can
> be done. (A patch can be even a complete remake of an application).
> On the other hand since the patches can touch everything in the code
> they can easily be outdated when the code improves.
>
> A module that plugs-in using specific "connectors" is more robust and
> it should work even if the code improves until the connectors remain
> unchanged (and in this case also connectors improvement may be
> compatible with old plugins).
>
> If I understand well (but please correct me if I am wrong) basing on
> SVN patches, the Neogia system should also be sensible on the
> repository the code has been checked-out from. What happens to OFBiz
> installation that is managed on a different SVN repository of even no
> SVN repo at all?
>
> -Bruno
>
>
>
> 2009/12/21 Erwan de FERRIERES <[hidden email]>:
>  
>> Hi Bruno,
>>
>> here are some comments inline
>>
>> Le 19/12/2009 00:10, Bruno Busco a écrit :
>>    
>>> I try to write down some ideas I have on how I would like add-on
>>> modules in OFBiz.
>>>
>>> -- Add-on module management --
>>> Every module should have a name, a version, a description, an author etc.
>>> Every module should have a list of modules from which it depends.
>>> A module should be added to the system using an add-on manager
>>> application.
>>> The add-on manager should be able to list all the modules installed
>>> with their version and dependencies.
>>> The add-on manager should let a module installation (or activation)
>>> only if all other required modules are installed and activated.
>>>      
>> The neogia addon management is using the same requirements you are talking
>> about and is already used and implemented.
>> The addon should use of the 3 types listed here :
>> application : only business rules and "classic" screens
>> framework : as named
>> specialpurpose : for a dedicated UI, for specifics or business rules in a
>> company (eg. the addon sales-adm-b2b is a specific interface which is using
>> standard OFBiz services, but relooked for the sales administration people in
>> a B2B environment).
>>    
>>> -- Module integration --
>>> An "administration" application should be used to set all
>>> configurations for all the modules (core and add-on). The
>>> configuration fields or fieldgroups for all the modules should be
>>> added to the admin configuration screens.
>>> Additional modules, when added to the system, should be able to add
>>> new features into other, pre-existent modules without requiring the
>>> pre-existent modules to be aware of them.
>>>      
>> We may start with all OFBiz components, a best pratice will be added in
>> addons.
>>    
>>> Example:
>>> In the catalog application, when looking at a product, there is a
>>> button that allows to go to the ecommerce page for that product.
>>> This is an example of how two applications are linked in a way that
>>> ties them toghether so that it is not possible to install one without
>>> the other.
>>> The ecommerce application depends on the catalog but the other way
>>> around should not be. This ecommerce page link (not only this of
>>> course) is an example of the catalog dependence on the ecommerce that
>>> should not be.
>>> This ecommerce page link button should be, in some way, not
>>> implemented in the catalog application but in the ecommerce one. The
>>> catalog application should only allow a plug-in hosting features
>>> (hooks ?) that allows other applications to add links, fields etc. to
>>> the product page and in all other places.
>>>      
>> This type of requirement is managed via one addon "catalog-ecommerce", which
>> is dependant from ecommerce and catalog.
>>    
>>> While looking at a party, there are links in the menu that go to
>>> "Shopping list", to "Employment applications", to "Billing and
>>> financial accounts", "Orders", "Quotes" and even "Geolocation".
>>> What happens if I want to use OFBiz to manage people that is not
>>> supposed to buy things but, for instance, doing something else?
>>> What happens if the users are not connected to the Internet and have
>>> no possibility to access the Googlemap for the Geolocalization?
>>>
>>> In these cases I would like to be able to disable (or not install) the
>>> Geolocalization, the orders, the accounting and the human resources
>>> modules.
>>> All the links should be automatically removed from the UI.
>>>      
>> Currently, some addons have been created and mandatory dependencies are
>> managed. The suggested ones are managed by hand. Adding a dedicated screen
>> is a good idea.
>>    
>>> I know that the entity, screen, form, menu extension system allows to
>>> have a new application that extends some other but what I think would
>>> be nice is a mechanism that allows a new application to change the
>>> behaviour of an "old" application (without changing its code).
>>>
>>> What about a system that allows to define a menu extension to a
>>> pre-existent menu?
>>> By this I mean that supposing to have an applicationA with a menuA, if
>>> I install an additional applicationB, this application is able to add
>>> a couple of menuitems to the menuA of the applicationA.
>>> And what about if this would be done on screens also?
>>>
>>>      
>> Addons are now used since 6 months and this seems to be dependant from
>> addons.
>> What appeared during this 6 months is that :
>> * sometimes modifying existing files is more readable,
>> * one other time, using extends is better,
>> * another time, adding a component will be the solution,
>> * and sometimes, it's OFBiz which seems to be not enough modular...
>>
>> HTH,
>>
>>    
>>> Thank you,
>>> -Bruno
>>>
>>>      
>> ../..
>>
>> --
>> Erwan de FERRIERES
>> www.nereide.biz
>>
>>    

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/