[jira] [Commented] (OFBIZ-4787) Party Manager Default Country in Update
[ https://issues.apache.org/jira/browse/OFBIZ-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249482#comment-13249482 ] Jacques Le Roux commented on OFBIZ-4787: Tom, Please open a new Jira for It's Country can not be changed because a foreign missing parameter on a call to updateEftAccount. Thanks Party Manager Default Country in Update --- Key: OFBIZ-4787 URL: https://issues.apache.org/jira/browse/OFBIZ-4787 Project: OFBiz Issue Type: Bug Components: party Affects Versions: SVN trunk Environment: demo-trunk Reporter: Tom Burns Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 11.04, SVN trunk Attachments: OFBIZ-4787 defaultCountryGeoId.patch In Party Manager Profile Contact Information Update the Country drop down always defaults to United States. This is misleading if the Country is not United States. If a user were to change some other address element he/she would have to also re-set Country to keep it from being changed to United States. To reproduce: In Party Manager lookup a party with a Postal Address say DemoSupplier* In Contact Information Postal Address Click Update In the Country field select any country but United States say Switzerland Click Save Note - Expect drop down default after save = Switzerland Actual drop down default after save = United States Click Go Back Expect Postal Address country = Switzerland Actual Postal Address country = Switzerland Click Click Update Expect drop down default to be Switzerland Actual United States * Note: Select any party but Company. It's Country can not be changed because a foreign missing parameter on a call to updateEftAccount. This may be a separate issue. -- 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: OFBiz slimdown jira
Hi Pierre, now that we have a tentative release plan: http://ofbiz.apache.org/download.html it would be easy to setup in Jira versions for upcoming releases (with a release date); at the moment we could add: 10.04.02 with release date 2012-04-30 11.04.01 with release date 2012-05-31 Does it sound good? Jacopo On Apr 7, 2012, at 11:19 AM, Pierre Smits wrote: Hi Jacopo, May I suggest to set a target date for this and the other releases intended for the near future (ie 09.04.02, 10.04.02, 11.x, 12.x). This will help us to better identify issues which we intend to address per release. But it also helps us communicate to the communty, than repeat over and over in the mailing lists. Regards, Pierre Op 5 april 2012 21:23 schreef Erwan de FERRIERES erwan.de-ferrie...@nereide.fr het volgende: Le 05/04/2012 10:26, Jacopo Cappellato a écrit : Yeah, I think it is now time to start the process, thank you Erwan. I have created the new version with name SlimDown (if a better name will be suggested we will change it); now we can create the tasks for the agreed upon decisions so far and use the Fix Version/s field to associate them to the roadmap. Jacopo Thanks Jacopo, now let's work ! On Apr 5, 2012, at 10:00 AM, Erwan de FERRIERES wrote: Hi Jacopo, do we have a better name for the Jira version than slimdown ? And would it be possible to create the jira version, so we can start on creating the tasks ? Cheers, -- Erwan de FERRIERES -- Erwan de FERRIERES www.nereide.biz
[jira] [Closed] (OFBIZ-3790) email password broken
[ https://issues.apache.org/jira/browse/OFBIZ-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3790. -- Resolution: Fixed Fix Version/s: SVN trunk Closing, see http://svn.apache.org/viewvc?rev=1310716view=rev email password broken - Key: OFBIZ-3790 URL: https://issues.apache.org/jira/browse/OFBIZ-3790 Project: OFBiz Issue Type: Bug Reporter: Si Chen Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: Screen shot 2010-05-28 at 9.25.05 AM.png, emailPasswd.diff Email password feature in party manager is broken. The log shows: 2010-05-28 09:24:58,193 (http-0.0.0.0-8543-14) [ ControlServlet.java:131:INFO ] [[[forgotPassword] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]] 2010-05-28 09:24:58,268 (http-0.0.0.0-8543-14) [ RequestHandler.java:597:INFO ] Ran Event [java:org.ofbiz.securityext.login.LoginEvents#forgotPassword] from [request], result is [success] 2010-05-28 09:24:58,275 (http-0.0.0.0-8543-14) [ RequestHandler.java:704:INFO ] Rendering View [forgotPassword], sessionId=6B88D615C7E15A7F8A3D1238F3447D27.jvm1 2010-05-28 09:24:58,278 (http-0.0.0.0-8543-14) [ ScreenRenderer.java:106:INFO ] render screen: forgotPassword, resource: component://common/widget/CommonScreens.xml 2010-05-28 09:24:58,325 (http-0.0.0.0-8543-14) [ PrimaryKeyFinder.java:142:INFO ] Returning null because found incomplete primary key in find: [GenericEntity:PartyNameView][partyId,null()] 2010-05-28 09:24:58,520 (http-0.0.0.0-8543-14) [ ServerHitBin.java:691:INFO ] Duplicate ServerHit was updated: [GenericEntity:ServerHit][contentId,partymgr.forgotPassword(java.lang.String)][createdStamp,2010-05-28 09:24:58.518(java.sql.Timestamp)][createdTxStamp,2010-05-28 09:24:58.516(java.sql.Timestamp)][hitStartDateTime,2010-05-28 09:24:58.193(java.sql.Timestamp)][hitTypeId,REQUEST(java.lang.String)][lastUpdatedStamp,2010-05-28 09:24:58.518(java.sql.Timestamp)][lastUpdatedTxStamp,2010-05-28 09:24:58.516(java.sql.Timestamp)][referrerUrl,https://ntc:8543/partymgr/control/main(java.lang.String)][requestUrl,https://ntc:8543/partymgr/control/forgotPassword(java.lang.String)][runningTimeMillis,322(java.lang.Long)][serverHostName,domU-12-31-39-00-0F-51(java.lang.String)][serverIpAddress,10.254.31.159(java.lang.String)][visitId,25693(java.lang.String)] 2010-05-28 09:24:58,521 (http-0.0.0.0-8543-14) [ ControlServlet.java:300:INFO ] [[[forgotPassword] Request Done- total:0.327,since last([forgotPassword] ...):0.327]] 2010-05-28 09:25:02,715 (http-0.0.0.0-8543-15) [ ControlServlet.java:131:INFO ] [[[forgotPassword] Request Begun, encoding=[UTF-8]- total:0.0,since last(Begin):0.0]] 2010-05-28 09:25:03,074 (http-0.0.0.0-8543-15) [ UtilProperties.java:871:INFO ] ResourceBundle SecurityextUiLabels (en_US) created in 0.12s with 53 properties 2010-05-28 09:25:03,075 (http-0.0.0.0-8543-15) [ RequestHandler.java:597:INFO ] Ran Event [java:org.ofbiz.securityext.login.LoginEvents#forgotPassword] from [request], result is [error] 2010-05-28 09:25:03,110 (http-0.0.0.0-8543-15) [ RequestHandler.java:400:ERROR] Request forgotPassword caused an error with the following message: Problems with configuration; please contact customer service. 2010-05-28 09:25:03,111 (http-0.0.0.0-8543-15) [ RequestHandler.java:704:INFO ] Rendering View [forgotPassword], sessionId=6B88D615C7E15A7F8A3D1238F3447D27.jvm1 2010-05-28 09:25:03,116 (http-0.0.0.0-8543-15) [ ScreenRenderer.java:106:INFO ] render screen: forgotPassword, resource: component://common/widget/CommonScreens.xml 2010-05-28 09:25:03,141 (http-0.0.0.0-8543-15) [ PrimaryKeyFinder.java:142:INFO ] Returning null because found incomplete primary key in find: [GenericEntity:PartyNameView][partyId,null()] 2010-05-28 09:25:03,380 (http-0.0.0.0-8543-15) [ ServerHitBin.java:691:INFO ] Duplicate ServerHit was updated: [GenericEntity:ServerHit][contentId,partymgr.forgotPassword(java.lang.String)][createdStamp,2010-05-28 09:25:03.378(java.sql.Timestamp)][createdTxStamp,2010-05-28 09:25:03.376(java.sql.Timestamp)][hitStartDateTime,2010-05-28 09:25:02.715(java.sql.Timestamp)][hitTypeId,REQUEST(java.lang.String)][lastUpdatedStamp,2010-05-28 09:25:03.378(java.sql.Timestamp)][lastUpdatedTxStamp,2010-05-28 09:25:03.376(java.sql.Timestamp)][referrerUrl,https://ntc:8543/partymgr/control/forgotPassword(java.lang.String)][requestUrl,https://ntc:8543/partymgr/control/forgotPassword(java.lang.String)][runningTimeMillis,660(java.lang.Long)][serverHostName,domU-12-31-39-00-0F-51(java.lang.String)][serverIpAddress,10.254.31.159(java.lang.String)][visitId,25693(java.lang.String)] 2010-05-28 09:25:03,381
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
On Apr 8, 2012, at 2:35 AM, Hans Bakker wrote: Jacopo, You removed the trunk download from the download page which was there from the start without trying to get a consensus. What are you talking about? I am shocked about how imprecise but this is blatant is ridiculous: what is the removal you are talking about? I simply added information about the new release schedule. Sure, if everybody thinks that is way to go, than that is it. However i think seeing the the history of OFBiz where the trunk was always very reliable and where problems were always fixed within hours, the trunk is very usable and people selecting the download page should be aware of it. Actually the official Apache pages list this link on the central site. http://projects.apache.org/projects/ofbiz.html So it has nothing to do with Apache policies. Hans, are you serious? Or you really don't understand? We have prominent links (2 of them) to the svn from the main page and we have a full page dedicated to svn instructions: http://ofbiz.apache.org/ https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html and no one would ever think to remove them: svn is essential information to get new contributions. The url to projects.apache.org (that *I* helped to have working on the DOAP file) is a good thing to have because it shows a summary of most relevant resources for OFBiz, including svn. So why not on the OFBiz site? I think it should be there taking the amount of changes that are applied to the trunk, showing the latest version is following the latest internet developments. Further what you are going to do with the 'what is new' page? Do you mean the page that was created from a proposal I did a few years ago and that now you are using (undisturbed because of the lack of the community and PMC oversight on this) to add ads of your company and (unclear) links to your sites? Here is what I would do there: 1) remove all the references to companies and external sites 2) keep it as a working document (as we are doing) to prepare official what's new pages specific for each release branch 3) add links to these release branch specific what's new pages from the README of the branch, from the OFBiz website etc.. If people want to try it, where should they find the download link? And the trunk demo, how do they find the download link here too? The checkout of source code is not a download and I didn't move the instructions: they are still there and there is a prominent link from the main page. Hans, if you can concentrate it is not that difficult to get: 1) download page isfor officially approved releases only; the releases are served thru the ASF mirrors infrastructure that can *only* serve officially voted releases 2) the source code/svn page is for persons interested in the living versions of svn trunk and branches; we have already good information for this and in fact very few people ask where are the source files? So lets do a voteand see if the removal of the link from the download page was agreed or not. Ok, prepare your proposal and then start the vote thread. Jacopo Hans On 04/07/2012 10:30 PM, Jacopo Cappellato wrote: I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo On Apr 7, 2012, at 12:06 PM, Jacques Le Roux wrote: From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com This is not consensus, it is a compromise. Right What is the purpose of mentioning that we have also a trunk (obvious) To relax each other positions (is that even English? :o). Meant for users for are not acquainted with open source but still potential OFBiz users and what is the text that you would like to add there? Beside the releases you could also go the bleeding edge way [http://en.wikipedia.org/wiki/Bleeding_edge_technology] and check out the trunk from OFBiz repository (Subversion) Depending of the way we prefer to present it, could be also state of art [http://en.wikipedia.org/wiki/State_of_the_art] because trunk is really not that bleeding edge... Jacques Jacopo On Apr 7, 2012, at 11:06 AM, Jacques Le Roux wrote: Maybe, as a consensus, we can put a word about it and not a link? Jacques From: Hans Bakkermailingl...@antwebsystems.com But Apache does not prohibit it? you want to be the best pupil in the Apache school? I
[jira] [Created] (OFBIZ-4792) Using GZip compression for js/css files
Using GZip compression for js/css files --- Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: ALL APPLICATIONS, specialpurpose/ecommerce Affects Versions: Release Branch 11.04 Environment: Windows/Linux Reporter: Mandeep Sidhu Fix For: Release Branch 11.04 I was wondering if it is possible to reduce the size of external javascript's/css files being fetched by making use of GZip encoding. The feeding server does understand and responds to GZip encoding, however Ofbiz is not requesting the content in GZip format. Kindly include this feature so that Ofbiz will include the GZip encoding option in the http header while requesting the external javascript file ? Also, if possible integrate the compressor module http://code.google.com/p/yui-compressor-ant-task/ as suggested by Jacques (Jacques Le Roux jacques.le.roux) -- 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: Summary of some recent discussions around the OFBiz release roadmap and some proposals
Jacopo, i have a very simple question about a link which always worked: http://ci.apache.org/projects/ofbiz/snapshots/ofbiz-trunk-current.zip It was normally shown on this page: http://ci.apache.org/projects/ofbiz/snapshots/ now it does not work anymore. My point is that this link should be reasonable visible somewhere preferably on the download page. enter ofbiz trunk current zip in google and you will see it is used pretty frequently (3030 times) (it often also points to http://build.ofbiz.org/builds/ofbiz-trunk-current.zip and other links) If you simply not want do do what i asked for is fine. I now ran out of steam finally. :-) Regards, Hans On 04/08/2012 01:03 PM, Jacopo Cappellato wrote: On Apr 8, 2012, at 2:35 AM, Hans Bakker wrote: Jacopo, You removed the trunk download from the download page which was there from the start without trying to get a consensus. What are you talking about? I am shocked about how imprecise but this is blatant is ridiculous: what is the removal you are talking about? I simply added information about the new release schedule. Sure, if everybody thinks that is way to go, than that is it. However i think seeing the the history of OFBiz where the trunk was always very reliable and where problems were always fixed within hours, the trunk is very usable and people selecting the download page should be aware of it. Actually the official Apache pages list this link on the central site. http://projects.apache.org/projects/ofbiz.html So it has nothing to do with Apache policies. Hans, are you serious? Or you really don't understand? We have prominent links (2 of them) to the svn from the main page and we have a full page dedicated to svn instructions: http://ofbiz.apache.org/ https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html and no one would ever think to remove them: svn is essential information to get new contributions. The url to projects.apache.org (that *I* helped to have working on the DOAP file) is a good thing to have because it shows a summary of most relevant resources for OFBiz, including svn. So why not on the OFBiz site? I think it should be there taking the amount of changes that are applied to the trunk, showing the latest version is following the latest internet developments. Further what you are going to do with the 'what is new' page? Do you mean the page that was created from a proposal I did a few years ago and that now you are using (undisturbed because of the lack of the community and PMC oversight on this) to add ads of your company and (unclear) links to your sites? Here is what I would do there: 1) remove all the references to companies and external sites 2) keep it as a working document (as we are doing) to prepare official what's new pages specific for each release branch 3) add links to these release branch specific what's new pages from the README of the branch, from the OFBiz website etc.. If people want to try it, where should they find the download link? And the trunk demo, how do they find the download link here too? The checkout of source code is not a download and I didn't move the instructions: they are still there and there is a prominent link from the main page. Hans, if you can concentrate it is not that difficult to get: 1) download page isfor officially approved releases only; the releases are served thru the ASF mirrors infrastructure that can *only* serve officially voted releases 2) the source code/svn page is for persons interested in the living versions of svn trunk and branches; we have already good information for this and in fact very few people ask where are the source files? So lets do a voteand see if the removal of the link from the download page was agreed or not. Ok, prepare your proposal and then start the vote thread. Jacopo Hans On 04/07/2012 10:30 PM, Jacopo Cappellato wrote: I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo On Apr 7, 2012, at 12:06 PM, Jacques Le Roux wrote: From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com This is not consensus, it is a compromise. Right What is the purpose of mentioning that we have also a trunk (obvious) To relax each other positions (is that even English? :o). Meant for users for are not acquainted with open source but still potential OFBiz users and what is the text that you would
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
To summarize: you were accusing me and pointing your finger to my commit even if my commit doesn't have anything to do with what you are reporting here. Jacopo On Apr 8, 2012, at 9:03 AM, Hans Bakker wrote: Jacopo, i have a very simple question about a link which always worked: http://ci.apache.org/projects/ofbiz/snapshots/ofbiz-trunk-current.zip It was normally shown on this page: http://ci.apache.org/projects/ofbiz/snapshots/ now it does not work anymore. My point is that this link should be reasonable visible somewhere preferably on the download page. enter ofbiz trunk current zip in google and you will see it is used pretty frequently (3030 times) (it often also points to http://build.ofbiz.org/builds/ofbiz-trunk-current.zip and other links) If you simply not want do do what i asked for is fine. I now ran out of steam finally. :-) Regards, Hans On 04/08/2012 01:03 PM, Jacopo Cappellato wrote: On Apr 8, 2012, at 2:35 AM, Hans Bakker wrote: Jacopo, You removed the trunk download from the download page which was there from the start without trying to get a consensus. What are you talking about? I am shocked about how imprecise but this is blatant is ridiculous: what is the removal you are talking about? I simply added information about the new release schedule. Sure, if everybody thinks that is way to go, than that is it. However i think seeing the the history of OFBiz where the trunk was always very reliable and where problems were always fixed within hours, the trunk is very usable and people selecting the download page should be aware of it. Actually the official Apache pages list this link on the central site. http://projects.apache.org/projects/ofbiz.html So it has nothing to do with Apache policies. Hans, are you serious? Or you really don't understand? We have prominent links (2 of them) to the svn from the main page and we have a full page dedicated to svn instructions: http://ofbiz.apache.org/ https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html and no one would ever think to remove them: svn is essential information to get new contributions. The url to projects.apache.org (that *I* helped to have working on the DOAP file) is a good thing to have because it shows a summary of most relevant resources for OFBiz, including svn. So why not on the OFBiz site? I think it should be there taking the amount of changes that are applied to the trunk, showing the latest version is following the latest internet developments. Further what you are going to do with the 'what is new' page? Do you mean the page that was created from a proposal I did a few years ago and that now you are using (undisturbed because of the lack of the community and PMC oversight on this) to add ads of your company and (unclear) links to your sites? Here is what I would do there: 1) remove all the references to companies and external sites 2) keep it as a working document (as we are doing) to prepare official what's new pages specific for each release branch 3) add links to these release branch specific what's new pages from the README of the branch, from the OFBiz website etc.. If people want to try it, where should they find the download link? And the trunk demo, how do they find the download link here too? The checkout of source code is not a download and I didn't move the instructions: they are still there and there is a prominent link from the main page. Hans, if you can concentrate it is not that difficult to get: 1) download page isfor officially approved releases only; the releases are served thru the ASF mirrors infrastructure that can *only* serve officially voted releases 2) the source code/svn page is for persons interested in the living versions of svn trunk and branches; we have already good information for this and in fact very few people ask where are the source files? So lets do a voteand see if the removal of the link from the download page was agreed or not. Ok, prepare your proposal and then start the vote thread. Jacopo Hans On 04/07/2012 10:30 PM, Jacopo Cappellato wrote: I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo On Apr 7, 2012, at 12:06 PM, Jacques Le Roux wrote: From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
By the way, an interesting resource is the Release FAQ: http://www.apache.org/dev/release.html I am quoting here a relevant part: = What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. = Jacopo On Apr 7, 2012, at 7:37 PM, Jacques Le Roux wrote: Actually I don't care much. It was mostly to find a consens er... compromise. So I let Hans handles that if he wants (no commits war please)... For those who are relatively new to this ML, we should though explain that recommnending to use trunk to users has been the inclination of OFBiz original creators. At this time it was vital for the project to get more contributions and I must say it's also easier for committers to contribute directly (this is actually not a big deal, a patch is an easy way most of the time). See for instance http://markmail.org/message/ee2mzldkkzg6im5x, the link there is now https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started (BTW this needs certainly an update, but actually all the documentation needs update and pruning). Jacopo was the 1st to propose another way: http://markmail.org/message/vh7jrgmwfmxrd4bh And to clarify my position: I'm supporting releases for a long time now (I mean backporting bugs, sometimes at my expense ;o). Fortunately it turns that it's easier and safer since the R10.04 release. I believe that this new way of doing allows 2 pathes (trunk or releases) and we need both! Hope this summarises well my POV and the situation Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo On Apr 7, 2012, at 12:06 PM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com This is not consensus, it is a compromise. Right What is the purpose of mentioning that we have also a trunk (obvious) To relax each other positions (is that even English? :o). Meant for users for are not acquainted with open source but still potential OFBiz users and what is the text that you would like to add there? Beside the releases you could also go the bleeding edge way [http://en.wikipedia.org/wiki/Bleeding_edge_technology] and check out the trunk from OFBiz repository (Subversion) Depending of the way we prefer to present it, could be also state of art [http://en.wikipedia.org/wiki/State_of_the_art] because trunk is really not that bleeding edge... Jacques Jacopo On Apr 7, 2012, at 11:06 AM, Jacques Le Roux wrote: Maybe, as a consensus, we can put a word about it and not a link? Jacques From: Hans Bakker mailingl...@antwebsystems.com But Apache does not prohibit it? you want to be the best pupil in the Apache school? I still think this is wrong not to mention it. Hans On 04/07/2012 11:38 AM, Jacopo Cappellato wrote: Thank you Hans, the download page is intended to end users and we can't include there links to download code that has not been officially approved; this was an issue we had in the past and the ASF asked us to fix the page in the past. For the trunk all the
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
Hi Jacopo, if that is the case i apologize, we got so far carried away, i lost track completely, that i went back to the original question. Regards, Hans On 04/08/2012 02:45 PM, Jacopo Cappellato wrote: To summarize: you were accusing me and pointing your finger to my commit even if my commit doesn't have anything to do with what you are reporting here. Jacopo On Apr 8, 2012, at 9:03 AM, Hans Bakker wrote: Jacopo, i have a very simple question about a link which always worked: http://ci.apache.org/projects/ofbiz/snapshots/ofbiz-trunk-current.zip It was normally shown on this page: http://ci.apache.org/projects/ofbiz/snapshots/ now it does not work anymore. My point is that this link should be reasonable visible somewhere preferably on the download page. enter ofbiz trunk current zip in google and you will see it is used pretty frequently (3030 times) (it often also points to http://build.ofbiz.org/builds/ofbiz-trunk-current.zip and other links) If you simply not want do do what i asked for is fine. I now ran out of steam finally. :-) Regards, Hans On 04/08/2012 01:03 PM, Jacopo Cappellato wrote: On Apr 8, 2012, at 2:35 AM, Hans Bakker wrote: Jacopo, You removed the trunk download from the download page which was there from the start without trying to get a consensus. What are you talking about? I am shocked about how imprecise but this is blatant is ridiculous: what is the removal you are talking about? I simply added information about the new release schedule. Sure, if everybody thinks that is way to go, than that is it. However i think seeing the the history of OFBiz where the trunk was always very reliable and where problems were always fixed within hours, the trunk is very usable and people selecting the download page should be aware of it. Actually the official Apache pages list this link on the central site. http://projects.apache.org/projects/ofbiz.html So it has nothing to do with Apache policies. Hans, are you serious? Or you really don't understand? We have prominent links (2 of them) to the svn from the main page and we have a full page dedicated to svn instructions: http://ofbiz.apache.org/ https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html and no one would ever think to remove them: svn is essential information to get new contributions. The url to projects.apache.org (that *I* helped to have working on the DOAP file) is a good thing to have because it shows a summary of most relevant resources for OFBiz, including svn. So why not on the OFBiz site? I think it should be there taking the amount of changes that are applied to the trunk, showing the latest version is following the latest internet developments. Further what you are going to do with the 'what is new' page? Do you mean the page that was created from a proposal I did a few years ago and that now you are using (undisturbed because of the lack of the community and PMC oversight on this) to add ads of your company and (unclear) links to your sites? Here is what I would do there: 1) remove all the references to companies and external sites 2) keep it as a working document (as we are doing) to prepare official what's new pages specific for each release branch 3) add links to these release branch specific what's new pages from the README of the branch, from the OFBiz website etc.. If people want to try it, where should they find the download link? And the trunk demo, how do they find the download link here too? The checkout of source code is not a download and I didn't move the instructions: they are still there and there is a prominent link from the main page. Hans, if you can concentrate it is not that difficult to get: 1) download page isfor officially approved releases only; the releases are served thru the ASF mirrors infrastructure that can *only* serve officially voted releases 2) the source code/svn page is for persons interested in the living versions of svn trunk and branches; we have already good information for this and in fact very few people ask where are the source files? So lets do a voteand see if the removal of the link from the download page was agreed or not. Ok, prepare your proposal and then start the vote thread. Jacopo Hans On 04/07/2012 10:30 PM, Jacopo Cappellato wrote: I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo
Re: Move AR and AP web applications our of Accounting into Extras
It is very normal in FICO solutions to have as much as possible a separation of concern implemented. This is applicable with regards to inbound and outbound money flows (AR vs AP), and in and outbound flow of goods (and the valueation thereof in FICO). For that (larger) companies ensure that people involved in AR would not have access to functions in AP. But in more sophisticated ERP solutions that also applicable with the financial aspects of Asset Maint (that OFBiz has in the special purpose application Asset Maint),stock movements, the wages,tax, pensions and soc sec administration of personell , and liquid asset (cash, banks and cc-) administration. All these are normally handled in sub accounting solutions (as are AR and AP, stock) where transactions are registered per identified item (ie the customer, supplier, stock item) and consolidated in transactions entries in the general part of FICO. Regards, Pierre Op 8 april 2012 07:53 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: But for what I understand the AR and AP applications contain alternative screens to the ones in the main accounting application. They are an effort to implement more focused/specific applications versus the more generic accounting application. So, the main accounting application should already contain both the AR/AP features, but some of its screens could serve both. I would be in favor of the removal if we can make sure that all the features that are removed are still available (even if in a more generic way) in the accounting application. Jacopo On Apr 8, 2012, at 1:23 AM, David E Jones wrote: When I first saw the subject I was thinking this as well. I always wondered why those were created as separate applications, perhaps for permission reasons I suppose. In a way they make more sense as part of the accounting webapp instead of in separate ones. -David Pierre Smits wrote: - 1 Accounts payable (AP) and accounts receivable (AP) are together with the ability to process accounting transactions the core ingredients of a good FICO solution. Without both any accountant will state that your accounting solution is worthless. Without both core accounting components you (as a company) would have no overview of money owed to you or that you owe to others. Regards, Pierre Op 7 april 2012 19:41 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: +1 Jacques Anil Patel wrote: Hi, Like lot of other stuff, I think AR and AP applications should be moved out of Ofbiz Accounting component. As such they are special purpose application, but again not core to Ofbiz application framework. I recommend we should relocate AR and AP webapplications out of Ofbiz Accounting to Ofbiz Extras. If we as community agree, I'll put efforts to complete the job. Thanks and Regards Anil Patel HotWax Media Inc
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. Jacopo On Apr 8, 2012, at 10:12 AM, Hans Bakker wrote: The page has a button Download to point a user (developer or not) to the download of ofbiz system files. Trunk should be part of that. Regards, Hans On 04/08/2012 03:06 PM, Jacopo Cappellato wrote: By the way, an interesting resource is the Release FAQ: http://www.apache.org/dev/release.html I am quoting here a relevant part: = What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. = Jacopo On Apr 7, 2012, at 7:37 PM, Jacques Le Roux wrote: Actually I don't care much. It was mostly to find a consens er... compromise. So I let Hans handles that if he wants (no commits war please)... For those who are relatively new to this ML, we should though explain that recommnending to use trunk to users has been the inclination of OFBiz original creators. At this time it was vital for the project to get more contributions and I must say it's also easier for committers to contribute directly (this is actually not a big deal, a patch is an easy way most of the time). See for instance http://markmail.org/message/ee2mzldkkzg6im5x, the link there is now https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started (BTW this needs certainly an update, but actually all the documentation needs update and pruning). Jacopo was the 1st to propose another way: http://markmail.org/message/vh7jrgmwfmxrd4bh And to clarify my position: I'm supporting releases for a long time now (I mean backporting bugs, sometimes at my expense ;o). Fortunately it turns that it's easier and safer since the R10.04 release. I believe that this new way of doing allows 2 pathes (trunk or releases) and we need both! Hope this summarises well my POV and the situation Jacques From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo On Apr 7, 2012, at 12:06 PM, Jacques Le Roux wrote: From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com This is not consensus, it is a compromise. Right What is the purpose of mentioning that we have also a trunk (obvious) To relax each other positions (is that even English? :o). Meant for users for are not acquainted with open source but still potential OFBiz users and what is the text that you would like to add there? Beside the releases you could also go the bleeding edge way [http://en.wikipedia.org/wiki/Bleeding_edge_technology] and check out the trunk from OFBiz repository (Subversion) Depending of the way we prefer to present it, could be also state of art [http://en.wikipedia.org/wiki/State_of_the_art] because trunk is really not that bleeding edge... Jacques Jacopo On Apr 7, 2012, at 11:06 AM, Jacques Le Roux wrote: Maybe, as a consensus, we can put a word about it and not a link? Jacques From: Hans
[jira] [Updated] (OFBIZ-4792) Using GZip compression for js/css files
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4792: --- Priority: Trivial (was: Major) Affects Version/s: (was: Release Branch 11.04) SVN trunk Fix Version/s: (was: Release Branch 11.04) SVN trunk We commit only bug fixes in releases Using GZip compression for js/css files --- Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: ALL APPLICATIONS, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Priority: Trivial Labels: build, features, javascript Fix For: SVN trunk Original Estimate: 72h Remaining Estimate: 72h I was wondering if it is possible to reduce the size of external javascript's/css files being fetched by making use of GZip encoding. The feeding server does understand and responds to GZip encoding, however Ofbiz is not requesting the content in GZip format. Kindly include this feature so that Ofbiz will include the GZip encoding option in the http header while requesting the external javascript file ? Also, if possible integrate the compressor module http://code.google.com/p/yui-compressor-ant-task/ as suggested by Jacques (Jacques Le Roux jacques.le.roux) -- 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: Summary of some recent discussions around the OFBiz release roadmap and some proposals
Wow what a long thread for such a simple issue, thanks for being so patient Jacopo. At the end of the day users simply shouldn't be downloading the trunk, it's intended for OFBiz developers and testers only. To pretend that the trunk is bug free is and all problems are fixed within hours is naive at best and a straight out lie at worst. The trunk also isn't guaranteed to conform to the ASLv2 and at numerous points in the past it hasn't. Continuous deployment from the trunk is a flawed strategy that puts the stability of your system into the hands of a random collection of OFBiz committers of varying quality, how that makes good business sense to anyone is beyond me. Regards Scott On 8/04/2012, at 8:31 PM, Jacopo Cappellato wrote: Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. Jacopo On Apr 8, 2012, at 10:12 AM, Hans Bakker wrote: The page has a button Download to point a user (developer or not) to the download of ofbiz system files. Trunk should be part of that. Regards, Hans On 04/08/2012 03:06 PM, Jacopo Cappellato wrote: By the way, an interesting resource is the Release FAQ: http://www.apache.org/dev/release.html I am quoting here a relevant part: = What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. = Jacopo On Apr 7, 2012, at 7:37 PM, Jacques Le Roux wrote: Actually I don't care much. It was mostly to find a consens er... compromise. So I let Hans handles that if he wants (no commits war please)... For those who are relatively new to this ML, we should though explain that recommnending to use trunk to users has been the inclination of OFBiz original creators. At this time it was vital for the project to get more contributions and I must say it's also easier for committers to contribute directly (this is actually not a big deal, a patch is an easy way most of the time). See for instance http://markmail.org/message/ee2mzldkkzg6im5x, the link there is now https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started (BTW this needs certainly an update, but actually all the documentation needs update and pruning). Jacopo was the 1st to propose another way: http://markmail.org/message/vh7jrgmwfmxrd4bh And to clarify my position: I'm supporting releases for a long time now (I mean backporting bugs, sometimes at my expense ;o). Fortunately it turns that it's easier and safer since the R10.04 release. I believe that this new way of doing allows 2 pathes (trunk or releases) and we need both! Hope this summarises well my POV and the situation Jacques From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't have the skills, the power, the merit to rule us (not to mention me); he did it in the past just because we let him do this. Now, if you and Hans feel that we should add a sentence about the trunk in the download page, please provide a valid motivation and a valid text, then start a vote: if the community will vote in favor of it I will be happy to accept and implement accordingly; otherwise I will not waste more of my time discussing this just to please Hans. Jacopo On Apr 7, 2012, at 12:06 PM, Jacques Le Roux wrote: From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com This is not consensus, it is a compromise. Right What is the purpose of mentioning that we have also a trunk
Re: OFBiz slimdown jira
Hi Jacopo, Currently following releases are identified on the web page (with their respective target dates): - April 2012 - Apache OFBiz 10.04.02 - October 2012 - Apache OFBiz 10.04.03 - April 2013 - Apache OFBiz 10.04.04 (last release of the 10.04 series) Tentative release schedule for the 11.04 series: - May 2012 - Apache OFBiz 11.04.01 - September 2012 - Apache OFBiz 11.04.02 - March 2013 - Apache OFBiz 11.04.03 - September 2013 - Apache OFBiz 11.04.04 - April 2014 - Apache OFBiz 11.04.05 (last release of the 11.04 series) Tentative release schedule for the 12.04 series: - April 2012 - creation of the release branch for 12.04 (this is not a release yet) - February 2013 - Apache OFBiz 12.04.01 - August 2013 - Apache OFBiz 12.04.02 - March 2014 - Apache OFBiz 12.04.03 - September 2014 - Apache OFBiz 12.04.04 - April 2015 - Apache OFBiz 12.04.05 (last release of the 12.04 series) So I would say that all intended releases with a future date should be registered in JIRA (with the date set). That will help us ddevelopers (and committers) to focus on delivering the best release possible each time. And it will help use generate a more detailed 'end-of-month report. It helps with timing the issue, and thus communication. But developers and committers should be aware of the fact that it doesn't make sense to allocate JIRA issues tot more than 1 version/release, meaning, that setting the fix version of an issue to e.g. 12.04.01 also implies that it is applicable to 12.04.02. Thus, when the first release date of a version draws near, we can release that version when no blockers or other critical issues are present and others (still not fixed issues) can move to the next release. Regards, Pierre Op 8 april 2012 08:01 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi Pierre, now that we have a tentative release plan: http://ofbiz.apache.org/download.html it would be easy to setup in Jira versions for upcoming releases (with a release date); at the moment we could add: 10.04.02 with release date 2012-04-30 11.04.01 with release date 2012-05-31 Does it sound good? Jacopo On Apr 7, 2012, at 11:19 AM, Pierre Smits wrote: Hi Jacopo, May I suggest to set a target date for this and the other releases intended for the near future (ie 09.04.02, 10.04.02, 11.x, 12.x). This will help us to better identify issues which we intend to address per release. But it also helps us communicate to the communty, than repeat over and over in the mailing lists. Regards, Pierre Op 5 april 2012 21:23 schreef Erwan de FERRIERES erwan.de-ferrie...@nereide.fr het volgende: Le 05/04/2012 10:26, Jacopo Cappellato a écrit : Yeah, I think it is now time to start the process, thank you Erwan. I have created the new version with name SlimDown (if a better name will be suggested we will change it); now we can create the tasks for the agreed upon decisions so far and use the Fix Version/s field to associate them to the roadmap. Jacopo Thanks Jacopo, now let's work ! On Apr 5, 2012, at 10:00 AM, Erwan de FERRIERES wrote: Hi Jacopo, do we have a better name for the Jira version than slimdown ? And would it be possible to create the jira version, so we can start on creating the tasks ? Cheers, -- Erwan de FERRIERES -- Erwan de FERRIERES www.nereide.biz
[jira] [Updated] (OFBIZ-4793) unify admin port and key setting: single point of definition in start.properties
[ https://issues.apache.org/jira/browse/OFBIZ-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis ANDRE updated OFBIZ-4793: - Attachment: ofbiz-admin-port.patch unify admin port and key setting: single point of definition in start.properties Key: OFBIZ-4793 URL: https://issues.apache.org/jira/browse/OFBIZ-4793 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: WXP SP3 Sun SDK 1.6.0_30 Reporter: Francis ANDRE Priority: Minor Attachments: ofbiz-admin-port.patch Hi If someone wants to change the admin password or port, he would have to change currently many files (-- build.xml, various .bat and .sh --). In order to avoid this error-prone pratice, I suggest to centralize the definition of the admin kay and port at 2 single points: the framework/start/src/org/ofbiz/base/start/start.properties and the framework/start/src/org/ofbiz/base/start/jetty.properties Rgds -- 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-4793) unify admin port and key setting: single point of definition in start.properties
unify admin port and key setting: single point of definition in start.properties Key: OFBIZ-4793 URL: https://issues.apache.org/jira/browse/OFBIZ-4793 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: WXP SP3 Sun SDK 1.6.0_30 Reporter: Francis ANDRE Priority: Minor Attachments: ofbiz-admin-port.patch Hi If someone wants to change the admin password or port, he would have to change currently many files (-- build.xml, various .bat and .sh --). In order to avoid this error-prone pratice, I suggest to centralize the definition of the admin kay and port at 2 single points: the framework/start/src/org/ofbiz/base/start/start.properties and the framework/start/src/org/ofbiz/base/start/jetty.properties Rgds -- 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: // TODO: Remove this block after the next release 2010-11-29
The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
Re: OFBiz slimdown jira
Hi Pierre, I understand what you propose and it makes sense; I am onlya bit worried about the confusion of having tom many versions in Jira. For example, if a bug fix is provided for the 10.04 series, then it should be most likely planned to be included in the upcoming release 10.04.02; I don't see a benefit of having also 10.04.03, 10.04.04, 10.04.05 in Jira. We could instead create 10.04.03 when 10.04.02 is released. But I don't have a strong opinion on this; but before creating new versions in Jira I would like to get also the point of view of others. Thanks, Jacopo On Apr 8, 2012, at 10:56 AM, Pierre Smits wrote: Hi Jacopo, Currently following releases are identified on the web page (with their respective target dates): - April 2012 - Apache OFBiz 10.04.02 - October 2012 - Apache OFBiz 10.04.03 - April 2013 - Apache OFBiz 10.04.04 (last release of the 10.04 series) Tentative release schedule for the 11.04 series: - May 2012 - Apache OFBiz 11.04.01 - September 2012 - Apache OFBiz 11.04.02 - March 2013 - Apache OFBiz 11.04.03 - September 2013 - Apache OFBiz 11.04.04 - April 2014 - Apache OFBiz 11.04.05 (last release of the 11.04 series) Tentative release schedule for the 12.04 series: - April 2012 - creation of the release branch for 12.04 (this is not a release yet) - February 2013 - Apache OFBiz 12.04.01 - August 2013 - Apache OFBiz 12.04.02 - March 2014 - Apache OFBiz 12.04.03 - September 2014 - Apache OFBiz 12.04.04 - April 2015 - Apache OFBiz 12.04.05 (last release of the 12.04 series) So I would say that all intended releases with a future date should be registered in JIRA (with the date set). That will help us ddevelopers (and committers) to focus on delivering the best release possible each time. And it will help use generate a more detailed 'end-of-month report. It helps with timing the issue, and thus communication. But developers and committers should be aware of the fact that it doesn't make sense to allocate JIRA issues tot more than 1 version/release, meaning, that setting the fix version of an issue to e.g. 12.04.01 also implies that it is applicable to 12.04.02. Thus, when the first release date of a version draws near, we can release that version when no blockers or other critical issues are present and others (still not fixed issues) can move to the next release. Regards, Pierre Op 8 april 2012 08:01 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi Pierre, now that we have a tentative release plan: http://ofbiz.apache.org/download.html it would be easy to setup in Jira versions for upcoming releases (with a release date); at the moment we could add: 10.04.02 with release date 2012-04-30 11.04.01 with release date 2012-05-31 Does it sound good? Jacopo On Apr 7, 2012, at 11:19 AM, Pierre Smits wrote: Hi Jacopo, May I suggest to set a target date for this and the other releases intended for the near future (ie 09.04.02, 10.04.02, 11.x, 12.x). This will help us to better identify issues which we intend to address per release. But it also helps us communicate to the communty, than repeat over and over in the mailing lists. Regards, Pierre Op 5 april 2012 21:23 schreef Erwan de FERRIERES erwan.de-ferrie...@nereide.fr het volgende: Le 05/04/2012 10:26, Jacopo Cappellato a écrit : Yeah, I think it is now time to start the process, thank you Erwan. I have created the new version with name SlimDown (if a better name will be suggested we will change it); now we can create the tasks for the agreed upon decisions so far and use the Fix Version/s field to associate them to the roadmap. Jacopo Thanks Jacopo, now let's work ! On Apr 5, 2012, at 10:00 AM, Erwan de FERRIERES wrote: Hi Jacopo, do we have a better name for the Jira version than slimdown ? And would it be possible to create the jira version, so we can start on creating the tasks ? Cheers, -- Erwan de FERRIERES -- Erwan de FERRIERES www.nereide.biz
[jira] [Commented] (OFBIZ-4792) Using GZip compression for js/css files
[
https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249504#comment-13249504
]
Jacques Le Roux commented on OFBIZ-4792:
You are missing a point Mandeep.
OFBiz is already compressing text files. This is done through the embedded
Tomcat. See in ofbiz-containers.xml
{code}
property name=compressableMimeType value=text/html,text/xml,text/plain/
property name=compression value=on/
{code}
Reference: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
So my proposition was only to add an yui-compressor-ant-task to compress those
files as described here http://developer.yahoo.com/yui/compressor/
Using GZip compression for js/css files
---
Key: OFBIZ-4792
URL: https://issues.apache.org/jira/browse/OFBIZ-4792
Project: OFBiz
Issue Type: New Feature
Components: ALL APPLICATIONS, specialpurpose/ecommerce
Affects Versions: SVN trunk
Environment: Windows/Linux
Reporter: Mandeep Sidhu
Priority: Trivial
Labels: build, compression, features, javascript
Fix For: SVN trunk
Original Estimate: 72h
Remaining Estimate: 72h
I was wondering if it is possible to reduce the size of external
javascript's/css files being fetched by making use of GZip encoding.
The feeding server does understand and responds to GZip encoding, however
Ofbiz is not requesting the content in GZip format.
Kindly include this feature so that Ofbiz will include the GZip encoding
option in the http header while requesting the external javascript file ?
Also, if possible integrate the compressor module
http://code.google.com/p/yui-compressor-ant-task/
as suggested by Jacques (Jacques Le Roux jacques.le.roux)
--
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] [Commented] (OFBIZ-4792) Using GZip compression for js/css files
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249505#comment-13249505 ] Jacques Le Roux commented on OFBIZ-4792: Note that for bigest files we already use compressed versions (ending by min.js, see framework/common/widget/CommonScreens.xml) Using GZip compression for js/css files --- Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: ALL APPLICATIONS, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Priority: Trivial Labels: build, compression, features, javascript Fix For: SVN trunk Original Estimate: 72h Remaining Estimate: 72h I was wondering if it is possible to reduce the size of external javascript's/css files being fetched by making use of GZip encoding. The feeding server does understand and responds to GZip encoding, however Ofbiz is not requesting the content in GZip format. Kindly include this feature so that Ofbiz will include the GZip encoding option in the http header while requesting the external javascript file ? Also, if possible integrate the compressor module http://code.google.com/p/yui-compressor-ant-task/ as suggested by Jacques (Jacques Le Roux jacques.le.roux) -- 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] [Commented] (OFBIZ-4792) Using GZip compression for js/css files
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249506#comment-13249506 ] Jacques Le Roux commented on OFBIZ-4792: and specialpurpose/ecommerce/widget/CommonScreens.xml Using GZip compression for js/css files --- Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: ALL APPLICATIONS, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Priority: Trivial Labels: build, compression, features, javascript Fix For: SVN trunk Original Estimate: 72h Remaining Estimate: 72h I was wondering if it is possible to reduce the size of external javascript's/css files being fetched by making use of GZip encoding. The feeding server does understand and responds to GZip encoding, however Ofbiz is not requesting the content in GZip format. Kindly include this feature so that Ofbiz will include the GZip encoding option in the http header while requesting the external javascript file ? Also, if possible integrate the compressor module http://code.google.com/p/yui-compressor-ant-task/ as suggested by Jacques (Jacques Le Roux jacques.le.roux) -- 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-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4792: --- Component/s: (was: ALL APPLICATIONS) (was: specialpurpose/ecommerce) framework Description: The idea is to create an ant task using [yui-compressor-ant-task|http://code.google.com/p/yui-compressor-ant-task/]to dynamically compress our own js and css files (most of the bigest external ones are already compressed) was: I was wondering if it is possible to reduce the size of external javascript's/css files being fetched by making use of GZip encoding. The feeding server does understand and responds to GZip encoding, however Ofbiz is not requesting the content in GZip format. Kindly include this feature so that Ofbiz will include the GZip encoding option in the http header while requesting the external javascript file ? Also, if possible integrate the compressor module http://code.google.com/p/yui-compressor-ant-task/ as suggested by Jacques (Jacques Le Roux jacques.le.roux) Labels: build compression css features javascript (was: build compression features javascript) Remaining Estimate: (was: 72h) Original Estimate: (was: 72h) Summary: Add a yui-compressor-ant-task (was: Using GZip compression for js/css files) I changed the description and removed the estimate Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task using [yui-compressor-ant-task|http://code.google.com/p/yui-compressor-ant-task/]to dynamically compress our own js and css files (most of the bigest external ones are already compressed) -- 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: Summary of some recent discussions around the OFBiz release roadmap and some proposals
Hi All, I think it is very unwise to let endusers use the most disruptive version available (the trunk) for evaluation purposes. It should only be available for developers or other, more technically experienced persons who want to assess the underlying (technical) implementations. We have both communications in place. At the right places in the site. The statement the trunk is bug free is and all problems are fixed within hours not only misleads the enduser, but it also puts an enormous pressure on developers and committers. Plus, it might lead to the ASF being liable for not delivering. Regards, Pierre Op 8 april 2012 10:55 schreef Scott Gray scott.g...@hotwaxmedia.com het volgende: Wow what a long thread for such a simple issue, thanks for being so patient Jacopo. At the end of the day users simply shouldn't be downloading the trunk, it's intended for OFBiz developers and testers only. To pretend that the trunk is bug free is and all problems are fixed within hours is naive at best and a straight out lie at worst. The trunk also isn't guaranteed to conform to the ASLv2 and at numerous points in the past it hasn't. Continuous deployment from the trunk is a flawed strategy that puts the stability of your system into the hands of a random collection of OFBiz committers of varying quality, how that makes good business sense to anyone is beyond me. Regards Scott On 8/04/2012, at 8:31 PM, Jacopo Cappellato wrote: Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. Jacopo On Apr 8, 2012, at 10:12 AM, Hans Bakker wrote: The page has a button Download to point a user (developer or not) to the download of ofbiz system files. Trunk should be part of that. Regards, Hans On 04/08/2012 03:06 PM, Jacopo Cappellato wrote: By the way, an interesting resource is the Release FAQ: http://www.apache.org/dev/release.html I am quoting here a relevant part: = What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. = Jacopo On Apr 7, 2012, at 7:37 PM, Jacques Le Roux wrote: Actually I don't care much. It was mostly to find a consens er... compromise. So I let Hans handles that if he wants (no commits war please)... For those who are relatively new to this ML, we should though explain that recommnending to use trunk to users has been the inclination of OFBiz original creators. At this time it was vital for the project to get more contributions and I must say it's also easier for committers to contribute directly (this is actually not a big deal, a patch is an easy way most of the time). See for instance http://markmail.org/message/ee2mzldkkzg6im5x, the link there is now https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started(BTW this needs certainly an update, but actually all the documentation needs update and pruning). Jacopo was the 1st to propose another way: http://markmail.org/message/vh7jrgmwfmxrd4bh And to clarify my position: I'm supporting releases for a long time now (I mean backporting bugs, sometimes at my expense ;o). Fortunately it turns that it's easier and safer since the R10.04 release. I believe that this new way of doing allows 2 pathes (trunk or releases) and we need both! Hope this summarises well my POV and the situation Jacques From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases him, he doesn't
[jira] [Updated] (OFBIZ-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4792: --- Description: The idea is to create an ant task using [yui-compressor-ant-task|http://code.google.com/p/yui-compressor-ant-task/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) was: The idea is to create an ant task using [yui-compressor-ant-task|http://code.google.com/p/yui-compressor-ant-task/]to dynamically compress our own js and css files (most of the bigest external ones are already compressed) Fixes typos in description Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task using [yui-compressor-ant-task|http://code.google.com/p/yui-compressor-ant-task/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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: OFBiz slimdown jira
Hi Jacopo, I agree with you that it doesn't make sense to communicate to many releases. It creates expectations with end uses, it might create confusion with reporters of issues and puts developers and committers under pressure. That is why in other projects, where proper change management and release management is implemented, only the releases in the nearest overseeable timeframe are made visible (mostly 2 for the upcoming year - depending on the capabilities of the development organization) and as soon as the first is released the one after the next is registered. Bringing this to what has been communicated on the website I would say the upcoming schedule in JIRA should be: For maintenance schedule 10.04: - 10.04.02 - due date 2012-04-30 - 10.04.03 - due date 2012-10-31 And when 10.04.02 is released create 10.04.04 For maintenance schedule 11.04: - 11.04.01 - due date 2012-05-31 - 11.04.02 - due date 2012-09-30 For upcoming release and maintenance schedule 12.04 - 12.04.01 - due date 2012-04-30 And as soon as it is released create 12.04.02 All in accordance what is already communicated. But of course, we must do what works best for us. Regards, Pierre Op 8 april 2012 11:05 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi Pierre, I understand what you propose and it makes sense; I am onlya bit worried about the confusion of having tom many versions in Jira. For example, if a bug fix is provided for the 10.04 series, then it should be most likely planned to be included in the upcoming release 10.04.02; I don't see a benefit of having also 10.04.03, 10.04.04, 10.04.05 in Jira. We could instead create 10.04.03 when 10.04.02 is released. But I don't have a strong opinion on this; but before creating new versions in Jira I would like to get also the point of view of others. Thanks, Jacopo On Apr 8, 2012, at 10:56 AM, Pierre Smits wrote: Hi Jacopo, Currently following releases are identified on the web page (with their respective target dates): - April 2012 - Apache OFBiz 10.04.02 - October 2012 - Apache OFBiz 10.04.03 - April 2013 - Apache OFBiz 10.04.04 (last release of the 10.04 series) Tentative release schedule for the 11.04 series: - May 2012 - Apache OFBiz 11.04.01 - September 2012 - Apache OFBiz 11.04.02 - March 2013 - Apache OFBiz 11.04.03 - September 2013 - Apache OFBiz 11.04.04 - April 2014 - Apache OFBiz 11.04.05 (last release of the 11.04 series) Tentative release schedule for the 12.04 series: - April 2012 - creation of the release branch for 12.04 (this is not a release yet) - February 2013 - Apache OFBiz 12.04.01 - August 2013 - Apache OFBiz 12.04.02 - March 2014 - Apache OFBiz 12.04.03 - September 2014 - Apache OFBiz 12.04.04 - April 2015 - Apache OFBiz 12.04.05 (last release of the 12.04 series) So I would say that all intended releases with a future date should be registered in JIRA (with the date set). That will help us ddevelopers (and committers) to focus on delivering the best release possible each time. And it will help use generate a more detailed 'end-of-month report. It helps with timing the issue, and thus communication. But developers and committers should be aware of the fact that it doesn't make sense to allocate JIRA issues tot more than 1 version/release, meaning, that setting the fix version of an issue to e.g. 12.04.01 also implies that it is applicable to 12.04.02. Thus, when the first release date of a version draws near, we can release that version when no blockers or other critical issues are present and others (still not fixed issues) can move to the next release. Regards, Pierre Op 8 april 2012 08:01 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi Pierre, now that we have a tentative release plan: http://ofbiz.apache.org/download.html it would be easy to setup in Jira versions for upcoming releases (with a release date); at the moment we could add: 10.04.02 with release date 2012-04-30 11.04.01 with release date 2012-05-31 Does it sound good? Jacopo On Apr 7, 2012, at 11:19 AM, Pierre Smits wrote: Hi Jacopo, May I suggest to set a target date for this and the other releases intended for the near future (ie 09.04.02, 10.04.02, 11.x, 12.x). This will help us to better identify issues which we intend to address per release. But it also helps us communicate to the communty, than repeat over and over in the mailing lists. Regards, Pierre Op 5 april 2012 21:23 schreef Erwan de FERRIERES erwan.de-ferrie...@nereide.fr het volgende: Le 05/04/2012 10:26, Jacopo Cappellato a écrit : Yeah, I think it is now time to start the process, thank you Erwan. I have created the new version with name SlimDown (if a better name will be suggested we will change
Re: Using GZip compression for js files in Ecommerce module
Hi all,
I don't know having this in OFBiz affects performance when OFBiz is behind
a webserver (like Apache HTTP) via normal proxy processes or via ajp, which
are standard scenarios in in a multi-tier, high availability/failover setup.
Regards,
Op 8 april 2012 11:13 schreef Jacques Le Roux
jacques.le.r...@les7arts.comhet volgende:
You are missing a point Mandeep.
OFBiz is already compressing text files. This is done through the embedded
Tomcat. See in ofbiz-containers.xml
{code}
property name=compressableMimeType value=text/html,text/xml,**
text/plain/
property name=compression value=on/
{code}
Reference:
http://tomcat.apache.org/**tomcat-7.0-doc/config/http.**htmlhttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html
So my proposition was only to add an yui-compressor-ant-task to compress
js/css files as described here
http://developer.yahoo.com/**yui/compressor/http://developer.yahoo.com/yui/compressor/
Note that for bigest files we already use compressed versions (ending by
min.js, see framework/common/widget/**CommonScreens.xml and
specialpurpose/ecommerce/**widget/CommonScreens.xml)
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
created Jira 4792
https://issues.apache.org/**jira/browse/OFBIZ-4792https://issues.apache.org/jira/browse/OFBIZ-4792
but still this will only compress the files Jacques, what if the
application is consuming external jss/css files, if the remote server has
the capability to server GZip encoded content to the requesting client,
we'd need to send the GZip encoding option in the http header for which I
believe Ofbiz needs to be touched.
Correct me if I am wrong.
Regards,
Mandeep Sidhu
On Sun, Apr 8, 2012 at 11:21 AM, Jacques Le Roux
jacques.le.r...@les7arts.com wrote:
I'd suggest to do it also for css
http://code.google.com/p/yui-http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-compressor-ant-task/
You could create a Jira and contribute https://cwiki.apache.org/**
confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
https://cwiki.**apache.org/confluence/display/**
OFBADMIN/OFBiz+Contributors+**Best+Practiceshttps://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
,
this
would be appreciated of course, not only for eCommerce BTW...
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
Hi,
I was wondering if it is possible to reduce the size of external
javascript's being fetched by making use of GZip encoding.
The feeding server does understand and responds to GZip encoding,
however
Ofbiz is not requesting the content in GZip format.
Can anybody please guide me as to what all modifications I need to make
so
that Ofbiz will include the GZip encoding option in the http header
while
requesting the external javascript file ?
Regards,
Mandeeep Sidhu
--
Mandeep Singh Sidhu
Re: ports in test-containers.xml
I will create a JIRA for this, But for testing what port numbers will we have for: - ajp - http - https - others? Regards, Pierre Op 8 april 2012 07:54 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: +1 On May 13, 2011, at 3:23 PM, Erwan de FERRIERES wrote: Hi all, I'm planning on changing the ports for the http and https test containers. This way, tests can be runned on the Apache jenkins instance (8080 is already used). Is there anyone against these ? Cheers, -- Erwan de FERRIERES www.nereide.biz
[jira] [Created] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Fix For: SVN trunk In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- 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: // TODO: Remove this block after the next release 2010-11-29
Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev Whay did you not remove it? Is there a reason or only an oversight? Is it the only thing to do? What about @Deprecated processEventReminder method? Should we keep EventReminders.properties file, etc. ? Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
Re: OFBiz slimdown jira
I agree with Jacopo, KISS please, we have already enough work... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi Pierre, I understand what you propose and it makes sense; I am onlya bit worried about the confusion of having tom many versions in Jira. For example, if a bug fix is provided for the 10.04 series, then it should be most likely planned to be included in the upcoming release 10.04.02; I don't see a benefit of having also 10.04.03, 10.04.04, 10.04.05 in Jira. We could instead create 10.04.03 when 10.04.02 is released. But I don't have a strong opinion on this; but before creating new versions in Jira I would like to get also the point of view of others. Thanks, Jacopo On Apr 8, 2012, at 10:56 AM, Pierre Smits wrote: Hi Jacopo, Currently following releases are identified on the web page (with their respective target dates): - April 2012 - Apache OFBiz 10.04.02 - October 2012 - Apache OFBiz 10.04.03 - April 2013 - Apache OFBiz 10.04.04 (last release of the 10.04 series) Tentative release schedule for the 11.04 series: - May 2012 - Apache OFBiz 11.04.01 - September 2012 - Apache OFBiz 11.04.02 - March 2013 - Apache OFBiz 11.04.03 - September 2013 - Apache OFBiz 11.04.04 - April 2014 - Apache OFBiz 11.04.05 (last release of the 11.04 series) Tentative release schedule for the 12.04 series: - April 2012 - creation of the release branch for 12.04 (this is not a release yet) - February 2013 - Apache OFBiz 12.04.01 - August 2013 - Apache OFBiz 12.04.02 - March 2014 - Apache OFBiz 12.04.03 - September 2014 - Apache OFBiz 12.04.04 - April 2015 - Apache OFBiz 12.04.05 (last release of the 12.04 series) So I would say that all intended releases with a future date should be registered in JIRA (with the date set). That will help us ddevelopers (and committers) to focus on delivering the best release possible each time. And it will help use generate a more detailed 'end-of-month report. It helps with timing the issue, and thus communication. But developers and committers should be aware of the fact that it doesn't make sense to allocate JIRA issues tot more than 1 version/release, meaning, that setting the fix version of an issue to e.g. 12.04.01 also implies that it is applicable to 12.04.02. Thus, when the first release date of a version draws near, we can release that version when no blockers or other critical issues are present and others (still not fixed issues) can move to the next release. Regards, Pierre Op 8 april 2012 08:01 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi Pierre, now that we have a tentative release plan: http://ofbiz.apache.org/download.html it would be easy to setup in Jira versions for upcoming releases (with a release date); at the moment we could add: 10.04.02 with release date 2012-04-30 11.04.01 with release date 2012-05-31 Does it sound good? Jacopo On Apr 7, 2012, at 11:19 AM, Pierre Smits wrote: Hi Jacopo, May I suggest to set a target date for this and the other releases intended for the near future (ie 09.04.02, 10.04.02, 11.x, 12.x). This will help us to better identify issues which we intend to address per release. But it also helps us communicate to the communty, than repeat over and over in the mailing lists. Regards, Pierre Op 5 april 2012 21:23 schreef Erwan de FERRIERES erwan.de-ferrie...@nereide.fr het volgende: Le 05/04/2012 10:26, Jacopo Cappellato a écrit : Yeah, I think it is now time to start the process, thank you Erwan. I have created the new version with name SlimDown (if a better name will be suggested we will change it); now we can create the tasks for the agreed upon decisions so far and use the Fix Version/s field to associate them to the roadmap. Jacopo Thanks Jacopo, now let's work ! On Apr 5, 2012, at 10:00 AM, Erwan de FERRIERES wrote: Hi Jacopo, do we have a better name for the Jira version than slimdown ? And would it be possible to create the jira version, so we can start on creating the tasks ? Cheers, -- Erwan de FERRIERES -- Erwan de FERRIERES www.nereide.biz
Re: OFBiz slimdown jira
I would prefer a category for each major release number. The revision or minor release number can be specified in each issue. -Adrian On 4/8/2012 10:05 AM, Jacopo Cappellato wrote: Hi Pierre, I understand what you propose and it makes sense; I am onlya bit worried about the confusion of having tom many versions in Jira. For example, if a bug fix is provided for the 10.04 series, then it should be most likely planned to be included in the upcoming release 10.04.02; I don't see a benefit of having also 10.04.03, 10.04.04, 10.04.05 in Jira. We could instead create 10.04.03 when 10.04.02 is released. But I don't have a strong opinion on this; but before creating new versions in Jira I would like to get also the point of view of others. Thanks, Jacopo On Apr 8, 2012, at 10:56 AM, Pierre Smits wrote: Hi Jacopo, Currently following releases are identified on the web page (with their respective target dates): - April 2012 - Apache OFBiz 10.04.02 - October 2012 - Apache OFBiz 10.04.03 - April 2013 - Apache OFBiz 10.04.04 (last release of the 10.04 series) Tentative release schedule for the 11.04 series: - May 2012 - Apache OFBiz 11.04.01 - September 2012 - Apache OFBiz 11.04.02 - March 2013 - Apache OFBiz 11.04.03 - September 2013 - Apache OFBiz 11.04.04 - April 2014 - Apache OFBiz 11.04.05 (last release of the 11.04 series) Tentative release schedule for the 12.04 series: - April 2012 - creation of the release branch for 12.04 (this is not a release yet) - February 2013 - Apache OFBiz 12.04.01 - August 2013 - Apache OFBiz 12.04.02 - March 2014 - Apache OFBiz 12.04.03 - September 2014 - Apache OFBiz 12.04.04 - April 2015 - Apache OFBiz 12.04.05 (last release of the 12.04 series) So I would say that all intended releases with a future date should be registered in JIRA (with the date set). That will help us ddevelopers (and committers) to focus on delivering the best release possible each time. And it will help use generate a more detailed 'end-of-month report. It helps with timing the issue, and thus communication. But developers and committers should be aware of the fact that it doesn't make sense to allocate JIRA issues tot more than 1 version/release, meaning, that setting the fix version of an issue to e.g. 12.04.01 also implies that it is applicable to 12.04.02. Thus, when the first release date of a version draws near, we can release that version when no blockers or other critical issues are present and others (still not fixed issues) can move to the next release. Regards, Pierre Op 8 april 2012 08:01 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Hi Pierre, now that we have a tentative release plan: http://ofbiz.apache.org/download.html it would be easy to setup in Jira versions for upcoming releases (with a release date); at the moment we could add: 10.04.02 with release date 2012-04-30 11.04.01 with release date 2012-05-31 Does it sound good? Jacopo On Apr 7, 2012, at 11:19 AM, Pierre Smits wrote: Hi Jacopo, May I suggest to set a target date for this and the other releases intended for the near future (ie 09.04.02, 10.04.02, 11.x, 12.x). This will help us to better identify issues which we intend to address per release. But it also helps us communicate to the communty, than repeat over and over in the mailing lists. Regards, Pierre Op 5 april 2012 21:23 schreef Erwan de FERRIERES erwan.de-ferrie...@nereide.fr het volgende: Le 05/04/2012 10:26, Jacopo Cappellato a écrit : Yeah, I think it is now time to start the process, thank you Erwan. I have created the new version with name SlimDown (if a better name will be suggested we will change it); now we can create the tasks for the agreed upon decisions so far and use the Fix Version/s field to associate them to the roadmap. Jacopo Thanks Jacopo, now let's work ! On Apr 5, 2012, at 10:00 AM, Erwan de FERRIERES wrote: Hi Jacopo, do we have a better name for the Jira version than slimdown ? And would it be possible to create the jira version, so we can start on creating the tasks ? Cheers, -- Erwan de FERRIERES -- Erwan de FERRIERES www.nereide.biz
Re: ports in test-containers.xml
I suggest to increase by one the last ports numbers to avoid collission even when shifted (see below) for instance RMI = 1099+1 = 1100 - ajp 8009+1 = 8010 etc. Because I already suggested to follow Geronimo's way in OFBiz integration in Apache sonar instance thread Geronimo does this. They pass a value through their scripts. It should not be too hard to copy/adapt. Of course it should be used not only for the test-container files but with all containers files. Then it will be easy and clean to change the ports for an instance. The idea is to pass a shift value to all ports, rather than a value for each ports. For instance 1 means 18080, 18443, 11099, etc.; 2 means 28080, 28443, 21099 http://markmail.org/message/mgmhrqchjjmo776q Erwan opened https://issues.apache.org/jira/browse/OFBIZ-4763 for that Jacques From: Pierre Smits pierre.sm...@gmail.com I will create a JIRA for this, But for testing what port numbers will we have for: - ajp - http - https - others? Regards, Pierre Op 8 april 2012 07:54 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: +1 On May 13, 2011, at 3:23 PM, Erwan de FERRIERES wrote: Hi all, I'm planning on changing the ports for the http and https test containers. This way, tests can be runned on the Apache jenkins instance (8080 is already used). Is there anyone against these ? Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: Using GZip compression for js files in Ecommerce module
You can also use mod_proxy + mod_deflate to do that but why do it since it's
already included in OFBiz (same with nginx, etc.)?
So no, I don't think it adds any performance impact if you don't use
mod_deflate and I believe it should be very minor if ever you
do it twice (but again don't do it ;o)
Jacques
From: Pierre Smits pierre.sm...@gmail.com
Hi all,
I don't know having this in OFBiz affects performance when OFBiz is behind
a webserver (like Apache HTTP) via normal proxy processes or via ajp, which
are standard scenarios in in a multi-tier, high availability/failover setup.
Regards,
Op 8 april 2012 11:13 schreef Jacques Le Roux
jacques.le.r...@les7arts.comhet volgende:
You are missing a point Mandeep.
OFBiz is already compressing text files. This is done through the embedded
Tomcat. See in ofbiz-containers.xml
{code}
property name=compressableMimeType value=text/html,text/xml,**
text/plain/
property name=compression value=on/
{code}
Reference:
http://tomcat.apache.org/**tomcat-7.0-doc/config/http.**htmlhttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html
So my proposition was only to add an yui-compressor-ant-task to compress
js/css files as described here
http://developer.yahoo.com/**yui/compressor/http://developer.yahoo.com/yui/compressor/
Note that for bigest files we already use compressed versions (ending by
min.js, see framework/common/widget/**CommonScreens.xml and
specialpurpose/ecommerce/**widget/CommonScreens.xml)
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
created Jira 4792
https://issues.apache.org/**jira/browse/OFBIZ-4792https://issues.apache.org/jira/browse/OFBIZ-4792
but still this will only compress the files Jacques, what if the
application is consuming external jss/css files, if the remote server has
the capability to server GZip encoded content to the requesting client,
we'd need to send the GZip encoding option in the http header for which I
believe Ofbiz needs to be touched.
Correct me if I am wrong.
Regards,
Mandeep Sidhu
On Sun, Apr 8, 2012 at 11:21 AM, Jacques Le Roux
jacques.le.r...@les7arts.com wrote:
I'd suggest to do it also for css
http://code.google.com/p/yui-http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-compressor-ant-task/
You could create a Jira and contribute https://cwiki.apache.org/**
confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
https://cwiki.**apache.org/confluence/display/**
OFBADMIN/OFBiz+Contributors+**Best+Practiceshttps://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
,
this
would be appreciated of course, not only for eCommerce BTW...
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
Hi,
I was wondering if it is possible to reduce the size of external
javascript's being fetched by making use of GZip encoding.
The feeding server does understand and responds to GZip encoding,
however
Ofbiz is not requesting the content in GZip format.
Can anybody please guide me as to what all modifications I need to make
so
that Ofbiz will include the GZip encoding option in the http header
while
requesting the external javascript file ?
Regards,
Mandeeep Sidhu
--
Mandeep Singh Sidhu
Re: // TODO: Remove this block after the next release 2010-11-29
Hi Jaques, All the answers are pretty obvious (to me at least) after a minute's look at the commit, but I'll humor you anyway. On 8/04/2012, at 10:08 PM, Jacques Le Roux wrote: Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev What did you not remove it? I figured it would be nicer for users if we waited until after a release. Is there a reason or only an oversight? Do you mean why haven't I removed it after the 11.04 release? Because we haven't had a next release yet. Is it the only thing to do? No, the property file also needs to be removed. What about @Deprecated processEventReminder method? Do you mean processWorkEffortEventReminder? Because #1 it's a service so deprecating it would do nothing and #2 only a block needs to be removed so why deprecate it? Should we keep EventReminders.properties file, etc. ? No the property file should also be removed, I don't know what else you're referring to with etc. Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
[jira] [Created] (OFBIZ-4795) Move SHARK to attic
Move SHARK to attic --- Key: OFBIZ-4795 URL: https://issues.apache.org/jira/browse/OFBIZ-4795 Project: OFBiz Issue Type: Task Components: specialpurpose/shark Affects Versions: SVN trunk Reporter: Pierre Smits Fix For: SlimDown Move all SHARK related code to the Attic environment of OFBiz -- 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: Using GZip compression for js files in Ecommerce module
Mmm.. finally this is wrong. Because if you use ajp then you bypass http/s
connectors and you should handle compression using
mod_proxy + mod_deflate in HTTPD
Sorry for the confusion
Note: this is out of OFBiz scope
Jacques
From: Jacques Le Roux jacques.le.r...@les7arts.com
You can also use mod_proxy + mod_deflate to do that but why do it since it's
already included in OFBiz (same with nginx, etc.)?
So no, I don't think it adds any performance impact if you don't use mod_deflate and I believe it should be very minor if ever
you
do it twice (but again don't do it ;o)
Jacques
From: Pierre Smits pierre.sm...@gmail.com
Hi all,
I don't know having this in OFBiz affects performance when OFBiz is behind
a webserver (like Apache HTTP) via normal proxy processes or via ajp, which
are standard scenarios in in a multi-tier, high availability/failover setup.
Regards,
Op 8 april 2012 11:13 schreef Jacques Le Roux
jacques.le.r...@les7arts.comhet volgende:
You are missing a point Mandeep.
OFBiz is already compressing text files. This is done through the embedded
Tomcat. See in ofbiz-containers.xml
{code}
property name=compressableMimeType value=text/html,text/xml,**
text/plain/
property name=compression value=on/
{code}
Reference:
http://tomcat.apache.org/**tomcat-7.0-doc/config/http.**htmlhttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html
So my proposition was only to add an yui-compressor-ant-task to compress
js/css files as described here
http://developer.yahoo.com/**yui/compressor/http://developer.yahoo.com/yui/compressor/
Note that for bigest files we already use compressed versions (ending by
min.js, see framework/common/widget/**CommonScreens.xml and
specialpurpose/ecommerce/**widget/CommonScreens.xml)
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
created Jira 4792
https://issues.apache.org/**jira/browse/OFBIZ-4792https://issues.apache.org/jira/browse/OFBIZ-4792
but still this will only compress the files Jacques, what if the
application is consuming external jss/css files, if the remote server has
the capability to server GZip encoded content to the requesting client,
we'd need to send the GZip encoding option in the http header for which I
believe Ofbiz needs to be touched.
Correct me if I am wrong.
Regards,
Mandeep Sidhu
On Sun, Apr 8, 2012 at 11:21 AM, Jacques Le Roux
jacques.le.r...@les7arts.com wrote:
I'd suggest to do it also for css
http://code.google.com/p/yui-http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-compressor-ant-task/
You could create a Jira and contribute https://cwiki.apache.org/**
confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
https://cwiki.**apache.org/confluence/display/**
OFBADMIN/OFBiz+Contributors+**Best+Practiceshttps://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
,
this
would be appreciated of course, not only for eCommerce BTW...
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
Hi,
I was wondering if it is possible to reduce the size of external
javascript's being fetched by making use of GZip encoding.
The feeding server does understand and responds to GZip encoding,
however
Ofbiz is not requesting the content in GZip format.
Can anybody please guide me as to what all modifications I need to make
so
that Ofbiz will include the GZip encoding option in the http header
while
requesting the external javascript file ?
Regards,
Mandeeep Sidhu
--
Mandeep Singh Sidhu
Re: Using GZip compression for js files in Ecommerce module
Note that, if you use something else than AJP (nginx with haproxy for instance)
you will still use Tomcat HTTP connectors hence
internal OFBiz compression...
I have added text/javascript,text/css as new compressableMimeTypes at r1310975
What about adding property compressionMinSize=2048/?
It needs only to change XSD it seems, but what about the size?
Jacques
From: Jacques Le Roux jacques.le.r...@les7arts.com
Mmm.. finally this is wrong. Because if you use ajp then you bypass http/s
connectors and you should handle compression using
mod_proxy + mod_deflate in HTTPD
Sorry for the confusion
Note: this is out of OFBiz scope
Jacques
From: Jacques Le Roux jacques.le.r...@les7arts.com
You can also use mod_proxy + mod_deflate to do that but why do it since it's
already included in OFBiz (same with nginx, etc.)?
So no, I don't think it adds any performance impact if you don't use
mod_deflate and I believe it should be very minor if ever
you
do it twice (but again don't do it ;o)
Jacques
From: Pierre Smits pierre.sm...@gmail.com
Hi all,
I don't know having this in OFBiz affects performance when OFBiz is behind
a webserver (like Apache HTTP) via normal proxy processes or via ajp, which
are standard scenarios in in a multi-tier, high availability/failover setup.
Regards,
Op 8 april 2012 11:13 schreef Jacques Le Roux
jacques.le.r...@les7arts.comhet volgende:
You are missing a point Mandeep.
OFBiz is already compressing text files. This is done through the embedded
Tomcat. See in ofbiz-containers.xml
{code}
property name=compressableMimeType value=text/html,text/xml,**
text/plain/
property name=compression value=on/
{code}
Reference:
http://tomcat.apache.org/**tomcat-7.0-doc/config/http.**htmlhttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html
So my proposition was only to add an yui-compressor-ant-task to compress
js/css files as described here
http://developer.yahoo.com/**yui/compressor/http://developer.yahoo.com/yui/compressor/
Note that for bigest files we already use compressed versions (ending by
min.js, see framework/common/widget/**CommonScreens.xml and
specialpurpose/ecommerce/**widget/CommonScreens.xml)
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
created Jira 4792
https://issues.apache.org/**jira/browse/OFBIZ-4792https://issues.apache.org/jira/browse/OFBIZ-4792
but still this will only compress the files Jacques, what if the
application is consuming external jss/css files, if the remote server has
the capability to server GZip encoded content to the requesting client,
we'd need to send the GZip encoding option in the http header for which I
believe Ofbiz needs to be touched.
Correct me if I am wrong.
Regards,
Mandeep Sidhu
On Sun, Apr 8, 2012 at 11:21 AM, Jacques Le Roux
jacques.le.r...@les7arts.com wrote:
I'd suggest to do it also for css
http://code.google.com/p/yui-http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-**
compressor-ant-task/ http://code.google.com/p/yui-compressor-ant-task/
You could create a Jira and contribute https://cwiki.apache.org/**
confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
https://cwiki.**apache.org/confluence/display/**
OFBADMIN/OFBiz+Contributors+**Best+Practiceshttps://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
,
this
would be appreciated of course, not only for eCommerce BTW...
Jacques
From: Mandeep Sidhu mandeep1985s...@gmail.com
Hi,
I was wondering if it is possible to reduce the size of external
javascript's being fetched by making use of GZip encoding.
The feeding server does understand and responds to GZip encoding,
however
Ofbiz is not requesting the content in GZip format.
Can anybody please guide me as to what all modifications I need to make
so
that Ofbiz will include the GZip encoding option in the http header
while
requesting the external javascript file ?
Regards,
Mandeeep Sidhu
--
Mandeep Singh Sidhu
Re: ports in test-containers.xml
Hi all, As it is more likely that port numbers near the ones we have are already taken, I support the schema mentioned by Jacques relating to the Geronimo variant. 1 current port number for integrated testing set ups (Jenkins), leading to: 11099 18009 18080 18443 Regards, Pierre Op 8 april 2012 12:17 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: I suggest to increase by one the last ports numbers to avoid collission even when shifted (see below) for instance RMI = 1099+1 = 1100 - ajp 8009+1 = 8010 etc. Because I already suggested to follow Geronimo's way in OFBiz integration in Apache sonar instance thread Geronimo does this. They pass a value through their scripts. It should not be too hard to copy/adapt. Of course it should be used not only for the test-container files but with all containers files. Then it will be easy and clean to change the ports for an instance. The idea is to pass a shift value to all ports, rather than a value for each ports. For instance 1 means 18080, 18443, 11099, etc.; 2 means 28080, 28443, 21099 http://markmail.org/message/**mgmhrqchjjmo776qhttp://markmail.org/message/mgmhrqchjjmo776q Erwan opened https://issues.apache.org/**jira/browse/OFBIZ-4763https://issues.apache.org/jira/browse/OFBIZ-4763for that Jacques From: Pierre Smits pierre.sm...@gmail.com I will create a JIRA for this, But for testing what port numbers will we have for: - ajp - http - https - others? Regards, Pierre Op 8 april 2012 07:54 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.**com jacopo.cappell...@hotwaxmedia.com het volgende: +1 On May 13, 2011, at 3:23 PM, Erwan de FERRIERES wrote: Hi all, I'm planning on changing the ports for the http and https test containers. This way, tests can be runned on the Apache jenkins instance (8080 is already used). Is there anyone against these ? Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
From: Pierre Smits pierre.sm...@gmail.com Hi All, I think it is very unwise to let endusers use the most disruptive version available (the trunk) for evaluation purposes. It should only be available for developers or other, more technically experienced persons who want to assess the underlying (technical) implementations. We have both communications in place. At the right places in the site. +1 The statement the trunk is bug free is and all problems are fixed within hours not only misleads the enduser, but it also puts an enormous pressure on developers and committers. Plus, it might lead to the ASF being liable for not delivering. Seems most of us are heading in the same direction.. Jacques Regards, Pierre Op 8 april 2012 10:55 schreef Scott Gray scott.g...@hotwaxmedia.com het volgende: Wow what a long thread for such a simple issue, thanks for being so patient Jacopo. At the end of the day users simply shouldn't be downloading the trunk, it's intended for OFBiz developers and testers only. To pretend that the trunk is bug free is and all problems are fixed within hours is naive at best and a straight out lie at worst. The trunk also isn't guaranteed to conform to the ASLv2 and at numerous points in the past it hasn't. Continuous deployment from the trunk is a flawed strategy that puts the stability of your system into the hands of a random collection of OFBiz committers of varying quality, how that makes good business sense to anyone is beyond me. Regards Scott On 8/04/2012, at 8:31 PM, Jacopo Cappellato wrote: Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. Jacopo On Apr 8, 2012, at 10:12 AM, Hans Bakker wrote: The page has a button Download to point a user (developer or not) to the download of ofbiz system files. Trunk should be part of that. Regards, Hans On 04/08/2012 03:06 PM, Jacopo Cappellato wrote: By the way, an interesting resource is the Release FAQ: http://www.apache.org/dev/release.html I am quoting here a relevant part: = What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. = Jacopo On Apr 7, 2012, at 7:37 PM, Jacques Le Roux wrote: Actually I don't care much. It was mostly to find a consens er... compromise. So I let Hans handles that if he wants (no commits war please)... For those who are relatively new to this ML, we should though explain that recommnending to use trunk to users has been the inclination of OFBiz original creators. At this time it was vital for the project to get more contributions and I must say it's also easier for committers to contribute directly (this is actually not a big deal, a patch is an easy way most of the time). See for instance http://markmail.org/message/ee2mzldkkzg6im5x, the link there is now https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started(BTW this needs certainly an update, but actually all the documentation needs update and pruning). Jacopo was the 1st to propose another way: http://markmail.org/message/vh7jrgmwfmxrd4bh And to clarify my position: I'm supporting releases for a long time now (I mean backporting bugs, sometimes at my expense ;o). Fortunately it turns that it's easier and safer since the R10.04 release. I believe that this new way of doing allows 2 pathes (trunk or releases) and we need both! Hope this summarises well my POV and the situation Jacques From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com I am against this, especially if it comes as an order issued by Hans: he is not in the position of being aggressive or forcing us to do what it pleases
Re: // TODO: Remove this block after the next release 2010-11-29
From: Scott Gray scott.g...@hotwaxmedia.com Hi Jaques, All the answers are pretty obvious (to me at least) after a minute's look at the commit, but I'll humor you anyway. Thanks for the answer, with humour is better :o) On 8/04/2012, at 10:08 PM, Jacques Le Roux wrote: Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev What did you not remove it? I figured it would be nicer for users if we waited until after a release. Is there a reason or only an oversight? Do you mean why haven't I removed it after the 11.04 release? Because we haven't had a next release yet. Ha I did not understood that. I thought R11.04 was the next. Is it the only thing to do? No, the property file also needs to be removed. What about @Deprecated processEventReminder method? Do you mean processWorkEffortEventReminder? Because #1 it's a service so deprecating it would do nothing and #2 only a block needs to be removed so why deprecate it? No I meant: should we not remove also the WorkEffortServices.processEventReminder() deprecated method? Should we keep EventReminders.properties file, etc. ? No the property file should also be removed, I don't know what else you're referring to with etc. Unknown, so I put etc. , ... in case (was not so clear to me) So we will clear that with R12.04, right? Jacques Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
Re: // TODO: Remove this block after the next release 2010-11-29
On 8/04/2012, at 11:05 PM, Jacques Le Roux wrote: From: Scott Gray scott.g...@hotwaxmedia.com Hi Jaques, All the answers are pretty obvious (to me at least) after a minute's look at the commit, but I'll humor you anyway. Thanks for the answer, with humour is better :o) On 8/04/2012, at 10:08 PM, Jacques Le Roux wrote: Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev What did you not remove it? I figured it would be nicer for users if we waited until after a release. Is there a reason or only an oversight? Do you mean why haven't I removed it after the 11.04 release? Because we haven't had a next release yet. Ha I did not understood that. I thought R11.04 was the next. Sorry I mistyped the first sentence, I meant that 11.04 has been branched but not released. Code shouldn't be removed until after the actual release. Is it the only thing to do? No, the property file also needs to be removed. What about @Deprecated processEventReminder method? Do you mean processWorkEffortEventReminder? Because #1 it's a service so deprecating it would do nothing and #2 only a block needs to be removed so why deprecate it? No I meant: should we not remove also the WorkEffortServices.processEventReminder() deprecated method? Ah a different commit. After the official release all code deprecated prior to the 11.04 branch should be removed. Should we keep EventReminders.properties file, etc. ? No the property file should also be removed, I don't know what else you're referring to with etc. Unknown, so I put etc. , ... in case (was not so clear to me) So we will clear that with R12.04, right? Sorry I don't understand the question. Jacques Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
Re: ports in test-containers.xml
Mmm, nope, sorry you did not get my point Pierre, What I mean is this for test-containers.xml ports RMI = 1099+1 = 1100 - ajp 8009+1 = 8010 1. In all case change test-containers.xml ports by adding 1 to them (I added 1, we could add 100 or whatever). That is change them now and commit. This way we can run test and ofbiz containers concurrently on the same machine OOTB w/out any other changes. 2. If we want to run many OFBiz instances on the same machine (being test or normal instances) we need a way to easily shift all ports, this is what https://issues.apache.org/jira/browse/OFBIZ-4763 is supposed to be For instance you could want to not only run many OFBiz instances on the same machine (eg: for devs manual tests on staging) but also many test instances on another one. One test instance may run only quick check (for instance unit tests only on custom code) when another one will run the complete set of tests (to detect regressions on core code for instance, rare but really harmful) Hope I'm more clear... :o) Jacques From: Pierre Smits pierre.sm...@gmail.com Hi all, As it is more likely that port numbers near the ones we have are already taken, I support the schema mentioned by Jacques relating to the Geronimo variant. 1 current port number for integrated testing set ups (Jenkins), leading to: 11099 18009 18080 18443 Regards, Pierre Op 8 april 2012 12:17 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: I suggest to increase by one the last ports numbers to avoid collission even when shifted (see below) for instance RMI = 1099+1 = 1100 - ajp 8009+1 = 8010 etc. Because I already suggested to follow Geronimo's way in OFBiz integration in Apache sonar instance thread Geronimo does this. They pass a value through their scripts. It should not be too hard to copy/adapt. Of course it should be used not only for the test-container files but with all containers files. Then it will be easy and clean to change the ports for an instance. The idea is to pass a shift value to all ports, rather than a value for each ports. For instance 1 means 18080, 18443, 11099, etc.; 2 means 28080, 28443, 21099 http://markmail.org/message/**mgmhrqchjjmo776qhttp://markmail.org/message/mgmhrqchjjmo776q Erwan opened https://issues.apache.org/**jira/browse/OFBIZ-4763https://issues.apache.org/jira/browse/OFBIZ-4763for that Jacques From: Pierre Smits pierre.sm...@gmail.com I will create a JIRA for this, But for testing what port numbers will we have for: - ajp - http - https - others? Regards, Pierre Op 8 april 2012 07:54 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.**com jacopo.cappell...@hotwaxmedia.com het volgende: +1 On May 13, 2011, at 3:23 PM, Erwan de FERRIERES wrote: Hi all, I'm planning on changing the ports for the http and https test containers. This way, tests can be runned on the Apache jenkins instance (8080 is already used). Is there anyone against these ? Cheers, -- Erwan de FERRIERES www.nereide.biz
[jira] [Updated] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-4794: Attachment: OFBIZ-4794-test-ports.patch This patch sets the different port numbers for CI testing in test-containers.xml set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Fix For: SVN trunk Attachments: OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- 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: ports in test-containers.xml
Hi Jacques, all, I concur that we need 1. a change of base port numbers in test-containers.xml to enable continuous integration for sequential testing (as standard ports are already (most likely) used by the underlying application server). 2. a dynamic change of port numbers to enable continuous integration for parallel testing (in accordance with your proposal of base portnumber + n). Regards, Pierre Op 8 april 2012 13:23 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Mmm, nope, sorry you did not get my point Pierre, What I mean is this for test-containers.xml ports RMI = 1099+1 = 1100 - ajp 8009+1 = 8010 1. In all case change test-containers.xml ports by adding 1 to them (I added 1, we could add 100 or whatever). That is change them now and commit. This way we can run test and ofbiz containers concurrently on the same machine OOTB w/out any other changes. 2. If we want to run many OFBiz instances on the same machine (being test or normal instances) we need a way to easily shift all ports, this is what https://issues.apache.org/**jira/browse/OFBIZ-4763https://issues.apache.org/jira/browse/OFBIZ-4763is supposed to be For instance you could want to not only run many OFBiz instances on the same machine (eg: for devs manual tests on staging) but also many test instances on another one. One test instance may run only quick check (for instance unit tests only on custom code) when another one will run the complete set of tests (to detect regressions on core code for instance, rare but really harmful) Hope I'm more clear... :o) Jacques From: Pierre Smits pierre.sm...@gmail.com Hi all, As it is more likely that port numbers near the ones we have are already taken, I support the schema mentioned by Jacques relating to the Geronimo variant. 1 current port number for integrated testing set ups (Jenkins), leading to: 11099 18009 18080 18443 Regards, Pierre Op 8 april 2012 12:17 schreef Jacques Le Roux jacques.le.r...@les7arts.com**het volgende: I suggest to increase by one the last ports numbers to avoid collission even when shifted (see below) for instance RMI = 1099+1 = 1100 - ajp 8009+1 = 8010 etc. Because I already suggested to follow Geronimo's way in OFBiz integration in Apache sonar instance thread Geronimo does this. They pass a value through their scripts. It should not be too hard to copy/adapt. Of course it should be used not only for the test-container files but with all containers files. Then it will be easy and clean to change the ports for an instance. The idea is to pass a shift value to all ports, rather than a value for each ports. For instance 1 means 18080, 18443, 11099, etc.; 2 means 28080, 28443, 21099 http://markmail.org/message/mgmhrqchjjmo776qhttp://markmail.org/message/**mgmhrqchjjmo776q http://**markmail.org/message/**mgmhrqchjjmo776qhttp://markmail.org/message/mgmhrqchjjmo776q Erwan opened https://issues.apache.org/jira/browse/OFBIZ-4763https://issues.apache.org/**jira/browse/OFBIZ-4763 https:/**/issues.apache.org/jira/**browse/OFBIZ-4763https://issues.apache.org/jira/browse/OFBIZ-4763for that Jacques From: Pierre Smits pierre.sm...@gmail.com I will create a JIRA for this, But for testing what port numbers will we have for: - ajp - http - https - others? Regards, Pierre Op 8 april 2012 07:54 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.com jacopo.cappellato@** hotwaxmedia.com jacopo.cappell...@hotwaxmedia.com het volgende: +1 On May 13, 2011, at 3:23 PM, Erwan de FERRIERES wrote: Hi all, I'm planning on changing the ports for the http and https test containers. This way, tests can be runned on the Apache jenkins instance (8080 is already used). Is there anyone against these ? Cheers, -- Erwan de FERRIERES www.nereide.biz
[jira] [Commented] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249527#comment-13249527 ] Jacques Le Roux commented on OFBIZ-4794: Nope, please see [my answer on dev ML|http://markmail.org/message/i4u5pijlclgtzwrm]. Also I recommend to add 1 (not 1 ;) ) to *all* ports in test-containers.xml, even those commented out, etc. set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Fix For: SVN trunk Attachments: OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- 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: ports in test-containers.xml
From: Jacques Le Roux jacques.le.r...@les7arts.com For instance you could want to not only run many OFBiz instances on the same machine (eg: for devs manual tests on staging) but also many test instances on another one. One test instance may run only quick check (for instance unit tests only on custom code) when another one will run the complete set of tests (to detect regressions on core code for instance, rare but really harmful) This is inspired by http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast Jacques
Re: // TODO: Remove this block after the next release 2010-11-29
From: Scott Gray scott.g...@hotwaxmedia.com On 8/04/2012, at 11:05 PM, Jacques Le Roux wrote: From: Scott Gray scott.g...@hotwaxmedia.com Hi Jaques, All the answers are pretty obvious (to me at least) after a minute's look at the commit, but I'll humor you anyway. Thanks for the answer, with humour is better :o) On 8/04/2012, at 10:08 PM, Jacques Le Roux wrote: Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev What did you not remove it? I figured it would be nicer for users if we waited until after a release. Is there a reason or only an oversight? Do you mean why haven't I removed it after the 11.04 release? Because we haven't had a next release yet. Ha I did not understood that. I thought R11.04 was the next. Sorry I mistyped the first sentence, I meant that 11.04 has been branched but not released. Code shouldn't be removed until after the actual release. Is it the only thing to do? No, the property file also needs to be removed. What about @Deprecated processEventReminder method? Do you mean processWorkEffortEventReminder? Because #1 it's a service so deprecating it would do nothing and #2 only a block needs to be removed so why deprecate it? No I meant: should we not remove also the WorkEffortServices.processEventReminder() deprecated method? Ah a different commit. After the official release all code deprecated prior to the 11.04 branch should be removed. Should we keep EventReminders.properties file, etc. ? No the property file should also be removed, I don't know what else you're referring to with etc. Unknown, so I put etc. , ... in case (was not so clear to me) So we will clear that with R12.04, right? Sorry I don't understand the question. Sorry I was not clear, actually forgot that R11.04 is not already officially released. So I meant rather when we will release R11.04 and now all is clear to me, thanks Last question, should we not have a list of such changes somewhere (in a Jira related to release?), or a standard way to find them quickly, or (another idea?)... Jacques Jacques Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
Re: ports in test-containers.xml
Indeed! Op 8 april 2012 13:36 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: From: Jacques Le Roux jacques.le.r...@les7arts.com For instance you could want to not only run many OFBiz instances on the same machine (eg: for devs manual tests on staging) but also many test instances on another one. One test instance may run only quick check (for instance unit tests only on custom code) when another one will run the complete set of tests (to detect regressions on core code for instance, rare but really harmful) This is inspired by http://martinfowler.com/**articles/** continuousIntegration.html#**KeepTheBuildFasthttp://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast Jacques
Re: // TODO: Remove this block after the next release 2010-11-29
On 8/04/2012, at 11:29 PM, Jacques Le Roux wrote: From: Scott Gray scott.g...@hotwaxmedia.com On 8/04/2012, at 11:05 PM, Jacques Le Roux wrote: From: Scott Gray scott.g...@hotwaxmedia.com Hi Jaques, All the answers are pretty obvious (to me at least) after a minute's look at the commit, but I'll humor you anyway. Thanks for the answer, with humour is better :o) On 8/04/2012, at 10:08 PM, Jacques Le Roux wrote: Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev What did you not remove it? I figured it would be nicer for users if we waited until after a release. Is there a reason or only an oversight? Do you mean why haven't I removed it after the 11.04 release? Because we haven't had a next release yet. Ha I did not understood that. I thought R11.04 was the next. Sorry I mistyped the first sentence, I meant that 11.04 has been branched but not released. Code shouldn't be removed until after the actual release. Is it the only thing to do? No, the property file also needs to be removed. What about @Deprecated processEventReminder method? Do you mean processWorkEffortEventReminder? Because #1 it's a service so deprecating it would do nothing and #2 only a block needs to be removed so why deprecate it? No I meant: should we not remove also the WorkEffortServices.processEventReminder() deprecated method? Ah a different commit. After the official release all code deprecated prior to the 11.04 branch should be removed. Should we keep EventReminders.properties file, etc. ? No the property file should also be removed, I don't know what else you're referring to with etc. Unknown, so I put etc. , ... in case (was not so clear to me) So we will clear that with R12.04, right? Sorry I don't understand the question. Sorry I was not clear, actually forgot that R11.04 is not already officially released. So I meant rather when we will release R11.04 and now all is clear to me, thanks Last question, should we not have a list of such changes somewhere (in a Jira related to release?), or a standard way to find them quickly, or (another idea?)… I should've added Deprecated to the comment on the block. When I'm removing old code I search for deprecated then check the revision history to see when it happened, would be nice if we included the date everywhere to make it easier. Jacques Jacques Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
[jira] [Updated] (OFBIZ-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4792: --- Description: The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) was: The idea is to create an ant task using [yui-compressor-ant-task|http://code.google.com/p/yui-compressor-ant-task/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) Changes description to refer to http://developer.yahoo.com/yui/compressor/ directly rather Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-4792: -- Assignee: Jacques Le Roux Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Assignee: Jacques Le Roux Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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] [Commented] (OFBIZ-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249530#comment-13249530 ] Jacques Le Roux commented on OFBIZ-4792: Commited initial work at revision: 1310983 Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Assignee: Jacques Le Roux Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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] [Commented] (OFBIZ-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249532#comment-13249532 ] Mandeep Sidhu commented on OFBIZ-4792: -- I analyzed the URL being accessed by my application, I am trying to consume a version of jquery from google's CDN. URL: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js the size I am getting back is around 72KB, which is not gzipped, although Ofbiz is sending gzip as part of content-encoding. Here's what OFbiz is requesting VaryAccept-Encoding Content-Encodinggzip Content-Typetext/javascript; charset=UTF-8 Last-Modified Mon, 02 Apr 2012 18:24:28 GMT DateWed, 04 Apr 2012 16:56:11 GMT Expires Thu, 04 Apr 2013 16:56:11 GMT X-Content-Type-Options nosniff Server GFE/2.0 Content-Length 24605 X-XSS-Protection1; mode=block Cache-Control public, max-age=31536000 Age 328756 One thing to note here is that it is not sending the user-agent header, and surprisingly google's CDN doesn't understand this and expects an established user-agent header, I used some tool to hit the same url and sent user-agent explicitly, surprisingly the received file size was 25Kb. do you've any idea as to why OFBIZ(tomcat server ) is omitting the user-agent header. Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Assignee: Jacques Le Roux Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mandeep Sidhu updated OFBIZ-4792: - Comment: was deleted (was: I analyzed the URL being accessed by my application, I am trying to consume a version of jquery from google's CDN. URL: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js the size I am getting back is around 72KB, which is not gzipped, although Ofbiz is sending gzip as part of content-encoding. Here's what OFbiz is requesting VaryAccept-Encoding Content-Encodinggzip Content-Typetext/javascript; charset=UTF-8 Last-Modified Mon, 02 Apr 2012 18:24:28 GMT DateWed, 04 Apr 2012 16:56:11 GMT Expires Thu, 04 Apr 2013 16:56:11 GMT X-Content-Type-Options nosniff Server GFE/2.0 Content-Length 24605 X-XSS-Protection1; mode=block Cache-Control public, max-age=31536000 Age 328756 One thing to note here is that it is not sending the user-agent header, and surprisingly google's CDN doesn't understand this and expects an established user-agent header, I used some tool to hit the same url and sent user-agent explicitly, surprisingly the received file size was 25Kb. do you've any idea as to why OFBIZ(tomcat server ) is omitting the user-agent header.) Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Assignee: Jacques Le Roux Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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] [Commented] (OFBIZ-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249534#comment-13249534 ] Mandeep Sidhu commented on OFBIZ-4792: -- my bad, I am just being ignorant here, I was looking at the response header, my bad, it's working perfectly fine. apologies :) Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Assignee: Jacques Le Roux Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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: // TODO: Remove this block after the next release 2010-11-29
From: Scott Gray scott.g...@hotwaxmedia.com On 8/04/2012, at 11:29 PM, Jacques Le Roux wrote: From: Scott Gray scott.g...@hotwaxmedia.com On 8/04/2012, at 11:05 PM, Jacques Le Roux wrote: From: Scott Gray scott.g...@hotwaxmedia.com Hi Jaques, All the answers are pretty obvious (to me at least) after a minute's look at the commit, but I'll humor you anyway. Thanks for the answer, with humour is better :o) On 8/04/2012, at 10:08 PM, Jacques Le Roux wrote: Hi Scott, So you committed this I see now http://svn.apache.org/viewvc?rev=1040016view=rev What did you not remove it? I figured it would be nicer for users if we waited until after a release. Is there a reason or only an oversight? Do you mean why haven't I removed it after the 11.04 release? Because we haven't had a next release yet. Ha I did not understood that. I thought R11.04 was the next. Sorry I mistyped the first sentence, I meant that 11.04 has been branched but not released. Code shouldn't be removed until after the actual release. Is it the only thing to do? No, the property file also needs to be removed. What about @Deprecated processEventReminder method? Do you mean processWorkEffortEventReminder? Because #1 it's a service so deprecating it would do nothing and #2 only a block needs to be removed so why deprecate it? No I meant: should we not remove also the WorkEffortServices.processEventReminder() deprecated method? Ah a different commit. After the official release all code deprecated prior to the 11.04 branch should be removed. Should we keep EventReminders.properties file, etc. ? No the property file should also be removed, I don't know what else you're referring to with etc. Unknown, so I put etc. , ... in case (was not so clear to me) So we will clear that with R12.04, right? Sorry I don't understand the question. Sorry I was not clear, actually forgot that R11.04 is not already officially released. So I meant rather when we will release R11.04 and now all is clear to me, thanks Last question, should we not have a list of such changes somewhere (in a Jira related to release?), or a standard way to find them quickly, or (another idea?)… I should've added Deprecated to the comment on the block. When I'm removing old code I search for deprecated then check the revision history to see when it happened, would be nice if we included the date everywhere to make it easier. OK, sounds like the best way indeed Thanks Jacques Jacques Jacques Jacques From: Scott Gray scott.g...@hotwaxmedia.com The instructions seem quite clear to me. Regards Scott On 7/04/2012, at 10:09 PM, Jacques Le Roux wrote: I meant this should awake a committer, at least one person should be aware of that... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Just look into *.java you will find it easily ;o) It's in WorkEffortServices.processWorkEffortEventReminder() Jacques From: Pierre Smits pierre.sm...@gmail.com Hi Jacques, This is very cryptic. To what issue does this relate to, and to what application or component? Regards, Pierre Op 7 april 2012 11:12 schreef Jacques Le Roux jacques.le.r...@les7arts.comhet volgende: Hi, Should we not remove this block and stuff related? // TODO: Remove this block after the next release 2010-11-29 Jacques
[jira] [Closed] (OFBIZ-4792) Add a yui-compressor-ant-task
[ https://issues.apache.org/jira/browse/OFBIZ-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4792. -- Resolution: Fixed I think it's enough OOTB. Now users will have to care in production... Add a yui-compressor-ant-task - Key: OFBIZ-4792 URL: https://issues.apache.org/jira/browse/OFBIZ-4792 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Environment: Windows/Linux Reporter: Mandeep Sidhu Assignee: Jacques Le Roux Priority: Trivial Labels: build, compression, css, features, javascript Fix For: SVN trunk The idea is to create an ant task which uses [YUICompressor|http://developer.yahoo.com/yui/compressor/] to dynamically minify our own (or custom for users) js and css files (most of the bigest external ones are already compressed) -- 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: Building OFBiz with Jenkins
Hi Erwan, all, I have currently setup a test environment for continuous integration with Jenkins wereby I have following build/test setup configured: 1. pull from svn trunk the latest code (works perfectly - triggers 2) 2. Do ant targets clean-all, build and load-demo (works perfectly - triggers 3) 3. Do ant targets download-cobertura and download-sonar-ant-task (works perfectly - for later cobertura code analysis and reporting to the sonar instance - triggers 4) 4. Do ant target run-tests (fails - see below - triggers 5 even when fails) 5. Do ant target cobertura-report-xml (works perfectly triggers 6, when I have figured out howto) 6. Do ant target sonar (not configured yet) First of all what do you think of that approach? Secondly, Item # 4 fails on: 1. not having ports for testing set right. See JIRA issue 4794https://issues.apache.org/jira/browse/OFBIZ-4794, which I have fixed locally 2. not having a working build setting in framework/base/build.xml. See JIRA issue 4757 https://issues.apache.org/jira/browse/OFBIZ-4757 3. on various test as it performs all unit tests available. The output generated is extensive and overwhelming. The question here is whether there is a list of all unit tests per component and/or test suites per component so that I can do a more granular testing per component and see what specific component test fails and what goes well. Regards, Pierre Op 6 april 2012 13:31 schreef Pierre Smits pierre.sm...@gmail.com het volgende: Hi all, Thanks to Anne I was able to run the ant targets 'build' and 'load-demo' in my Jenkins after having pulled directly from svn. Regards, Pierre Op 31 maart 2012 13:08 schreef Pierre Smits pierre.sm...@gmail.com het volgende: Hi all, I am trying to build OFBiz through Jenkings, but get following message: Started by user Pierre Smits http://sandbox.somonar.prd:8080/jenkins/user/Pierre%20Smits Updating http://svn.apache.org/repos/asf/ofbiz/trunk U framework/base/src/org/ofbiz/base/util/test/ObjectTypeTests.java U framework/base/src/org/ofbiz/base/util/ObjectType.java At revision 1307764 [trunk] $ ant build Buildfile: build.xml BUILD FAILED/var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/build.xml:25: The following error occurred while executing this line: /var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/macros.xml:26: No supported regular expression matcher found: java.lang.ClassNotFoundException: org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp Total time: 0 seconds Build step 'Invoke Ant' marked build as failure Does the error sound familiar? And how can I resolve this? Regards, Pierre
[jira] [Commented] (OFBIZ-4787) Party Manager Default Country in Update
[ https://issues.apache.org/jira/browse/OFBIZ-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249562#comment-13249562 ] Tom Burns commented on OFBIZ-4787: -- I will create a new issue for It's country... Your patch is a hidden gem. The lack of context sensitivity in drop downs is a major OFBiz usability issue in my mind and the Country / State presentation is a poster child for the problem. I'll open a new improvement issue for eCommerce and Facility since you have closed this one. Tom Party Manager Default Country in Update --- Key: OFBIZ-4787 URL: https://issues.apache.org/jira/browse/OFBIZ-4787 Project: OFBiz Issue Type: Bug Components: party Affects Versions: SVN trunk Environment: demo-trunk Reporter: Tom Burns Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 11.04, SVN trunk Attachments: OFBIZ-4787 defaultCountryGeoId.patch In Party Manager Profile Contact Information Update the Country drop down always defaults to United States. This is misleading if the Country is not United States. If a user were to change some other address element he/she would have to also re-set Country to keep it from being changed to United States. To reproduce: In Party Manager lookup a party with a Postal Address say DemoSupplier* In Contact Information Postal Address Click Update In the Country field select any country but United States say Switzerland Click Save Note - Expect drop down default after save = Switzerland Actual drop down default after save = United States Click Go Back Expect Postal Address country = Switzerland Actual Postal Address country = Switzerland Click Click Update Expect drop down default to be Switzerland Actual United States * Note: Select any party but Company. It's Country can not be changed because a foreign missing parameter on a call to updateEftAccount. This may be a separate issue. -- 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] [Commented] (OFBIZ-4787) Party Manager Default Country in Update
[ https://issues.apache.org/jira/browse/OFBIZ-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249574#comment-13249574 ] Jacques Le Roux commented on OFBIZ-4787: Thank you for the compliment. Actually it's not that hidden. If you look at the examples: https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples#DropDownFieldsExampleForm_geoId_title But I must say a clear example with Freemarker was missing indeed. Looking forwar for eCommerce and Facility. A Jira for each would be better... Party Manager Default Country in Update --- Key: OFBIZ-4787 URL: https://issues.apache.org/jira/browse/OFBIZ-4787 Project: OFBiz Issue Type: Bug Components: party Affects Versions: SVN trunk Environment: demo-trunk Reporter: Tom Burns Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 11.04, SVN trunk Attachments: OFBIZ-4787 defaultCountryGeoId.patch In Party Manager Profile Contact Information Update the Country drop down always defaults to United States. This is misleading if the Country is not United States. If a user were to change some other address element he/she would have to also re-set Country to keep it from being changed to United States. To reproduce: In Party Manager lookup a party with a Postal Address say DemoSupplier* In Contact Information Postal Address Click Update In the Country field select any country but United States say Switzerland Click Save Note - Expect drop down default after save = Switzerland Actual drop down default after save = United States Click Go Back Expect Postal Address country = Switzerland Actual Postal Address country = Switzerland Click Click Update Expect drop down default to be Switzerland Actual United States * Note: Select any party but Company. It's Country can not be changed because a foreign missing parameter on a call to updateEftAccount. This may be a separate issue. -- 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: Building OFBiz with Jenkins
On Apr 8, 2012, at 4:30 PM, Pierre Smits wrote: 4. Do ant target run-tests (fails - see below - triggers 5 even when fails) Pierre, I don't know if it is useful but run-tests completes successfully in my local box. Jacopo
[jira] [Assigned] (OFBIZ-4588) Use flexibleStringRenderer for alt-target element on form
[ https://issues.apache.org/jira/browse/OFBIZ-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-4588: -- Assignee: Jacques Le Roux Use flexibleStringRenderer for alt-target element on form - Key: OFBIZ-4588 URL: https://issues.apache.org/jira/browse/OFBIZ-4588 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Screen Widget Redesign, SVN trunk Reporter: Nicolas Malin Assignee: Jacques Le Roux Priority: Minor Labels: form, renderer, widget Fix For: SVN trunk Attachments: JIRA-4588, OFBIZ-4588.patch At this time the alt-target element value is only parse on bsh interpreter. To resynchronise with the rest of framework, I propose to convert with a flexibleStringRenderer. Maybe remove bsh interpretor to use UEL and script call system. -- 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-4588) Use flexibleStringRenderer for alt-target element on form
[ https://issues.apache.org/jira/browse/OFBIZ-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4588. -- Resolution: Fixed Fix Version/s: SVN trunk Thanks Nicolas, Your patch is in trunk at r1311082 Use flexibleStringRenderer for alt-target element on form - Key: OFBIZ-4588 URL: https://issues.apache.org/jira/browse/OFBIZ-4588 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Screen Widget Redesign, SVN trunk Reporter: Nicolas Malin Priority: Minor Labels: form, renderer, widget Fix For: SVN trunk Attachments: JIRA-4588, OFBIZ-4588.patch At this time the alt-target element value is only parse on bsh interpreter. To resynchronise with the rest of framework, I propose to convert with a flexibleStringRenderer. Maybe remove bsh interpretor to use UEL and script call system. -- 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] [Commented] (OFBIZ-4782) load field info by a factory
[ https://issues.apache.org/jira/browse/OFBIZ-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249606#comment-13249606 ] Jacques Le Roux commented on OFBIZ-4782: Hi Nicolas, You missed to add import org.ofbiz.widget.form.FieldInfoFactory; BTW do you use EXTERN_WIDGET in your own code? Will this not break when a wrong fiels type (typo for instance) will be used? load field info by a factory Key: OFBIZ-4782 URL: https://issues.apache.org/jira/browse/OFBIZ-4782 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Nicolas Malin Priority: Minor Labels: field, screen, widget Attachments: OFBIZ-4782.patch Improve field info loading by a factory as screen loading. this issue is also a helper to define specific customer field without break or modify OFBiz class. -- 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-4472) New element auto-parameters-entity for link/hyperlink
[
https://issues.apache.org/jira/browse/OFBIZ-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reassigned OFBIZ-4472:
--
Assignee: (was: Jacques Le Roux)
New element auto-parameters-entity for link/hyperlink
-
Key: OFBIZ-4472
URL: https://issues.apache.org/jira/browse/OFBIZ-4472
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: Screen Widget Redesign, SVN trunk
Reporter: Nicolas Malin
Priority: Minor
Attachments: OFBIZ-4472.patch, OFBIZ-4472.patch, OFBIZ-4472.patch
When you want edit/remove an entity from link call it's needed to give all pk
on parameter element as like :
{quote} field name=deleteLink
hyperlink target=example_deleteExampleFeatureAppl
parameter param-name=exampleId/
parameter param-name=exampleFeatureId/
parameter param-name=fromDate/
hyperlink/
/field
{quote}
To simplify, I introduce auto-parameters-entity like this :
{quote}
field name=deleteLink
hyperlink target=example_deleteExampleFeatureAppl
auto-parameters-entity entity-name=ExampleFeatureAppl/
hyperlink/
/field
{quote}
or
{quote}
form name=ListExampleFeatureAppls type=list
default-entity-name=ExampleFeatureAppl
field name=deleteLink
hyperlink target=example_deleteExampleFeatureAppl
auto-parameters-entity/
hyperlink/
/field
{quote}
This method is inspired from auto-fields-entity and I homogenized on widget
renderer screen (link), menu (link) and form (hyperlink, sub-link)
Any comments are welcome
--
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-4467) Improve auto-fields-entity (select include field and auto drop-down)
[ https://issues.apache.org/jira/browse/OFBIZ-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-4467: -- Assignee: (was: Jacques Le Roux) Improve auto-fields-entity (select include field and auto drop-down) Key: OFBIZ-4467 URL: https://issues.apache.org/jira/browse/OFBIZ-4467 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Screen Widget Redesign, SVN trunk Reporter: Nicolas Malin Priority: Minor Attachments: OFBIZ-4467-example.patch, OFBIZ-4467.patch, OFBIZ-4467.patch, OFBIZ-4467.png Hi Here are two improvments to complete the element 'auto-fields-entity' of forms. The first one consists in adding one fields allowing to select which fields are include in the form (same way as what is made on the definitions of service): For example: auto-fields-entity entity-name=Example include=pk default-field-type=display/ = To display only the primary key fields of the Example entity auto-fields-entity entity-name=Example include=nonpk default-field-type=edit = To display only the non primary key fields of the Example entity exclude field-name=longDescription/ = To exclude one precise fields of an entity The second one consists in including for fields with relation a drop-down or a display entity according to EntityType Any comments are welcome -- 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] [Issue Comment Edited] (OFBIZ-4588) Use flexibleStringRenderer for alt-target element on form
[ https://issues.apache.org/jira/browse/OFBIZ-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249604#comment-13249604 ] Jacques Le Roux edited comment on OFBIZ-4588 at 4/8/12 9:38 PM: Thanks Nicolas, Your patch is in trunk at r1311109 (I add to revert r1311082) was (Author: jacques.le.roux): Thanks Nicolas, Your patch is in trunk at r1311082 Use flexibleStringRenderer for alt-target element on form - Key: OFBIZ-4588 URL: https://issues.apache.org/jira/browse/OFBIZ-4588 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Screen Widget Redesign, SVN trunk Reporter: Nicolas Malin Assignee: Jacques Le Roux Priority: Minor Labels: form, renderer, widget Fix For: SVN trunk Attachments: JIRA-4588, OFBIZ-4588.patch At this time the alt-target element value is only parse on bsh interpreter. To resynchronise with the rest of framework, I propose to convert with a flexibleStringRenderer. Maybe remove bsh interpretor to use UEL and script call system. -- 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-4796) Current SVN does not work with INR as the default currency.
Current SVN does not work with INR as the default currency. --- Key: OFBIZ-4796 URL: https://issues.apache.org/jira/browse/OFBIZ-4796 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: SVN trunk Environment: Windows, Current SVN Trunk, Derby, Seed data plus custom XML data Reporter: Sanjeev Gupta Fix For: Release Branch 11.04 When you upload custom data using an XML file; with store's default currency set to INR and the product prices defined in INR - your can't add products to the shopping chart. You get errors like : 1) Could not find a valid price for the product with ID [ID], not adding to cart 2) Fatal error calling inventory checking services: org.ofbiz.service.ServiceValidationException: The following required parameter is missing: [isStoreInventoryAvailableOrNotRequired.productStoreId]. As a work around you have to manually go into general.properties and change the default currency - I'm assuming that this would work in you are running a one or multiple stores with just on currency, but not if you have multiple currencies in stores. Even with this workaround the prices in the store shows up as Rs100 instead of Rs 100. Please note the space between Rs and 100. This problem does not exist in 11.04, everything works fine - locale defined in the product store work without any issue and the prices show up correctly Rs 100 -- 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
