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 <[email protected]>
wrote:
Have you a clear idea of that this entails in term of migration, no only OOTB,
but for custom projects which relies on trunk?
I did some reasonings about it and it shouldn't be a big deal, especially on
the programming side (it will require mostly search and replace sessions); of
course I didn't do a thorough analysis, I just wanted to start the conversation
here; the good news is that it can be done in chunks, hopefully with the help
of the community (that could also support the migration of custom projects).
I guess for Java it should not be so hard but for minilang and groovy could be
harder, everybody does not use Idea (groovy part)...
I am sorry but the above sentence doesn't make any sense to me...
Also what does this bring to the project? Why do you want to do so (apart being
in line with other projects)? And why should we be in line with them, do you
envision something?
The main advantages are the following:
1) standardize our layout structure to make it consistent with other projects
(may make it easier for a new developer to understand OFBiz and appreciate it
since the beginning)
2) review of past decision in light of the experience, lessons learned and
established conventions: most of the decision we took for the project were
optimal at that time but may be suboptimal in light of new technologies,
standards, trends etc... in order for our (more than 10 years old) project to
stay fresh and healthy we have to always revisit our decisions and keep it
young; when the first objection to proposals is that this could impact custom
projects or existing contributors, then in my opinion it is a sign of defensive
mentality that could bring to staleness; these concerns and considerations are
still important, but should be discussed (trying to propose a good migration
plan) at a later point and not used to slow down or stop the change
3) simplify the pre compilation of Groovy (and possibly other) scripts: this
could be done to spot coding errors in advance, to improve performance at
runtime, or just to simplify the deployment
4) simplify our build scripts: right now the ant scripts do some funny/complex
stuff in order to separate test classes from main ones
5) moving a step forward in the direction of allowing the adoption of Maven
like tools (Maven, Gradle etc..) that could make it easier to share external
components (grow the ecosystem)
6) right now there is not a standard place for non-Java services or events: the
script folder is traditionally used for Minilang, where should Groovy (or other
languages) service implementation live?
7) I have some, longer term, plans to make the OFBiz framework codebase more
modular: several smaller jars with clear dependencies that could be deployed in
different ways (vs the monolithic approach we have to follow now); a
standardization of the source folders may help the adoption of tools and
strategies for achieving this
Regards,
Jacopo
Jacques
Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
In my opinion it would be nice to review how we organize the code in our
components and switch to a directory layout that is more inline with what other
projects are doing, for example:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
More specifically I would like to switch from, for example:
script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/
to:
src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/
What do you think?
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
