everyone will say that I ramble but

I don't understand how it's possible to find a consensus on slim-down
boundary or what should be in ofbiz kernel if there is no simple process
to have a OFbiz with the selected functionalities.
I clearly speak about addon manager.

Some example to be more clear :
First example) Birt or JasperReport :
  * To have a correct implementation it's necessary to add some file,
update some others
  * everybody will agree it's important to have report in a ERP and
currently report available in ofbiz in one of these weakness
  * when I want to develop or to contribute to ofbiz project with some
report, theses report should be easily downloadable and installable for
the users which want
    * added some and update some other (menus at least)
for the technical way of birt implementation in ofbiz (or jasper one)
ofbiz's PMC (and committer and contributors) can discuss and status to
the correct way or quality or default solution and so decide to put
 - in apache-ofbiz
 - in ofbiz-extra quality level 1 or 2 or 3 ...
but in all case, it should be easy for user
1) to see that these solutions exists
2) to understand to Apache OFbiz position on it
3) to be able to use it if they choose without a complex and dedicated
process

Second example) CRM application :
  * all main crm functions exist in ofbiz applications
  * CRM for B2B and B2C are not the same, in industry or service more not
  * some function which should be extend for CRM-B2B-industry are the
same than for CRM-B2C-Service
Why it's necessary to choose which one should be in ofbiz and other out
but in all case, it should be easy for user
1) to see that these solutions exists
2) to understand to Apache OFbiz position on it
3) to be able to use it if they choose without a complex and dedicated
process


Some things can be at the component level some other at functions level.
If we want to increase contribution we should give tools and
organization for that. Currently Jira is perfect for bug correction or
enhancement which should go to ofbiz, but not for business or technical
functionalities dedicated for a business or a implementation type.
We are multiple to develop the same thing for our customers, it's not
logical in Apache project ecosystem.

Clearly, addon management for an ERP in a difficult point, some of ERP
address some point of addon management but not all.
Clearly, addon management must be manage with
1) correct tools
2) correct administrative process and quality evaluation

one ofbiz addon manager implementation exist and is available on
ofbiz-extra http://code.google.com/a/apache-extras.org/p/ofbiz-adm/
If ofbiz-extra is, like paul said, a place to forgot contribution, it's
better to clearly said it.

if these implementation of ofbiz-addon is correct for ofbiz's PMC (and
committer and contributors),  I think it must be included in the ofbiz
kernel to facilitate all other installation or un-installation.


Last point, if there is no addon management in ofbiz, only component,
IMO I have exactly the same opinion as Hans, otherwise every point is
open to discussion.

Olivier

Le 16/11/2012 09:29, Jacopo Cappellato a écrit :
> Please see inline:
>
> On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote:
>
>> Hi Jacopo,
>>
>> So apart the next step is to move all specialpurpose components to Apache 
>> Extras. Are we still all OK to do that?
> I don't think we should move all specialpurpose components out of the 
> project, and for sure not all of them in one shot: we could discuss on a per 
> component basis.
>
>> I heard here and there that not all the community is expecting good from 
>> this move.
> Of course it will be impossible to make everyone happy but the feedback I am 
> reading in this thread makes me happy (no dramatic tones, like happened in 
> the past, willing to evaluate pros and cons etc..).
> BTW, some time ago I also proposed an alternative path: see email with 
> subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we 
> could provide two set of ant scripts, one similar to the one we have that 
> builds/tests everything (framework+applications+specialpurpose) and one (the 
> default) that only builds/tests the framework+applications; the release 
> branches may only contain the framework+applications and separate releases of 
> specialpurpose applications could be voted/released at different time. This 
> approach may reach two goals:
> 1) slim down the "main" code that the community is more focused to 
> improve/maintain/release
> 2) keep under the OFBiz community the ownership of all the other 
> specialpurpose components (this should address Paul's concerns); if one of 
> them will get more attention and interest and could grow in quality or it is 
> generic enough we could decide to move it to the release branch (maybe move 
> it to applications)
>
>> Like less attention to moved components or new component going only to 
>> Apache Extras.
>> An example is the new Solr component wich is supposed to be used with the 
>> eCommerce component.
> The problem I have with these components (and to be clear I am not referring 
> to this specific contribution) is that they are one particular implementation 
> (and very often not the best) of a requirement (e.g. Solr integration, 
> reporting tool, help system etc...) and there could be 100 others different 
> ways to implement the same: for example, even if everyone agrees that the 
> "online help" is useful, there are many doubts that the specific 
> implementation of it we are discussing is the right way to go; or even if 
> everyone agrees that a better reporting tool would be nice to have, there are 
> many that think that the current Birt component is not the right way to go.
>
> Kind regards,
>
> Jacopo
>
>> So far we agreed that the eCommerce component will be the only one (apart if 
>> we agree on it the new webhelp component) to stay in specialpurpose, right?
>>
>> Thanks to one last time share your opinions, before the next move occurs...
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com>
>>> Thank you Jacques.
>>>
>>> I am going to work on the debian removal, that should be quick.
>>>
>>> Another important milestone would be the creation of an extras.html page 
>>> for our website where we could list:
>>> 1) the components for OFBiz managed out of the OFBiz as Apache Extras
>>> 2) the components moved to Attic (migrating the information currently in 
>>> Confluence)
>>>
>>> A short description in the page should describe the process.
>>>
>>> For this task a contributor/committer with good English skills would be 
>>> required. The final content of the page will be approved in this list 
>>> before it will be published.
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>>
>>> On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote:
>>>
>>>> I don't see much activity recently
>>>> https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
>>>>
>>>> Should we not focus a bit more on it?
>>>>
>>>> Jacques
>>>>
>>>
>

Reply via email to