Re: Slim-down effort: current situation
Please see inline: On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote: Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I don't think we should move all specialpurpose components out of the project, and for sure not all of them in one shot: we could discuss on a per component basis. I heard here and there that not all the community is expecting good from this move. Of course it will be impossible to make everyone happy but the feedback I am reading in this thread makes me happy (no dramatic tones, like happened in the past, willing to evaluate pros and cons etc..). BTW, some time ago I also proposed an alternative path: see email with subject [PROPOSAL] from specialpurpose to extras: to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals: 1) slim down the main code that the community is more focused to improve/maintain/release 2) keep under the OFBiz community the ownership of all the other specialpurpose components (this should address Paul's concerns); if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications) Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce component. The problem I have with these components (and to be clear I am not referring to this specific contribution) is that they are one particular implementation (and very often not the best) of a requirement (e.g. Solr integration, reporting tool, help system etc...) and there could be 100 others different ways to implement the same: for example, even if everyone agrees that the online help is useful, there are many doubts that the specific implementation of it we are discussing is the right way to go; or even if everyone agrees that a better reporting tool would be nice to have, there are many that think that the current Birt component is not the right way to go. Kind regards, Jacopo So far we agreed that the eCommerce component will be the only one (apart if we agree on it the new webhelp component) to stay in specialpurpose, right? Thanks to one last time share your opinions, before the next move occurs... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Slim-down effort: current situation
Inline... From: Jacopo Cappellato jacopo.cappell...@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 jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Is it a good time to remove the debian folder?
Hi Adam, glad to see you back. First of all an off topic (I apologize for it but I ): the guy at Freemarker.org is still waiting for your CLA that is necessary to include your patch into the next Freemarker release (we are currently using a Freemarker jar modified by you and we should fix it asap); please get in touch with him and/or resend the CLA when you can. Thank you. As regards the debian folder, I am sure it was working but it is also true that it is a very specific component and that no one in this community (apart you) showed interest or even attempted to maintain it (I am sure no one apart from you would be able to): these are all good reasons for moving it out to the official trunk and releases; however I see it a good tool that you could provide distribute outside of the official project. You can think of the best way to do this (it seems you already have some) but I also want to mention (since you are very busy) that there is no rush as the component was stale for a long time and we could bring it back into the future if/when the community will show an interest on it. Kind regards, Jacopo On Nov 15, 2012, at 6:49 PM, Adam Heath wrote: On 11/15/2012 10:54 AM, Jacopo Cappellato wrote: This is now completed at rev. 1409880 https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Jacopo On Jul 26, 2012, at 8:09 AM, Jacopo Cappellato wrote: ... the removal will be documented, as usual, in the Attic page: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Hmm, sad. I understand the reasoning, and I've been super busy at work, and missed both the original email and this final one. Ean had to poke me about it. The debian folder *does* function, and will produce proper debian-policy-compliant debs. The only reason you don't see it uploaded to debian.org(I am also a debian developer, or used to be), is that ofbiz embeds outside libraries in side it, and that is not allowed for an upload to debian main. I'd like to keep this around, but I also understand the desire to keep ofbiz upstream clean. Here are my thoughts, based on a discussion Ean and I *just* had here at work. 1: Create a fork of ofbiz on github. Git is much better for distributed development. 2: Re-add this debian folder from the attic. 3: Import any changes I might have locally. This should be small, as I was mostly upstream(I need to check a few older branches). 3: Announce this branch as the location for debian development. *Only* changes to make debian integration should be placed here. 4: Start filing issue trees in jira for pure upstream work. This would include things like removing embedded libraries(maybe a post-download kinda thing).
Re: Slim-down effort: current situation
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
Re: Is it a good time to remove the debian folder?
Hi Adam, If you think that for visibility, it's good to create a ofbiz-debian project on ofbiz-extra, I can do it until you have time to manage it. Olivier Le 16/11/2012 10:41, Jacopo Cappellato a écrit : Hi Adam, glad to see you back. First of all an off topic (I apologize for it but I ): the guy at Freemarker.org is still waiting for your CLA that is necessary to include your patch into the next Freemarker release (we are currently using a Freemarker jar modified by you and we should fix it asap); please get in touch with him and/or resend the CLA when you can. Thank you. As regards the debian folder, I am sure it was working but it is also true that it is a very specific component and that no one in this community (apart you) showed interest or even attempted to maintain it (I am sure no one apart from you would be able to): these are all good reasons for moving it out to the official trunk and releases; however I see it a good tool that you could provide distribute outside of the official project. You can think of the best way to do this (it seems you already have some) but I also want to mention (since you are very busy) that there is no rush as the component was stale for a long time and we could bring it back into the future if/when the community will show an interest on it. Kind regards, Jacopo On Nov 15, 2012, at 6:49 PM, Adam Heath wrote: On 11/15/2012 10:54 AM, Jacopo Cappellato wrote: This is now completed at rev. 1409880 https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Jacopo On Jul 26, 2012, at 8:09 AM, Jacopo Cappellato wrote: ... the removal will be documented, as usual, in the Attic page: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Hmm, sad. I understand the reasoning, and I've been super busy at work, and missed both the original email and this final one. Ean had to poke me about it. The debian folder *does* function, and will produce proper debian-policy-compliant debs. The only reason you don't see it uploaded to debian.org(I am also a debian developer, or used to be), is that ofbiz embeds outside libraries in side it, and that is not allowed for an upload to debian main. I'd like to keep this around, but I also understand the desire to keep ofbiz upstream clean. Here are my thoughts, based on a discussion Ean and I *just* had here at work. 1: Create a fork of ofbiz on github. Git is much better for distributed development. 2: Re-add this debian folder from the attic. 3: Import any changes I might have locally. This should be small, as I was mostly upstream(I need to check a few older branches). 3: Announce this branch as the location for debian development. *Only* changes to make debian integration should be placed here. 4: Start filing issue trees in jira for pure upstream work. This would include things like removing embedded libraries(maybe a post-download kinda thing).
Re: Is it a good time to remove the debian folder?
I thought it was ok from ddekany's last comment http://sourceforge.net/tracker/?func=detailatid=100794aid=3527625group_id=794 ? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi Adam, glad to see you back. First of all an off topic (I apologize for it but I ): the guy at Freemarker.org is still waiting for your CLA that is necessary to include your patch into the next Freemarker release (we are currently using a Freemarker jar modified by you and we should fix it asap); please get in touch with him and/or resend the CLA when you can. Thank you. As regards the debian folder, I am sure it was working but it is also true that it is a very specific component and that no one in this community (apart you) showed interest or even attempted to maintain it (I am sure no one apart from you would be able to): these are all good reasons for moving it out to the official trunk and releases; however I see it a good tool that you could provide distribute outside of the official project. You can think of the best way to do this (it seems you already have some) but I also want to mention (since you are very busy) that there is no rush as the component was stale for a long time and we could bring it back into the future if/when the community will show an interest on it. Kind regards, Jacopo On Nov 15, 2012, at 6:49 PM, Adam Heath wrote: On 11/15/2012 10:54 AM, Jacopo Cappellato wrote: This is now completed at rev. 1409880 https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Jacopo On Jul 26, 2012, at 8:09 AM, Jacopo Cappellato wrote: ... the removal will be documented, as usual, in the Attic page: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Hmm, sad. I understand the reasoning, and I've been super busy at work, and missed both the original email and this final one. Ean had to poke me about it. The debian folder *does* function, and will produce proper debian-policy-compliant debs. The only reason you don't see it uploaded to debian.org(I am also a debian developer, or used to be), is that ofbiz embeds outside libraries in side it, and that is not allowed for an upload to debian main. I'd like to keep this around, but I also understand the desire to keep ofbiz upstream clean. Here are my thoughts, based on a discussion Ean and I *just* had here at work. 1: Create a fork of ofbiz on github. Git is much better for distributed development. 2: Re-add this debian folder from the attic. 3: Import any changes I might have locally. This should be small, as I was mostly upstream(I need to check a few older branches). 3: Announce this branch as the location for debian development. *Only* changes to make debian integration should be placed here. 4: Start filing issue trees in jira for pure upstream work. This would include things like removing embedded libraries(maybe a post-download kinda thing).
Re: Is it a good time to remove the debian folder?
I don't think that the comment is about the license clearance: yesterday I had an email exchange with Daniel Dekany (ddekany) and he is still waiting for the CLA. Jacopo On Nov 16, 2012, at 11:08 AM, Jacques Le Roux wrote: I thought it was ok from ddekany's last comment http://sourceforge.net/tracker/?func=detailatid=100794aid=3527625group_id=794 ? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi Adam, glad to see you back. First of all an off topic (I apologize for it but I ): the guy at Freemarker.org is still waiting for your CLA that is necessary to include your patch into the next Freemarker release (we are currently using a Freemarker jar modified by you and we should fix it asap); please get in touch with him and/or resend the CLA when you can. Thank you. As regards the debian folder, I am sure it was working but it is also true that it is a very specific component and that no one in this community (apart you) showed interest or even attempted to maintain it (I am sure no one apart from you would be able to): these are all good reasons for moving it out to the official trunk and releases; however I see it a good tool that you could provide distribute outside of the official project. You can think of the best way to do this (it seems you already have some) but I also want to mention (since you are very busy) that there is no rush as the component was stale for a long time and we could bring it back into the future if/when the community will show an interest on it. Kind regards, Jacopo On Nov 15, 2012, at 6:49 PM, Adam Heath wrote: On 11/15/2012 10:54 AM, Jacopo Cappellato wrote: This is now completed at rev. 1409880 https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Jacopo On Jul 26, 2012, at 8:09 AM, Jacopo Cappellato wrote: ... the removal will be documented, as usual, in the Attic page: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Hmm, sad. I understand the reasoning, and I've been super busy at work, and missed both the original email and this final one. Ean had to poke me about it. The debian folder *does* function, and will produce proper debian-policy-compliant debs. The only reason you don't see it uploaded to debian.org(I am also a debian developer, or used to be), is that ofbiz embeds outside libraries in side it, and that is not allowed for an upload to debian main. I'd like to keep this around, but I also understand the desire to keep ofbiz upstream clean. Here are my thoughts, based on a discussion Ean and I *just* had here at work. 1: Create a fork of ofbiz on github. Git is much better for distributed development. 2: Re-add this debian folder from the attic. 3: Import any changes I might have locally. This should be small, as I was mostly upstream(I need to check a few older branches). 3: Announce this branch as the location for debian development. *Only* changes to make debian integration should be placed here. 4: Start filing issue trees in jira for pure upstream work. This would include things like removing embedded libraries(maybe a post-download kinda thing).
Re: [VOTE] [RELEASE] Apache OFBiz 11.04.01
+1 Jacopo On Nov 13, 2012, at 11:25 AM, Jacopo Cappellato wrote: This is the vote thread to approve the first release for the 11.04 branch. This new release, Apache OFBiz 11.04.01 (major release number: 11.04; minor release number: 01) is the first release of the 11.04 series and contains all the features of the trunk up to April 2011 and since then has been stabilized with bug fixes. It will become the OFBiz current stable release and users of the 10.04 series will be encouraged to migrate to it. The candidate release files can be downloaded from here: https://dist.apache.org/repos/dist/dev/ofbiz/ (committers only) or from here: http://people.apache.org/~jacopoc/dist/ (everyone else) and are: * apache-ofbiz-11.04.01.zip: the release package, based on the 11.04 branch at revision 1408646 (latest as of now) * KEYS: text file with keys * apache-ofbiz-11.04.01.zip.asc: the detached signature file * apache-ofbiz-11.04.01.zip.md5, apache-ofbiz-11.04.01.zip.sha: hashes Please download and test the zip file and its signatures (for instructions on testing the signatures seehttp://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 11.04.01 [ -1] do not release This vote will be closed in 72 hours. For more details about this process please read http://www.apache.org/foundation/voting.html The following text is quoted from the above url: Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. Kind Regards, Jacopo
Re: Slim-down effort: current situation
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
[VOTE] [RESULT] Apache OFBiz 11.04.01
The vote is now closed. Thanks to the voters, this vote has passed with the following results: [+1] 7 [-1] 0 The minimum (3) number of +1 votes from PMC members has been reached: 6 votes from Erwan, Jacques, Ashish, Scott, Anil, Jacopo I will proceed with the remaining steps required to release the package. Jacopo
Re: Slim-down effort: current situation
@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: [VOTE] [RESULT] Apache OFBiz 11.04.01
Am 16.11.2012 11:38, schrieb Jacopo Cappellato: The vote is now closed. Thanks to the voters, this vote has passed with the following results: Damn, I'm too late ;-) But anyway, looks good except for run-tests which fails on my local machine (but is successfull on Buildbot) - no time to have a closer look.. so +0 from me Christian
Re: [VOTE] [RESULT] Apache OFBiz 11.04.01
ouch..interesting tests are successful on mine; I would love to get the feedback from others before we announce the release. Thanks Christian. Jacopo On Nov 16, 2012, at 12:02 PM, Christian Geisert wrote: Am 16.11.2012 11:38, schrieb Jacopo Cappellato: The vote is now closed. Thanks to the voters, this vote has passed with the following results: Damn, I'm too late ;-) But anyway, looks good except for run-tests which fails on my local machine (but is successfull on Buildbot) - no time to have a closer look.. so +0 from me Christian
Re: Slim-down effort: current situation
Very well summed up, Paul Thanks Jacques From: madppiper p...@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
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: [VOTE] [RESULT] Apache OFBiz 11.04.01
Hello, Am 16.11.2012 12:25, schrieb Jacopo Cappellato: ouch..interesting tests are successful on mine; I would love to get the feedback from others before we announce the release. Does OFBiz 11.04.01 include already tomcat 7? regards, Mark -- m...@it-infrastrukturen.org http://rsync.it-infrastrukturen.org
Re: [VOTE] [RESULT] Apache OFBiz 11.04.01
No, it is bundled with Tomcat 6.0.36 Kind regards, Jacopo On Nov 16, 2012, at 3:37 PM, Mark Schneider wrote: Hello, Am 16.11.2012 12:25, schrieb Jacopo Cappellato: ouch..interesting tests are successful on mine; I would love to get the feedback from others before we announce the release. Does OFBiz 11.04.01 include already tomcat 7? regards, Mark -- m...@it-infrastrukturen.org http://rsync.it-infrastrukturen.org
Re: Slim-down effort: current situation
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
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: [VOTE] [RESULT] Apache OFBiz 11.04.01
Thank you Jacopo. Am 16.11.2012 15:49, schrieb Jacopo Cappellato: No, it is bundled with Tomcat 6.0.36 I see that tomcat 7 is first bundled with ofbiz.12.04. Where can I find description of differences between OFBiz *10.04.04*, *11.04* and *12.04*? regards, Mark -- m...@it-infrastrukturen.org http://rsync.it-infrastrukturen.org
Re: [VOTE] [RESULT] Apache OFBiz 11.04.01
We discussed it this morning with Christian. I believe it's the same with cross sometimes on Builbot and dissapear by itseld (false errors/failure) It would be good to double-check, but I don't expect a final/defintive result on this. IIRW, the best we have so far is Adam's invetigation about thread contentions in some rare cases which appear uniquely during tests. In other words I'd not be too concerned by this issue, but of course fixing it would be a relief. BTW, Christian which failure/errors did you get exactly? HTH Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com ouch..interesting tests are successful on mine; I would love to get the feedback from others before we announce the release. Thanks Christian. Jacopo On Nov 16, 2012, at 12:02 PM, Christian Geisert wrote: Am 16.11.2012 11:38, schrieb Jacopo Cappellato: The vote is now closed. Thanks to the voters, this vote has passed with the following results: Damn, I'm too late ;-) But anyway, looks good except for run-tests which fails on my local machine (but is successfull on Buildbot) - no time to have a closer look.. so +0 from me Christian
Re: [VOTE] [RESULT] Apache OFBiz 11.04.01
Ha, and I forgot, for those interested, you can always check at http://ci.apache.org/projects/ofbiz/logs/ Jacques Jacques Le Roux wrote: We discussed it this morning with Christian. I believe it's the same with cross sometimes on Builbot and dissapear by itseld (false errors/failure) It would be good to double-check, but I don't expect a final/defintive result on this. IIRW, the best we have so far is Adam's invetigation about thread contentions in some rare cases which appear uniquely during tests. In other words I'd not be too concerned by this issue, but of course fixing it would be a relief. BTW, Christian which failure/errors did you get exactly? HTH Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com ouch..interesting tests are successful on mine; I would love to get the feedback from others before we announce the release. Thanks Christian. Jacopo On Nov 16, 2012, at 12:02 PM, Christian Geisert wrote: Am 16.11.2012 11:38, schrieb Jacopo Cappellato: The vote is now closed. Thanks to the voters, this vote has passed with the following results: Damn, I'm too late ;-) But anyway, looks good except for run-tests which fails on my local machine (but is successfull on Buildbot) - no time to have a closer look.. so +0 from me Christian
Re: latest trunk code is broken (NOT!)
Wai bzb.ofbiz at gmail.com writes: Hello Hans, All, Sorry for the false alarm. I have read the ofbiz README file. I do run a ./ant run-install during the first trunk checkout. Subsequently all svn updates to my working copy, I use the ./ant refresh to recompile. It has not caused me any problems until this incident. When I run ./ant refresh on ofbiz using derby database, I do see that the derby database files are deleted. So running ./startofbiz.sh after that would cause ofbiz to recreate the database tables. Perhaps this was one of those rare glitches that take place somewhere during the workflow starting from the svn update command. But all works fine now. Thanks all for helping. Wai PS: Hans, my first name is Wai. No need to address me as MisterI'm just a simple working stiff -- View this message in context: http://ofbiz.135035.n4.nabble.com/latest-trunk-code-is-broken-tp3945234p3948024.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. Hello, I too ran into this error when installing the demo on Ubuntu 12.04 using the Quick Easy Setup instructions found on this page: https://cwiki.apache.org/OFBADMIN/demo-and-test-setup-guide.html The demo data was not installed using these instructions. Subsequently, after following the readme instructions, everything was fine. Micah
Re: [VOTE] [RESULT] Apache OFBiz 11.04.01
Here you go: http://www.apache.org/dist/ofbiz/ 12.04 is still not listed there because it is not officially released. If you are looking at the different features, the best document to look at is: https://cwiki.apache.org/OFBIZ/main-new-features.html I hope it helps. Regards, Jacopo On Nov 16, 2012, at 4:09 PM, Mark Schneider wrote: Thank you Jacopo. Am 16.11.2012 15:49, schrieb Jacopo Cappellato: No, it is bundled with Tomcat 6.0.36 I see that tomcat 7 is first bundled with ofbiz.12.04. Where can I find description of differences between OFBiz *10.04.04*, *11.04* and *12.04*? regards, Mark -- m...@it-infrastrukturen.org http://rsync.it-infrastrukturen.org
[jira] [Commented] (OFBIZ-5072) Tenant authentication problem
[ https://issues.apache.org/jira/browse/OFBIZ-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13499115#comment-13499115 ] Rene Frauli commented on OFBIZ-5072: I have tried to reproduce the issue with the current trunk with success. So it's not only a problem of backporting to 12.04. You can easily reproduce it with the following steps: 1. Load Demo 2. Load Demo Multitenant 3. Start 4. Login as tenant with admin / ofbiz / DEMO1 5. Go to Party and open details from admin 6. change password from user login admin to for e.g. test1 7. logout 8. try to login with admin / test1 / DEMO1 Now you will get an error, because the password is wrong. When you try to login with admin / test1 without tenant it works. So that means the password was not changed for the tenant admin, it was changed for the general admin. Rene Tenant authentication problem - Key: OFBIZ-5072 URL: https://issues.apache.org/jira/browse/OFBIZ-5072 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 12.04 Reporter: Rene Frauli Assignee: Jacopo Cappellato Fix For: SVN trunk, Release Branch 12.04 Attachments: LoginWorker.java.patch In 12.04 the LoginWorker method setWebContextObjects object doesn't store the delegator, dispatcher, security and the authz in the session only in the request. The effect is that the session for the tenant is not correct and the tenant cannot be used at all with strange effects. For e.g. data are stored with the default delegator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: latest trunk code is broken (NOT!)
From: Micah mmw_can...@yahoo.com Wai bzb.ofbiz at gmail.com writes: Hello Hans, All, Sorry for the false alarm. I have read the ofbiz README file. I do run a ./ant run-install during the first trunk checkout. Subsequently all svn updates to my working copy, I use the ./ant refresh to recompile. It has not caused me any problems until this incident. When I run ./ant refresh on ofbiz using derby database, I do see that the derby database files are deleted. So running ./startofbiz.sh after that would cause ofbiz to recreate the database tables. Perhaps this was one of those rare glitches that take place somewhere during the workflow starting from the svn update command. But all works fine now. Thanks all for helping. Wai PS: Hans, my first name is Wai. No need to address me as MisterI'm just a simple working stiff -- View this message in context: http://ofbiz.135035.n4.nabble.com/latest-trunk-code-is-broken-tp3945234p3948024.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. Hello, I too ran into this error when installing the demo on Ubuntu 12.04 using the Quick Easy Setup instructions found on this page: https://cwiki.apache.org/OFBADMIN/demo-and-test-setup-guide.html The demo data was not installed using these instructions. Subsequently, after following the readme instructions, everything was fine. Micah Thanks for report, We will have a look at it... Could you give more details on your experience? Jacques
Re: svn commit: r1403870 - /ofbiz/branches/20120329_portletWidget/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java
Erwan, could you please explain why this patch was committed to the portletWidget branch? There were some objections in Jira and in general there was no general approval for the inclusion. Also, it was a patch for the trunk, not the branch. This is not the way to go, the branch is not the playground of one committer and we cannot use it as an easy way (a lot of traffic, less reviews from committers) to see the code we like committed to trunk. If this is the general trend, I am tempted to say that the experiment of branches (mostly) used by one committer is failing: branches make sense only if a relevant part of the committer group is working on new stuff, not just one. Kind regards, Jacopo PS: a message to all: since I am not going to review each and every commit done on this branch, I am going to vote -1 to the merging of the portletWidget branch with the trunk until I will get enough guarantees from the people that worked on it that the changes will be only related to the original purpose of the branch. On Oct 30, 2012, at 10:10 PM, er...@apache.org wrote: Author: erwan Date: Tue Oct 30 21:10:10 2012 New Revision: 1403870 URL: http://svn.apache.org/viewvc?rev=1403870view=rev Log: Applying a patch from Olivier Heintz on branch OFBIZ-4949 add a new attribute for for entity-engine-xml tag, put-other-field-to-null= true, if it exist at the beginning data file, all update will put to null all field not detail in this file Modified: ofbiz/branches/20120329_portletWidget/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java
