On Apr 24, 2015, at 5:01 PM, Adam Heath <[email protected]> wrote:
> On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: >> On Apr 24, 2015, at 4:36 PM, Adam Heath <[email protected]> wrote: >> >>>>> src/main/java/org/ofbiz/product/ >>>>> src/main/minilang/org/ofbiz/product/ >>>>> src/main/groovy/... >>>>> src/test/java/org/ofbiz/product/ >>> I haven't yet gotten to integrating a groovy compiler plugin, I see only >>> one .groovy in framework/service/src, for the entire project. >> When I proposed this I was also thinking about to move the groovy (data >> preparation) scripts that are currently under WEB-INF/actions folders; most >> of them could be used in non web applications. > > Hmm, right. Good idea. We(Brainfood) would love it if all the action code > was turned into services. But, even in that case, src/main/scripts would be > used, as I think src/main/groovy is for groovyc. I'll find out today if that > is the case. I like the idea of differentiating between pre-compiled vs parsed scripts using src/main/groovy vs src/main/scripts Just to re-state the motivations for my initial proposal I am quoting here them from a previous message in this thread (I apologize for the double posting but I my comments may have been lost in this long thread): > 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
