Hi
As newbie, I do not know exactly the origin of this "never endind story for a small task", but in no way thoses small tasks should end in the bin directory, because under Eclipse this is where all callses are generated and when doing a refresh or a clean project, all stuff in the bin directory is *erased*. Thus do never put something in the output directory of an Eclipse Java projet,i.e, usually the bin directory. Le 26/03/2012 23:05, Mansour Al Akeel a écrit : > Jacopo, > thank you for your efforts in moving this project forward. I have been > following the other thread, and didn't want to comment. However, since > you need feed back, here we go. > > I think those scripts should be removed. In fact I believe we > shouldn't even deliver the project with tomcat. I like to see ofbiz > with a build system that produces a war file or osgi bundle. When > deployed to a container it points to a location on the file system > where applications are. We have seen this already in moqui. And it > allows us to configure it for different containers. Back again to the > subject of distributing tomcat with ofbiz, I prefer not to get a > software that is distributed with its platform. For example, if I need > a browser I will just go an install it, but I will never install a > browser that is bundled with an operating system unless I need to > install an operating system. I am not sure if my point is clear here. > > Users that find it extremely tedious and confusing to type "./tools" > in front of the executable name, can configure their SVN not to update > these files. I don't use SVN personally. I configured git to pull from > SVN, and I use git directly, so I can not give directions about how to > do this, but a quick search returns this, > http://stackoverflow.com/questions/895548/subversion-ignore-modifications-to-a-file-locally-on-one-client-only > And I think continuous integration can be re-configured to adopt these > changes on the client side. > > Using ant task is not so bad. I think it supports something like > daemons in the parallel task, where tomcat can be started in the > background. > another task from antconrib is "forget" > http://ant-contrib.sourceforge.net/tasks/tasks/forget.html > > Another solution is to modify the PATH env variable. This works on my > box and should work on any linux box using "bash". Here's what I just > did: > > 04:34:38 @ ofbiz.svn $ # let's delete startofbiz.sh in the root !! > 04:35:11 @ ofbiz.svn $ rm startofbiz.sh > 04:35:15 @ ofbiz.svn $ export PATH=$PATH:./tools > 04:35:35 @ ofbiz.svn $ which startofbiz.sh > /home/mansour/workspace/ofbiz.src/ofbiz.svn/tools/startofbiz.sh > > I am not sure how to do it on windows. So someone else may enlighten > us by the wonderful work around to run an executable script with out > having to type "tools". > > So this can be added to the login script on Hans machine, for the > account running ofbiz: > > export PATH=$PATH:./tools > > and should be good to go after activating the login script. > > Bottom line, > I prefer to remove them for cosmetic reasons, and to get the users > used to do some extra on their side (like typing the extra "./tools"). > But at the same time, I don't really see harm keeping those scripts in > the root of ofbiz, and since it not significant. > > My only concern is more about politics involved in making future > decisions related to the progress of ofbiz. If we have to go through > this to change the location of a script, what are we going to do, when > and if we (the community) decided to do a major change ?!! > > This is exactly how I feel Jacopo. > > > > On Mon, Mar 26, 2012 at 5:43 AM, Jacopo Cappellato > <[hidden email]> wrote: >> Here is an update on this never-ending story for a small task :-) >> All my work is now back into the trunk: this means that all the executable scripts (*.sh and *.bat) are now under the "tools" folder. This means that from now on in trunk (and in future releases from 12.04 on) in order to run the scripts, assuming you are in the OFBiz home folder, you will have to: >> a) "cd" to the "tools" folder and then run the scripts as usual OR >> b) run the scripts specifying the "tools" path; for example "./tools/startofbiz.sh" >> >> However there is a simpler way of starting a stopping OFBiz from the home folder (in all operating systems): >> 1) starting ofbiz: >> ant run >> 2) stopping ofbiz: >> ant stop >> >> The two commands above are essentially the same of the startofbiz/stopofiz.sh/bat versions. >> The OFBiz README file has been already updated to reflect these changes, so users will be informed. >> >> Now we need your help/input to complete this work: >> >> 1) please test the scripts, the "ant" versions and the ones moved under the "tools" folder (because we had to modify them to make them work from the new location), in your os/platform: we did some limited tests on Linux/OSX but it would be great to get more feedback (especially for the Windows versions) >> >> 2) what about renaming the "ant run" task into "ant start"? In my opinion it will be easier to have an "ant start" and an "ant stop" commands to manage the OFBiz instance >> >> 3) Hans copied the original version of the start and stop scripts for Linux/Unix (startofbiz.sh and stopofbiz.sh) back in the OFBiz home folder; Hans has provided several reasons for this but I will summarize here only the ones that (in my opinion) make sense (you can read the other thread if interested or Hans is free to add them here if he really thinks that what I have suppressed actually makes sense in this context): >> 3.a) backward compatibility for the Unix/Linux users: Linux users that are used at running the start and stop scripts from the home folder can still do this without having to cd to the tools folder (or use the "tools/" prefix) or without having to switch to the "ant" equivalents >> 3.b) Hans preference would be to remove these duplicated scripts from the home folder and replace them with symlinks (and probably provide similar ones for Windows) to the scripts in the "tools" folder >> In my opinion adding the symlinks (or keeping the copies of the scripts in the home folder) for backward compatibility is not necessary... or at least it is something we could revisit/reconsider if people will start to complain. >> Even if it will not be terrible to have them in the home folder I think it somewhat defeats the original purpose of this change: have a cleaner home folder with as less files as possible (to give more visibility to README and License files). >> Of course old users will have to adjust to this but I don't expect it to be too difficult, especially if we improve our docs to help them use the "ant" versions more. >> I know this is somewhat trivial decision (and I am sorry to bother you) but it seems that Hans has a strong opinion on this and before giving up and letting him decide for all I thought it was good to check the general feeling of the community. >> >> This is all, thank you >> >> Jacopo >> >> >> On Mar 24, 2012, at 7:19 AM, Jacopo Cappellato wrote: >> >>> Part of my changes has been reverted by Hans in rev. 1304679 and 1304687 (we are discussing this in another thread) but I would really appreciate if in the meantime you all could help to test my changes (before the revert). >>> >>> Thanks, >>> >>> Jacopo >>> >>> On Mar 23, 2012, at 3:15 PM, Jacopo Cappellato wrote: >>> >>>> Jose, Price, >>>> >>>> thank you for your feedback, it really helps. >>>> Jose, I have modified the script according to your suggestions, thank you. >>>> I am going to commit the changes shortly. >>>> >>>> Thanks, >>>> >>>> Jacopo >>>> >>>> >>>> On Mar 23, 2012, at 11:43 AM, Prince Sewani wrote: >>>> >>>>> Hi Jacopo, >>>>> >>>>> Although I'm not a windows user but yes it works fine from the tools folder on windows. >>>>> >>>>> >>>>> Regards >>>>> Prince >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> From: Jacopo Cappellato<[hidden email]> >>>>> To: [hidden email] >>>>> Sent: Friday, March 23, 2012 3:32 PM >>>>> Subject: Re: "bin" folder for executable files/scripts >>>>> >>>>> Actually, the /d shouldn't be required: >>>>> >>>>> =========================================== >>>>> echo off >>>>> set OFBIZ_HOME=%0\..\..\ >>>>> echo on >>>>> cd %OFBIZ_HOME% >>>>> "%JAVA_HOME%\bin\java" -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar >>>>> echo off >>>>> =========================================== >>>>> >>>>> Thanks, >>>>> >>>>> Jacopo >>>>> >>>>> On Mar 23, 2012, at 10:57 AM, Jacopo Cappellato wrote: >>>>> >>>>>> I did progress on this: I was able to move all the scripts to the "tools" folder; I didn't add the "bin" subfolder to it because the existing files in the "tools" folder are not used and can be removed: in this way we will have a "tools" folder containing all the platform dependent scripts. >>>>>> But now I need some help from Windows users: >>>>>> >>>>>> could you please try to create a "startofbiz.bat" file in the "tools" folder with the following content: >>>>>> =========================================== >>>>>> echo off >>>>>> set OFBIZ_HOME=%0\..\..\ >>>>>> echo on >>>>>> cd /d %OFBIZ_HOME% >>>>>> "%JAVA_HOME%\bin\java" -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar >>>>>> echo off >>>>>> =========================================== >>>>>> >>>>>> Then you should try to run it from the home folder: >>>>>> >>>>>> tools\startorfbiz.bat >>>>>> >>>>>> and from the tools folder: >>>>>> >>>>>> cd tools >>>>>> startorfbiz.bat >>>>>> >>>>>> Both should work fine: I already did this work for the sh files but I couldn't test the above mechanism for Windows. >>>>>> >>>>>> I would really appreciate your feedback. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>>>> On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote: >>>>>> >>>>>>> Well the 'bin' clashing with eclipse default is really a concern >>>>>>> to being with, the learning curve is yet steep, and with to dos of IDE's as of now, >>>>>>> everyone is pretty much acquainted. Also in-case we change it to 'bin' in the main folder, >>>>>>> then there'll be an additional set of documentation required for that to help users on different Operating systems. >>>>>>> >>>>>>> Unless we go like opentaps (felt that on a few things) and then one is not really able to use it (Just a comment No offense). >>>>>>> >>>>>>> >>>>>>> "tools/bin" sounds great, unless that also doesn't call of any other clash or so. >>>>>>> >>>>>>> Regards >>>>>>> Prince >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Mansour Al Akeel<[hidden email]> >>>>>>> To: [hidden email] >>>>>>> Sent: Monday, March 19, 2012 4:13 PM >>>>>>> Subject: Re: "bin" folder for executable files/scripts >>>>>>> >>>>>>> bin is good enough. >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux >>>>>>> <[hidden email]> wrote: >>>>>>>> Hi Jacopo, >>>>>>>> >>>>>>>> tools/bin sounds good to me >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> From: "Jacopo Cappellato"<[hidden email]> >>>>>>>> >>>>>>>>> Thanks everyone for the valuable comments! >>>>>>>>> I am trying to finalize this thread: there seems to be consensus to move >>>>>>>>> all the executable scripts into a folder to keep things organized. >>>>>>>>> For the name of the folder: >>>>>>>>> * some of you think that the "bin" (as I originally suggested) should be >>>>>>>>> used because it is often used for this purpose >>>>>>>>> * some of you are worried that this could interfere with some commonly >>>>>>>>> used IDEs (e.g. Eclipse) that use the bin folder for output and need to be >>>>>>>>> configured to use a different standard name >>>>>>>>> >>>>>>>>> After reviewing what we have now in OFBiz I am wondering if we could use >>>>>>>>> the already existing "tools" folder; its current layout is: >>>>>>>>> tools/api-java16 >>>>>>>>> tools/src >>>>>>>>> >>>>>>>>> option a: add all the executables to tools/ folder directly >>>>>>>>> option b: create a subfolder tools/bin and add all the executables there >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote: >>>>>>>>> >>>>>>>>>> Then we could recommend to name .bin for instance >>>>>>>>>> But I wonder if this will not be a source of problem for newbies... >>>>>>>>>> >>>>>>>>>> And also for Windows users, bin is not a standard name at all >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> From: "Adrian Crum"<[hidden email]> >>>>>>>>>>> That's fine with me. We just need to update the Eclipse configuration >>>>>>>>>>> files. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> On 2/29/2012 3:20 PM, J. Eckard wrote: >>>>>>>>>>>> I think that eclipse / eclipse users should have to accommodate the >>>>>>>>>>>> directory structure of OFBiz, not the other way around. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the feedback! Any suggestion for the name of the folder? I >>>>>>>>>>>>> was hoping to use a "standard" name, that is why I initially proposed the >>>>>>>>>>>>> "bin" folder... but since that is not an option we will have to think to >>>>>>>>>>>>> something else (unless we use the existing "tools" folder but I am not sure >>>>>>>>>>>>> about the intended usage of that). >>>>>>>>>>>>> >>>>>>>>>>>>> Jacopo >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> +1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>> >>>>>>>>>>>>>> From: "Adrian Crum"<[hidden email]> >>>>>>>>>>>>>>> Sounds great, but don't use "bin" - that folder is created by >>>>>>>>>>>>>>> Eclipse and it is in the SVN ignore list. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2/27/2012 7:10 PM, Jacopo Cappellato wrote: >>>>>>>>>>>>>>>> The number of executable files (*.sh and *bat) in the OFBiz home >>>>>>>>>>>>>>>> folder is rather big: what if we create a "bin" folder and we move all of >>>>>>>>>>>>>>>> them there? In this way users will have a place where they will find all the >>>>>>>>>>>>>>>> executable files only and the main folder will be cleaner. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> |
Hi Francis,
sorry for the confusion (the subject is misleading) but we actually decided to not use the bin folder to avoid issues with Eclipse or other editors; all the scripts are now in the "tools" folder. Jacopo On Mar 27, 2012, at 5:51 AM, Francis ANDRE wrote: > Hi > > As newbie, I do not know exactly the origin of this "never endind story for a small task", but in no way thoses small tasks should end in the bin directory, because under Eclipse this is where all callses are generated and when doing a refresh or a clean project, all stuff in the bin directory is *erased*. > > Thus do never put something in the output directory of an Eclipse Java projet,i.e, usually the bin directory. > > > > Le 26/03/2012 23:05, Mansour Al Akeel a écrit : >> Jacopo, >> thank you for your efforts in moving this project forward. I have been >> following the other thread, and didn't want to comment. However, since >> you need feed back, here we go. >> >> I think those scripts should be removed. In fact I believe we >> shouldn't even deliver the project with tomcat. I like to see ofbiz >> with a build system that produces a war file or osgi bundle. When >> deployed to a container it points to a location on the file system >> where applications are. We have seen this already in moqui. And it >> allows us to configure it for different containers. Back again to the >> subject of distributing tomcat with ofbiz, I prefer not to get a >> software that is distributed with its platform. For example, if I need >> a browser I will just go an install it, but I will never install a >> browser that is bundled with an operating system unless I need to >> install an operating system. I am not sure if my point is clear here. >> >> Users that find it extremely tedious and confusing to type "./tools" >> in front of the executable name, can configure their SVN not to update >> these files. I don't use SVN personally. I configured git to pull from >> SVN, and I use git directly, so I can not give directions about how to >> do this, but a quick search returns this, >> http://stackoverflow.com/questions/895548/subversion-ignore-modifications-to-a-file-locally-on-one-client-only >> And I think continuous integration can be re-configured to adopt these >> changes on the client side. >> >> Using ant task is not so bad. I think it supports something like >> daemons in the parallel task, where tomcat can be started in the >> background. >> another task from antconrib is "forget" >> http://ant-contrib.sourceforge.net/tasks/tasks/forget.html >> >> Another solution is to modify the PATH env variable. This works on my >> box and should work on any linux box using "bash". Here's what I just >> did: >> >> 04:34:38 @ ofbiz.svn $ # let's delete startofbiz.sh in the root !! >> 04:35:11 @ ofbiz.svn $ rm startofbiz.sh >> 04:35:15 @ ofbiz.svn $ export PATH=$PATH:./tools >> 04:35:35 @ ofbiz.svn $ which startofbiz.sh >> /home/mansour/workspace/ofbiz.src/ofbiz.svn/tools/startofbiz.sh >> >> I am not sure how to do it on windows. So someone else may enlighten >> us by the wonderful work around to run an executable script with out >> having to type "tools". >> >> So this can be added to the login script on Hans machine, for the >> account running ofbiz: >> >> export PATH=$PATH:./tools >> >> and should be good to go after activating the login script. >> >> Bottom line, >> I prefer to remove them for cosmetic reasons, and to get the users >> used to do some extra on their side (like typing the extra "./tools"). >> But at the same time, I don't really see harm keeping those scripts in >> the root of ofbiz, and since it not significant. >> >> My only concern is more about politics involved in making future >> decisions related to the progress of ofbiz. If we have to go through >> this to change the location of a script, what are we going to do, when >> and if we (the community) decided to do a major change ?!! >> >> This is exactly how I feel Jacopo. >> >> >> >> On Mon, Mar 26, 2012 at 5:43 AM, Jacopo Cappellato >> <[hidden email]> wrote: >>> Here is an update on this never-ending story for a small task :-) >>> All my work is now back into the trunk: this means that all the executable scripts (*.sh and *.bat) are now under the "tools" folder. This means that from now on in trunk (and in future releases from 12.04 on) in order to run the scripts, assuming you are in the OFBiz home folder, you will have to: >>> a) "cd" to the "tools" folder and then run the scripts as usual OR >>> b) run the scripts specifying the "tools" path; for example "./tools/startofbiz.sh" >>> >>> However there is a simpler way of starting a stopping OFBiz from the home folder (in all operating systems): >>> 1) starting ofbiz: >>> ant run >>> 2) stopping ofbiz: >>> ant stop >>> >>> The two commands above are essentially the same of the startofbiz/stopofiz.sh/bat versions. >>> The OFBiz README file has been already updated to reflect these changes, so users will be informed. >>> >>> Now we need your help/input to complete this work: >>> >>> 1) please test the scripts, the "ant" versions and the ones moved under the "tools" folder (because we had to modify them to make them work from the new location), in your os/platform: we did some limited tests on Linux/OSX but it would be great to get more feedback (especially for the Windows versions) >>> >>> 2) what about renaming the "ant run" task into "ant start"? In my opinion it will be easier to have an "ant start" and an "ant stop" commands to manage the OFBiz instance >>> >>> 3) Hans copied the original version of the start and stop scripts for Linux/Unix (startofbiz.sh and stopofbiz.sh) back in the OFBiz home folder; Hans has provided several reasons for this but I will summarize here only the ones that (in my opinion) make sense (you can read the other thread if interested or Hans is free to add them here if he really thinks that what I have suppressed actually makes sense in this context): >>> 3.a) backward compatibility for the Unix/Linux users: Linux users that are used at running the start and stop scripts from the home folder can still do this without having to cd to the tools folder (or use the "tools/" prefix) or without having to switch to the "ant" equivalents >>> 3.b) Hans preference would be to remove these duplicated scripts from the home folder and replace them with symlinks (and probably provide similar ones for Windows) to the scripts in the "tools" folder >>> In my opinion adding the symlinks (or keeping the copies of the scripts in the home folder) for backward compatibility is not necessary... or at least it is something we could revisit/reconsider if people will start to complain. >>> Even if it will not be terrible to have them in the home folder I think it somewhat defeats the original purpose of this change: have a cleaner home folder with as less files as possible (to give more visibility to README and License files). >>> Of course old users will have to adjust to this but I don't expect it to be too difficult, especially if we improve our docs to help them use the "ant" versions more. >>> I know this is somewhat trivial decision (and I am sorry to bother you) but it seems that Hans has a strong opinion on this and before giving up and letting him decide for all I thought it was good to check the general feeling of the community. >>> >>> This is all, thank you >>> >>> Jacopo >>> >>> >>> On Mar 24, 2012, at 7:19 AM, Jacopo Cappellato wrote: >>> >>>> Part of my changes has been reverted by Hans in rev. 1304679 and 1304687 (we are discussing this in another thread) but I would really appreciate if in the meantime you all could help to test my changes (before the revert). >>>> >>>> Thanks, >>>> >>>> Jacopo >>>> >>>> On Mar 23, 2012, at 3:15 PM, Jacopo Cappellato wrote: >>>> >>>>> Jose, Price, >>>>> >>>>> thank you for your feedback, it really helps. >>>>> Jose, I have modified the script according to your suggestions, thank you. >>>>> I am going to commit the changes shortly. >>>>> >>>>> Thanks, >>>>> >>>>> Jacopo >>>>> >>>>> >>>>> On Mar 23, 2012, at 11:43 AM, Prince Sewani wrote: >>>>> >>>>>> Hi Jacopo, >>>>>> >>>>>> Although I'm not a windows user but yes it works fine from the tools folder on windows. >>>>>> >>>>>> >>>>>> Regards >>>>>> Prince >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> From: Jacopo Cappellato<[hidden email]> >>>>>> To: [hidden email] >>>>>> Sent: Friday, March 23, 2012 3:32 PM >>>>>> Subject: Re: "bin" folder for executable files/scripts >>>>>> >>>>>> Actually, the /d shouldn't be required: >>>>>> >>>>>> =========================================== >>>>>> echo off >>>>>> set OFBIZ_HOME=%0\..\..\ >>>>>> echo on >>>>>> cd %OFBIZ_HOME% >>>>>> "%JAVA_HOME%\bin\java" -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar >>>>>> echo off >>>>>> =========================================== >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jacopo >>>>>> >>>>>> On Mar 23, 2012, at 10:57 AM, Jacopo Cappellato wrote: >>>>>> >>>>>>> I did progress on this: I was able to move all the scripts to the "tools" folder; I didn't add the "bin" subfolder to it because the existing files in the "tools" folder are not used and can be removed: in this way we will have a "tools" folder containing all the platform dependent scripts. >>>>>>> But now I need some help from Windows users: >>>>>>> >>>>>>> could you please try to create a "startofbiz.bat" file in the "tools" folder with the following content: >>>>>>> =========================================== >>>>>>> echo off >>>>>>> set OFBIZ_HOME=%0\..\..\ >>>>>>> echo on >>>>>>> cd /d %OFBIZ_HOME% >>>>>>> "%JAVA_HOME%\bin\java" -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar >>>>>>> echo off >>>>>>> =========================================== >>>>>>> >>>>>>> Then you should try to run it from the home folder: >>>>>>> >>>>>>> tools\startorfbiz.bat >>>>>>> >>>>>>> and from the tools folder: >>>>>>> >>>>>>> cd tools >>>>>>> startorfbiz.bat >>>>>>> >>>>>>> Both should work fine: I already did this work for the sh files but I couldn't test the above mechanism for Windows. >>>>>>> >>>>>>> I would really appreciate your feedback. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>>> On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote: >>>>>>> >>>>>>>> Well the 'bin' clashing with eclipse default is really a concern >>>>>>>> to being with, the learning curve is yet steep, and with to dos of IDE's as of now, >>>>>>>> everyone is pretty much acquainted. Also in-case we change it to 'bin' in the main folder, >>>>>>>> then there'll be an additional set of documentation required for that to help users on different Operating systems. >>>>>>>> >>>>>>>> Unless we go like opentaps (felt that on a few things) and then one is not really able to use it (Just a comment No offense). >>>>>>>> >>>>>>>> >>>>>>>> "tools/bin" sounds great, unless that also doesn't call of any other clash or so. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prince >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: Mansour Al Akeel<[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> Sent: Monday, March 19, 2012 4:13 PM >>>>>>>> Subject: Re: "bin" folder for executable files/scripts >>>>>>>> >>>>>>>> bin is good enough. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux >>>>>>>> <[hidden email]> wrote: >>>>>>>>> Hi Jacopo, >>>>>>>>> >>>>>>>>> tools/bin sounds good to me >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> From: "Jacopo Cappellato"<[hidden email]> >>>>>>>>> >>>>>>>>>> Thanks everyone for the valuable comments! >>>>>>>>>> I am trying to finalize this thread: there seems to be consensus to move >>>>>>>>>> all the executable scripts into a folder to keep things organized. >>>>>>>>>> For the name of the folder: >>>>>>>>>> * some of you think that the "bin" (as I originally suggested) should be >>>>>>>>>> used because it is often used for this purpose >>>>>>>>>> * some of you are worried that this could interfere with some commonly >>>>>>>>>> used IDEs (e.g. Eclipse) that use the bin folder for output and need to be >>>>>>>>>> configured to use a different standard name >>>>>>>>>> >>>>>>>>>> After reviewing what we have now in OFBiz I am wondering if we could use >>>>>>>>>> the already existing "tools" folder; its current layout is: >>>>>>>>>> tools/api-java16 >>>>>>>>>> tools/src >>>>>>>>>> >>>>>>>>>> option a: add all the executables to tools/ folder directly >>>>>>>>>> option b: create a subfolder tools/bin and add all the executables there >>>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote: >>>>>>>>>> >>>>>>>>>>> Then we could recommend to name .bin for instance >>>>>>>>>>> But I wonder if this will not be a source of problem for newbies... >>>>>>>>>>> >>>>>>>>>>> And also for Windows users, bin is not a standard name at all >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> From: "Adrian Crum"<[hidden email]> >>>>>>>>>>>> That's fine with me. We just need to update the Eclipse configuration >>>>>>>>>>>> files. >>>>>>>>>>>> >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> On 2/29/2012 3:20 PM, J. Eckard wrote: >>>>>>>>>>>>> I think that eclipse / eclipse users should have to accommodate the >>>>>>>>>>>>> directory structure of OFBiz, not the other way around. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the feedback! Any suggestion for the name of the folder? I >>>>>>>>>>>>>> was hoping to use a "standard" name, that is why I initially proposed the >>>>>>>>>>>>>> "bin" folder... but since that is not an option we will have to think to >>>>>>>>>>>>>> something else (unless we use the existing "tools" folder but I am not sure >>>>>>>>>>>>>> about the intended usage of that). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacopo >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: "Adrian Crum"<[hidden email]> >>>>>>>>>>>>>>>> Sounds great, but don't use "bin" - that folder is created by >>>>>>>>>>>>>>>> Eclipse and it is in the SVN ignore list. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/27/2012 7:10 PM, Jacopo Cappellato wrote: >>>>>>>>>>>>>>>>> The number of executable files (*.sh and *bat) in the OFBiz home >>>>>>>>>>>>>>>>> folder is rather big: what if we create a "bin" folder and we move all of >>>>>>>>>>>>>>>>> them there? In this way users will have a place where they will find all the >>>>>>>>>>>>>>>>> executable files only and the main folder will be cleaner. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> |
In reply to this post by Mansour
On Mar 26, 2012, at 11:05 PM, Mansour Al Akeel wrote: > [...] My only concern is more about politics involved in making future > decisions related to the progress of ofbiz. If we have to go through > this to change the location of a script, what are we going to do, when > and if we (the community) decided to do a major change ?!! > > This is exactly how I feel Jacopo. This is actually the main problem that I am determined to fix: the problem is real and the consequence of it is evident in the status of the OFBiz codebase. The situation will greatly improve when committers will understand that we *have* to use our commit rights to serve the OFBiz community by implementing what is decided in the OFBiz dev list (and not to freely contribute our own code to the project). In the past this didn't happen also because there was not a common strategy for the project and so "every contribution" was good for the project and every committer was authorized to contribute what she/he wanted... this was an anomaly that we are now fixing but of course we have to face with the resistance from committers that were used to do what they wanted to without constraints. But I am very determined and confident that this will soon be fixed because committers can't use the power, that the OFBiz PMC gave them to serve the project, to block or refrain what the community decided and so we will have to get comfortable with the new situation (and the OFBiz PMC will oversight this situation). Kind regards, Jacopo |
In reply to this post by Mansour
On Mar 26, 2012, at 11:05 PM, Mansour Al Akeel wrote: > Using ant task is not so bad. I think it supports something like > daemons in the parallel task, where tomcat can be started in the > background. > another task from antconrib is "forget" > http://ant-contrib.sourceforge.net/tasks/tasks/forget.html Mansour, this is interesting, thank you. I think we can add a new task to run OFBiz as a separate process using the "spawn" attribute: <target name="run-batch" description="This will start OFBiz in a separate process"> <java jar="ofbiz.jar" fork="true" spawn="true"> <jvmarg value="${memory.initial.param}"/> <jvmarg value="${pos.memory.max.param}"/> <jvmarg value="${memory.maxpermsize.param}"/> <sysproperty key="ofbiz.admin.port" value="${ofbiz.admin.port}"/> <sysproperty key="ofbiz.admin.key" value="${ofbiz.admin.key}"/> </java> </target> Jacopo |
Free forum by Nabble | Edit this page |