You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2012/11/15 08:49:40 UTC
Slim-down effort: current situation
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
Re: Slim-down effort: current situation
Posted by madppiper <pp...@ilscipio.com>.
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?
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637653.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Re: Slim-down effort: current situation
Posted by Paul Piper <pp...@ilscipio.com>.
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 ;))
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637828.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
Posted by Ean Schuessler <ea...@brainfood.com>.
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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Re: Slim-down effort: current situation
Posted by Olivier Heintz <ho...@nereide.biz>.
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
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Re: Slim-down effort: current situation
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <do...@brainfood.com>
> On 11/16/2012 05:40 AM, Jacques Le Roux wrote:
>> Very well summed up, Paul
>>
>> Thanks
>>
>> Jacques
>>
>> From: "madppiper" <pp...@ilscipio.com>
>>> @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.
Re: Slim-down effort: current situation
Posted by Adam Heath <do...@brainfood.com>.
On 11/16/2012 05:40 AM, Jacques Le Roux wrote:
> Very well summed up, Paul
>
> Thanks
>
> Jacques
>
> From: "madppiper" <pp...@ilscipio.com>
>> @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.
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
Very well summed up, Paul
Thanks
Jacques
From: "madppiper" <pp...@ilscipio.com>
> @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.
Re: Slim-down effort: current situation
Posted by madppiper <pp...@ilscipio.com>.
@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.
Re: Slim-down effort: current situation
Posted by Olivier Heintz <ho...@nereide.biz>.
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" <ja...@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
>>>>
>>>
>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
Inline...
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> 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" <ja...@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
>>>>
>>>
>>>
>
>
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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" <ja...@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
>>>
>>
>>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
I tend to agree with you Hans for those components, complements inline
From: "Hans Bakker" <ma...@antwebsystems.com>
> 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" <ja...@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
>>>>
>>>
>
Re: Slim-down effort: current situation
Posted by Hans Bakker <ma...@antwebsystems.com>.
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" <ja...@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
>>>
>>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@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
>>
>
>
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@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
>
Re: Slim-down effort: current situation
Posted by Paul Piper <pp...@ilscipio.com>.
I think this is a very good idea, Jacopo - straight forward and easy to
maintain
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4638733.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Of course in both cases we should cleanup and improve our ant scripts and remove direct references to specific specialpurpose components like:
<fileset dir="${ofbiz.home.dir}/specialpurpose/birt/lib" includes="*.jar"/>
<fileset dir="${ofbiz.home.dir}/specialpurpose/ebaystore/lib" includes="*.jar"/>
<fileset dir="${ofbiz.home.dir}/specialpurpose/googlecheckout/lib" includes="*.jar"/>
<fileset dir="${ofbiz.home.dir}/specialpurpose/ldap/lib" includes="*.jar"/>
<fileset dir="${ofbiz.home.dir}/specialpurpose/pos/lib" includes="*.jar"/>
This is something that should have never been committed like this and so it would be good to fix regardless of our final decision on the separation of specialpurpose components
Regards,
Jacopo
On Jan 16, 2013, at 2:38 PM, Jacopo Cappellato wrote:
> Thanks Nicolas.
> I had a quick look too to find a way to exclude specialpurpose components from the build/test process and the easiest way (I didn't test it) would be to set the property:
> specialpurpose.present to false.
> At the moment it is set with:
> <available file="specialpurpose/build.xml" property="specialpurpose.present"/>
> Another way would be to change the layout of our trunk, from:
>
> trunk/applications
> trunk/framework
> trunk/specialpurpose
>
> to
>
> trunk/ofbiz/applications
> trunk/ofbiz/framework
> trunk/specialpurpose
>
> In this way in order to checkout OFbiz only (no specialpurpose) you could do:
>
> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz
>
> And in order to download everything you would do:
>
> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
> cd ofbiz-trunk
> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose
>
> I like the latter more.
>
> Kind regards,
>
> Jacopo
>
>
> On Jan 16, 2013, at 2:23 PM, Malin Nicolas wrote:
>
>> Hi Jacopo,
>> Your solution is a good pragmatism and give a clear work to do for contributors
>>
>> If other people are ok with your proposition, I will try to find a solution to activate a component with ant.
>>
>> PS : My apologies for the latency
>>
>> Nicolas
>>
>>
>>
>> Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
>>> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>>>
>>> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
>>> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
>>> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
>>> * the official releases (and release branches) will not contain the specialpurpose folder
>>> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
>>> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>>>
>>> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
>>> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
>>> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>>>
>>> Some clarifications:
>>> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
>>> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>>>
>>> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>>>
>>>> Yes thanks!
>>>>
>>>> Jacques
>>>>
>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>>>
>>>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>>> Do you mean the following?
>>>>>
>>>>> ========================
>>>>> 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; 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)
>>>>> ========================
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>
>
Re: Slim-down effort: current situation
Posted by Malin Nicolas <ma...@librenberry.net>.
:) right, so change 13.04 by 14.04 on my last comments ;)
On my side, I will test OFBiz without specialpurpose to find bad depends.
Nicolas
Le 16/01/2013 16:21, Jacopo Cappellato a écrit :
> Yes, it makes a lot of sense to treat the specialpurpose components as hot-deploy components.
> However I'd suggest to move at small steps in this direction because right now there are specialpurpose components that depends on each other and this would make the story more complicated if you want to use just one.
> For this reason I would suggest to first implement the ability to run OFBiz or OFbiz with all specialpurpose components and then improve it to run specific specialpurpose components only.
>
> Jacopo
>
> On Jan 16, 2013, at 3:50 PM, Malin Nicolas wrote:
>
>> It's sound good, I just see a little problem if we want only one specialpurpose component, we need to do
>>
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
>> $ cd ofbiz-trunk
>> $ mkdir specialpurpose
>> $ cd specialpurpose
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/build.xml
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt (as example)
>> $ #create your component-load.xml
>>
>> Why not use hot-deploy (and/or improve hot-deploy) for specialpurpose components to obtain a result like this :
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
>> $ cd ofbiz-trunk
>> $ cd hot-deploy
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
>>
>> and an other solution for branch :
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.04 ofbiz-13.04
>> $ cd ofbiz-13.04
>> $ ant load-special-component birt
>>
>> Nicolas
>>
>> Le 16/01/2013 14:38, Jacopo Cappellato a écrit :
>>> Thanks Nicolas.
>>> I had a quick look too to find a way to exclude specialpurpose components from the build/test process and the easiest way (I didn't test it) would be to set the property:
>>> specialpurpose.present to false.
>>> At the moment it is set with:
>>> <available file="specialpurpose/build.xml" property="specialpurpose.present"/>
>>> Another way would be to change the layout of our trunk, from:
>>>
>>> trunk/applications
>>> trunk/framework
>>> trunk/specialpurpose
>>>
>>> to
>>>
>>> trunk/ofbiz/applications
>>> trunk/ofbiz/framework
>>> trunk/specialpurpose
>>>
>>> In this way in order to checkout OFbiz only (no specialpurpose) you could do:
>>>
>>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz
>>>
>>> And in order to download everything you would do:
>>>
>>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
>>> cd ofbiz-trunk
>>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose
>>>
>>> I like the latter more.
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>>
>>> On Jan 16, 2013, at 2:23 PM, Malin Nicolas wrote:
>>>
>>>> Hi Jacopo,
>>>> Your solution is a good pragmatism and give a clear work to do for contributors
>>>>
>>>> If other people are ok with your proposition, I will try to find a solution to activate a component with ant.
>>>>
>>>> PS : My apologies for the latency
>>>>
>>>> Nicolas
>>>>
>>>>
>>>>
>>>> Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
>>>>> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>>>>>
>>>>> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
>>>>> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
>>>>> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
>>>>> * the official releases (and release branches) will not contain the specialpurpose folder
>>>>> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
>>>>> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>>>>>
>>>>> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
>>>>> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
>>>>> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>>>>>
>>>>> Some clarifications:
>>>>> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
>>>>> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>>>>>
>>>>> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>>>>>
>>>>>> Yes thanks!
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>>>>> Do you mean the following?
>>>>>>>
>>>>>>> ========================
>>>>>>> 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; 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)
>>>>>>> ========================
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Yes, it makes a lot of sense to treat the specialpurpose components as hot-deploy components.
However I'd suggest to move at small steps in this direction because right now there are specialpurpose components that depends on each other and this would make the story more complicated if you want to use just one.
For this reason I would suggest to first implement the ability to run OFBiz or OFbiz with all specialpurpose components and then improve it to run specific specialpurpose components only.
Jacopo
On Jan 16, 2013, at 3:50 PM, Malin Nicolas wrote:
> It's sound good, I just see a little problem if we want only one specialpurpose component, we need to do
>
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
> $ cd ofbiz-trunk
> $ mkdir specialpurpose
> $ cd specialpurpose
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/build.xml
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt (as example)
> $ #create your component-load.xml
>
> Why not use hot-deploy (and/or improve hot-deploy) for specialpurpose components to obtain a result like this :
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
> $ cd ofbiz-trunk
> $ cd hot-deploy
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
>
> and an other solution for branch :
> $ svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.04 ofbiz-13.04
> $ cd ofbiz-13.04
> $ ant load-special-component birt
>
> Nicolas
>
> Le 16/01/2013 14:38, Jacopo Cappellato a écrit :
>> Thanks Nicolas.
>> I had a quick look too to find a way to exclude specialpurpose components from the build/test process and the easiest way (I didn't test it) would be to set the property:
>> specialpurpose.present to false.
>> At the moment it is set with:
>> <available file="specialpurpose/build.xml" property="specialpurpose.present"/>
>> Another way would be to change the layout of our trunk, from:
>>
>> trunk/applications
>> trunk/framework
>> trunk/specialpurpose
>>
>> to
>>
>> trunk/ofbiz/applications
>> trunk/ofbiz/framework
>> trunk/specialpurpose
>>
>> In this way in order to checkout OFbiz only (no specialpurpose) you could do:
>>
>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz
>>
>> And in order to download everything you would do:
>>
>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
>> cd ofbiz-trunk
>> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose
>>
>> I like the latter more.
>>
>> Kind regards,
>>
>> Jacopo
>>
>>
>> On Jan 16, 2013, at 2:23 PM, Malin Nicolas wrote:
>>
>>> Hi Jacopo,
>>> Your solution is a good pragmatism and give a clear work to do for contributors
>>>
>>> If other people are ok with your proposition, I will try to find a solution to activate a component with ant.
>>>
>>> PS : My apologies for the latency
>>>
>>> Nicolas
>>>
>>>
>>>
>>> Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
>>>> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>>>>
>>>> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
>>>> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
>>>> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
>>>> * the official releases (and release branches) will not contain the specialpurpose folder
>>>> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
>>>> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>>>>
>>>> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
>>>> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
>>>> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>>>>
>>>> Some clarifications:
>>>> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
>>>> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>>>>
>>>> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>>> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>>>>
>>>>> Yes thanks!
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>>>> Do you mean the following?
>>>>>>
>>>>>> ========================
>>>>>> 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; 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)
>>>>>> ========================
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>
Re: Slim-down effort: current situation
Posted by Malin Nicolas <ma...@librenberry.net>.
It's sound good, I just see a little problem if we want only one
specialpurpose component, we need to do
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
$ cd ofbiz-trunk
$ mkdir specialpurpose
$ cd specialpurpose
$ svn co
http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/build.xml
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
(as example)
$ #create your component-load.xml
Why not use hot-deploy (and/or improve hot-deploy) for specialpurpose
components to obtain a result like this :
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
$ cd ofbiz-trunk
$ cd hot-deploy
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
and an other solution for branch :
$ svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.04
ofbiz-13.04
$ cd ofbiz-13.04
$ ant load-special-component birt
Nicolas
Le 16/01/2013 14:38, Jacopo Cappellato a écrit :
> Thanks Nicolas.
> I had a quick look too to find a way to exclude specialpurpose components from the build/test process and the easiest way (I didn't test it) would be to set the property:
> specialpurpose.present to false.
> At the moment it is set with:
> <available file="specialpurpose/build.xml" property="specialpurpose.present"/>
> Another way would be to change the layout of our trunk, from:
>
> trunk/applications
> trunk/framework
> trunk/specialpurpose
>
> to
>
> trunk/ofbiz/applications
> trunk/ofbiz/framework
> trunk/specialpurpose
>
> In this way in order to checkout OFbiz only (no specialpurpose) you could do:
>
> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz
>
> And in order to download everything you would do:
>
> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
> cd ofbiz-trunk
> svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose
>
> I like the latter more.
>
> Kind regards,
>
> Jacopo
>
>
> On Jan 16, 2013, at 2:23 PM, Malin Nicolas wrote:
>
>> Hi Jacopo,
>> Your solution is a good pragmatism and give a clear work to do for contributors
>>
>> If other people are ok with your proposition, I will try to find a solution to activate a component with ant.
>>
>> PS : My apologies for the latency
>>
>> Nicolas
>>
>>
>>
>> Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
>>> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>>>
>>> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
>>> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
>>> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
>>> * the official releases (and release branches) will not contain the specialpurpose folder
>>> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
>>> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>>>
>>> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
>>> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
>>> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>>>
>>> Some clarifications:
>>> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
>>> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>>>
>>> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>>>
>>>> Yes thanks!
>>>>
>>>> Jacques
>>>>
>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>>>
>>>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>>> Do you mean the following?
>>>>>
>>>>> ========================
>>>>> 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; 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)
>>>>> ========================
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Thanks Nicolas.
I had a quick look too to find a way to exclude specialpurpose components from the build/test process and the easiest way (I didn't test it) would be to set the property:
specialpurpose.present to false.
At the moment it is set with:
<available file="specialpurpose/build.xml" property="specialpurpose.present"/>
Another way would be to change the layout of our trunk, from:
trunk/applications
trunk/framework
trunk/specialpurpose
to
trunk/ofbiz/applications
trunk/ofbiz/framework
trunk/specialpurpose
In this way in order to checkout OFbiz only (no specialpurpose) you could do:
svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz
And in order to download everything you would do:
svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
cd ofbiz-trunk
svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose
I like the latter more.
Kind regards,
Jacopo
On Jan 16, 2013, at 2:23 PM, Malin Nicolas wrote:
> Hi Jacopo,
> Your solution is a good pragmatism and give a clear work to do for contributors
>
> If other people are ok with your proposition, I will try to find a solution to activate a component with ant.
>
> PS : My apologies for the latency
>
> Nicolas
>
>
>
> Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
>> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>>
>> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
>> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
>> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
>> * the official releases (and release branches) will not contain the specialpurpose folder
>> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
>> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>>
>> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
>> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
>> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>>
>> Some clarifications:
>> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
>> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>>
>> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>>
>> What do you think?
>>
>> Jacopo
>>
>> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>>
>>> Yes thanks!
>>>
>>> Jacques
>>>
>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>>
>>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>> Do you mean the following?
>>>>
>>>> ========================
>>>> 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; 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)
>>>> ========================
>>>>
>>>> Jacopo
>>>>
>>>>
>
Re: Slim-down effort: current situation
Posted by Malin Nicolas <ma...@librenberry.net>.
Hi Jacopo,
Your solution is a good pragmatism and give a clear work to do for
contributors
If other people are ok with your proposition, I will try to find a
solution to activate a component with ant.
PS : My apologies for the latency
Nicolas
Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>
> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
> * the official releases (and release branches) will not contain the specialpurpose folder
> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>
> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>
> Some clarifications:
> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>
> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>
> What do you think?
>
> Jacopo
>
> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>> Do you mean the following?
>>>
>>> ========================
>>> 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; 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)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>
> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
> * the official releases (and release branches) will not contain the specialpurpose folder
> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>
> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
About the side note: indeed! It will be easier to do with your proposed new way.
> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>
> Some clarifications:
> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>
> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>
> What do you think?
+1, definitively the way to go, with maybe some refinements
Jacques
>
> Jacopo
>
> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>
>>> Do you mean the following?
>>>
>>> ========================
>>> 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; 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)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
>
>
Re: Slim-down effort: current situation
Posted by Olivier Heintz <ho...@nereide.biz>.
Very clear and efficient
Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>
> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
+1
> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
+1
> * the official releases (and release branches) will not contain the specialpurpose folder
+1
> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
+1
> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
+1
maybe it will be necessary in future to decide how to process when a
component in specialpurpose has junit and selenium test for all functions
>
> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
+1
> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
+1
>
> Some clarifications:
> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
+1
>
> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>
> What do you think?
Completely agree
even if I would have liked a little note on the notion addon (smaller
than a component) :-)
>
> Jacopo
>
> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>> Do you mean the following?
>>>
>>> ========================
>>> 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; 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)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
>
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
* svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
* however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
* we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
* the official releases (and release branches) will not contain the specialpurpose folder
* we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
* key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
Some clarifications:
* we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
* we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
What do you think?
Jacopo
On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
> Yes thanks!
>
> Jacques
>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>
>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>
>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>
>> Do you mean the following?
>>
>> ========================
>> 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; 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)
>> ========================
>>
>> Jacopo
>>
>>
Re: Slim-down effort: current situation
Posted by Anil Patel <an...@hotwaxmedia.com>.
One of the solutions is to create brach on github, https://github.com/apache/ofbiz. A feature can be developed on Github and then a final patch can be submitted to Ofbiz Jira.
Regards
Anil Patel
On Jan 4, 2013, at 9:17 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
> http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html
>
> Opinions?
>
> Jacques
>
> From: "Jacques Le Roux" <ja...@les7arts.com>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>
>>> Do you mean the following?
>>>
>>> ========================
>>> 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; 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)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
>>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
A bit out of subject, I found this article interesting http://kohsuke.org/2013/01/04/the-other-side-of-forking-and-pull-requests
And he made me wonder how the OpenErp project is handling its addons (some years ago someone told me this was a weak part of the project, I never dug)
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: <de...@me.com>
>> On Jan 5, 2013, at 1:47 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>> From: "Ean Schuessler" <ea...@brainfood.com>
>>>> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>>>> I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
>>>
>>> Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>>>
>>>> The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
>>>
>>> Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
>>> If the work is of low quality in GitHub it will be ignored as well.
>>>
>>> If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
>>>
>>> I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git
>>
>> Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch.
>
> I'd have to check that, but I believe once well (and very politely ;o) explained it should be possible to convince them
>
>> With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach.
>
> Of course, as you said it's already there, so we have nothing to do, nothing happens.
>
> Jacques
>
>> -David
>>
>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: <de...@me.com>
> On Jan 5, 2013, at 1:47 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> From: "Ean Schuessler" <ea...@brainfood.com>
>>> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>>> I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
>>
>> Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>>
>>> The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
>>
>> Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
>> If the work is of low quality in GitHub it will be ignored as well.
>>
>> If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
>>
>> I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git
>
> Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch.
I'd have to check that, but I believe once well (and very politely ;o) explained it should be possible to convince them
> With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach.
Of course, as you said it's already there, so we have nothing to do, nothing happens.
Jacques
> -David
>
Re: Slim-down effort: current situation
Posted by de...@me.com.
On Jan 5, 2013, at 1:47 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
> From: "Ean Schuessler" <ea...@brainfood.com>
>> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>> I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
>
> Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>
>> The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
>
> Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
> If the work is of low quality in GitHub it will be ignored as well.
>
> If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
>
> I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git
Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch.
With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach.
-David
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Ean Schuessler" <ea...@brainfood.com>
> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
If the work is of low quality in GitHub it will be ignored as well.
If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git
Jacques
> ----- "Jacques Le Roux" wrote:
>> Because it's possibly easier for committers to follow the work done and not get a big patch at the end.
>> With Git you tend to receive either a burst of patches or a big one, both in one shoot.
>> Then it's hard to review the work done. By steps it's easier
>> I don't use GitHub, I have enough to do with OFBiz patches already...
>
> --
> Ean Schuessler, CTO
> ean@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>
Re: Slim-down effort: current situation
Posted by Ean Schuessler <ea...@brainfood.com>.
I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
----- "Jacques Le Roux" wrote:
> Because it's possibly easier for committers to follow the work done and not get a big patch at the end.
> With Git you tend to receive either a burst of patches or a big one, both in one shoot.
> Then it's hard to review the work done. By steps it's easier
> I don't use GitHub, I have enough to do with OFBiz patches already...
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
Because it's possibly easier for committers to follow the work done and not get a big patch at the end.
With Git you tend to receive either a burst of patches or a big one, both in one shoot.
Then it's hard to review the work done. By steps it's easier
I don't use GitHub, I have enough to do with OFBiz patches already...
Jacques
From: "Ean Schuessler" <ea...@brainfood.com>
> Why wouldn't they just fork and then issue a pull request on GitHub?
>
> ----- "Jacques Le Roux" wrote:
>> I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
>> http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html
>
> --
> Ean Schuessler, CTO
> ean@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>
Re: Slim-down effort: current situation
Posted by Ean Schuessler <ea...@brainfood.com>.
Why wouldn't they just fork and then issue a pull request on GitHub?
----- "Jacques Le Roux" wrote:
> I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
> http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html
Opinions?
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> Yes thanks!
>
> Jacques
>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>
>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>
>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>
>> Do you mean the following?
>>
>> ========================
>> 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; 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)
>> ========================
>>
>> Jacopo
>>
>>
>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes thanks!
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>
> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>
>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>
> Do you mean the following?
>
> ========================
> 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; 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)
> ========================
>
> Jacopo
>
>
Re: Slim-down effort: current situation
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
Do you mean the following?
========================
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; 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)
========================
Jacopo
Re: Slim-down effort: current situation
Posted by Nicolas Malin <ma...@librenberry.net>.
Thanks jacques, create a wiki page sound good to me :)
Nicolas
Le 16/12/2012 14:28, Jacques Le Roux a écrit :
> From: "Jacques Le Roux" <ja...@les7arts.com>
>> From: "Nicolas Malin" <ma...@librenberry.net>
>>> Le 15/11/2012 08:49, Jacques Le Roux a écrit :
>>>> 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
>>>>
>>> Hi all,
>>>
>>> To continue on slim-down effort, I propose to work on a POC.
>>> We define the expected to manage component on extra.
>>> We select a component or subject to move from OFBiz to extra and a
>>> delivery date.
>> I think we should also refer to "[PROPOSAL] from specialpurpose to extras" thread here.
>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>> Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future.
>> I personnaly begin to lose the focus, a sole place to look at would be easier.
>> There are a lot of good ideas, we need to pick the better (by consensus of course ;o)
> I created https://cwiki.apache.org/confluence/display/OFBIZ/Slimdown+Effort+Roadmap (just a mock for now, feel free to do what you want...)
>
> Jacques
>
>>> Each contributor wishing to work on it, would propose a solution to move
>>> and use a component on extra, open an issue containing the process,
>>> management and the example with selected component.
>>>
>>> After the delivery date, we check avantage/disavantage of each
>>> proposition and vote to choose the favorite solution.
>>> Write a best pratice to move/create a component on extra usable by OFBiz.
>>>
>>> Then we can start with this process
>>> * proposal/vote
>>> * open jira issue
>>> * write information on extras.html
>>> * run move
>> It sounds like this could be in the page I proposed to create.
>> Before going further I believe we need to clarify in all minds, get consensus and then work on them
>>
>> My 2cts
>>
>> Jacques
>>
>>> The aim isn't to define what to do but how to contribute when the goal
>>> will be fixed.
>>>
>>> Your opinions ?
>>>
>>> Nicolas
>>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : 06.17.66.40.06
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : 02.48.02.56.12
>>> Site : http://www.librenberry.net/
>>>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Nicolas Malin" <ma...@librenberry.net>
>> Le 15/11/2012 08:49, Jacques Le Roux a écrit :
>>> 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
>>>
>> Hi all,
>>
>> To continue on slim-down effort, I propose to work on a POC.
>> We define the expected to manage component on extra.
>> We select a component or subject to move from OFBiz to extra and a
>> delivery date.
>
> I think we should also refer to "[PROPOSAL] from specialpurpose to extras" thread here.
> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
> Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future.
> I personnaly begin to lose the focus, a sole place to look at would be easier.
> There are a lot of good ideas, we need to pick the better (by consensus of course ;o)
I created https://cwiki.apache.org/confluence/display/OFBIZ/Slimdown+Effort+Roadmap (just a mock for now, feel free to do what you want...)
Jacques
>> Each contributor wishing to work on it, would propose a solution to move
>> and use a component on extra, open an issue containing the process,
>> management and the example with selected component.
>>
>> After the delivery date, we check avantage/disavantage of each
>> proposition and vote to choose the favorite solution.
>> Write a best pratice to move/create a component on extra usable by OFBiz.
>>
>> Then we can start with this process
>> * proposal/vote
>> * open jira issue
>> * write information on extras.html
>> * run move
>
> It sounds like this could be in the page I proposed to create.
> Before going further I believe we need to clarify in all minds, get consensus and then work on them
>
> My 2cts
>
> Jacques
>
>> The aim isn't to define what to do but how to contribute when the goal
>> will be fixed.
>>
>> Your opinions ?
>>
>> Nicolas
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : 06.17.66.40.06
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : 02.48.02.56.12
>> Site : http://www.librenberry.net/
>>
>
Re: Slim-down effort: current situation
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Nicolas Malin" <ma...@librenberry.net>
> Le 15/11/2012 08:49, Jacques Le Roux a écrit :
>> 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
>>
> Hi all,
>
> To continue on slim-down effort, I propose to work on a POC.
> We define the expected to manage component on extra.
> We select a component or subject to move from OFBiz to extra and a
> delivery date.
I think we should also refer to "[PROPOSAL] from specialpurpose to extras" thread here.
I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future.
I personnaly begin to lose the focus, a sole place to look at would be easier.
There are a lot of good ideas, we need to pick the better (by consensus of course ;o)
> Each contributor wishing to work on it, would propose a solution to move
> and use a component on extra, open an issue containing the process,
> management and the example with selected component.
>
> After the delivery date, we check avantage/disavantage of each
> proposition and vote to choose the favorite solution.
> Write a best pratice to move/create a component on extra usable by OFBiz.
>
> Then we can start with this process
> * proposal/vote
> * open jira issue
> * write information on extras.html
> * run move
It sounds like this could be in the page I proposed to create.
Before going further I believe we need to clarify in all minds, get consensus and then work on them
My 2cts
Jacques
> The aim isn't to define what to do but how to contribute when the goal
> will be fixed.
>
> Your opinions ?
>
> Nicolas
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
Re: Slim-down effort: current situation
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 15/11/2012 08:49, Jacques Le Roux a écrit :
> 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
>
Hi all,
To continue on slim-down effort, I propose to work on a POC.
We define the expected to manage component on extra.
We select a component or subject to move from OFBiz to extra and a
delivery date.
Each contributor wishing to work on it, would propose a solution to move
and use a component on extra, open an issue containing the process,
management and the example with selected component.
After the delivery date, we check avantage/disavantage of each
proposition and vote to choose the favorite solution.
Write a best pratice to move/create a component on extra usable by OFBiz.
Then we can start with this process
* proposal/vote
* open jira issue
* write information on extras.html
* run move
The aim isn't to define what to do but how to contribute when the goal
will be fixed.
Your opinions ?
Nicolas
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/