Re: Not able to login with ofbiz password for https://demo-trunk.ofbiz.apache.org:8443/catalog/control/checkLogin
Hi Jaideep, Use username as "flexadmin" and password is "ofbiz" Thanks& regards Himanil Gupta Enterprise Software Developer HotWax Media Indore http://www.hotwaxmedia.com/ On 03/20/2012 11:02 AM, jaideep singh wrote: Hello All, Getting error while login on the demo trunk so please provide correct password. Regards Jaideep Singh
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
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
Re: Lose Weight Program for OFBiz
I want also to emphasize that having many possible syntaxes in but have a single way in OFBiz OOTB. I guess there are no needs to argue about... Jacques From: "Jacques Le Roux" A point I'd like to emphasize: before moving things out we should check all related pending Jiras Jacques
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 li
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
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 com
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 co
Re: goodbye
This is not the way, you should use https://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists Jacques From: "Francisca Hernández" 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
goodbye
unsubscribe dev@ofbiz.apache.org
Re: "bin" folder for executable files/scripts
bin is good enough. On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux wrote: > Hi Jacopo, > > tools/bin sounds good to me > > Jacques > > From: "Jacopo Cappellato" > >> 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" 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 Crum" 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 >> >> >> >
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 sh
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 ba
[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
[jira] [Closed] (OFBIZ-4730) make 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 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 > in minilang has been update to lookup properties in that > entity firstly, but the in widgets does not. > Is there any particular concern about not to change the behaviour of > 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] [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] [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
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 an
[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: "bin" folder for executable files/scripts
Hi Jacopo, tools/bin sounds good to me Jacques From: "Jacopo Cappellato" 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" 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 Crum" 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] [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
[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