I can imagine that some will vote a -1 regarding this reorganisation of the structure, as this will break backward compatibility and puts the pressure on all those users who have created extensions and replacements (e.g. in hot-deploy), especially regarding referenced scripts.
How do we ensure that the pain is minimised? How do we plan for success? Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Sat, Apr 25, 2015 at 9:45 AM, Jacopo Cappellato < [email protected]> wrote: > 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 >
