Le 21/01/2015 10:06, Jacopo Cappellato a écrit :
On Jan 20, 2015, at 1:49 PM, Jacques Le Roux<[email protected]>
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
