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 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
