Thanks for detailed advantages of going with this approach. My +1 for going with this approach.
Thanks -- Divesh Dutta On Wed, Jan 21, 2015 at 2:36 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> > wrote: > > > Have you a clear idea of that this entails in term of migration, no only > OOTB, but for custom projects which relies on trunk? > > I did some reasonings about it and it shouldn't be a big deal, especially > on the programming side (it will require mostly search and replace > sessions); of course I didn't do a thorough analysis, I just wanted to > start the conversation here; the good news is that it can be done in > chunks, hopefully with the help of the community (that could also support > the migration of custom projects). > > > I guess for Java it should not be so hard but for minilang and groovy > could be harder, everybody does not use Idea (groovy part)... > > I am sorry but the above sentence doesn't make any sense to me... > > > > > Also what does this bring to the project? Why do you want to do so > (apart being in line with other projects)? And why should we be in line > with them, do you envision something? > > The main advantages are the following: > > 1) standardize our layout structure to make it consistent with other > projects (may make it easier for a new developer to understand OFBiz and > appreciate it since the beginning) > 2) review of past decision in light of the experience, lessons learned and > established conventions: most of the decision we took for the project were > optimal at that time but may be suboptimal in light of new technologies, > standards, trends etc... in order for our (more than 10 years old) project > to stay fresh and healthy we have to always revisit our decisions and keep > it young; when the first objection to proposals is that this could impact > custom projects or existing contributors, then in my opinion it is a sign > of defensive mentality that could bring to staleness; these concerns and > considerations are still important, but should be discussed (trying to > propose a good migration plan) at a later point and not used to slow down > or stop the change > 3) simplify the pre compilation of Groovy (and possibly other) scripts: > this could be done to spot coding errors in advance, to improve performance > at runtime, or just to simplify the deployment > 4) simplify our build scripts: right now the ant scripts do some > funny/complex stuff in order to separate test classes from main ones > 5) moving a step forward in the direction of allowing the adoption of > Maven like tools (Maven, Gradle etc..) that could make it easier to share > external components (grow the ecosystem) > 6) right now there is not a standard place for non-Java services or > events: the script folder is traditionally used for Minilang, where should > Groovy (or other languages) service implementation live? > 7) I have some, longer term, plans to make the OFBiz framework codebase > more modular: several smaller jars with clear dependencies that could be > deployed in different ways (vs the monolithic approach we have to follow > now); a standardization of the source folders may help the adoption of > tools and strategies for achieving this > > Regards, > > Jacopo > > > > > Jacques > > > > Le 20/01/2015 12:41, Jacopo Cappellato a écrit : > >> In my opinion it would be nice to review how we organize the code in > our components and switch to a directory layout that is more inline with > what other projects are doing, for example: > >> > >> > http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html > >> > >> More specifically I would like to switch from, for example: > >> > >> script/org/ofbiz/product/ > >> src/org/ofbiz/product/ > >> src/org/ofbiz/product/test/ > >> > >> to: > >> > >> src/main/java/org/ofbiz/product/ > >> src/main/minilang/org/ofbiz/product/ > >> src/main/groovy/... > >> src/test/java/org/ofbiz/product/ > >> > >> What do you think? > >> > >> Jacopo > >> > >
