ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bakker <h.bak...@antwebsystems.com>
Subject Re: Addons for OFBiz
Date Thu, 14 May 2015 01:08:25 GMT

There are several solutions not modifying the core system when modifying 
a service:
1. we create a new service calling the standard service and do the 
modifications before or after it.
2. if there are many changes, copy the whole service to the new 
component rename it and modify it.
3. if it is a useful change contribute it to the core system.


On 13/05/15 15:12, pierre wrote:
> Hi Hans,
> At Néréide we use the same way as you explain except that some time we 
> have to do modifications in OFBiz core to slightly change one service 
> because there is an error or the process is not exactly what we need. 
> In this case we have to isolate these modifications so that they can 
> be applied when OFBiz core is upgraded. This is done thru addon.
> How do you manage modifications in OFBiz core?
> Pierre
> On 13/05/2015 09:48, Hans Bakker wrote:
>> Julien, It can be that i do not understand your point.
>> When we implement OFBiz for a customer we create a new component in 
>> hot-deploy and we re-use as much from the OFBiz system as we can. We 
>> also create new components like GrowERP which is just a component in 
>> Hot-deploy. When we do that we almost not change the core ofbiz 
>> system so we can easily upgrade.
>> So i think that add-ons can be easily created just by adding new 
>> components in hot-deploy, or do i miss something?
>> Regards,
>> Hans
>> On 13/05/15 13:56, Julien NICOLAS wrote:
>>> Hi all,
>>> I was hopping more people will explain on this subject. It's exactly 
>>> what I was thinking, that the functional part is less than the last 
>>> priority of the project.
>>> I don't know exactly how I can do it but I really want to start 
>>> something that will use OFBiz as a framework. If it can be done with 
>>> the OFBiz community, it will be really good.
>>> Efforts exist but need people of the strong OFBiz community to be 
>>> really better (GrowERP, BigFish, TERCompta, etc.).
>>> It's a pity that every new company that want to work with OFBiz must 
>>> work on it's own version to be able to integrate it. I don't think 
>>> it's a good thing for the project growing.
>>> And OFBiz community don't allow company to find easily other effort 
>>> to enhance the software. And finally it seems that there is less 
>>> than 5 peoples interested to work on this way.
>>> Maybe I'm wrong, functional is not as important as I thought...
>>> Sorry for the noise,
>>> Julien.
>>> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>>>> I agree with Julien's analysis.
>>>> If I say "sub-projects" again, Jacques will whack me upside the 
>>>> head but I really think that a restructuring of the way the 
>>>> architecture is presented and developed would provide a number of 
>>>> benefits:
>>>> - increase community involvement with less work for the current key 
>>>> committers
>>>> - reduce or eliminate sub-optimal inter-component dependencies 
>>>> through clearer definitions and independent releases of components
>>>> - reduce mixing of core seed data with demo and customizable seed 
>>>> data and inter-component data confusion.
>>>> - facilitate the construction of components and add-ons that do not 
>>>> have undesirable or unknown side-affects
>>>> - facilitate the injection of a smart installer that would allow 
>>>> the selection of  components and templates as suggested at install 
>>>> time.
>>>> - facilitate the development of an OFBiz marketplace for add-ons 
>>>> and industry-specific configurations.
>>>> - make the role of the framework as a base for other products much 
>>>> clearer.
>>>> - possibly make it easier to "Moquify" the framework if the 
>>>> framework API can be made less implementation dependent - lots of 
>>>> issues here that already have been fully ventilated last week.
>>>> Ron
>>>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>>>> Hi Julien,
>>>>> thank you for bringing this up!
>>>>> I don't think that this is of no interest in the community, it's 
>>>>> just overlaid by the many other topics we are discussing 
>>>>> currently. I personally think that all topics are worth to be 
>>>>> discussed and elaborated, maybe they have to be prioritised a 
>>>>> little bit more. Right now it's a little bit confusing and not 
>>>>> easy to follow (and contribute to) the discussions besides daily 
>>>>> business.
>>>>> I think it is an important topic to simplify the backend 
>>>>> component's UI and have more sophisticated usability there. On the 
>>>>> other hand, it is important to somehow show customers the powers 
>>>>> of OFBiz and the many already set-up functionalities. It would be 
>>>>> a big step forward if we find a way to make this customizeable. 
>>>>> For an ERP, it would also be a big plus to have some kind of 
>>>>> "business templates" (!= UI templates) on top of such a mechanism, 
>>>>> like
>>>>> - Your customer sells products over the internet? - pull the 
>>>>> ecommerce template
>>>>> - Your customer brews beer? - pull the manufacturing +x template
>>>>> - Your customer has a small business? - pull the corresponding 
>>>>> template
>>>>> etc.
>>>>> I belive that would require different configuration mechanisms, 
>>>>> more on a database level with a clever UI instead of many 
>>>>> different property files. And maybe a tool to chain services 
>>>>> together on base of  such a template.
>>>>> I won't reduce the functionality in OFBiz per se, as long as they 
>>>>> are stable and/or have a maintainer.
>>>>> I know of at least one contributor who is also working on a more 
>>>>> sophisticated UI, maybe he shows up here also ;-)
>>>>> So, without having a concrete plan or more thought-out ideas how 
>>>>> to implement this, I would support such an effort.
>>>>> As a community, I think we have to find a way to channel the 
>>>>> different interests from core technology work up to the business 
>>>>> layer. Some kind of overall project management would help but 
>>>>> would be difficult to install in an open community. Too many open 
>>>>> building sites in parallel are not that efficient.
>>>>> Curious what others think...
>>>>> Regards,
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>>>> Hello All,
>>>>>> Since I work on the bootstrap theme in OFBiz, I have many 
>>>>>> thoughtful, carefully read the ofbiz community exchanges and 
>>>>>> spoke with some members of the OFBiz community.
>>>>>> Today I am convinced that the OFBiz project is a framework that 
>>>>>> is not intended to be an ERP. Its OOTB user interface is a 
>>>>>> nightmare and is not really user oriented.
>>>>>> Several topics that seem to have no link together, seems to be 
>>>>>> linked around the same idea.
>>>>>> The first topic is about functionality of OFBiz.
>>>>>> On one hand, there is the OFBiz framework. It contains a user 
>>>>>> interface to show the possibility of OFBiz, but must be changed 
>>>>>> during integration. It also includes functional oriented 
>>>>>> features. These features split the community between those who 
>>>>>> want to keep them in the project and those who wish to exclude them.
>>>>>> On the other hand, there are new initiatives,abandoned projects,

>>>>>> old or having no longer contributors (project manager, POS, etc.)

>>>>>> who need support, visibility, even if they are not added to the 
>>>>>> OFBiz project.
>>>>>> A first approach was discussed with GIT. It can allow everyone to

>>>>>> share their work more easily with branch feature. Which is good 
>>>>>> but not the best in my opinion.
>>>>>> Another topic that is important to me is the functional part of 
>>>>>> OFBiz.
>>>>>> Sharan explained me about its willingness to invest energy to 
>>>>>> make the software more functional, and if it's possible to have a

>>>>>> version with ERP oriented for small businesses with minimal 
>>>>>> features but easy to use. Like growERP or TerCompta offer. Using

>>>>>> OFBiz framework but simplify the UI to allow the software to be 
>>>>>> used intuitively without modifications.
>>>>>> These initiatives come up against the model of OFBiz project. Who

>>>>>> has still not decided whether it is an ERP, in which case it 
>>>>>> needs to adjust its UI or an automation of enterprise processes 
>>>>>> framework, which involves getting rid of unnecessary features 
>>>>>> dedicated to ERP.
>>>>>> There are several solutions that could help to make better the 
>>>>>> model of OFBiz and satisfy the entire community.
>>>>>> The first solution would be to limit the “OFBiz framewok” project

>>>>>> framework for automation enterprise processes and to have another

>>>>>> “OFBiz ERP” project which would use the framework as a basis,
>>>>>> which would provide a user-friendly UI and dedicated tools to ERP.
>>>>>> The second option is to find a way to cut the project in 
>>>>>> extensions. This solution would have the opportunity to clean the

>>>>>> framework and have features as micro projects and therefore no 
>>>>>> longer a monolithic software.
>>>>>> I see a lot of debate about adding new functionality that allow 
>>>>>> to improve development, compile, manage sources, merge with 
>>>>>> another framework, but the debate on the division of project 
>>>>>> extensions seems not to interest. It seems to me extremely 
>>>>>> important to facilitate development and therefore, ultimately, 
>>>>>> the visibility of the project in the developers community.
>>>>>> At Nomaka, we initiated an effort starting from the first 
>>>>>> solution. We took OFBiz framework, deleted all the themes and 
>>>>>> created a new one. Then we redesigned the interface to match a 
>>>>>> basic ERP.
>>>>>> We started with actor UI. Disabled existing screens and created 
>>>>>> new ones more functional and user-friendly.
>>>>>> I find it a pity to work alone in my corner without being able to

>>>>>> easily share my work, without taking advantage of the OFBiz 
>>>>>> community knowledge to guide me onthe right way.
>>>>>> I wonder if we could work on this axis and balance the rigidity 
>>>>>> necessary to have a stable project and flexibility that allow to

>>>>>> include non-committer contributions ...
>>>>>> What do you think ?
>>>>>> Julien.
> -- 
> logoNrd <http://nereide.fr/>
> 	Pierre GAUDIN
> Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre
> information@nereide.fr
> 3bis rue des Isles 37270 VERETZ
> Std: 02 47 50 30 54 - mob: 06 08 40 25 70
> ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE 
> <http://www.libre-entreprise.org/>

View raw message