On Jan 20, 2015, at 1:49 PM, Jacques Le Roux <[email protected]> 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 >>
