Slim-down effort: current situation

[Jacopo Cappellato-4]

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" <[hidden email]>
>>>> 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
>>>>
>>>>
>

[Jacopo Cappellato-4]

Of course in both cases we should cleanup and improve our ant scripts and remove direct references to specific specialpurpose components like:

          <fileset dir="${ofbiz.home.dir}/specialpurpose/birt/lib" includes="*.jar"/>
          <fileset dir="${ofbiz.home.dir}/specialpurpose/ebaystore/lib" includes="*.jar"/>
          <fileset dir="${ofbiz.home.dir}/specialpurpose/googlecheckout/lib" includes="*.jar"/>
          <fileset dir="${ofbiz.home.dir}/specialpurpose/ldap/lib" includes="*.jar"/>
          <fileset dir="${ofbiz.home.dir}/specialpurpose/pos/lib" includes="*.jar"/>

This is something that should have never been committed like this and so it would be good to fix regardless of our final decision on the separation of specialpurpose components

Regards,

Jacopo

On Jan 16, 2013, at 2:38 PM, Jacopo Cappellato wrote:

> 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" <[hidden email]>
>>>>> 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
>>>>>
>>>>>
>>
>

[Malin Nicolas]

It's sound good, I just see a little problem if we want only one
specialpurpose component, we need to do

$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
$ cd ofbiz-trunk
$ mkdir specialpurpose
$ cd specialpurpose
$ svn co
http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/build.xml
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt 
(as example)
$ #create your component-load.xml

Why not use hot-deploy (and/or improve hot-deploy) for specialpurpose
components to obtain a result like this :
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
$ cd ofbiz-trunk
$ cd hot-deploy
$ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt

and an other solution for branch :
$ svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.04 
ofbiz-13.04
$ cd ofbiz-13.04
$ ant load-special-component birt

Nicolas

Le 16/01/2013 14:38, Jacopo Cappellato a écrit :

> 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" <[hidden email]>
>>>>> 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
>>>>>
>>>>>

[Jacopo Cappellato-4]

Yes, it makes a lot of sense to treat the specialpurpose components as hot-deploy components.
However I'd suggest to move at small steps in this direction because right now there are specialpurpose components that depends on each other and this would make the story more complicated if you want to use just one.
For this reason I would suggest to first implement the ability to run OFBiz or OFbiz with all specialpurpose components and then improve it to run specific specialpurpose components only.

Jacopo

On Jan 16, 2013, at 3:50 PM, Malin Nicolas wrote:

> It's sound good, I just see a little problem if we want only one specialpurpose component, we need to do
>
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
> $ cd ofbiz-trunk
> $ mkdir specialpurpose
> $ cd specialpurpose
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/build.xml
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt (as example)
> $ #create your component-load.xml
>
> Why not use hot-deploy (and/or improve hot-deploy) for specialpurpose components to obtain a result like this :
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
> $ cd ofbiz-trunk
> $ cd hot-deploy
> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
>
> and an other solution for branch :
> $ svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.04 ofbiz-13.04
> $ cd ofbiz-13.04
> $ ant load-special-component birt
>
> Nicolas
>
> Le 16/01/2013 14:38, Jacopo Cappellato a écrit :
>> 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" <[hidden email]>
>>>>>> 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
>>>>>>
>>>>>>
>

[Malin Nicolas]

:) right, so change 13.04 by 14.04 on my last comments ;)

On my side, I will test OFBiz without specialpurpose to find bad depends.

Nicolas

Le 16/01/2013 16:21, Jacopo Cappellato a écrit :

> Yes, it makes a lot of sense to treat the specialpurpose components as hot-deploy components.
> However I'd suggest to move at small steps in this direction because right now there are specialpurpose components that depends on each other and this would make the story more complicated if you want to use just one.
> For this reason I would suggest to first implement the ability to run OFBiz or OFbiz with all specialpurpose components and then improve it to run specific specialpurpose components only.
>
> Jacopo
>
> On Jan 16, 2013, at 3:50 PM, Malin Nicolas wrote:
>
>> It's sound good, I just see a little problem if we want only one specialpurpose component, we need to do
>>
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
>> $ cd ofbiz-trunk
>> $ mkdir specialpurpose
>> $ cd specialpurpose
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/build.xml
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt (as example)
>> $ #create your component-load.xml
>>
>> Why not use hot-deploy (and/or improve hot-deploy) for specialpurpose components to obtain a result like this :
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/ofbiz ofbiz-trunk
>> $ cd ofbiz-trunk
>> $ cd hot-deploy
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
>>
>> and an other solution for branch :
>> $ svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.04 ofbiz-13.04
>> $ cd ofbiz-13.04
>> $ ant load-special-component birt
>>
>> Nicolas
>>
>> Le 16/01/2013 14:38, Jacopo Cappellato a écrit :
>>> 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" <[hidden email]>
>>>>>>> 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
>>>>>>>
>>>>>>>