From: "Jacopo Cappellato" <[email protected]> > 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... > * 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 > * the official releases (and release branches) will not contain the > specialpurpose folder > * 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") > * 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... > > 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)
About the side note: indeed! It will be easier to do with your proposed new way. > 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) > > 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 > > 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? +1, definitively the way to go, with maybe some refinements Jacques > > Jacopo > > On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote: > >> Yes thanks! >> >> Jacques >> >> From: "Jacopo Cappellato" <[email protected]> >>> >>> 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 >>> >>> > >
