Re: Lose Weight Program for OFBiz
On Mar 19, 2012, at 12:26 AM, Anne wrote: Basic ideas all look very good to me. IMO anything that is incomplete or not maintained should be moved to Attic or Extras, unless there is a very good reason for keeping it. The reason for moving it should be well documented. That way it is obvious which code needs work. If someone wants it, they can fix it and offer to maintain it, and then the community can consider whether it is important enough to return. Hopefully if non-committers can easily see what areas need work, they'll be more likely to adopt some code. Cheers, Anne. Anne, I completely agree. I actually see a few more areas of involvement/participation for the community in this cleanup effort: 1) when this discussion will be finalized, we will have a pretty clear roadmap of cleanup tasks to work one; we will then create Jira tasks for the agreed upon removals and community members (committers and non-committers) will have a chance to assign the tasks to them and help the community to implement the plan; this is really a roadmap 2) for components candidate to become projects in the Apache Extras (for OFBiz): we will need at least one project maintainer for each of them: this person doesn't necessarily have to be one of the existing OFBiz committers; I would actually like to see new persons show up and take the leadership; we could then delegate to them to write up (in their Apache Extras project) the goals for the component (of course we will sync with them) 3) for components that will be simply removed (Attic): I agree about the need to document the status of the code at the time of the removal to give opportunity in the future to an interested person to get them and do some more work Kind regards, Jacopo
[jira] [Created] (OFBIZ-4732) Not able to add Order Item Type for PO while adding item to existing PO.
Not able to add Order Item Type for PO while adding item to existing PO. Key: OFBIZ-4732 URL: https://issues.apache.org/jira/browse/OFBIZ-4732 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Release Branch 10.04, Release Branch 11.04, SVN trunk Reporter: Deepak Dixit Priority: Minor Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk If we are creating PO then user can add order item type from show cart screen, so there should be an option to add order item type while adding item to existing PO on edit item screen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4732) Not able to add Order Item Type for PO while adding item to existing PO.
[ https://issues.apache.org/jira/browse/OFBIZ-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Dixit updated OFBIZ-4732: Attachment: OFBIZ-4732-Trunk.patch OFBIZ-4732-11.04.patch OFBIZ-4732-10.04.patch Here is the patch for the issue. Not able to add Order Item Type for PO while adding item to existing PO. Key: OFBIZ-4732 URL: https://issues.apache.org/jira/browse/OFBIZ-4732 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Release Branch 10.04, Release Branch 11.04, SVN trunk Reporter: Deepak Dixit Priority: Minor Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk Attachments: OFBIZ-4732-10.04.patch, OFBIZ-4732-11.04.patch, OFBIZ-4732-Trunk.patch If we are creating PO then user can add order item type from show cart screen, so there should be an option to add order item type while adding item to existing PO on edit item screen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: bin folder for executable files/scripts
Hi Jacopo, tools/bin sounds good to me Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thanks everyone for the valuable comments! I am trying to finalize this thread: there seems to be consensus to move all the executable scripts into a folder to keep things organized. For the name of the folder: * some of you think that the bin (as I originally suggested) should be used because it is often used for this purpose * some of you are worried that this could interfere with some commonly used IDEs (e.g. Eclipse) that use the bin folder for output and need to be configured to use a different standard name After reviewing what we have now in OFBiz I am wondering if we could use the already existing tools folder; its current layout is: tools/api-java16 tools/src option a: add all the executables to tools/ folder directly option b: create a subfolder tools/bin and add all the executables there What do you think? Jacopo On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote: Then we could recommend to name .bin for instance But I wonder if this will not be a source of problem for newbies... And also for Windows users, bin is not a standard name at all Jacques From: Adrian Crum adrian.c...@sandglass-software.com That's fine with me. We just need to update the Eclipse configuration files. -Adrian On 2/29/2012 3:20 PM, J. Eckard wrote: I think that eclipse / eclipse users should have to accommodate the directory structure of OFBiz, not the other way around. On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote: Thanks for the feedback! Any suggestion for the name of the folder? I was hoping to use a standard name, that is why I initially proposed the bin folder... but since that is not an option we will have to think to something else (unless we use the existing tools folder but I am not sure about the intended usage of that). Jacopo On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote: +1 Jacques From: Adrian Crumadrian.c...@sandglass-software.com Sounds great, but don't use bin - that folder is created by Eclipse and it is in the SVN ignore list. -Adrian On 2/27/2012 7:10 PM, Jacopo Cappellato wrote: The number of executable files (*.sh and *bat) in the OFBiz home folder is rather big: what if we create a bin folder and we move all of them there? In this way users will have a place where they will find all the executable files only and the main folder will be cleaner. Jacopo
[jira] [Assigned] (OFBIZ-4732) Not able to add Order Item Type for PO while adding item to existing PO.
[ https://issues.apache.org/jira/browse/OFBIZ-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-4732: -- Assignee: Ashish Vijaywargiya Not able to add Order Item Type for PO while adding item to existing PO. Key: OFBIZ-4732 URL: https://issues.apache.org/jira/browse/OFBIZ-4732 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Release Branch 10.04, Release Branch 11.04, SVN trunk Reporter: Deepak Dixit Assignee: Ashish Vijaywargiya Priority: Minor Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk Attachments: OFBIZ-4732-10.04.patch, OFBIZ-4732-11.04.patch, OFBIZ-4732-Trunk.patch If we are creating PO then user can add order item type from show cart screen, so there should be an option to add order item type while adding item to existing PO on edit item screen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz
Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities. I cannot agree with the removal of these components, Birt integration and JCR (in the short term) Some other proposals: 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?) 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work. 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This to get a real committers (and contributors, see next point) list. 4. Also list contributors who have a function/task assigned either for creating documents, reporting errors or supply patches, list the contributions he/she did so we can keep up if he/she could be nominated to be a committer. Thanks again for your activity, keep up the good work! Regards, Hans On 03/18/2012 04:10 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and
[jira] [Created] (OFBIZ-4733) Xml Deserializer does not support BigDecimal
Xml Deserializer does not support BigDecimal
Key: OFBIZ-4733
URL: https://issues.apache.org/jira/browse/OFBIZ-4733
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Alexander Reelsen
In the last weeks the XML Serializer in trunk was extended to support
BigDecimal. Unfortunately deserializing is not supported, which leads to
services being broken when running via async as their are persisted in
runtime_data... like sending mails, when a bigdecimal is involved
Patch is:
--- a/framework/entity/src/org/ofbiz/entity/serialize/XmlSerializer.java
Fri Mar 16 16:32:16 2012 +0100
+++ b/framework/entity/src/org/ofbiz/entity/serialize/XmlSerializer.java
Mon Mar 19 09:08:17 2012 +0100
@@ -300,6 +300,9 @@
} else if (std-Integer.equals(tagName)) {
String valStr = element.getAttribute(value);
return Integer.valueOf(valStr);
+} else if (std-BigDecimal.equals(tagName)) {
+String valStr = element.getAttribute(value);
+return new BigDecimal(valStr);
} else if (std-Long.equals(tagName)) {
String valStr = element.getAttribute(value);
return Long.valueOf(valStr);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-4733) Xml Deserializer does not support BigDecimal
[
https://issues.apache.org/jira/browse/OFBIZ-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-4733:
--
Assignee: Jacques Le Roux
Xml Deserializer does not support BigDecimal
Key: OFBIZ-4733
URL: https://issues.apache.org/jira/browse/OFBIZ-4733
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Alexander Reelsen
Assignee: Jacques Le Roux
In the last weeks the XML Serializer in trunk was extended to support
BigDecimal. Unfortunately deserializing is not supported, which leads to
services being broken when running via async as their are persisted in
runtime_data... like sending mails, when a bigdecimal is involved
Patch is:
--- a/framework/entity/src/org/ofbiz/entity/serialize/XmlSerializer.java
Fri Mar 16 16:32:16 2012 +0100
+++ b/framework/entity/src/org/ofbiz/entity/serialize/XmlSerializer.java
Mon Mar 19 09:08:17 2012 +0100
@@ -300,6 +300,9 @@
} else if (std-Integer.equals(tagName)) {
String valStr = element.getAttribute(value);
return Integer.valueOf(valStr);
+} else if (std-BigDecimal.equals(tagName)) {
+String valStr = element.getAttribute(value);
+return new BigDecimal(valStr);
} else if (std-Long.equals(tagName)) {
String valStr = element.getAttribute(value);
return Long.valueOf(valStr);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4730) make property-to-field/ in widget firstly lookup up the SystemProperty entity and then the properties file
[ https://issues.apache.org/jira/browse/OFBIZ-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Bakker closed OFBIZ-4730. -- Resolution: Fixed New Revision: 1302320, thank you Leon for the contribution. make property-to-field/ in widget firstly lookup up the SystemProperty entity and then the properties file Key: OFBIZ-4730 URL: https://issues.apache.org/jira/browse/OFBIZ-4730 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Leon Assignee: Hans Bakker Priority: Minor Attachments: OFBIZ-4730.patch Entity SystemProperty has been introduced to framework, and property-to-field/ in minilang has been update to lookup properties in that entity firstly, but the property-to-field/ in widgets does not. Is there any particular concern about not to change the behaviour of property-to-field/ in widgets, such as performance impact? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4733) Xml Deserializer does not support BigDecimal
[
https://issues.apache.org/jira/browse/OFBIZ-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-4733.
--
Resolution: Fixed
Fix Version/s: SVN trunk
Thanks Alexander,
As it was a tiny one, I have applied your change directly in code at r1302324
in trunk.
But please next time provide a valid svn patch and attach it following
[instructions|https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-HowtoSendinYourContributions(orhowtocreateandapplypatches)]
Xml Deserializer does not support BigDecimal
Key: OFBIZ-4733
URL: https://issues.apache.org/jira/browse/OFBIZ-4733
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Alexander Reelsen
Assignee: Jacques Le Roux
Fix For: SVN trunk
In the last weeks the XML Serializer in trunk was extended to support
BigDecimal. Unfortunately deserializing is not supported, which leads to
services being broken when running via async as their are persisted in
runtime_data... like sending mails, when a bigdecimal is involved
Patch is:
--- a/framework/entity/src/org/ofbiz/entity/serialize/XmlSerializer.java
Fri Mar 16 16:32:16 2012 +0100
+++ b/framework/entity/src/org/ofbiz/entity/serialize/XmlSerializer.java
Mon Mar 19 09:08:17 2012 +0100
@@ -300,6 +300,9 @@
} else if (std-Integer.equals(tagName)) {
String valStr = element.getAttribute(value);
return Integer.valueOf(valStr);
+} else if (std-BigDecimal.equals(tagName)) {
+String valStr = element.getAttribute(value);
+return new BigDecimal(valStr);
} else if (std-Long.equals(tagName)) {
String valStr = element.getAttribute(value);
return Long.valueOf(valStr);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz
Hi Hans, please see inline: On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. The not complete is not the only motivation: I have also considered if they seem to be used and maintained; or if they follow best practices or if they are very specific: some of them are actually a very specific way to implement a very specific set of requirements and may be better represented as independent optional components that can be downloaded and used only by users with these specific needs. Keeping all them in will also mean that, if and when the community will decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens to ABC or from the OFBiz Framework to Moqui) they will also need to be maintained and migrated by the community... when the user based may be very limited. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities. I agree that reporting is a weak point in OFBiz; I disagree that the integrated Birt component is the answer to this problem: the integration is minimal and the reports that are implemented with Birt are very good example of how weak the current integration is: they have a bunch of data preparation code buried in them and their layout is very simple too. And you still have to define controller entries for the reports and also screen/forms for the parameters to invoke them... this is really a small help provided by the framework; a real integration, ready to be released with OFBiz, should do much more than this (like letting the user to define a new report using the report designer only and then publish it to OFBiz from there without requiring all these programming tasks). And as a side effect for having this integration we have to bundle and deliver to all the users a big amount of jars; instead this should be an optional (downloaded separately) component that only interested users should get (and these users will probably already have their own Birt setup). OFbiz should stay lighter and should delegate the decision about what reporting engine to use to the user. I suspect that, if the user community is really using this integration to build reports, we would get a lot of them contributed... and this is not happening. I cannot agree with the removal of these components, Birt integration and JCR (in the short term) Fair enough; we will see what others have to say on this subject as well. Then we will take the best decision for the community. Some other proposals: 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?) This is a good idea indeed if the presence/lack of junit test will be used as an additional element for the decision; but it can't be the only one because we could have a component that has a lot of junit tests but for some reason is not a good fit for OFBiz (for example because its implementation doesn't follow best practices, or no one is willing to maintain it etc...); in this case it should be removed as well. 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work. I don't like very much this because it implies some sort of ownership over code. 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This
Re: Lose Weight Program for OFBiz
Hi Hans, I don't want to argue the merits of removing specific portions of code/features/components but I think it's worth mentioning some of the benefits of moving features to Extras: - Greater access to contributors, if someone is making regular quality contributions to a specific Extra then they can easily be granted commit access. Easier for the contributor and no worry for the PMC that we have to grant access to the entire codebase (which in turn is better for the entire community) - Moving something to Extras shouldn't be considered as a loss to OFBiz or to the community. It is merely a means of streamlining and consolidating what is offered by OFBiz OOTB. Personally I envision OFBiz Extras as potentially becoming a vibrant community in itself, if we seed that community with a decent set of add-on functionality then it's quite possible other people would start to do the same. Providing and managing an Extra for the community would bring a type of recognition that donating it directly to OFBiz never could. For a company such as yours that likes to promote itself quite a bit it could actually work out to be an advantage for you. - The benefits of a slimmer OFBiz really can't be understated, at the moment we have something like 7000+ services, I don't know about you but I'd be lucky to be able to describe what maybe 10-20% actually do. The idea that you can download OFBiz, pop over to Extras and gran the things you actually need sounds super appealing to me. Sure it's an extra step that needs to be taken but I don't think that outweighs that benefits of being able to run only what you need. - New features for old releases. With components existing outside of OFBiz, contributors could make newer versions of components compatible with older releases of OFBiz, essentially allowing what we don't currently. If we can build a good community around Extras then I think we could see some amazing things happen in this regard. People could be empowered to do things that would never be accepted into OFBiz but would still be useful to a large number of people. Perhaps someone wants to develop Catalog Manager 2.0 using Apache Wicket or Apache Click or some other UI framework, they could do that and know that it will have an audience because we'll be actively endorsing the Extras community as a place to go for additional functionality. Anyway, I'm not arguing any of your points, I just want to make it clear to you and everyone else that I see this as an opportunity to make more features available for OFBiz rather than any attempt to take out the trash (that's the Attic's job). Regards Scott On 19/03/2012, at 9:05 PM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities. I cannot agree with the removal of these components, Birt integration and JCR (in the short term) Some other proposals: 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?) 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work. 3. List functions/tasks with every committer, if a committer does not have a function/task or is not active for a year, put him on the emeritus list, if he gets active again put him back as a committer on his request. This to get a real committers (and contributors, see next point) list. 4. Also list contributors who have a function/task assigned either for creating documents, reporting errors or supply patches, list the contributions he/she did so we can keep up if he/she could be nominated to be a committer. Thanks again for your activity, keep up the good work! Regards, Hans On 03/18/2012 04:10 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated)
Re: bin folder for executable files/scripts
bin is good enough. On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Hi Jacopo, tools/bin sounds good to me Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thanks everyone for the valuable comments! I am trying to finalize this thread: there seems to be consensus to move all the executable scripts into a folder to keep things organized. For the name of the folder: * some of you think that the bin (as I originally suggested) should be used because it is often used for this purpose * some of you are worried that this could interfere with some commonly used IDEs (e.g. Eclipse) that use the bin folder for output and need to be configured to use a different standard name After reviewing what we have now in OFBiz I am wondering if we could use the already existing tools folder; its current layout is: tools/api-java16 tools/src option a: add all the executables to tools/ folder directly option b: create a subfolder tools/bin and add all the executables there What do you think? Jacopo On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote: Then we could recommend to name .bin for instance But I wonder if this will not be a source of problem for newbies... And also for Windows users, bin is not a standard name at all Jacques From: Adrian Crum adrian.c...@sandglass-software.com That's fine with me. We just need to update the Eclipse configuration files. -Adrian On 2/29/2012 3:20 PM, J. Eckard wrote: I think that eclipse / eclipse users should have to accommodate the directory structure of OFBiz, not the other way around. On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote: Thanks for the feedback! Any suggestion for the name of the folder? I was hoping to use a standard name, that is why I initially proposed the bin folder... but since that is not an option we will have to think to something else (unless we use the existing tools folder but I am not sure about the intended usage of that). Jacopo On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote: +1 Jacques From: Adrian Crumadrian.c...@sandglass-software.com Sounds great, but don't use bin - that folder is created by Eclipse and it is in the SVN ignore list. -Adrian On 2/27/2012 7:10 PM, Jacopo Cappellato wrote: The number of executable files (*.sh and *bat) in the OFBiz home folder is rather big: what if we create a bin folder and we move all of them there? In this way users will have a place where they will find all the executable files only and the main folder will be cleaner. Jacopo
goodbye
unsubscribe dev@ofbiz.apache.org
Re: Lose Weight Program for OFBiz
A point I'd like to emphasize: before moving things out we should check all related pending Jiras Jacques
Re: goodbye
This is not the way, you should use https://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists Jacques From: Francisca Hernández fhernan...@iguanait.com unsubscribe dev@ofbiz.apache.org
Re: Lose Weight Program for OFBiz
Scott, I appreciate your reply , but this apache extra's stuff is not working.: the Apache extra's is now over one year old, in that time there are 125 extra's for 84 projects. I even counted all the test and apple dirs.most projects are empty and do not have any extra's sorry i see moving out of special purpose components to extra's as a big error. Your advantages below will not work because Apache extra will be not a success. What is apache extra? A link screen to google projects which have some link to a apache project. Good for single developers, not good for us (Antwebsystems) because we rather use our own infrastructure which is integrated with the OFBiz system scrum component what is not possible with an external svn. Extra publicity? not really , we can publisize links in the ofbiz wiki to our own repository just the same. Regards, Hans On 03/19/2012 05:32 PM, Scott Gray wrote: Hi Hans, I don't want to argue the merits of removing specific portions of code/features/components but I think it's worth mentioning some of the benefits of moving features to Extras: - Greater access to contributors, if someone is making regular quality contributions to a specific Extra then they can easily be granted commit access. Easier for the contributor and no worry for the PMC that we have to grant access to the entire codebase (which in turn is better for the entire community) - Moving something to Extras shouldn't be considered as a loss to OFBiz or to the community. It is merely a means of streamlining and consolidating what is offered by OFBiz OOTB. Personally I envision OFBiz Extras as potentially becoming a vibrant community in itself, if we seed that community with a decent set of add-on functionality then it's quite possible other people would start to do the same. Providing and managing an Extra for the community would bring a type of recognition that donating it directly to OFBiz never could. For a company such as yours that likes to promote itself quite a bit it could actually work out to be an advantage for you. - The benefits of a slimmer OFBiz really can't be understated, at the moment we have something like 7000+ services, I don't know about you but I'd be lucky to be able to describe what maybe 10-20% actually do. The idea that you can download OFBiz, pop over to Extras and gran the things you actually need sounds super appealing to me. Sure it's an extra step that needs to be taken but I don't think that outweighs that benefits of being able to run only what you need. - New features for old releases. With components existing outside of OFBiz, contributors could make newer versions of components compatible with older releases of OFBiz, essentially allowing what we don't currently. If we can build a good community around Extras then I think we could see some amazing things happen in this regard. People could be empowered to do things that would never be accepted into OFBiz but would still be useful to a large number of people. Perhaps someone wants to develop Catalog Manager 2.0 using Apache Wicket or Apache Click or some other UI framework, they could do that and know that it will have an audience because we'll be actively endorsing the Extras community as a place to go for additional functionality. Anyway, I'm not arguing any of your points, I just want to make it clear to you and everyone else that I see this as an opportunity to make more features available for OFBiz rather than any attempt to take out the trash (that's the Attic's job). Regards Scott On 19/03/2012, at 9:05 PM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities. I cannot agree with the removal of these components, Birt integration and JCR (in the short term) Some other proposals: 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?) 2. To have a lead
Re: Lose Weight Program for OFBiz
Jacopo, I appreciate you reply and effort, can however not agree with you. Perhaps for you good reasoning, not for me. Regards, Hans On 03/19/2012 05:08 PM, Jacopo Cappellato wrote: Hi Hans, please see inline: On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. The not complete is not the only motivation: I have also considered if they seem to be used and maintained; or if they follow best practices or if they are very specific: some of them are actually a very specific way to implement a very specific set of requirements and may be better represented as independent optional components that can be downloaded and used only by users with these specific needs. Keeping all them in will also mean that, if and when the community will decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens to ABC or from the OFBiz Framework to Moqui) they will also need to be maintained and migrated by the community... when the user based may be very limited. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities. I agree that reporting is a weak point in OFBiz; I disagree that the integrated Birt component is the answer to this problem: the integration is minimal and the reports that are implemented with Birt are very good example of how weak the current integration is: they have a bunch of data preparation code buried in them and their layout is very simple too. And you still have to define controller entries for the reports and also screen/forms for the parameters to invoke them... this is really a small help provided by the framework; a real integration, ready to be released with OFBiz, should do much more than this (like letting the user to define a new report using the report designer only and then publish it to OFBiz from there without requiring all these programming tasks). And as a side effect for having this integration we have to bundle and deliver to all the users a big amount of jars; instead this should be an optional (downloaded separately) component that only interested users should get (and these users will probably already have their own Birt setup). OFbiz should stay lighter and should delegate the decision about what reporting engine to use to the user. I suspect that, if the user community is really using this integration to build reports, we would get a lot of them contributed... and this is not happening. I cannot agree with the removal of these components, Birt integration and JCR (in the short term) Fair enough; we will see what others have to say on this subject as well. Then we will take the best decision for the community. Some other proposals: 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?) This is a good idea indeed if the presence/lack of junit test will be used as an additional element for the decision; but it can't be the only one because we could have a component that has a lot of junit tests but for some reason is not a good fit for OFBiz (for example because its implementation doesn't follow best practices, or no one is willing to maintain it etc...); in this case it should be removed as well. 2. To have a lead committer appointed for every component in the system who will check incoming patches and will commit them, to relieve Jacques of some work. I don't like very much this because it implies some sort of ownership over code. 3. List functions/tasks with every committer, if a committer
OFBiz integration in Apache sonar instance
Hi all, last year I started the OFBiz integration in the Apache sonar instance. But I've been stopped by a request from infra, as I need to give the ports dynamically. And don't know how to make it happen... https://issues.apache.org/jira/browse/INFRA-3590 If anyone has a pointer, this would be really appreciated. TIA, -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz
Thank you Scott. I will wait a bit more before summarizing some of the concepts/opinion expressed so far and then I will initiate, as you suggested, separate threads. Jacopo On Mar 18, 2012, at 9:15 PM, Scott Gray wrote: I agree with the concept completely. I wonder though if each of the suggested changes should get their own thread rather than be discussed in this one, a thread with too many topics flying around is a little difficult to follow. Or perhaps even just tackle each of these consecutively after an agreement on the course of action is reached and a volunteer to do the work is found then we could move on to the next suggestion? Regards Scott On 18/03/2012, at 10:10 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...) DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually
Re: Lose Weight Program for OFBiz
I want also to emphasize that having many possible syntaxes in use-when, set, etc. is not a plus for me. We could make it possible but have a single way in OFBiz OOTB. I guess there are no needs to argue about... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com A point I'd like to emphasize: before moving things out we should check all related pending Jiras Jacques
loop code simplification
Hi,
I'm trying to remove a lot of iterators, and use the for-each syntax,
which exists since java 1.5.
During my journey, I found a lot of double tests for a while like this one:
while (typePurposes != null typePurposes.hasNext()) {
(ContactMechWorker.java line 606)
Can it be simplified to for(GenericValue contactMechTypePurpose :
theList) ? Or should I keep it like it is ?
Regards,
--
Erwan de FERRIERES
www.nereide.biz
Not able to login with ofbiz password for https://demo-trunk.ofbiz.apache.org:8443/catalog/control/checkLogin
Hello All, Getting error while login on the demo trunk so please provide correct password. Regards Jaideep Singh
