Thanks Nicolas. I had a quick look too to find a way to exclude specialpurpose components from the build/test process and the easiest way (I didn't test it) would be to set the property: specialpurpose.present to false. At the moment it is set with: <available file="specialpurpose/build.xml" property="specialpurpose.present"/> Another way would be to change the layout of our trunk, from:
trunk/applications trunk/framework trunk/specialpurpose to trunk/ofbiz/applications trunk/ofbiz/framework trunk/specialpurpose In this way in order to checkout OFbiz only (no specialpurpose) you could do: svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz And in order to download everything you would do: svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk cd ofbiz-trunk svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose I like the latter more. Kind regards, Jacopo On Jan 16, 2013, at 2:23 PM, Malin Nicolas wrote: > Hi Jacopo, > Your solution is a good pragmatism and give a clear work to do for > contributors > > If other people are ok with your proposition, I will try to find a solution > to activate a component with ant. > > PS : My apologies for the latency > > Nicolas > > > > 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... >> * 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) >> 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? >> >> 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 >>>> >>>> >
