Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
:) 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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
I think this is a very good idea, Jacopo - straight forward and easy to maintain -- View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4638733.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
A bit out of subject, I found this article interesting http://kohsuke.org/2013/01/04/the-other-side-of-forking-and-pull-requests And he made me wonder how the OpenErp project is handling its addons (some years ago someone told me this was a weak part of the project, I never dug) Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com From: d...@me.com On Jan 5, 2013, at 1:47 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: From: Ean Schuessler e...@brainfood.com I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this. The nice thing about GIT is that the chaff doesn't get into the wheat bucket. Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks. If the work is of low quality in GitHub it will be ignored as well. If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch? I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch. I'd have to check that, but I believe once well (and very politely ;o) explained it should be possible to convince them With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach. Of course, as you said it's already there, so we have nothing to do, nothing happens. Jacques -David
Re: Slim-down effort: current situation
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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 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
Re: Slim-down effort: current situation
From: d...@me.com On Jan 5, 2013, at 1:47 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: From: Ean Schuessler e...@brainfood.com I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this. The nice thing about GIT is that the chaff doesn't get into the wheat bucket. Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks. If the work is of low quality in GitHub it will be ignored as well. If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch? I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch. I'd have to check that, but I believe once well (and very politely ;o) explained it should be possible to convince them With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach. Of course, as you said it's already there, so we have nothing to do, nothing happens. Jacques -David
Re: Slim-down effort: current situation
Because it's possibly easier for committers to follow the work done and not get a big patch at the end. With Git you tend to receive either a burst of patches or a big one, both in one shoot. Then it's hard to review the work done. By steps it's easier I don't use GitHub, I have enough to do with OFBiz patches already... Jacques From: Ean Schuessler e...@brainfood.com Why wouldn't they just fork and then issue a pull request on GitHub? - Jacques Le Roux wrote: I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)? http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. The nice thing about GIT is that the chaff doesn't get into the wheat bucket. - Jacques Le Roux wrote: Because it's possibly easier for committers to follow the work done and not get a big patch at the end. With Git you tend to receive either a burst of patches or a big one, both in one shoot. Then it's hard to review the work done. By steps it's easier I don't use GitHub, I have enough to do with OFBiz patches already... -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
From: Ean Schuessler e...@brainfood.com I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this. The nice thing about GIT is that the chaff doesn't get into the wheat bucket. Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks. If the work is of low quality in GitHub it will be ignored as well. If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch? I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git Jacques - Jacques Le Roux wrote: Because it's possibly easier for committers to follow the work done and not get a big patch at the end. With Git you tend to receive either a burst of patches or a big one, both in one shoot. Then it's hard to review the work done. By steps it's easier I don't use GitHub, I have enough to do with OFBiz patches already... -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
On Jan 5, 2013, at 1:47 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: From: Ean Schuessler e...@brainfood.com I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this. The nice thing about GIT is that the chaff doesn't get into the wheat bucket. Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks. If the work is of low quality in GitHub it will be ignored as well. If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch? I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch. With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach. -David
Re: Slim-down effort: current situation
I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)? http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html Opinions? Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com 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
Re: Slim-down effort: current situation
One of the solutions is to create brach on github, https://github.com/apache/ofbiz. A feature can be developed on Github and then a final patch can be submitted to Ofbiz Jira. Regards Anil Patel On Jan 4, 2013, at 9:17 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)? http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html Opinions? Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com 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
Re: Slim-down effort: current situation
Why wouldn't they just fork and then issue a pull request on GitHub? - Jacques Le Roux wrote: I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)? http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
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
Re: Slim-down effort: current situation
From: Nicolas Malin malin.nico...@librenberry.net Le 15/11/2012 08:49, Jacques Le Roux a écrit : I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques Hi all, To continue on slim-down effort, I propose to work on a POC. We define the expected to manage component on extra. We select a component or subject to move from OFBiz to extra and a delivery date. I think we should also refer to [PROPOSAL] from specialpurpose to extras thread here. 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? Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future. I personnaly begin to lose the focus, a sole place to look at would be easier. There are a lot of good ideas, we need to pick the better (by consensus of course ;o) Each contributor wishing to work on it, would propose a solution to move and use a component on extra, open an issue containing the process, management and the example with selected component. After the delivery date, we check avantage/disavantage of each proposition and vote to choose the favorite solution. Write a best pratice to move/create a component on extra usable by OFBiz. Then we can start with this process * proposal/vote * open jira issue * write information on extras.html * run move It sounds like this could be in the page I proposed to create. Before going further I believe we need to clarify in all minds, get consensus and then work on them My 2cts Jacques The aim isn't to define what to do but how to contribute when the goal will be fixed. Your opinions ? Nicolas -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Slim-down effort: current situation
From: Jacques Le Roux jacques.le.r...@les7arts.com From: Nicolas Malin malin.nico...@librenberry.net Le 15/11/2012 08:49, Jacques Le Roux a écrit : I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques Hi all, To continue on slim-down effort, I propose to work on a POC. We define the expected to manage component on extra. We select a component or subject to move from OFBiz to extra and a delivery date. I think we should also refer to [PROPOSAL] from specialpurpose to extras thread here. 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? Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future. I personnaly begin to lose the focus, a sole place to look at would be easier. There are a lot of good ideas, we need to pick the better (by consensus of course ;o) I created https://cwiki.apache.org/confluence/display/OFBIZ/Slimdown+Effort+Roadmap (just a mock for now, feel free to do what you want...) Jacques Each contributor wishing to work on it, would propose a solution to move and use a component on extra, open an issue containing the process, management and the example with selected component. After the delivery date, we check avantage/disavantage of each proposition and vote to choose the favorite solution. Write a best pratice to move/create a component on extra usable by OFBiz. Then we can start with this process * proposal/vote * open jira issue * write information on extras.html * run move It sounds like this could be in the page I proposed to create. Before going further I believe we need to clarify in all minds, get consensus and then work on them My 2cts Jacques The aim isn't to define what to do but how to contribute when the goal will be fixed. Your opinions ? Nicolas -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Slim-down effort: current situation
Thanks jacques, create a wiki page sound good to me :) Nicolas Le 16/12/2012 14:28, Jacques Le Roux a écrit : From: Jacques Le Roux jacques.le.r...@les7arts.com From: Nicolas Malin malin.nico...@librenberry.net Le 15/11/2012 08:49, Jacques Le Roux a écrit : I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques Hi all, To continue on slim-down effort, I propose to work on a POC. We define the expected to manage component on extra. We select a component or subject to move from OFBiz to extra and a delivery date. I think we should also refer to [PROPOSAL] from specialpurpose to extras thread here. 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? Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future. I personnaly begin to lose the focus, a sole place to look at would be easier. There are a lot of good ideas, we need to pick the better (by consensus of course ;o) I created https://cwiki.apache.org/confluence/display/OFBIZ/Slimdown+Effort+Roadmap (just a mock for now, feel free to do what you want...) Jacques Each contributor wishing to work on it, would propose a solution to move and use a component on extra, open an issue containing the process, management and the example with selected component. After the delivery date, we check avantage/disavantage of each proposition and vote to choose the favorite solution. Write a best pratice to move/create a component on extra usable by OFBiz. Then we can start with this process * proposal/vote * open jira issue * write information on extras.html * run move It sounds like this could be in the page I proposed to create. Before going further I believe we need to clarify in all minds, get consensus and then work on them My 2cts Jacques The aim isn't to define what to do but how to contribute when the goal will be fixed. Your opinions ? Nicolas -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/ -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Slim-down effort: current situation
Le 15/11/2012 08:49, Jacques Le Roux a écrit : I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques Hi all, To continue on slim-down effort, I propose to work on a POC. We define the expected to manage component on extra. We select a component or subject to move from OFBiz to extra and a delivery date. Each contributor wishing to work on it, would propose a solution to move and use a component on extra, open an issue containing the process, management and the example with selected component. After the delivery date, we check avantage/disavantage of each proposition and vote to choose the favorite solution. Write a best pratice to move/create a component on extra usable by OFBiz. Then we can start with this process * proposal/vote * open jira issue * write information on extras.html * run move The aim isn't to define what to do but how to contribute when the goal will be fixed. Your opinions ? Nicolas -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Slim-down effort: current situation
On 11/20/2012 07:17 PM, Jacques Le Roux wrote: No worries Adam, Paul gave Yum just as a sort-of-like example. I don't know the addons technology, but I'm sure it's not related at all with Yum or even apt-get (more Ant and maybe Ivy) And of course, we all prefer get-apt (at least I do, actually I don't even know Yum :D) I've had the (mis)?fortune to use yast and yum, and they both suck compared to apt. I just can't sugar coat it any. I am a *true* programmer, the ideas I get, and I don't really care about how they are implemented. But in this case, the implementation of yum and yast shows the poor ideas behind them, and that is what has burrowed underneath my skin.
Re: Slim-down effort: current situation
Adam and I have been talking about a feature like this for a while. Its a good question whether something like Maven would serve as a good basis for resolving dependencies or maybe even a pluggable architecture. On Red Hat and Debian systems you could even automatically bring in native dependencies like Memcached, Varnish, NGINX, etc. and provide turn-key configuration of what would otherwise be a very complicated installation. Its also interesting to see how Puppet handles some of these problems. - Jacopo Cappellato wrote: On Nov 16, 2012, at 3:28 PM, Olivier Heintz wrote: It's to decrease the number of step to install, to help people (IT user, not end user I know) Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools. Regards, Jacopo -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
No need to get all hyped up over this. At this very stage I think we still have a decision pending on how to progress with apache extras before any of this would be required. Personally, what I saw at the Apachecon I liked and i think that Olivier and his team did a good job at it, so I would propose to wait for this to be presented properly (it is more of a patch- svn-managing tool than a package-installer). Of course maven is also an alternative, but that too has its flaws and would require alot of work to restructure everything here... also it is not compatible with SVN if I am not mistaken, so propably not an option (but somebody else should verify that again ;)) -- View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637828.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
On 11/16/2012 05:40 AM, Jacques Le Roux wrote: Very well summed up, Paul Thanks Jacques From: madppiper p...@ilscipio.com @jacopo: That sounds like a terrific idea of yours! I have to read up on [Proposal], but from your outline here, i would say it is a more sincere step. @Olivier: I liked your presenation on addon-manager a lot and as already discussed would think that a tool like this (sort of like a yum- install manager) could be beneficial to whatever we come up with here. But the tool for me is an addition to the proposal above, it is not a contradiction to it. AIE! NO YUM! BAD! YUM SUCKAGE! I've had the mis-fortune to use yum, and apt-get both. The former is really crappy, slow, and not smart at all.
Re: Slim-down effort: current situation
No worries Adam, Paul gave Yum just as a sort-of-like example. I don't know the addons technology, but I'm sure it's not related at all with Yum or even apt-get (more Ant and maybe Ivy) And of course, we all prefer get-apt (at least I do, actually I don't even know Yum :D) Jacques From: Adam Heath doo...@brainfood.com On 11/16/2012 05:40 AM, Jacques Le Roux wrote: Very well summed up, Paul Thanks Jacques From: madppiper p...@ilscipio.com @jacopo: That sounds like a terrific idea of yours! I have to read up on [Proposal], but from your outline here, i would say it is a more sincere step. @Olivier: I liked your presenation on addon-manager a lot and as already discussed would think that a tool like this (sort of like a yum- install manager) could be beneficial to whatever we come up with here. But the tool for me is an addition to the proposal above, it is not a contradiction to it. AIE! NO YUM! BAD! YUM SUCKAGE! I've had the mis-fortune to use yum, and apt-get both. The former is really crappy, slow, and not smart at all.
Re: Slim-down effort: current situation
Please see inline: On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote: Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I don't think we should move all specialpurpose components out of the project, and for sure not all of them in one shot: we could discuss on a per component basis. I heard here and there that not all the community is expecting good from this move. Of course it will be impossible to make everyone happy but the feedback I am reading in this thread makes me happy (no dramatic tones, like happened in the past, willing to evaluate pros and cons etc..). 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 (this should address Paul's concerns); 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) Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce component. The problem I have with these components (and to be clear I am not referring to this specific contribution) is that they are one particular implementation (and very often not the best) of a requirement (e.g. Solr integration, reporting tool, help system etc...) and there could be 100 others different ways to implement the same: for example, even if everyone agrees that the online help is useful, there are many doubts that the specific implementation of it we are discussing is the right way to go; or even if everyone agrees that a better reporting tool would be nice to have, there are many that think that the current Birt component is not the right way to go. Kind regards, Jacopo So far we agreed that the eCommerce component will be the only one (apart if we agree on it the new webhelp component) to stay in specialpurpose, right? Thanks to one last time share your opinions, before the next move occurs... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Slim-down effort: current situation
Inline... From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Please see inline: On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote: Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I don't think we should move all specialpurpose components out of the project, and for sure not all of them in one shot: we could discuss on a per component basis. Great I heard here and there that not all the community is expecting good from this move. Of course it will be impossible to make everyone happy but the feedback I am reading in this thread makes me happy (no dramatic tones, like happened in the past, willing to evaluate pros and cons etc..). 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 (this should address Paul's concerns); 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) This sounds like a really smart way, I will have to read [PROPOSAL] from specialpurpose to extras (closer) again... Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce component. The problem I have with these components (and to be clear I am not referring to this specific contribution) is that they are one particular implementation (and very often not the best) of a requirement (e.g. Solr integration, reporting tool, help system etc...) and there could be 100 others different ways to implement the same: for example, even if everyone agrees that the online help is useful, there are many doubts that the specific implementation of it we are discussing is the right way to go; or even if everyone agrees that a better reporting tool would be nice to have, there are many that think that the current Birt component is not the right way to go. 100 others different ways I'm not sure ;) But yes I get your point. The problem is then to get things done in time... There is nothing perfect in this world (which does not mean I believe in another perfect world)... Jacques Kind regards, Jacopo So far we agreed that the eCommerce component will be the only one (apart if we agree on it the new webhelp component) to stay in specialpurpose, right? Thanks to one last time share your opinions, before the next move occurs... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Slim-down effort: current situation
everyone will say that I ramble but I don't understand how it's possible to find a consensus on slim-down boundary or what should be in ofbiz kernel if there is no simple process to have a OFbiz with the selected functionalities. I clearly speak about addon manager. Some example to be more clear : First example) Birt or JasperReport : * To have a correct implementation it's necessary to add some file, update some others * everybody will agree it's important to have report in a ERP and currently report available in ofbiz in one of these weakness * when I want to develop or to contribute to ofbiz project with some report, theses report should be easily downloadable and installable for the users which want * added some and update some other (menus at least) for the technical way of birt implementation in ofbiz (or jasper one) ofbiz's PMC (and committer and contributors) can discuss and status to the correct way or quality or default solution and so decide to put - in apache-ofbiz - in ofbiz-extra quality level 1 or 2 or 3 ... but in all case, it should be easy for user 1) to see that these solutions exists 2) to understand to Apache OFbiz position on it 3) to be able to use it if they choose without a complex and dedicated process Second example) CRM application : * all main crm functions exist in ofbiz applications * CRM for B2B and B2C are not the same, in industry or service more not * some function which should be extend for CRM-B2B-industry are the same than for CRM-B2C-Service Why it's necessary to choose which one should be in ofbiz and other out but in all case, it should be easy for user 1) to see that these solutions exists 2) to understand to Apache OFbiz position on it 3) to be able to use it if they choose without a complex and dedicated process Some things can be at the component level some other at functions level. If we want to increase contribution we should give tools and organization for that. Currently Jira is perfect for bug correction or enhancement which should go to ofbiz, but not for business or technical functionalities dedicated for a business or a implementation type. We are multiple to develop the same thing for our customers, it's not logical in Apache project ecosystem. Clearly, addon management for an ERP in a difficult point, some of ERP address some point of addon management but not all. Clearly, addon management must be manage with 1) correct tools 2) correct administrative process and quality evaluation one ofbiz addon manager implementation exist and is available on ofbiz-extra http://code.google.com/a/apache-extras.org/p/ofbiz-adm/ If ofbiz-extra is, like paul said, a place to forgot contribution, it's better to clearly said it. if these implementation of ofbiz-addon is correct for ofbiz's PMC (and committer and contributors), I think it must be included in the ofbiz kernel to facilitate all other installation or un-installation. Last point, if there is no addon management in ofbiz, only component, IMO I have exactly the same opinion as Hans, otherwise every point is open to discussion. Olivier Le 16/11/2012 09:29, Jacopo Cappellato a écrit : Please see inline: On Nov 16, 2012, at 8:11 AM, Jacques Le Roux wrote: Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I don't think we should move all specialpurpose components out of the project, and for sure not all of them in one shot: we could discuss on a per component basis. I heard here and there that not all the community is expecting good from this move. Of course it will be impossible to make everyone happy but the feedback I am reading in this thread makes me happy (no dramatic tones, like happened in the past, willing to evaluate pros and cons etc..). 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 (this should address Paul's concerns); 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) Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce
Re: Slim-down effort: current situation
On Nov 16, 2012, at 10:50 AM, Olivier Heintz wrote: I don't understand how it's possible to find a consensus on slim-down boundary or what should be in ofbiz kernel if there is no simple process to have a OFbiz with the selected functionalities. I clearly speak about addon manager. Even if an OFBiz Plugin Manager would be a nice to have tool I don't think that without it we could not proceed with the removal of some components: it is true that this would require some manual steps (depending on the instructions of the component and on the type of deployment of the company using OFBiz) to plug-in the external component but it is also true that at the moment in order to have an OFBiz instance in production every company at least need the following skills: a database administrator (in order to fine tune db indexes, create db users, import data etc...), an architect (in order to identify the proper hardware and configuration for the application servers, database servers, web servers) and very often a developer (to extract data from legacy systems and import in OFBiz, to customize screens and processes, to debug problems etc...). Without this skill set all you can do is to setup a staging/demo box; if you have at least part of the skillset for a production system, manually deploying a couple more components would not be a big deal either. The only real area where a user friendly OFBiz Plugin Manager tool would be required is in a multi tenant system served as saas: the user (of a tenant) could setup plugins that are visible to that tenant only. Kind regards, Jacopo
Re: Slim-down effort: current situation
@jacopo: That sounds like a terrific idea of yours! I have to read up on [Proposal], but from your outline here, i would say it is a more sincere step. @Olivier: I liked your presenation on addon-manager a lot and as already discussed would think that a tool like this (sort of like a yum- install manager) could be beneficial to whatever we come up with here. But the tool for me is an addition to the proposal above, it is not a contradiction to it. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637667.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
Very well summed up, Paul Thanks Jacques From: madppiper p...@ilscipio.com @jacopo: That sounds like a terrific idea of yours! I have to read up on [Proposal], but from your outline here, i would say it is a more sincere step. @Olivier: I liked your presenation on addon-manager a lot and as already discussed would think that a tool like this (sort of like a yum- install manager) could be beneficial to whatever we come up with here. But the tool for me is an addition to the proposal above, it is not a contradiction to it. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637667.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
Le 16/11/2012 11:37, Jacopo Cappellato a écrit : On Nov 16, 2012, at 10:50 AM, Olivier Heintz wrote: I don't understand how it's possible to find a consensus on slim-down boundary or what should be in ofbiz kernel if there is no simple process to have a OFbiz with the selected functionalities. I clearly speak about addon manager. Even if an OFBiz Plugin Manager would be a nice to have tool I don't think that without it we could not proceed with the removal of some components: it is true that this would require some manual steps (depending on the instructions of the component and on the type of deployment of the company using OFBiz) to plug-in the external component but it is also true that at the moment in order to have an OFBiz instance in production every company at least need the following skills: a database administrator (in order to fine tune db indexes, create db users, import data etc...), an architect (in order to identify the proper hardware and configuration for the application servers, database servers, web servers) and very often a developer (to extract data from legacy systems and import in OFBiz, to customize screens and processes, to debug problems etc...). Without this skill set all you can do is to setup a staging/demo box; if you have at least part of the skillset for a production system, manually deploying a couple more components would not be a big deal either. why there are some jar in ofbiz, all people installing ofbiz have the knowledge to find and download all what is necessary It's to decrease the number of step to install, to help people (IT user, not end user I know) If putting something to extra is saying, it will be not easy and quick to install, it's the same thing that saying don't use it If we want specialpurpose or ofbiz-added function or extra is usable, it should as simple as ofbiz The only real area where a user friendly OFBiz Plugin Manager tool would be required is in a multi tenant system served as saas: the user (of a tenant) could setup plugins that are visible to that tenant only. Excuse-me, my explanation was not clear. OFBiz plugin can change any part of OFBiz (xml, java, properties, screen, services, framework, ...). In Multi-tenant there is only one application instance, so all use same ofbiz code. Configuration can only be done by parameters. Plug Manager is useful for building a ofbiz solution for a specific case . Kind regards, Jacopo
Re: Slim-down effort: current situation
On Nov 16, 2012, at 3:28 PM, Olivier Heintz wrote: It's to decrease the number of step to install, to help people (IT user, not end user I know) Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools. Regards, Jacopo
Re: Slim-down effort: current situation
On Nov 16, 2012, at 3:53 PM, Jacopo Cappellato wrote: Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools. oops... errata corrige: ... but not mandatory to use external tools --- ... but not mandatory to use external components Jacopo
Re: Slim-down effort: current situation
Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Slim-down effort: current situation
Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I heard here and there that not all the community is expecting good from this move. Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce component. So far we agreed that the eCommerce component will be the only one (apart if we agree on it the new webhelp component) to stay in specialpurpose, right? Thanks to one last time share your opinions, before the next move occurs... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Slim-down effort: current situation
In general i agree with this action however, 1. components which need to be integrated with components like help and reporting (birt) in order to be useful and which are essential for the functionality of the system, i do not agree: help Birt 2. further the following components are standard in any ERP system so OFBiz should have it too: ecommerce asset management pos,webpos 3. Then the components which are essential for new developers: example cmssite Regards, Hans On 11/16/2012 02:11 PM, Jacques Le Roux wrote: Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I heard here and there that not all the community is expecting good from this move. Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce component. So far we agreed that the eCommerce component will be the only one (apart if we agree on it the new webhelp component) to stay in specialpurpose, right? Thanks to one last time share your opinions, before the next move occurs... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Re: Slim-down effort: current situation
I am concerned about this move to be honest. In general, the idea to focus with apache ofbiz on its core and to cluster the other components into external plugins is an important step, however, I do not think that moving it all outside of ASF would help us by any means. In my opinion it is important to keep a relation between OFBiz and its subprojects. Granted, not all of which can fulfill the quality or commitment that we want to achieve, but taking it outside the realms of ASF and the PMC means that we forcefully take away the relation of one and another. This in turn means that the OFBiz and Apache brand do not apply to those projects and hence the level of commitment is going to be even less (why would any company commit its work if its not even going to be a part of the oficial brand?). In addition, taking projects entirely out of focus will result in less participation overall, because the projects are going to have less observations - not more. This will result in an overall downfall in quality of such components (which is not all that strong to begin with) and could hurt the community. Instead, there is a high probability that we will see an increase of additional and similar projects (a second, or third demo shop would probably not be too uncommon) which will strip the quality even further. Simply put the incentives aren't right. On top there is actually a somewhat legal infringement if I am not mistaken. Since the developers commited their sources to ASF, I wouldn't be too certain that you can simply take them and move them to google. Even if under the Apache license, I am not sure if its that easy to do so. Perhaps to clarify once more: The move in itself is good, but I would really hope for an ASF based subproject. It is important that we do this, but why not choose a better way that sets the incentives right? -- View this message in context: http://ofbiz.135035.n4.nabble.com/Slim-down-effort-current-situation-tp4637617p4637653.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Slim-down effort: current situation
I tend to agree with you Hans for those components, complements inline From: Hans Bakker mailingl...@antwebsystems.com In general i agree with this action however, 1. components which need to be integrated with components like help and reporting (birt) in order to be useful and which are essential for the functionality of the system, i do not agree: help Essential in my opinion, we should name it webhelp to make clear what it uses (docbook-webhelp seems a bit too much no?) Birt The only drawback with Birt though is its size, could we not use Ivy to charge what is not specific to OFBiz. Because I think not everybody is using Birt 2. further the following components are standard in any ERP system so OFBiz should have it too: ecommerce What about the new related Solr component contributed recently https://issues.apache.org/jira/browse/OFBIZ-4941 asset management pos,webpos Exactly my opinion for those 3 too 3. Then the components which are essential for new developers: example +1 cmssite I'd have to review more And what about projectmgr? The others are for me specific enough to get to Apache Extras Jacques Regards, Hans On 11/16/2012 02:11 PM, Jacques Le Roux wrote: Hi Jacopo, So apart the next step is to move all specialpurpose components to Apache Extras. Are we still all OK to do that? I heard here and there that not all the community is expecting good from this move. Like less attention to moved components or new component going only to Apache Extras. An example is the new Solr component wich is supposed to be used with the eCommerce component. So far we agreed that the eCommerce component will be the only one (apart if we agree on it the new webhelp component) to stay in specialpurpose, right? Thanks to one last time share your opinions, before the next move occurs... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques. I am going to work on the debian removal, that should be quick. Another important milestone would be the creation of an extras.html page for our website where we could list: 1) the components for OFBiz managed out of the OFBiz as Apache Extras 2) the components moved to Attic (migrating the information currently in Confluence) A short description in the page should describe the process. For this task a contributor/committer with good English skills would be required. The final content of the page will be approved in this list before it will be published. Kind regards, Jacopo On Nov 15, 2012, at 8:49 AM, Jacques Le Roux wrote: I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
Slim-down effort: current situation
I don't see much activity recently https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551 Should we not focus a bit more on it? Jacques
