[jira] [Resolved] (OFBIZ-4338) Can not load only seed datas
[ https://issues.apache.org/jira/browse/OFBIZ-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane DUCAS resolved OFBIZ-4338. --- Resolution: Fixed Can not load only seed datas - Key: OFBIZ-4338 URL: https://issues.apache.org/jira/browse/OFBIZ-4338 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Stéphane DUCAS Priority: Minor When trying to load only seed datas the full demo datas are loaded -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4338) Can not load only seed datas
[ https://issues.apache.org/jira/browse/OFBIZ-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065771#comment-13065771 ] Stéphane DUCAS commented on OFBIZ-4338: --- This happened because I removed the -delegator=default argument when importing datas.. When I put this argument evrything is ok.. Can not load only seed datas - Key: OFBIZ-4338 URL: https://issues.apache.org/jira/browse/OFBIZ-4338 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Stéphane DUCAS Priority: Minor When trying to load only seed datas the full demo datas are loaded -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Maven-esque directory structures (was Re: GSoC Project update: Code and Test separation of Ofbiz and Implementing pure webdriver)
I've been doing a little more research on Maven, and I'm guessing that the pattern that Ganath is proposing is at least partly based on the convention for src directories in Maven (which appears to be required for use of Maven, BTW... ie with their convention over configuration approach, which is certainly nice for various reasons even if it does impose certain constraints). If we wanted our src directories to be Maven-friendly, it would look like: component/src/main/java component/src/test/java In other words, if we're going to make a change, perhaps we should change to that as the Maven conventions seem to be turning into industry standards (perhaps because the Maven conventions are some of the few that exist and are even remotely widely used). Along that vein, we might also consider moving the files under component/script and even component/config to: component/src/main/resources BTW, just as a side note if we ever had Maven POM files, their location in each component would just be component/pom.xml -David On Jul 13, 2011, at 11:09 PM, Ganath Rathnayaka wrote: Hi David, Since we have the current structure of the code, component/src/main component/src/test which contains separated test and code. We can do the code transformation to, component/src component/src-test easily. But to build the project, it may need some work to change the build, commons and macros xml files. Since I need to finish the project before 16th August, I and Erwan need to change the scope of the project if this change need to be done because we have another part (implementing a webdriver) of the project to be done. Here I am expecting all your final decision before I make my next movement. thanks Ganath
Re: Maven-esque directory structures (was Re: GSoC Project update: Code and Test separation of Ofbiz and Implementing pure webdriver)
Thank you David. -Adrian On 7/15/2011 10:03 AM, David E Jones wrote: I've been doing a little more research on Maven, and I'm guessing that the pattern that Ganath is proposing is at least partly based on the convention for src directories in Maven (which appears to be required for use of Maven, BTW... ie with their convention over configuration approach, which is certainly nice for various reasons even if it does impose certain constraints). If we wanted our src directories to be Maven-friendly, it would look like: component/src/main/java component/src/test/java In other words, if we're going to make a change, perhaps we should change to that as the Maven conventions seem to be turning into industry standards (perhaps because the Maven conventions are some of the few that exist and are even remotely widely used). Along that vein, we might also consider moving the files undercomponent/script and evencomponent/config to: component/src/main/resources BTW, just as a side note if we ever had Maven POM files, their location in each component would just becomponent/pom.xml -David On Jul 13, 2011, at 11:09 PM, Ganath Rathnayaka wrote: Hi David, Since we have the current structure of the code, component/src/main component/src/test which contains separated test and code. We can do the code transformation to, component/src component/src-test easily. But to build the project, it may need some work to change the build, commons and macros xml files. Since I need to finish the project before 16th August, I and Erwan need to change the scope of the project if this change need to be done because we have another part (implementing a webdriver) of the project to be done. Here I am expecting all your final decision before I make my next movement. thanks Ganath
Re: Changing the Jar files loading order
Info about that are contained in the README.txt file in the hot-deploy folder. -Bruno 2011/7/14 Scott Gray scott.g...@hotwaxmedia.com On 14/07/2011, at 8:12 AM, Adam Heath wrote: On 07/11/2011 05:50 AM, Ajay Lashkari wrote: Hi All, when we start the ofbiz, it loads framework-applications-specialpurpose and then hot-deploy. so please tell me that if there is a way to change the loading order of there relevant jar files , from where i can change it? if there is any file exist for that configuration please tell me the name of it. If you want to change the order of things that are loaded from hot-deploy, then just change the name to something that will sort earlier alphabetically. Ie: hot-deploy/foo loads *after* hot-deploy/bar. hot-deploy/00-foo would load *before* bar. Or you can just drop a component-load.xml into the hot-deploy folder and explicitly define the load order.
