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
>>>> 
>>>> 
> 

Reply via email to