Slim-down effort: current situation

[Jacques Le Roux]

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

[Jacopo Cappellato-4]

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
>

[Jacques Le Roux]

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 heard here and there that not all the community is expecting good from this move.
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.
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" <[hidden email]>

> 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
>>
>
>

[hans_bakker]

In general i agree with this action however,

1. components which need to be integrated with components like help and
reporting (birt) in order to be useful and which are essential for the
functionality of the system, i do not agree:

help
Birt

2. further the following components are standard in any ERP system so
OFBiz should have it too:

ecommerce
asset management
pos,webpos

3. Then the components which are essential for new developers:
example
cmssite

Regards,
Hans






On 11/16/2012 02:11 PM, 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 heard here and there that not all the community is expecting good from this move.
> 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.
> 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" <[hidden email]>
>> 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
>>>
>>

[Paul Piper]

I am concerned about this move to be honest. In general, the idea to focus with apache ofbiz on its core and to cluster the other components into external "plugins" is an important step, however, I do not think that moving it all outside of ASF would help us by any means.

In my opinion it is important to keep a relation between OFBiz and its subprojects. Granted, not all of which can fulfill the quality or commitment that we want to achieve, but taking it outside the realms of ASF and the PMC means that we forcefully take away the relation of one and another. This in turn means that the OFBiz and Apache brand do not apply to those projects and hence the level of commitment is going to be even less (why would any company commit its work if its not even going to be a part of the oficial brand?).

In addition, taking projects entirely out of focus will result in less participation overall, because the projects are going to have less observations - not more. This will result in an overall downfall in quality of such components (which is not all that strong to begin with) and could hurt the community. Instead, there is a high probability that we will see an increase of additional and similar projects (a second, or third demo shop would probably not be too uncommon) which will strip the quality even further. Simply put the incentives aren't right.

On top there is actually a somewhat legal infringement if I am not mistaken. Since the developers commited their sources to ASF, I wouldn't be too certain that you can simply take them and move them to google. Even if under the Apache license, I am not sure if its that easy to do so.

Perhaps to clarify once more: The move in itself is good, but I would really hope for an ASF based subproject. It is important that we do this, but why not choose a better way that sets the incentives right?

[Jacques Le Roux]

I tend to agree with you Hans for those components, complements inline

From: "Hans Bakker" <[hidden email]>
> In general i agree with this action however,
>
> 1. components which need to be integrated with components like help and
> reporting (birt) in order to be useful and which are essential for the
> functionality of the system, i do not agree:
>
> help
Essential in my opinion, we should name it webhelp to make clear what it uses (docbook-webhelp seems a bit too much no?)

> Birt

The only drawback with Birt though is its size, could we not use Ivy to charge what is not specific to OFBiz. Because I think not everybody is using Birt

> 2. further the following components are standard in any ERP system so
> OFBiz should have it too:
>
> ecommerce
What about the new related Solr component contributed recently https://issues.apache.org/jira/browse/OFBIZ-4941
> asset management
> pos,webpos
Exactly my opinion for those 3 too
 
> 3. Then the components which are essential for new developers:
> example
+1
> cmssite
I'd have to review more

And what about projectmgr?

The others are for me specific enough to get to Apache Extras

Jacques

> Regards,
> Hans
>
>
>
>
>
>
> On 11/16/2012 02:11 PM, 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 heard here and there that not all the community is expecting good from this move.
>> 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.
>> 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" <[hidden email]>
>>> 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
>>>>
>>>
>

[Jacopo Cappellato-4]

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" <[hidden email]>
>> 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
>>>
>>
>>

[Jacques Le Roux]

Inline...

From: "Jacopo Cappellato" <[hidden email]>
> 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.

Great
 
>> 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)

This sounds like a really smart way, I will have to read "[PROPOSAL] from specialpurpose to extras" (closer) again...

>> 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.

100 others different ways I'm not sure ;) But yes I get your point. The problem is then to get things done in time... There is nothing perfect in this world (which does not mean I believe in another perfect world)...

Jacques

> 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" <[hidden email]>
>>> 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
>>>>
>>>
>>>
>
>

[Olivier.heintz]

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" <[hidden email]>
>>> 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
>>>>
>>>
>

[Jacopo Cappellato-4]

On Nov 16, 2012, at 10:50 AM, Olivier Heintz wrote:

> 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.

Even if an OFBiz Plugin Manager would be a nice to have tool I don't think that without it we could not proceed with the removal of some components: it is true that this would require some manual steps (depending on the instructions of the component and on the type of deployment of the company using OFBiz) to plug-in the external component but it is also true that at the moment in order to have an OFBiz instance in production every company at least need the following skills: a database administrator (in order to fine tune db indexes, create db users, import data etc...), an architect (in order to identify the proper hardware and configuration for the application servers, database servers, web servers) and very often a developer (to extract data from legacy systems and import in OFBiz, to customize screens and processes, to debug problems etc...). Without this skill set all you can do is to setup a staging/demo box; if you have at least part of the skillset for a production system, manually deploying a couple more components would not be a big deal either.
The only real area where a user friendly OFBiz Plugin Manager tool would be required is in a multi tenant system served as saas: the user (of a tenant) could setup plugins that are visible to that tenant only.

Kind regards,

Jacopo

[Paul Piper]

@jacopo: That sounds like a terrific idea of yours! I have to read up on [Proposal], but from your outline here, i would say it is a more sincere step.

@Olivier: I liked your presenation on addon-manager a lot and as already discussed would think that a tool like this (sort of like a yum- install manager) could be beneficial to whatever we come up with here. But the tool for me is an addition to the proposal above, it is not a contradiction to it.

[Jacques Le Roux]

Very well summed up, Paul

Thanks

Jacques

From: "madppiper" <[hidden email]>

> @jacopo: That sounds like a terrific idea of yours! I have to read up on
> [Proposal], but from your outline here, i would say it is a more sincere
> step.
>
> @Olivier: I liked your presenation on addon-manager a lot and as already
> discussed would think that a tool like this (sort of like a yum- install
> manager) could be beneficial to whatever we come up with here. But the tool
> for me is an addition to the proposal above, it is not a contradiction to
> it.
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637667.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Olivier.heintz]

Le 16/11/2012 11:37, Jacopo Cappellato a écrit :
> On Nov 16, 2012, at 10:50 AM, Olivier Heintz wrote:
>
>> 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.
> Even if an OFBiz Plugin Manager would be a nice to have tool I don't think that without it we could not proceed with the removal of some components: it is true that this would require some manual steps (depending on the instructions of the component and on the type of deployment of the company using OFBiz) to plug-in the external component but it is also true that at the moment in order to have an OFBiz instance in production every company at least need the following skills: a database administrator (in order to fine tune db indexes, create db users, import data etc...), an architect (in order to identify the proper hardware and configuration for the application servers, database servers, web servers) and very often a developer (to extract data from legacy systems and import in OFBiz, to customize screens and processes, to debug problems etc...). Without this skill set all you can do is to setup a staging/demo box; if you have at least part of the skillset for a production system, manually deploying a couple more components would not be a big deal either.
why there are some jar in ofbiz, all people installing ofbiz have the
knowledge to find and download all what is necessary
It's to decrease the number of step to install, to help people (IT user,
not end user I know)

If putting something to extra is saying, it will be not easy and quick
to install, it's the same thing that saying don't use it
If we want specialpurpose or ofbiz-added function or extra is usable, it
should as simple as ofbiz
> The only real area where a user friendly OFBiz Plugin Manager tool would be required is in a multi tenant system served as saas: the user (of a tenant) could setup plugins that are visible to that tenant only.
Excuse-me, my explanation was not clear. OFBiz plugin can change any
part of OFBiz (xml, java, properties, screen, services, framework, ...).
In Multi-tenant there is only one application instance, so all use same
ofbiz code. Configuration can only be done by parameters.
Plug Manager is useful for building a ofbiz solution for a "specific case" .
> Kind regards,
>
> Jacopo

[Jacopo Cappellato-4]

On Nov 16, 2012, at 3:28 PM, Olivier Heintz wrote:

> It's to decrease the number of step to install, to help people (IT user,
> not end user I know)

Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools.

Regards,

Jacopo

[Jacopo Cappellato-4]

On Nov 16, 2012, at 3:53 PM, Jacopo Cappellato wrote:

> Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools.

oops... errata corrige:

"... but not mandatory to use external tools" ---> "... but not mandatory to use external components"

Jacopo

[Adam Heath-2]

On 11/16/2012 05:40 AM, Jacques Le Roux wrote:

> Very well summed up, Paul
>
> Thanks
>
> Jacques
>
> From: "madppiper" <[hidden email]>
>> @jacopo: That sounds like a terrific idea of yours! I have to read up on
>> [Proposal], but from your outline here, i would say it is a more sincere
>> step.
>>
>> @Olivier: I liked your presenation on addon-manager a lot and as already
>> discussed would think that a tool like this (sort of like a yum- install
>> manager) could be beneficial to whatever we come up with here. But the tool
>> for me is an addition to the proposal above, it is not a contradiction to
>> it.

AIE! NO YUM!  BAD!  YUM SUCKAGE!

I've had the mis-fortune to use yum, and apt-get both.  The former is
really crappy, slow, and not smart at all.

[Jacques Le Roux]

No worries Adam,

Paul gave Yum just as a "sort-of-like" example. I don't know the addons technology, but I'm sure it's not related at all with Yum or even apt-get (more Ant and maybe Ivy)
And of course, we all prefer get-apt (at least I do, actually I don't even know Yum  :D)

Jacques

From: "Adam Heath" <[hidden email]>

> On 11/16/2012 05:40 AM, Jacques Le Roux wrote:
>> Very well summed up, Paul
>>
>> Thanks
>>
>> Jacques
>>
>> From: "madppiper" <[hidden email]>
>>> @jacopo: That sounds like a terrific idea of yours! I have to read up on
>>> [Proposal], but from your outline here, i would say it is a more sincere
>>> step.
>>>
>>> @Olivier: I liked your presenation on addon-manager a lot and as already
>>> discussed would think that a tool like this (sort of like a yum- install
>>> manager) could be beneficial to whatever we come up with here. But the tool
>>> for me is an addition to the proposal above, it is not a contradiction to
>>> it.
>
> AIE! NO YUM!  BAD!  YUM SUCKAGE!
>
> I've had the mis-fortune to use yum, and apt-get both.  The former is
> really crappy, slow, and not smart at all.

[Adam Heath-2]

On 11/20/2012 07:17 PM, Jacques Le Roux wrote:
> No worries Adam,
>
> Paul gave Yum just as a "sort-of-like" example. I don't know the addons technology, but I'm sure it's not related at all with Yum or even apt-get (more Ant and maybe Ivy)
> And of course, we all prefer get-apt (at least I do, actually I don't even know Yum  :D)

I've had the (mis)?fortune to use yast and yum, and they both suck
compared to apt.  I just can't sugar coat it any.

I am a *true* programmer, the ideas I get, and I don't really care
about how they are implemented.  But in this case, the implementation
of yum and yast shows the poor ideas behind them, and that is what has
burrowed underneath my skin.

[Ean Schuessler]

Adam and I have been talking about a feature like this for a while. Its a good question whether something like Maven would serve as a good basis for resolving dependencies or maybe even a pluggable architecture. On Red Hat and Debian systems you could even automatically bring in native dependencies like Memcached, Varnish, NGINX, etc. and provide turn-key configuration of what would otherwise be a very complicated installation. Its also interesting to see how Puppet handles some of these problems.

----- "Jacopo Cappellato" wrote:
> On Nov 16, 2012, at 3:28 PM, Olivier Heintz wrote:
> > It's to decrease the number of step to install, to help people (IT user,
> > not end user I know)
> Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools.
> Regards,
> Jacopo

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com 

[Paul Piper]

No need to get all hyped up over this. At this very stage I think we still have a decision pending on how to progress with apache extras before any of this would be required. Personally, what I saw at the Apachecon I liked and i think that Olivier and his team did a good job at it, so I would propose to wait for this to be presented properly (it is more of a patch- &svn-managing tool than a package-installer).

Of course maven is also an alternative, but that too has its flaws and would require alot of work to restructure everything here... also it is not compatible with SVN if I am not mistaken, so propably not an option (but somebody else should verify that again ;))