Re: jquey
hi, i have found a few bugs in the ecommerce app, related to jQuery...since a jira is already open for the ecommerce migration, i am not sure if i should open a new jira issue for individual bugs/errors in the ecommerce application or add them to comments of jira relation to the ecommerce migration. please advice... thanks rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3093809.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
For now you can use the Jira issue. If you feel that the bug is important and will be difficult to track mixed with others please open a new one Thanks Jacques From: rohit rohitksur...@yahoo.com hi, i have found a few bugs in the ecommerce app, related to jQuery...since a jira is already open for the ecommerce migration, i am not sure if i should open a new jira issue for individual bugs/errors in the ecommerce application or add them to comments of jira relation to the ecommerce migration. please advice... thanks rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3093809.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Jacques, you have already ported in the jquery branch all the changes of the trunk. So now the jquery branch is actually how the trunk should be after the merge. Any conflict should be quickly resolved using the copy of the files from the jquery brqnch. -Bruno 2010/12/10 Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Yes, while mucking around with the trunk demo this morning I simply misused the merge (wrong way) and actually I have any conflicts to handle but a false one. It's committing... Jacques From: Bruno Busco bruno.bu...@gmail.com Jacques, you have already ported in the jquery branch all the changes of the trunk. So now the jquery branch is actually how the trunk should be after the merge. Any conflict should be quickly resolved using the copy of the files from the jquery brqnch. -Bruno 2010/12/10 Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
:) Jacques i planed that issue for tomorrow. Cheers Sascha Am 07.12.2010 um 11:55 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Calling selenium from the build XML was jquey
I am headed the same way with tests that span components. The Tests are like a user would do, like adding prodcts, entering an order, and making changes to data. Also Selenium gives you page layout changes Errors. though the individual pages are stored on each component, the test are in the framework that span components. The problem that Adam addressed was how to build these tests from the build.xml, not run them. That to me, is attainable, in the future but requires a lot more coding work. the one gotcha I see in self generated tests is you don't get legacy type of errors for what has been changed, like when an entity has a new field or one is removed or changed. This is crucial to production servers and supporting a client. As I originally said, if a layout(page) is effected by the addition of Jquey, that will negate tests for those layouts. It would be even harder to programmatic generate tests using selenium. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/5/2010 4:02 AM: Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha 2010/12/3 BJ Freemanbjf...@free-man.net what what level were you working on? I am working on scenarios for a user, like orderentry, adding products, placing order through Ecommerce. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.comhttp://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 12:11 AM: Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heathdoo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re: Calling selenium from the build XML was jquey
On 12/06/2010 12:30 PM, BJ Freeman wrote: The problem that Adam addressed was how to build these tests from the build.xml, not run them. That to me, is attainable, in the future but requires a lot more coding work. That wasn't what I said. I want to be able to run a selenium test from build.xml. I don't care how the test was created. But if the test has been added to trunk, I want a very simple command to run, that then tells me if it passes or not. If it requires setting up an external process, then the 'simple' tag doesn't apply. If it isn't simple, then it won't be run, and then errors would creep in.
Re: Calling selenium from the build XML was jquey
thanks for the the clarification. No problem running tests from build. the problem is the errors at this time, can not be reported in the logs, only visually to log errors will take some work in selenium. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Adam Heath sent the following on 12/6/2010 11:48 AM: On 12/06/2010 12:30 PM, BJ Freeman wrote: The problem that Adam addressed was how to build these tests from the build.xml, not run them. That to me, is attainable, in the future but requires a lot more coding work. That wasn't what I said. I want to be able to run a selenium test from build.xml. I don't care how the test was created. But if the test has been added to trunk, I want a very simple command to run, that then tells me if it passes or not. If it requires setting up an external process, then the 'simple' tag doesn't apply. If it isn't simple, then it won't be run, and then errors would creep in.
Re: Calling selenium from the build XML was jquey
Sorry, I'm a little late on this thread. Is the logging problem related to SeleniumXml or another Selenium sub-probject? I believe the problem with SeleniumXml is that it run outside of the ofbiz container and doesn't have access to the log4j settings, etc that are available in the ofbiz container. A patch could be added to configure Seleniumxml to use the same log4j settings setup in the framework. Then the errors could be found in the same logs files as the other tests. is this what developers are asking for? Brett On Mon, Dec 6, 2010 at 3:15 PM, BJ Freeman bjf...@free-man.net wrote: thanks for the the clarification. No problem running tests from build. the problem is the errors at this time, can not be reported in the logs, only visually to log errors will take some work in selenium. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Adam Heath sent the following on 12/6/2010 11:48 AM: On 12/06/2010 12:30 PM, BJ Freeman wrote: The problem that Adam addressed was how to build these tests from the build.xml, not run them. That to me, is attainable, in the future but requires a lot more coding work. That wasn't what I said. I want to be able to run a selenium test from build.xml. I don't care how the test was created. But if the test has been added to trunk, I want a very simple command to run, that then tells me if it passes or not. If it requires setting up an external process, then the 'simple' tag doesn't apply. If it isn't simple, then it won't be run, and then errors would creep in.
Re: Calling selenium from the build XML was jquey
http://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#N231EE OFBiz SeleniumXml You will get an assertion (or other exception) if the test fails. this is to run from build.xml like ant selelium_orders (not yes in build)_ do you will get a build sucessful if test compelets. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Brett Palmer sent the following on 12/6/2010 4:30 PM: Sorry, I'm a little late on this thread. Is the logging problem related to SeleniumXml or another Selenium sub-probject? I believe the problem with SeleniumXml is that it run outside of the ofbiz container and doesn't have access to the log4j settings, etc that are available in the ofbiz container. A patch could be added to configure Seleniumxml to use the same log4j settings setup in the framework. Then the errors could be found in the same logs files as the other tests. is this what developers are asking for? Brett On Mon, Dec 6, 2010 at 3:15 PM, BJ Freemanbjf...@free-man.net wrote: thanks for the the clarification. No problem running tests from build. the problem is the errors at this time, can not be reported in the logs, only visually to log errors will take some work in selenium. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.comhttp://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Adam Heath sent the following on 12/6/2010 11:48 AM: On 12/06/2010 12:30 PM, BJ Freeman wrote: The problem that Adam addressed was how to build these tests from the build.xml, not run them. That to me, is attainable, in the future but requires a lot more coding work. That wasn't what I said. I want to be able to run a selenium test from build.xml. I don't care how the test was created. But if the test has been added to trunk, I want a very simple command to run, that then tells me if it passes or not. If it requires setting up an external process, then the 'simple' tag doesn't apply. If it isn't simple, then it won't be run, and then errors would creep in.
Re: jquey
Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
Hi Bruno, OK, then a tag should be sufficient. What about beforejQuery? Jacques From: Bruno Busco bruno.bu...@gmail.com Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
+1 ;-) 2010/12/5 Jacques Le Roux jacques.le.r...@les7arts.com Hi Bruno, OK, then a tag should be sufficient. What about beforejQuery? Jacques From: Bruno Busco bruno.bu...@gmail.com Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: Calling selenium from the build XML was jquey
Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha 2010/12/3 BJ Freeman bjf...@free-man.net what what level were you working on? I am working on scenarios for a user, like orderentry, adding products, placing order through Ecommerce. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 12:11 AM: Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heathdoo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml. -- Sascha Rodekamp Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: Calling selenium from the build XML was jquey
Le 05/12/2010 13:02, Sascha Rodekamp a écrit : Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha Hi Sascha, would it be possible to put all of this in a JIRA issue ? I may need some of this, and I may also need it to clarify what I want from Selenium in OFBiz (and work on it later...). Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: Calling selenium from the build XML was jquey
Le 05/12/2010 13:02, Sascha Rodekamp a écrit : Hi BJ, sorry for the late response, but i was not at home yesterday. :-). That was more or less a POC. I tried to create a showcase to test standard Application Screens (i.e. a standard ecommerce module). Therefore i created the unit tests with the selenium firefox plugin, modifyed the tests for my purposes and used them in a little selfmade testing framework. That was very simple. It reads test data (i.e user data, orders which should be placed ...) from an excel file (Apache POI), creates a list with the neded data and called the tests class with the unit tests, from this point selenium did all the work, run the test and give me a result. That's it. Maybe a little bit uncommon but as i said it was a POC for a certain use case :-) But at the end of the day a think there is a lot of stuff / test cases which can be handled by selenium, but i also noticed that it is a lot of work creating all the tests... Hope you get an idea what i was trying to do. Have a good day Sascha Hi Sascha, would it be possible to put all of this in a JIRA issue ? I may need some of this, and I may also need it to clarify what I want from Selenium in OFBiz (and work on it later...). Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: jquey
hi Jacques, Though i am not sure which is the best choice, but i strongly think that the jQuery branch should be merged with the trunk, without any further delay, primarily for these reasons: 1) that the code is reasonably complete, 2) most of the people in this thread have supported the merger of the code with the trunk, and most importantly 2) that the primary contributor of this work, ie. Sascha, has indicated that she has both the time and the willingness to address any issue/bugs that may arise after merging with the trunk. I think its not too ofter that someone has both the willingness and also the time to devote to such important transition in code. Hence we should not risk wasting such valuable man-hours, which otherwise may be available. Thanks Rohit - https://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3073021.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz smime.p7s Description: S/MIME cryptographic signature
Re: jquey
Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heath doo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re: jquey
IMO, there are 2 options for releasing branch(es). * Only one which will be later the official release. The problem is then whether people want to have Dojo/Prototype or jQuery in this new release branch. * Two branches, one which which will be later the official release and one which will not be officially released. I would consider it as a fork since it would have Dojo/Prototype when the official will have later jQuery. Maybe fork is not really appropriate, but I think you get my point. We could also make 2 official releases. One with Dojo/Prototype and another with jQuery. I'm not quite sure switching from Dojo/Prototype to jQuery requires a specific release... Other opinions, ideas? Thanks Jacques Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
I may be missing something, I don't see how to build a scenario of say doing a orderentry, can be built the say you suggest. in this scenario, it follows as if a user was inputting data and looking for results at the UI level. In simpliest, how would you redifine a element position? = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Adam Heath sent the following on 12/2/2010 10:42 PM: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re:Calling selenium from the build XML was jquey
what what level were you working on? I am working on scenarios for a user, like orderentry, adding products, placing order through Ecommerce. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 12:11 AM: Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heathdoo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re: jquey
Hi Jacques et al, there are no real options, IMHO, jQuery is the way to go. jQuery, like it or not, is now a somewhat established 'standard', allowing corporations to hire consultants and coders for. Additionally, the existing Dojo/Prototype/Scriptalicious codebase is a _mess_ and a lot of work to clean up. Sascha did very good work, also the backend seems much faster with jQuery. I think that a good fact/opinion collection already has happened on the mailing list, so that a decision can be made. Please prevent whatever happened that prohibited not actually releasing 10.04 until today. I suggest that, based on the input so far, the three top committers come to a unanimous conclusion and decide where to go and all follow in line. I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality. The outcome will outweigh the momentary pain. Greetings have a nice weekend, - Karl On 03.12.2010, at 11:47, Jacques Le Roux wrote: IMO, there are 2 options for releasing branch(es). * Only one which will be later the official release. The problem is then whether people want to have Dojo/Prototype or jQuery in this new release branch. * Two branches, one which which will be later the official release and one which will not be officially released. I would consider it as a fork since it would have Dojo/Prototype when the official will have later jQuery. Maybe fork is not really appropriate, but I think you get my point. We could also make 2 official releases. One with Dojo/Prototype and another with jQuery. I'm not quite sure switching from Dojo/Prototype to jQuery requires a specific release... Other opinions, ideas? Thanks Jacques Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz _ Lusini GmbH Karl Pitrich, Chief Technology Officer Adams-Lehmann-Straße 109, 80797 München Telefon +49 89 416170 113 Telefax +49 89 416170 190 E-Mail karl.pitr...@lusini.com Sitz der Gesellschaft: München, HRB 188366 Amtsgericht München, Geschäftsführer: Markus Bohl USt IdNr. DE 270565360, Steuernr. 152/131/90056 _ smime.p7s Description: S/MIME cryptographic signature
Re: jquey
ofbiz is to me is versatility with letting different implementation work side by side. the core is that the entities when modified will display at UI level with no other changes to code. If you add a field at entity level that field will display at the UI level with no more work. So as long as any effort keeps that philosophy then I have no problem. and as long as I can continued to work on my production servers without major changes, then I am ok with it. For those that want to change this, I suggest a different effort so they can resolve their requirement but not effect the basic philosophy of ofbiz design. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Karl Pitrich sent the following on 12/3/2010 7:49 AM: I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality.
Re: jquey
Good evening, BJ i'm on you're site. During the migration i tried to keep the old behavior. So if you're using standard components from the UI you're instances shouldn't be effected. And let me say that a few (UI) features, after the migration, are more stable and faster than the old once (i.e. the lookups). Another side point to merge in the next days is, that i have this month free time to fix bugs (which maybe occurs :-)) 2010/12/3 BJ Freeman bjf...@free-man.net ofbiz is to me is versatility with letting different implementation work side by side. the core is that the entities when modified will display at UI level with no other changes to code. If you add a field at entity level that field will display at the UI level with no more work. So as long as any effort keeps that philosophy then I have no problem. and as long as I can continued to work on my production servers without major changes, then I am ok with it. For those that want to change this, I suggest a different effort so they can resolve their requirement but not effect the basic philosophy of ofbiz design. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Karl Pitrich sent the following on 12/3/2010 7:49 AM: I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality. -- Sascha Rodekamp Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: jquey
so you have some selenium tests that work on the same pages between trunk and jquery. good to hear. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 11:32 AM: Good evening, BJ i'm on you're site. During the migration i tried to keep the old behavior. So if you're using standard components from the UI you're instances shouldn't be effected. And let me say that a few (UI) features, after the migration, are more stable and faster than the old once (i.e. the lookups). Another side point to merge in the next days is, that i have this month free time to fix bugs (which maybe occurs :-)) 2010/12/3 BJ Freemanbjf...@free-man.net ofbiz is to me is versatility with letting different implementation work side by side. the core is that the entities when modified will display at UI level with no other changes to code. If you add a field at entity level that field will display at the UI level with no more work. So as long as any effort keeps that philosophy then I have no problem. and as long as I can continued to work on my production servers without major changes, then I am ok with it. For those that want to change this, I suggest a different effort so they can resolve their requirement but not effect the basic philosophy of ofbiz design. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.comhttp://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Karl Pitrich sent the following on 12/3/2010 7:49 AM: I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality.
Re: jquey
I would be in favor to merge quickly, like the replacing of the ftl macroprocessor, the system only get properly tested when it is in the trunk. If it is in the trunk, we will help debugging it. Regards, Hans On Thu, 2010-12-02 at 00:18 -0500, Anil Patel wrote: Hans, On other thread Jacques indicated that work of migrating to JQuery is complete. Do you think, it will be good idea to merge JQuery branch with trunk quickly so you can add additional features much more easily? Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword ofbiz On Dec 1, 2010, at 10:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques From: Hans Bakker mailingl...@antwebsystems.com I would be in favor to merge quickly, like the replacing of the ftl macroprocessor, the system only get properly tested when it is in the trunk. If it is in the trunk, we will help debugging it. Regards, Hans On Thu, 2010-12-02 at 00:18 -0500, Anil Patel wrote: Hans, On other thread Jacques indicated that work of migrating to JQuery is complete. Do you think, it will be good idea to merge JQuery branch with trunk quickly so you can add additional features much more easily? Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword ofbiz On Dec 1, 2010, at 10:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
+1, always better to merge sooner, get more testing on it... Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com - Original Message - You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
+1 Yeah, I would love such a great Xmas present :-) -- Regards, Michael Xu (xudong) On Thu, Dec 2, 2010 at 8:45 PM, Sascha Rodekamp sascha.rodekamp.lynx.de@ googlemail.com wrote: You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
sigh so all work on Selenium screens will have to be re-done. Jacques Le Roux sent the following on 12/2/2010 1:35 AM: = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques From: Hans Bakker mailingl...@antwebsystems.com I would be in favor to merge quickly, like the replacing of the ftl macroprocessor, the system only get properly tested when it is in the trunk. If it is in the trunk, we will help debugging it. Regards, Hans On Thu, 2010-12-02 at 00:18 -0500, Anil Patel wrote: Hans, On other thread Jacques indicated that work of migrating to JQuery is complete. Do you think, it will be good idea to merge JQuery branch with trunk quickly so you can add additional features much more easily? Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword ofbiz On Dec 1, 2010, at 10:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
Why? Did you use Dojo or Prototype? Jacques BJ Freeman wrote: sigh so all work on Selenium screens will have to be re-done. Jacques Le Roux sent the following on 12/2/2010 1:35 AM: = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques From: Hans Bakker mailingl...@antwebsystems.com I would be in favor to merge quickly, like the replacing of the ftl macroprocessor, the system only get properly tested when it is in the trunk. If it is in the trunk, we will help debugging it. Regards, Hans On Thu, 2010-12-02 at 00:18 -0500, Anil Patel wrote: Hans, On other thread Jacques indicated that work of migrating to JQuery is complete. Do you think, it will be good idea to merge JQuery branch with trunk quickly so you can add additional features much more easily? Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword ofbiz On Dec 1, 2010, at 10:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
before I jump I guess I should test. my thinking was the screens as Selenium would see them be changed, so the tests would fail. will try over the weekend = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Jacques Le Roux sent the following on 12/2/2010 12:27 PM: Why? Did you use Dojo or Prototype? Jacques BJ Freeman wrote: sigh so all work on Selenium screens will have to be re-done. Jacques Le Roux sent the following on 12/2/2010 1:35 AM: = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques From: Hans Bakker mailingl...@antwebsystems.com I would be in favor to merge quickly, like the replacing of the ftl macroprocessor, the system only get properly tested when it is in the trunk. If it is in the trunk, we will help debugging it. Regards, Hans On Thu, 2010-12-02 at 00:18 -0500, Anil Patel wrote: Hans, On other thread Jacques indicated that work of migrating to JQuery is complete. Do you think, it will be good idea to merge JQuery branch with trunk quickly so you can add additional features much more easily? Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword ofbiz On Dec 1, 2010, at 10:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
Le 02/12/2010 21:48, BJ Freeman a écrit : before I jump I guess I should test. my thinking was the screens as Selenium would see them be changed, so the tests would fail. Hi BJ, maybe, but work should not be so important. Selenium are also broken when an elenent is changing its location, like a button-bar instead of a link, etc... Anyway, the problem will be in finding the element, so very little change in the end. Cheers, -- Erwan de FERRIERES www.nereide.biz
Re: jquey
Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Erwan de FERRIERES sent the following on 12/2/2010 1:50 PM: Le 02/12/2010 21:48, BJ Freeman a écrit : before I jump I guess I should test. my thinking was the screens as Selenium would see them be changed, so the tests would fail. Hi BJ, maybe, but work should not be so important. Selenium are also broken when an elenent is changing its location, like a button-bar instead of a link, etc... Anyway, the problem will be in finding the element, so very little change in the end. Cheers,
Re: jquey
Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: jquey
BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
jquey
We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
Seems like it would be prudent to wait until it is merged from the branch given the amount of work going on there already. Why don't you put your features into the jquery branch as further examples of where it will be utilized? Cheers, Ruppert On Dec 1, 2010, at 8:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
Re: jquey
Hans, On other thread Jacques indicated that work of migrating to JQuery is complete. Do you think, it will be good idea to merge JQuery branch with trunk quickly so you can add additional features much more easily? Thanks and Regards Anil Patel HotWax Media Inc Find us on the web at www.hotwaxmedia.com or Google Keyword ofbiz On Dec 1, 2010, at 10:21 PM, Hans Bakker wrote: We have a number of new ofbiz features lined up, however they use jquery... is it possble to add the jquery libraries earlier then waiting for the merge of the jquery branch? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates.
