Very clear and efficient
Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
Let's see if we can move on the slim-down effort in this direction; here is a
slightly more detailed proposal:
* svn layout of the project will stay as is now:
framework+applications+specialpupose; if you checkout the trunk you will get
everything as it is now
* however all the specialpupose components will be disabled by default;
building the project will not build them, running tests will not run the tests
on them etc...
+1
* we will provide easy mechanisms (ant scripts/settings or similar) to enable
specialpurpose components; in this way developers interested in testing/working
on some specialpurpose components will have an easy way to do this
+1
* the official releases (and release branches) will not contain the
specialpurpose folder
+1
* we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if
there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS
1.0", "OFBiz Extra - Birt 1.0")
+1
* key point: it will be acceptable to commit code to improve OFBiz even if it
breaks some of the specialpurpose components: e.g. API changes, jar updates
(duplicated of jars in some specialpurpose components) etc...
+1
maybe it will be necessary in future to decide how to process when a
component in specialpurpose has junit and selenium test for all functions
The last point is the most important because with it we will reach some
important goals that could alleviate the tension/conflicts we had in the past
while discussing topics about what should go in OFBiz and what not:
a) committers will have a core set of common, generic and more frequently used
components (framework/applications) to focus on; it will be easier to maintain
a smaller codebase and this will speed up the evolution of OFBiz; it will also
remove a lot of burden in the release management because we will have less
external dependencies to look for for vulnerability reports; for example, if a
vulnerability report is reported by the Birt community, and we are distributing
the Birt jars in our releases, in the current situation we would be forced to
issue a new release (as a side note, I am not even sure if we are keeping an
eye on vulnerability reports from all the projects we have pulled jars from)
+1
b) committers interested in keeping up-to-date some of the specialpurpose
components could easily update the code and commit it; over time we will see
what are the specialpurpose components that are actively maintained (and we
could issue releases for them) and what are the components that are not (and we
could discuss if it is worth of keeping them in the trunk or not, but they will
not cause any major issues even if they stay there)
+1
Some clarifications:
* we may want to review over time the list of components currently under
specialpurpose; if there is a general consensus in the direction of keeping a
few of them in the releases then we could keep them enabled and include them in
branches
* we will have to change something in the way we build the classpath in ant in
order to include jars and build the component only if the component is enabled;
it should not be difficult to achieve but this is important because it will
allow us to have potentially conflicting jars in the framework/applications and
specialpurpose
+1
As a roadmap, we could try to implement this approach before the next cut of
the 13.04 release branch (in April 2013): that branch could be the first one
without the specialpurpose components.
What do you think?
Completely agree
even if I would have liked a little note on the notion addon (smaller
than a component) :-)
Jacopo
On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
Yes thanks!
Jacques
From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com>
On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
I even wonder if Jacopo did not make a more recent (and flexible) proposition
with which I totaly agreed (during fall, it seems to me but, I can't find it),
Jacopo?
Do you mean the following?
========================
BTW, some time ago I also proposed an alternative path: see email with subject
"[PROPOSAL] from specialpurpose to extras": to that I can add that we could
provide two set of ant scripts, one similar to the one we have that builds/tests
everything (framework+applications+specialpurpose) and one (the default) that only
builds/tests the framework+applications; the release branches may only contain the
framework+applications and separate releases of specialpurpose applications could be
voted/released at different time. This approach may reach two goals:
1) slim down the "main" code that the community is more focused to
improve/maintain/release
2) keep under the OFBiz community the ownership of all the other specialpurpose
components; if one of them will get more attention and interest and could grow
in quality or it is generic enough we could decide to move it to the release
branch (maybe move it to applications)
========================
Jacopo
