Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 02:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ If each component were released separately, then it becomes a non-problem. I haven't yet given up on this, tho.
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 03:16 AM, Jacques Le Roux wrote: Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend api layer. Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code.
Re: Proposal: redefining the components' directory layout for source files
On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? Ant is the ultimate in flexibility. The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz. I would be tempted to look at providing alternative Ant builds. It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html Having Ant scripts that build individual components or groups of components should be pretty simple. It is also possible to deploy artifacts built with Ant to Maven Central. http://central.sonatype.org/pages/apache-ant.html I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development tasks, it can be part of the move to Maven and any reorganization of the applications. This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 03:27 AM, Jacopo Cappellato wrote:
On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
So you would like to suppress the concept of event?
Most of the events are currently implemented in Java and are already under src
folder.
Not what I mean. The following method definition pattern is the problem:
==
public static String $methodName(HttpServletRequest request,
HttpServletResponse response) {
Integer pageNum =
NumberParsingUtil.parseInt(request.getParameter(page));
...
// core logic starts here
ListMapString, Object searchDataResults =
dispatcher.runSync(doSearch, context);
MapString, Object parsedData = new HashMap();
int largeSizeCount = 0, smallSizeCount = 0;
for (MapString, Object data: searchDataResults) {
if (data.size() 10) largeSizeCount++;
if (data.size() 5) smallSizeCount++;
}
parsedData.put(largeSizeCount, largeSizeCount);
parsedData.put(smallSizeCount, smallSizeCount);
parsedData.put(totalCount, searchDataResults.size());
parsedData.put(results, searchDataResults);
..
request.setAttribute(search:parsedData, parsedData);
return success;
}
==
There are 3 things going on here. The first part reads the incoming
request data, fetching whatever it needs. The second does some kind of
business logic. The third then places the results of that back into the
request for later processing by further code.
The middle part needs to be extracted into a separate location that is
callable through the service engine.
ps: this is pseudo code
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 08:22 AM, Ron Wheeler wrote: On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? You mis-parsed Jacques' statement. Remove the (no Ant) part, and it becomes: that would be a Maven only solution blocker. It is an issue with maven, not ant.
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 15:22, Ron Wheeler a écrit : On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? No I meant if ever we would head to Maven only (no Ant build in the project) then it would be a blocker. Ant is the ultimate in flexibility. The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz. I would be tempted to look at providing alternative Ant builds. I'm undecided on this, but it seems redundant to me and duplicate to maintain. It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Having Ant scripts that build individual components or groups of components should be pretty simple. That exists already It is also possible to deploy artifacts built with Ant to Maven Central. http://central.sonatype.org/pages/apache-ant.html I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development tasks, it can be part of the move to Maven and any reorganization of the applications. This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven. I think, if ever we go the Maven way, we will still need Ant around and ready Jacques Ron
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 16:59, Adam Heath a écrit : On 04/28/2015 08:22 AM, Ron Wheeler wrote: On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? You mis-parsed Jacques' statement. Remove the (no Ant) part, and it becomes: that would be a Maven only solution blocker. It is an issue with maven, not ant. Yes, I'm a specialist of digressions in parenthesis, my mind is built that way it seems Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 16:47, Adam Heath a écrit : On 04/28/2015 03:16 AM, Jacques Le Roux wrote: Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend api layer. Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code. Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an architecture solution Jacques
Re: Proposal: redefining the components' directory layout for source files
On Apr 28, 2015, at 6:45 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Recently I have read in some ASF thread that the ASF prefers that source releases do not contain binaries; in light of this I would not be against a change in this direction. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Interesting, it did not occur to me this was J2EE related +1 Jacques Le 24/04/2015 18:47, Adrian Crum a écrit : +1 OFBiz stopped following J2EE patterns years ago, so we might as well make it official. Adrian Crum Sandglass Software www.sandglass-software.com On 4/24/2015 3:57 PM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. Jacopo
Re: Proposal: redefining the components' directory layout for source files
+1 Jacques Le 25/04/2015 12:39, Jacopo Cappellato a écrit : Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 25/04/2015 14:32, Michael Brohl a écrit : +1 for the mentioned statements, especially planning, an announced branch which is not backward compatible and a sensible look at users who build their business on the OFBiz foundation without denying serious changes just because of this fact. Maybe it is possible to provide some migration tools (scripts etc.) to help automate the migration and make it less painless for the users. At least a good documentation should be provided which should be started during development to get every change and best practice documented. Things often get lost when documenting later. It could be a must have for a patch for fundamental changes: no documentation, no commit. Indeed a bit like TDD. What Adam is doing with Git rebase and separated commit is heading in the right direction but we need also complete external documentation (wiki commits log) Jacques Michael ecomify GmbH www.ecomify.de Am 25.04.15 um 12:39 schrieb Jacopo Cappellato: Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 10:27, Jacopo Cappellato a écrit : On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: So you would like to suppress the concept of event? Most of the events are currently implemented in Java and are already under src folder. Jacopo In custom projects I like to use simple-methods events... Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 21/01/2015 16:08, Ron Wheeler a écrit : Very good reasons. I am excited by #7. If done correctly, it could make it much easier for new people to get involved since it should partition the application into chunks that are easier to learn. It will also relieve some of the management burden since the people reviewing code changes will be able to focus on key changes by ignoring check-ins that involve functions that they do not feel the need to examine closely and spending the time on check-ins to critical or complex code where there is a real danger that the code may pass the acceptance tests but have consequences for other modules or use cases. First step on the road to sub-projects? #2 does introduce the requirement for a sensible plan for the restructuring so that the impact on existing forks is controlled. It probably should be planned to coincide with a major release (so-called freeze) so that it is clear to everyone that the structure changed at a well-defined point. Might not be a bad time to look at changing org.ofbiz to org.apache.ofbiz since that will bring the code up to date and make the searching for modules in Maven Central a bit more sensible. I saw so far no really valuable reasons to change org.ofbiz to org.apache.ofbiz. Everybody knows I'm not a huge fan of currently planned changes, including and especially Maven. But if ever we get into this direction, I think this is a good reason... as you said to be carefully planned... and advertised, we have now also Twitter for that for people who have not enough time to follow the MLs. This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 Jacques It is also a simple but messy change that has a big impact of forks so it need to happen at a well defined point. It is a bigger project but not unmanageable with a bit of teamwork and a good IDE. Ron On 21/01/2015 4:06 AM, Jacopo Cappellato 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
Re: Proposal: redefining the components' directory layout for source files
I agree with you. I have already committed to bilingualism in my development and system administration processes. Once we get through this discussion, I might put out an argument for an installer like IzPack that can make deployment into different environments with the appropriate seed data loaded a bit less transparent and more user friendly. Ron On 28/04/2015 12:45 PM, Jacques Le Roux wrote: Le 28/04/2015 15:22, Ron Wheeler a écrit : On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? No I meant if ever we would head to Maven only (no Ant build in the project) then it would be a blocker. Ant is the ultimate in flexibility. The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz. I would be tempted to look at providing alternative Ant builds. I'm undecided on this, but it seems redundant to me and duplicate to maintain. It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Having Ant scripts that build individual components or groups of components should be pretty simple. That exists already It is also possible to deploy artifacts built with Ant to Maven Central. http://central.sonatype.org/pages/apache-ant.html I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development tasks, it can be part of the move to Maven and any reorganization of the applications. This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven. I think, if ever we go the Maven way, we will still need Ant around and ready Jacques Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
And the reasoning behind that is quite simple: saving on storage and bandwidth, thus cost. Best regards, Pierre Op dinsdag 28 april 2015 heeft Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com het volgende geschreven: On Apr 28, 2015, at 6:45 PM, Jacques Le Roux jacques.le.r...@les7arts.com javascript:; wrote: This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Recently I have read in some ASF thread that the ASF prefers that source releases do not contain binaries; in light of this I would not be against a change in this direction. Jacopo -- Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 18:59, Jacques Le Roux a écrit : Le 28/04/2015 16:47, Adam Heath a écrit : On 04/28/2015 03:16 AM, Jacques Le Roux wrote: Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend api layer. Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code. Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an architecture solution Jacques To clarify this was to reuse events inside services, notably the ShoppingCart... Jacques
Re: Proposal: redefining the components' directory layout for source files
On Apr 28, 2015, at 10:52 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: In custom projects I like to use simple-methods events... We will not change your custom projects :-) Jacopo
Re: Proposal: redefining the components' directory layout for source files
Quoting: We will not change your custom projects :-) On top of that, with proper notification you can plan to address the migration aspects to your wishes. 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 Tue, Apr 28, 2015 at 11:07 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 28, 2015, at 10:52 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: In custom projects I like to use simple-methods events... We will not change your custom projects :-) Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Jacques
Re: Proposal: redefining the components' directory layout for source files
On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: So you would like to suppress the concept of event? Most of the events are currently implemented in Java and are already under src folder. Jacopo
Re: Proposal: redefining the components' directory layout for source files
You can already compile components separately by using the specific build files Jacques Le 24/04/2015 06:26, Ron Wheeler a écrit : +1 Any change of breaking the project up into components that are compiled separately? Ron On 23/04/2015 11:42 PM, Scott Gray wrote: +1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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
Re: Proposal: redefining the components' directory layout for source files
On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. What I think Ron meant, is that it'd be nice to be able to checkout out *just* one component, and have all it's dependants(jars/other-components) downloaded automatically. Then, work can be done on *just* this component, in isolation. For this, maven works great. ps: Note Ron's phrase of breaking the project up. pps: But, even then, other projects have multiple released artifacts per checkout, so maybe all of framework is one repo, and each application/specialpurpose/hot-deploy component becomes separate. Jacques Le 24/04/2015 06:26, Ron Wheeler a écrit : +1 Any change of breaking the project up into components that are compiled separately? Ron On 23/04/2015 11:42 PM, Scott Gray wrote: +1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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
Re: Proposal: redefining the components' directory layout for source files
On 27/04/2015 10:52 AM, Adam Heath wrote: On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. What I think Ron meant, is that it'd be nice to be able to checkout out *just* one component, and have all it's dependants(jars/other-components) downloaded automatically. Then, work can be done on *just* this component, in isolation. For this, maven works great. Yes. That is what I meant. ps: Note Ron's phrase of breaking the project up. pps: But, even then, other projects have multiple released artifacts per checkout, so maybe all of framework is one repo, and each application/specialpurpose/hot-deploy component becomes separate. Sounds about right. I would also look at ways to separate the data from code so that could be easier to sort out required core seed data from customized entities and to build simple installation automated procedures. For example, an interactive iZPack installer that installs the OFBiz modules that you want and loads the seed data that you need and sets up the services. Jacques Le 24/04/2015 06:26, Ron Wheeler a écrit : +1 Any change of breaking the project up into components that are compiled separately? Ron On 23/04/2015 11:42 PM, Scott Gray wrote: +1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
+1 I agree that while backward-compatibility is an important factor to consider, it should not be the sole reason for halting an evolutionary effort such as this. Following along with what Adrian has already said, whether it is this proposal or some other effort where there has been a potential for user impact, I feel that as long as any gotchas are expressed with such a release, the users' expectations will be able to be set appropriately. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-redefining-the-components-directory-layout-for-source-files-tp4662062p4667483.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Proposal: redefining the components' directory layout for source files
+1 I agree that while backward-compatibility is an important factor to consider, it should not be the sole reason for halting an evolutionary effort such as this. Following along with what Adrian has already said, whether it is this proposal or some other effort where there is a potential for user impact, I feel that as long as any gotchas are expressed with such a release, the users' expectations will be able to be set appropriately. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-redefining-the-components-directory-layout-for-source-files-tp4662062p4667482.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Proposal: redefining the components' directory layout for source files
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 jacopo.cappell...@hotwaxsystems.com wrote: On Apr 24, 2015, at 5:01 PM, Adam Heath doo...@brainfood.com wrote: On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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
Re: Proposal: redefining the components' directory layout for source files
I would like to suggest again that the R15.x branch be labelled and advertised as a major rewrite that will not be backward compatible. Let's do all of our major changes in one revision, and as Pierre suggested, include in that revision instructions on how to migrate from pre-R15 to post-R15. Adrian Crum Sandglass Software www.sandglass-software.com On 4/25/2015 10:24 AM, Jacopo Cappellato wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
On Apr 24, 2015, at 5:01 PM, Adam Heath doo...@brainfood.com wrote: On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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
Re: Proposal: redefining the components' directory layout for source files
On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Has anyone actually made any findings regarding the file reorganization's impact on the ability to support previous releases. I did not see any mention of changes to class names (other than fixing the organization name org.ofbiz to org.apache.ofbiz which seems to have been put on pause for now). I gather that there is an impact on the build scripts and perhaps the organization of classes into jar files. Is there anything else that people who have private forks need to evaluate. Ron On 25/04/2015 8:32 AM, Michael Brohl wrote: +1 for the mentioned statements, especially planning, an announced branch which is not backward compatible and a sensible look at users who build their business on the OFBiz foundation without denying serious changes just because of this fact. Maybe it is possible to provide some migration tools (scripts etc.) to help automate the migration and make it less painless for the users. At least a good documentation should be provided which should be started during development to get every change and best practice documented. Things often get lost when documenting later. It could be a must have for a patch for fundamental changes: no documentation, no commit. Michael ecomify GmbH www.ecomify.de Am 25.04.15 um 12:39 schrieb Jacopo Cappellato: Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
+1 for the mentioned statements, especially planning, an announced branch which is not backward compatible and a sensible look at users who build their business on the OFBiz foundation without denying serious changes just because of this fact. Maybe it is possible to provide some migration tools (scripts etc.) to help automate the migration and make it less painless for the users. At least a good documentation should be provided which should be started during development to get every change and best practice documented. Things often get lost when documenting later. It could be a must have for a patch for fundamental changes: no documentation, no commit. Michael ecomify GmbH www.ecomify.de Am 25.04.15 um 12:39 schrieb Jacopo Cappellato: Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: 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 Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo smime.p7s Description: S/MIME Cryptographic Signature
Re: Proposal: redefining the components' directory layout for source files
+0.5 (see below, comment inline) Yes, I agree. I even have a way forward, if you've been paying attention to the maven branch(OFBIZ-6271). I have maven working with the *existing* layout in ofbiz. My plan for migration has been this: * Get maven working with existing structure. Ie, maven can compile all the code, can create all the jars, basically, it can do everything that the build.xml files do. This is a little tricky, as the top-level build.xml contains several custom targets; I'll probably just use the antrun plugin for these. * Add top-level properties in ofbiz-parent.pom, that define all the folders we might need to move; update ofbiz-component-pom.xml to use these variables. * Switch each component one at a time, setting variables in the local pom.xml(s) with the new location. Each one of these should be a separate commit. * Announce(!) * ??? Profit? ps: The standard maven test hooks do *not* run coverage against code compiled by the test phase. Aka, there is no way to know if src/test/* is getting correct coverage. I think I can fix this, as we really should verify not only the baseline code, but the testing code, for correctness. On 04/23/2015 10:42 PM, Scott Gray wrote: +1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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/ Altho, actually, I think this layout is because maven is stupid, and the plugins and fileset api does not allow for different type files in different folders. Aka, the groovyc and javac hooks have a hard time compiling .groovy and .java when they exist together in src/, so maven authors decided to split them into src/*/groovy and src/*/java. I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project.
Re: Proposal: redefining the components' directory layout for source files
On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. Jacopo
Re: Proposal: redefining the components' directory layout for source files
+1 Looks like Adam has the right approach. Ron On 24/04/2015 10:36 AM, Adam Heath wrote: +0.5 (see below, comment inline) Yes, I agree. I even have a way forward, if you've been paying attention to the maven branch(OFBIZ-6271). I have maven working with the *existing* layout in ofbiz. My plan for migration has been this: * Get maven working with existing structure. Ie, maven can compile all the code, can create all the jars, basically, it can do everything that the build.xml files do. This is a little tricky, as the top-level build.xml contains several custom targets; I'll probably just use the antrun plugin for these. * Add top-level properties in ofbiz-parent.pom, that define all the folders we might need to move; update ofbiz-component-pom.xml to use these variables. * Switch each component one at a time, setting variables in the local pom.xml(s) with the new location. Each one of these should be a separate commit. * Announce(!) * ??? Profit? ps: The standard maven test hooks do *not* run coverage against code compiled by the test phase. Aka, there is no way to know if src/test/* is getting correct coverage. I think I can fix this, as we really should verify not only the baseline code, but the testing code, for correctness. On 04/23/2015 10:42 PM, Scott Gray wrote: +1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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/ Altho, actually, I think this layout is because maven is stupid, and the plugins and fileset api does not allow for different type files in different folders. Aka, the groovyc and javac hooks have a hard time compiling .groovy and .java when they exist together in src/, so maven authors decided to split them into src/*/groovy and src/*/java. I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
Still +1 ! Ron On 24/04/2015 11:12 AM, Adam Heath wrote: On 04/24/2015 10:05 AM, Ron Wheeler wrote: +1 Looks like Adam has the right approach. Thanks. However, I'm thinking of adding a few steps. See below. Ron On 24/04/2015 10:36 AM, Adam Heath wrote: +0.5 (see below, comment inline) Yes, I agree. I even have a way forward, if you've been paying attention to the maven branch(OFBIZ-6271). I have maven working with the *existing* layout in ofbiz. My plan for migration has been this: * Get maven working with existing structure. Ie, maven can compile all the code, can create all the jars, basically, it can do everything that the build.xml files do. This is a little tricky, as the top-level build.xml contains several custom targets; I'll probably just use the antrun plugin for these. * Add top-level properties in ofbiz-parent.pom, that define all the folders we might need to move; update ofbiz-component-pom.xml to use these variables. * Add top-level properties in common.xml(and/or macros.xml), same as maven/pom. * Switch each component one at a time, setting variables in the local pom.xml(s) with the new location. Each one of these should be a separate commit. * Do this to each component's build.xml as well. This change should be part of the commit above. * Announce(!) * ??? Profit? ps: The standard maven test hooks do *not* run coverage against code compiled by the test phase. Aka, there is no way to know if src/test/* is getting correct coverage. I think I can fix this, as we really should verify not only the baseline code, but the testing code, for correctness. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
On 04/24/2015 10:05 AM, Ron Wheeler wrote: +1 Looks like Adam has the right approach. Thanks. However, I'm thinking of adding a few steps. See below. Ron On 24/04/2015 10:36 AM, Adam Heath wrote: +0.5 (see below, comment inline) Yes, I agree. I even have a way forward, if you've been paying attention to the maven branch(OFBIZ-6271). I have maven working with the *existing* layout in ofbiz. My plan for migration has been this: * Get maven working with existing structure. Ie, maven can compile all the code, can create all the jars, basically, it can do everything that the build.xml files do. This is a little tricky, as the top-level build.xml contains several custom targets; I'll probably just use the antrun plugin for these. * Add top-level properties in ofbiz-parent.pom, that define all the folders we might need to move; update ofbiz-component-pom.xml to use these variables. * Add top-level properties in common.xml(and/or macros.xml), same as maven/pom. * Switch each component one at a time, setting variables in the local pom.xml(s) with the new location. Each one of these should be a separate commit. * Do this to each component's build.xml as well. This change should be part of the commit above. * Announce(!) * ??? Profit? ps: The standard maven test hooks do *not* run coverage against code compiled by the test phase. Aka, there is no way to know if src/test/* is getting correct coverage. I think I can fix this, as we really should verify not only the baseline code, but the testing code, for correctness.
Re: Proposal: redefining the components' directory layout for source files
+1 OFBiz stopped following J2EE patterns years ago, so we might as well make it official. Adrian Crum Sandglass Software www.sandglass-software.com On 4/24/2015 3:57 PM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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. Jacopo
Re: Proposal: redefining the components' directory layout for source files
On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com 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.
Re: Proposal: redefining the components' directory layout for source files
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
Re: Proposal: redefining the components' directory layout for source files
+1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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
Re: Proposal: redefining the components' directory layout for source files
+1 Any change of breaking the project up into components that are compiled separately? Ron On 23/04/2015 11:42 PM, Scott Gray wrote: +1 Regards Scott On 21 January 2015 at 00:41, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: 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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
On 21 Jan 2015, at 09:24, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/01/2015 15:45, Jacques Le Roux a écrit : 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) Maven, are you serious (have mercy!)? And Gradle seems still a bit unstable (this is a year old opinion based on exchanges in the Moqui community so could be biased) and no longer backed by Pivotal, I read those last days (Groovy as well) I was wrong only Groovy and Grails are directly concerned, not Gradle (though indirectly) https://www.voxxed.com/blog/2015/01/sad-odd-decision-pivotal-set-groovy-adrift/ (see also link to Pivotal FAQ) That was from January. I don't know where Grails is headed, but Groovy has already found a new home: http://incubator.apache.org/projects/groovy.html -David
Re: Proposal: redefining the components' directory layout for source files
Is this still an ongoing discussion? Has all been said? Is it time for trying to get to some consensus, e.g. through a vote? 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 Thu, Jan 22, 2015 at 11:39 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 22/01/2015 09:53, Jacopo Cappellato a écrit : On Jan 21, 2015, at 6:35 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks! I agree it's far better than what I had (previsou version I guess) But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring I don't use refactoring tools, but navigation is indeed supported; however this is a bit off topic in this thread and maybe in these forums :-) Indeed, I just wanted to share :) Jacques Jacopo Jacques Le 21/01/2015 14:14, Jacopo Cappellato a écrit : There is an excellent tool for Groovy in Eclipse Jacopo
Re: Proposal: redefining the components' directory layout for source files
On Jan 21, 2015, at 6:35 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks! I agree it's far better than what I had (previsou version I guess) But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring I don't use refactoring tools, but navigation is indeed supported; however this is a bit off topic in this thread and maybe in these forums :-) Jacopo Jacques Le 21/01/2015 14:14, Jacopo Cappellato a écrit : There is an excellent tool for Groovy in Eclipse Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 22/01/2015 09:53, Jacopo Cappellato a écrit : On Jan 21, 2015, at 6:35 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks! I agree it's far better than what I had (previsou version I guess) But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring I don't use refactoring tools, but navigation is indeed supported; however this is a bit off topic in this thread and maybe in these forums :-) Indeed, I just wanted to share :) Jacques Jacopo Jacques Le 21/01/2015 14:14, Jacopo Cappellato a écrit : There is an excellent tool for Groovy in Eclipse Jacopo
Re: Proposal: redefining the components' directory layout for source files
I guess you think about http://groovy.codehaus.org/Eclipse+Plugin (also called GGTS) ? I just updated, thanks! I agree it's far better than what I had (previsou version I guess) But I guess you can't have the strength a strongly typed language like Java give you in term of navigation between artefacts and refactoring Jacques Le 21/01/2015 14:14, Jacopo Cappellato a écrit : There is an excellent tool for Groovy in Eclipse Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 21/01/2015 15:45, Jacques Le Roux a écrit : 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) Maven, are you serious (have mercy!)? And Gradle seems still a bit unstable (this is a year old opinion based on exchanges in the Moqui community so could be biased) and no longer backed by Pivotal, I read those last days (Groovy as well) I was wrong only Groovy and Grails are directly concerned, not Gradle (though indirectly) https://www.voxxed.com/blog/2015/01/sad-odd-decision-pivotal-set-groovy-adrift/ (see also link to Pivotal FAQ) Jacques
Re: Proposal: redefining the components' directory layout for source files
True. To summarize, I support any effort to make things more organized. This all sounds fine to me. Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2015 7:03 AM, Jacopo Cappellato wrote: On Jan 21, 2015, at 3:56 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I don't like the idea of mixing scripts with Java source code. I understand it makes sense from the perspective that scripts and Java are both source code, but the nice thing about keeping the Java source separate is it can be removed during deployment - reducing the project's footprint on the target server. You could do the same by removing the src/main/java folders and by keeping the src/main/minilang/ ones. Jacopo Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2015 12:36 AM, Jacopo Cappellato wrote: On Jan 20, 2015, at 4:29 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation. This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like. The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the component:// URL feature. So, instead of your suggestion we could do: script/groovy/FooScript_1.groovy script/groovy/FooScript_2.groovy script/minilang/BarScript_1.xml script/minilang/BarScript_2.xml script/js/BazScript_1.js +1 on the idea of getting rid of the classpaths for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste. As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy. Again, I think they should go into src/main/groovy or src/test/groovy. (Yes, the Service Engine supports JavaScript.) To use FooScript_1.groovy you can use two methods: 1. The component:// URL feature: component://mycomponent/script/groovy/FooScript_1.groovy 2. The classpath: groovy/FooScript_1.groovy Option 2 could have problems with name clash, so I have always preferred option 1. While we are having this discussion, we could also consider changing the package naming from org.ofbiz.* to org.apache.ofbiz.* +1!!! Jacopo Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 3:41 AM, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
Le 21/01/2015 02:13, Adrian Crum a écrit : I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by volunteers, so I don't see how cost/benefit applies. It is also a community driven project where decisions get debated, volunteers working for the project should take into consideration users point of view. If a such modification has advantages for the community, it may also have some drawbacks. cost/benefit should be interpreted as pros and cons and should be always apply. So it is good to have such proposal , debate theme but it will better to have a kind of road map and plan the changes for future. Sometime, some volunteers decide to make some important changes and commit theme without a pre-discussions, without jira and that is a not the good way to manage the project. Thank you all for the work you provide, the commitment etc.. Youssef Khaye Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 5:04 PM, Hans Bakker wrote: Jacopo, 'nice' is not enough reason to change the directory structure. Please this is a business application where decisions should be taken based on cost/benefit. Regards, Hans On 20/01/15 18:41, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
On Jan 20, 2015, at 4:29 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation. This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like. The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the component:// URL feature. So, instead of your suggestion we could do: script/groovy/FooScript_1.groovy script/groovy/FooScript_2.groovy script/minilang/BarScript_1.xml script/minilang/BarScript_2.xml script/js/BazScript_1.js +1 on the idea of getting rid of the classpaths for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste. As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy. Again, I think they should go into src/main/groovy or src/test/groovy. (Yes, the Service Engine supports JavaScript.) To use FooScript_1.groovy you can use two methods: 1. The component:// URL feature: component://mycomponent/script/groovy/FooScript_1.groovy 2. The classpath: groovy/FooScript_1.groovy Option 2 could have problems with name clash, so I have always preferred option 1. While we are having this discussion, we could also consider changing the package naming from org.ofbiz.* to org.apache.ofbiz.* +1!!! Jacopo Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 3:41 AM, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
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
Re: Proposal: redefining the components' directory layout for source files
There is an excellent tool for Groovy in Eclipse Jacopo On Jan 21, 2015, at 1:47 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/01/2015 10:06, Jacopo Cappellato a écrit : 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... I mean that refactoring with an IDE is easier. For Eclipse users there are tools for Java but not minilang and groovy where things must be done by hand with a less secure manner. I don't use IntelliJ IDEA but I know it has more Groovy support, hence more secure when refactoring. Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 21/01/2015 10:06, Jacopo Cappellato a écrit : 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... I mean that refactoring with an IDE is easier. For Eclipse users there are tools for Java but not minilang and groovy where things must be done by hand with a less secure manner. I don't use IntelliJ IDEA but I know it has more Groovy support, hence more secure when refactoring. Jacques
Re: Proposal: redefining the components' directory layout for source files
I don't like the idea of mixing scripts with Java source code. I understand it makes sense from the perspective that scripts and Java are both source code, but the nice thing about keeping the Java source separate is it can be removed during deployment - reducing the project's footprint on the target server. Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2015 12:36 AM, Jacopo Cappellato wrote: On Jan 20, 2015, at 4:29 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation. This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like. The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the component:// URL feature. So, instead of your suggestion we could do: script/groovy/FooScript_1.groovy script/groovy/FooScript_2.groovy script/minilang/BarScript_1.xml script/minilang/BarScript_2.xml script/js/BazScript_1.js +1 on the idea of getting rid of the classpaths for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste. As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy. Again, I think they should go into src/main/groovy or src/test/groovy. (Yes, the Service Engine supports JavaScript.) To use FooScript_1.groovy you can use two methods: 1. The component:// URL feature: component://mycomponent/script/groovy/FooScript_1.groovy 2. The classpath: groovy/FooScript_1.groovy Option 2 could have problems with name clash, so I have always preferred option 1. While we are having this discussion, we could also consider changing the package naming from org.ofbiz.* to org.apache.ofbiz.* +1!!! Jacopo Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 3:41 AM, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
On Jan 21, 2015, at 3:56 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I don't like the idea of mixing scripts with Java source code. I understand it makes sense from the perspective that scripts and Java are both source code, but the nice thing about keeping the Java source separate is it can be removed during deployment - reducing the project's footprint on the target server. You could do the same by removing the src/main/java folders and by keeping the src/main/minilang/ ones. Jacopo Adrian Crum Sandglass Software www.sandglass-software.com On 1/21/2015 12:36 AM, Jacopo Cappellato wrote: On Jan 20, 2015, at 4:29 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation. This is a non problem: even if we split the main and test classes using the src/main and src/test folders we are still free to place them in the packages we like. The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the component:// URL feature. So, instead of your suggestion we could do: script/groovy/FooScript_1.groovy script/groovy/FooScript_2.groovy script/minilang/BarScript_1.xml script/minilang/BarScript_2.xml script/js/BazScript_1.js +1 on the idea of getting rid of the classpaths for Minilang as a general direction; I still think they should go under src/minilang but at this point this is just a matter of personal taste. As regards Groovy, with it you can implement classes and not just scripts and having the ability to define the packages will be very useful especially when we will have more services implemented in Groovy. Again, I think they should go into src/main/groovy or src/test/groovy. (Yes, the Service Engine supports JavaScript.) To use FooScript_1.groovy you can use two methods: 1. The component:// URL feature: component://mycomponent/script/groovy/FooScript_1.groovy 2. The classpath: groovy/FooScript_1.groovy Option 2 could have problems with name clash, so I have always preferred option 1. While we are having this discussion, we could also consider changing the package naming from org.ofbiz.* to org.apache.ofbiz.* +1!!! Jacopo Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 3:41 AM, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
Improvements, though painful at first when applied, are always intended with the future in mind. And it is based on the past. Not improving is like living in the past. That being said, I find good in any argument provided. Yes, it has impact And yes, undertaking something like this should be done with JIRA issues and in a separate branch. So that persons can evaluate and assess impact on migration aspects for their custom dependencies. And after it has been evaluated and people have had time to assess impact on the migration aspects, it is time to vote on bringing it back into trunk and a release. Jacques remarked 'sounds like marketing to me', and there is nothing wrong with being able to promote OFBiz with innovations applied. No one forgoes the 'New/Improved' opportunity when it comes to promotions. It brings fresh blood, even to open source projects. When all the viewpoints have been posted, it is time to assess each argument and work towards consensus by means of compromising. 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
Re: Proposal: redefining the components' directory layout for source files
Very good reasons. I am excited by #7. If done correctly, it could make it much easier for new people to get involved since it should partition the application into chunks that are easier to learn. It will also relieve some of the management burden since the people reviewing code changes will be able to focus on key changes by ignoring check-ins that involve functions that they do not feel the need to examine closely and spending the time on check-ins to critical or complex code where there is a real danger that the code may pass the acceptance tests but have consequences for other modules or use cases. First step on the road to sub-projects? #2 does introduce the requirement for a sensible plan for the restructuring so that the impact on existing forks is controlled. It probably should be planned to coincide with a major release (so-called freeze) so that it is clear to everyone that the structure changed at a well-defined point. Might not be a bad time to look at changing org.ofbiz to org.apache.ofbiz since that will bring the code up to date and make the searching for modules in Maven Central a bit more sensible. It is also a simple but messy change that has a big impact of forks so it need to happen at a well defined point. It is a bigger project but not unmanageable with a bit of teamwork and a good IDE. Ron On 21/01/2015 4:06 AM, Jacopo Cappellato 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/
Re: Proposal: redefining the components' directory layout for source files
Le 21/01/2015 10:06, Jacopo Cappellato a écrit : On Jan 20, 2015, at 1:49 PM, Jacques Le Rouxjacques.le.r...@les7arts.com wrote: 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) Thought weak, that's a +1 indeed 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; Sorry, but sounds like marketing to me ;) 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; I know the We have always doing things like that derision leitmotiv, but sorry I don't see much innovation in this. Especially when counterbalanced with the risks and mostly the necessary effort. I have currently any responsabilities in a custom project based on the trunk and I don't want to discuss that point. But I'd like to have the opinions of concerned persons. Apart Hans and Youssef nobody seems concerned, but I guess there are more people who will be affected; how do they see things, notably about their patches on the core code, and that will be also valid for people who will want to upgrade later to say 15.xx and/or later release/s... From this perspective, these changes can have a real impact depending on the number and size of the patches. As said Youssef, we can't no longer ignore our base of users, OFBiz is now a well established product in some companies which really rely on it. 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 Good point! Looking forward for a good and complete discussion, not disdain as we sometimes do... 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 I must say I have no idea how this can be done, since it's dynamic, but could be interesting indeed. 4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones +1 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) Maven, are you serious (have mercy!)? And Gradle seems still a bit unstable (this is a year old opinion based on exchanges in the Moqui community so could be biased) and no longer backed by Pivotal, I read those last days (Groovy as well) 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? Good question 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 Maybe and hopefully... Jacques Regards, Jacopo Thanks Jacopo, It clarifies things
Re: Proposal: redefining the components' directory layout for source files
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 guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)... 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? 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
Re: Proposal: redefining the components' directory layout for source files
Good step forward. Ron On 20/01/2015 6:41 AM, Jacopo Cappellato wrote: 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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
I suggested a Maven-like folder structure years ago, and there was pushback from Adam. He was concerned that test classes would reside in the same package as the classes being tested - which would expose their implementation. The classpath under the script folder is not necessary. That was used before we had FlexibleLocation and the component:// URL feature. So, instead of your suggestion we could do: script/groovy/FooScript_1.groovy script/groovy/FooScript_2.groovy script/minilang/BarScript_1.xml script/minilang/BarScript_2.xml script/js/BazScript_1.js (Yes, the Service Engine supports JavaScript.) To use FooScript_1.groovy you can use two methods: 1. The component:// URL feature: component://mycomponent/script/groovy/FooScript_1.groovy 2. The classpath: groovy/FooScript_1.groovy Option 2 could have problems with name clash, so I have always preferred option 1. While we are having this discussion, we could also consider changing the package naming from org.ofbiz.* to org.apache.ofbiz.* Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 3:41 AM, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
Jacopo, 'nice' is not enough reason to change the directory structure. Please this is a business application where decisions should be taken based on cost/benefit. Regards, Hans On 20/01/15 18:41, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
It will make the project look more professional which has some benefit in reviews by IT departments of potential adopters or by technical reviewers for blogs or journals. I am not sure if this can be quantified but it is a benefit. The cost seems pretty low since it should only affect the build and the docs. Ron On 20/01/2015 8:13 PM, Adrian Crum wrote: I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by volunteers, so I don't see how cost/benefit applies. Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 5:04 PM, Hans Bakker wrote: Jacopo, 'nice' is not enough reason to change the directory structure. Please this is a business application where decisions should be taken based on cost/benefit. Regards, Hans On 20/01/15 18:41, Jacopo Cappellato wrote: 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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by volunteers, so I don't see how cost/benefit applies. Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 5:04 PM, Hans Bakker wrote: Jacopo, 'nice' is not enough reason to change the directory structure. Please this is a business application where decisions should be taken based on cost/benefit. Regards, Hans On 20/01/15 18:41, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
So what are the advantages vs drawbacks? Who can clearly tell us that? Jacques Le 21/01/2015 02:13, Adrian Crum a écrit : I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by volunteers, so I don't see how cost/benefit applies. Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 5:04 PM, Hans Bakker wrote: Jacopo, 'nice' is not enough reason to change the directory structure. Please this is a business application where decisions should be taken based on cost/benefit. Regards, Hans On 20/01/15 18:41, Jacopo Cappellato wrote: 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
Re: Proposal: redefining the components' directory layout for source files
I agree about those benefits (even if they are weak) but I'd like to have the drawbacks measured better. Doing an easy things does not mean it has no implications, see when we decided to remove the specialpurpose from R13 Jacques Le 21/01/2015 02:32, Ron Wheeler a écrit : It will make the project look more professional which has some benefit in reviews by IT departments of potential adopters or by technical reviewers for blogs or journals. I am not sure if this can be quantified but it is a benefit. The cost seems pretty low since it should only affect the build and the docs. Ron On 20/01/2015 8:13 PM, Adrian Crum wrote: I disagree. This is an open source software project where decisions should be made based on good design principles. The work is being done by volunteers, so I don't see how cost/benefit applies. Adrian Crum Sandglass Software www.sandglass-software.com On 1/20/2015 5:04 PM, Hans Bakker wrote: Jacopo, 'nice' is not enough reason to change the directory structure. Please this is a business application where decisions should be taken based on cost/benefit. Regards, Hans On 20/01/15 18:41, Jacopo Cappellato wrote: 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
