Lose Weight Program for OFBiz

[Mansour]

Jacques,
We use RTL.
May be you are right about the the ease of use to find an item, but
the user who has permission to all these functionality is an admin,
and normally, she is comfortable finding any item quickly. The rest of
the uses don't have that much items and menus shown.

I know, other themes may look better, or fancier, but most users use
flat gray to base their work on and extend/customize it, because it's
easier and cleaner. I am not sure if bigger organization prefer
fancier look and feel over cleaner. And to be honest, I think flat
gray looks more professional than others. Therefore, it give a
positive first impression, when demonstrated.

Additional themes may still exist beside FlatGray, but I recommend to
make it the default one.


On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
<[hidden email]> wrote:

> I see that most people prefer Flat Grey.
>
> Let me explain why I prefer Tomahawk.
>
> Did you ever wonder why the paper we write on has more than often a greater
> height than width, why newspaper have many columns, etc.
> Here is an answer
> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>
> OK, my argument: don't you feel a pain to find an application, a menu entry
> in Flat Grey? No? Then you are used to find it at some place and don't care
> anymore. Now just imagine the same for a new user...
>
> This is where Tomahawk is better. It's far easier to find an entry in 2
> colums (applications in Tomahawk) than in 7 columns (applications in Flat
> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
> Flat Grey). Just try it
>
> Another point: Product screens are awful in Flat Grey (to many buttons for
> menus, hard to spot). Though actually I believe Tomahawk would benefit from
> a third column, for instance for Product. This could be 2 twin columns if
> more than, say, 15 entries would show in a column. Like we have for
> Applications, though not sure how it's organized. I mean why some are in
> right column and other in left one? Also something wich could help spot
> entries quicker would be to allow sorting entries in menus by language. It's
> now only done based on English.
>
> OK, now there is the RTL feature. Who use it? Few I guess
> (http://en.wikipedia.org/wiki/Right-to-left
> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not
> diminish RTL importance, but ponders it in choice for a default theme.
>
> My 2 cts
>
> Jacques
>
>
> From: "Ashish Vijaywargiya" <[hidden email]>
>
>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>> the best to keep as the default one for the project.
>>
>> --
>> Ashish
>>
>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>>> > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of
>>> > them
>>> to "Extras"; keep just one (or two)
>>> >
>>>
>>> Jacques proposed to keep Tomahawk (default) and Flat Grey.
>>> Olivier proposed to keep just one (Tomahawk, I guess).
>>> No other comments so far.
>>> What should be do with the remaining themes? Attic or Extras? Are there
>>> volunteers for Extras? I would suggest that, if we move them to Extras we
>>> create *one* project only (for all the themes) rather than one project
>>> for
>>> theme... but I would love to get your feedback on this.
>>>
>>> Jacopo
>>
>>
>

[Jacques Le Roux]

Hi Mansour,

From: "Mansour Al Akeel" <[hidden email]>
> Jacques,
> We use RTL.
> May be you are right about the the ease of use to find an item, but
> the user who has permission to all these functionality is an admin,
> and normally, she is comfortable finding any item quickly. The rest of
> the uses don't have that much items and menus shown.

This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep
Tomahawk as OOTB default for the reasons I explained and others I add below.

> I know, other themes may look better, or fancier, but most users use
> flat gray to base their work on and extend/customize it, because it's
> easier and cleaner. I am not sure if bigger organization prefer
> fancier look and feel over cleaner. And to be honest, I think flat
> gray looks more professional than others. Therefore, it give a
> positive first impression, when demonstrated.
>
> Additional themes may still exist beside FlatGray, but I recommend to
> make it the default one.

What makes you think "most users use flat gray to base their work" ?
Could you define "easier and cleaner", and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I
understand for you is a must have)
What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks
grey/pale and it's difficult to spot things.
With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's
If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB
(contrary to deployments)

Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to
add <<title="Skip navigation" accesskey="2>> (which is really only a small/poor beginnng) but that's for all themes. What is
specific to Flat Grey?

The only things I could concede:
1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about
contrast is maybe biased
2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long
term (hours of work)

Thanks for sharing your opinion :o)

Jacques

>
> On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
> <[hidden email]> wrote:
>> I see that most people prefer Flat Grey.
>>
>> Let me explain why I prefer Tomahawk.
>>
>> Did you ever wonder why the paper we write on has more than often a greater
>> height than width, why newspaper have many columns, etc.
>> Here is an answer
>> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>>
>> OK, my argument: don't you feel a pain to find an application, a menu entry
>> in Flat Grey? No? Then you are used to find it at some place and don't care
>> anymore. Now just imagine the same for a new user...
>>
>> This is where Tomahawk is better. It's far easier to find an entry in 2
>> colums (applications in Tomahawk) than in 7 columns (applications in Flat
>> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
>> Flat Grey). Just try it
>>
>> Another point: Product screens are awful in Flat Grey (to many buttons for
>> menus, hard to spot). Though actually I believe Tomahawk would benefit from
>> a third column, for instance for Product. This could be 2 twin columns if
>> more than, say, 15 entries would show in a column. Like we have for
>> Applications, though not sure how it's organized. I mean why some are in
>> right column and other in left one? Also something wich could help spot
>> entries quicker would be to allow sorting entries in menus by language. It's
>> now only done based on English.
>>
>> OK, now there is the RTL feature. Who use it? Few I guess
>> (http://en.wikipedia.org/wiki/Right-to-left
>> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not
>> diminish RTL importance, but ponders it in choice for a default theme.
>>
>> My 2 cts
>>
>> Jacques
>>
>>
>> From: "Ashish Vijaywargiya" <[hidden email]>
>>
>>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>>> the best to keep as the default one for the project.
>>>
>>> --
>>> Ashish
>>>
>>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>>> [hidden email]> wrote:
>>>
>>>> > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of
>>>> > them
>>>> to "Extras"; keep just one (or two)
>>>> >
>>>>
>>>> Jacques proposed to keep Tomahawk (default) and Flat Grey.
>>>> Olivier proposed to keep just one (Tomahawk, I guess).
>>>> No other comments so far.
>>>> What should be do with the remaining themes? Attic or Extras? Are there
>>>> volunteers for Extras? I would suggest that, if we move them to Extras we
>>>> create *one* project only (for all the themes) rather than one project
>>>> for
>>>> theme... but I would love to get your feedback on this.
>>>>
>>>> Jacopo
>>>
>>>
>>

[Vikas Mayur-2]

Hi Jacopo,

I have few questions on the proposed idea for Extras.

-- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
-- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
-- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
-- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
-- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?

Regards
Vikas

On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:

> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>
> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>
> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>
> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
> And this is exactly what we have now:
> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>
> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>
> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>
> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>
> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>
> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>
> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
> * is this feature used by other code in the system?
> * is the feature functional? or is it largely incomplete?
> * is this an old component/code?
> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>
> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>
> Legenda for what I propose for each piece of code:
> * Attic: remove from code base and document the removal for future reference in this page
> * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain "OFBiz Extras"
>
> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>
> A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component
>
> B) specialpurpose/pos: move to "Extras"
>
> C) $OFBIZ_HOME/debian: move to "Attic"
>
> D) the seleniumxml code in framework/testtools: move to "Attic"
>
> E) specialpurpose/workflow: move to "Attic"
>
> F) specialpurpose/shark: move to "Attic"
>
> G) specialpurpose/ofbizwebsite: move to "Attic"
>
> H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic"
>
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>
> J) framework/appserver: move to "Extras"
>
> K) framework/jetty: move to "Extras" (or "Attic")
>
> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>
> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>
> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>
> O) framework/documents: move the content to Wiki and then move to "Attic"
>
> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>
> Q) framework/example and framework/exampleext: move to specialpurpose
>
> Kind regards,
>
> Jacopo
>

[Jacopo Cappellato-4]

Hi Vikas,

I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):

On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:

> Hi Jacopo,
>
> I have few questions on the proposed idea for Extras.
>
> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?

No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.

>
> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.

Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there

> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?

I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience

> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?

No

> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?

Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.

Regards,

Jacopo

>
> Regards
> Vikas
>
> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>
>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>
>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>
>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>
>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>> And this is exactly what we have now:
>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>
>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>
>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>
>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>
>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>
>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>
>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>> * is this feature used by other code in the system?
>> * is the feature functional? or is it largely incomplete?
>> * is this an old component/code?
>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>
>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>
>> Legenda for what I propose for each piece of code:
>> * Attic: remove from code base and document the removal for future reference in this page
>> * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain "OFBiz Extras"
>>
>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>
>> A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component
>>
>> B) specialpurpose/pos: move to "Extras"
>>
>> C) $OFBIZ_HOME/debian: move to "Attic"
>>
>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>
>> E) specialpurpose/workflow: move to "Attic"
>>
>> F) specialpurpose/shark: move to "Attic"
>>
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
>> H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic"
>>
>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>
>> J) framework/appserver: move to "Extras"
>>
>> K) framework/jetty: move to "Extras" (or "Attic")
>>
>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>
>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>
>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>
>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>
>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>
>> Q) framework/example and framework/exampleext: move to specialpurpose
>>
>> Kind regards,
>>
>> Jacopo
>>
>

[Vikas Mayur-2]

Thanks Jacopo for your quick response. It clears my doubt.

Regards
Vikas

On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote:

> Hi Vikas,
>
> I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):
>
> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:
>
>> Hi Jacopo,
>>
>> I have few questions on the proposed idea for Extras.
>>
>> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
>
> No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.
>
>>
>> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
>
> Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there
>
>> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
>
> I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience
>
>> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
>
> No
>
>> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?
>
> Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.
>
> Regards,
>
> Jacopo
>
>
>>
>> Regards
>> Vikas
>>
>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>>
>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>
>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>
>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>
>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>> And this is exactly what we have now:
>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>
>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>
>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>
>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>
>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>
>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>
>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>> * is this feature used by other code in the system?
>>> * is the feature functional? or is it largely incomplete?
>>> * is this an old component/code?
>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>
>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>
>>> Legenda for what I propose for each piece of code:
>>> * Attic: remove from code base and document the removal for future reference in this page
>>> * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain "OFBiz Extras"
>>>
>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>
>>> A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component
>>>
>>> B) specialpurpose/pos: move to "Extras"
>>>
>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>
>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>
>>> E) specialpurpose/workflow: move to "Attic"
>>>
>>> F) specialpurpose/shark: move to "Attic"
>>>
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>
>>> H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic"
>>>
>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>
>>> J) framework/appserver: move to "Extras"
>>>
>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>
>>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>>
>>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>>
>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>
>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>
>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>
>>> Kind regards,
>>>
>>> Jacopo
>>>
>>
>

[samhamilton]

Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too?

Thanks
Sam


On 21 Mar 2012, at 16:23, Vikas Mayur wrote:

> Thanks Jacopo for your quick response. It clears my doubt.
>
> Regards
> Vikas
>
> On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote:
>
>> Hi Vikas,
>>
>> I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):
>>
>> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:
>>
>>> Hi Jacopo,
>>>
>>> I have few questions on the proposed idea for Extras.
>>>
>>> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
>>
>> No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.
>>
>>>
>>> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
>>
>> Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there
>>
>>> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
>>
>> I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience
>>
>>> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
>>
>> No
>>
>>> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?
>>
>> Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.
>>
>> Regards,
>>
>> Jacopo
>>
>>
>>>
>>> Regards
>>> Vikas
>>>
>>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>>>
>>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>>
>>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>>
>>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>>
>>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>>> And this is exactly what we have now:
>>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>>
>>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>>
>>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>>
>>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>>
>>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>>
>>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>>
>>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>>> * is this feature used by other code in the system?
>>>> * is the feature functional? or is it largely incomplete?
>>>> * is this an old component/code?
>>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>>
>>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>>
>>>> Legenda for what I propose for each piece of code:
>>>> * Attic: remove from code base and document the removal for future reference in this page
>>>> * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain "OFBiz Extras"
>>>>
>>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>>
>>>> A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component
>>>>
>>>> B) specialpurpose/pos: move to "Extras"
>>>>
>>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>>
>>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>>
>>>> E) specialpurpose/workflow: move to "Attic"
>>>>
>>>> F) specialpurpose/shark: move to "Attic"
>>>>
>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>
>>>> H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic"
>>>>
>>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>>
>>>> J) framework/appserver: move to "Extras"
>>>>
>>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>>
>>>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>>>
>>>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>>>
>>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>>
>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>>
>>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>>
>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>
>>>> Kind regards,
>>>>
>>>> Jacopo
>>>>
>>>
>>
>

[Jacopo Cappellato-4]

We will setup a page in the OFBiz website, for sure.
The final decision on the projects that will appear there will be done by the OFBiz PMC but I guess that initially it will only contain projects in Apache Extras; there may be exceptions to to this rule, I guess.

Jacopo

On Mar 21, 2012, at 11:05 AM, Sam Hamilton wrote:

> Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too?
>
> Thanks
> Sam
>
>
> On 21 Mar 2012, at 16:23, Vikas Mayur wrote:
>
>> Thanks Jacopo for your quick response. It clears my doubt.
>>
>> Regards
>> Vikas
>>
>> On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote:
>>
>>> Hi Vikas,
>>>
>>> I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF):
>>>
>>> On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote:
>>>
>>>> Hi Jacopo,
>>>>
>>>> I have few questions on the proposed idea for Extras.
>>>>
>>>> -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time?
>>>
>>> No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement.
>>>
>>>>
>>>> -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras.
>>>
>>> Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there
>>>
>>>> -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities?
>>>
>>> I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience
>>>
>>>> -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz?
>>>
>>> No
>>>
>>>> -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not?
>>>
>>> Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove.
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>>
>>>>
>>>> Regards
>>>> Vikas
>>>>
>>>> On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote:
>>>>
>>>>> In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase.
>>>>>
>>>>> We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm.
>>>>> Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc...
>>>>>
>>>>> Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project.
>>>>>
>>>>> The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code.
>>>>> And this is exactly what we have now:
>>>>> * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component)
>>>>> * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product
>>>>>
>>>>> The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users.
>>>>>
>>>>> It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it.
>>>>>
>>>>> OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc...
>>>>>
>>>>> I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight.
>>>>>
>>>>> In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project.
>>>>>
>>>>> IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations:
>>>>> * can the component be easily removed by the project? is it independent and can live outside as a plugin?
>>>>> * do we need all this custom code? can't we find a simpler, lighter and better way to implement this?
>>>>> * is this feature used by other code in the system?
>>>>> * is the feature functional? or is it largely incomplete?
>>>>> * is this an old component/code?
>>>>> * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
>>>>>
>>>>> DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list.... there are great ideas that didn't come to a finalization... it doesn't mean that moving them out of the project will kill them and this may actually help to get more visibility and different user group; so please when you will read it... think to the greater good of the community.
>>>>>
>>>>> Legenda for what I propose for each piece of code:
>>>>> * Attic: remove from code base and document the removal for future reference in this page
>>>>> * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain "OFBiz Extras"
>>>>>
>>>>> And now (drums)..... THE LIST - PART 1(but this is really a very first pass only, PART 2 will come soon with more granular - subcomponent - details):
>>>>>
>>>>> A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component
>>>>>
>>>>> B) specialpurpose/pos: move to "Extras"
>>>>>
>>>>> C) $OFBIZ_HOME/debian: move to "Attic"
>>>>>
>>>>> D) the seleniumxml code in framework/testtools: move to "Attic"
>>>>>
>>>>> E) specialpurpose/workflow: move to "Attic"
>>>>>
>>>>> F) specialpurpose/shark: move to "Attic"
>>>>>
>>>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>>>
>>>>> H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic"
>>>>>
>>>>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two)
>>>>>
>>>>> J) framework/appserver: move to "Extras"
>>>>>
>>>>> K) framework/jetty: move to "Extras" (or "Attic")
>>>>>
>>>>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>>>>
>>>>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>>>>
>>>>> N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework"
>>>>>
>>>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>>>
>>>>> P) framework/datafile: (who is currently using it?) move to "Extras" or "Attic"; we could replace it with commons-csv or similar tool
>>>>>
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Jacopo
>>>>>
>>>>
>>>
>>
>

[Pierre Smits]

I prefer to keep the Flat Grey and one other.

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
[hidden email]> het volgende:

> > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them
> to "Extras"; keep just one (or two)
> >
>
> Jacques proposed to keep Tomahawk (default) and Flat Grey.
> Olivier proposed to keep just one (Tomahawk, I guess).
> No other comments so far.
> What should be do with the remaining themes? Attic or Extras? Are there
> volunteers for Extras? I would suggest that, if we move them to Extras we
> create *one* project only (for all the themes) rather than one project for
> theme... but I would love to get your feedback on this.
>
> Jacopo

[Pierre Smits]

+1 on removal from core (framework), as it doesn't add any value in a
framework. However, having it available as a separate downloadable
application (to be used from hot-deploy or special purpose) would be
beneficiary for newcomers in the development scene.

Regards,

Pierre

Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
[hidden email]> het volgende:

> > Q) framework/example and framework/exampleext: move to specialpurpose
>
> Adrian would like to keep Example in the framework but slim it down a lot
> to the essential (no form widgets examples, no Ajax examples, no content
> examples etc...). Adrian would you please confirm if in your vision the
> "example" application should document the layout of a typical OFBiz
> component only? If yes, we could use the output of the "ant
> create-component" task to document the best practice layout.
> Jacques, Olivier would like to keep also the examples for the various
> higher level features available to OFBiz applications.
>
> I think that from the discussion it could emerge the following solution to
> please everyone:
>
> * keep the "example" component in the framework but slim it down to the
> bare essential
> * move the "exampleext" component to specialpurpose and migrate to it all
> the extra features: this could also be used as a best practice guide on how
> to extend a component from hot-deploy/specialpurpose
>
> I still think that it would be nicer to not bundle the "example" component
> ootb to keep the framework cleaner: the example should be downloaded
> separately (when we will have clear separation between framework and the
> rest); this approach is similar to tomcat and its example applications. But
> I don't have a strong opinion on this.
>
> Jacopo
>
>

[Pierre Smits]

+1

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
[hidden email]> het volgende:

>
> > G) specialpurpose/ofbizwebsite: move to "Attic"
> >
>
> Jacques and Olivier proposed to move it to Extras instead just in case
> someone will pick up the work and complete it in the future.
> I would like to mention that, if the original goal was "to eat our own dog
> food" and run the OFBiz site on it, then this could be in contrast with the
> ASF infrastructure offered to the projects.
>
> Jacopo

[hans_bakker]

---- then this could be in contrast with the ASF infrastructure offered
to the projects. -----

??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/

Regards,
Hans

On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>
> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.
>
> Jacopo

[Pierre Smits]

A) removal of framework/guiapp out of framework: +1

B) move specialpurpose/pos to 'Extras' +1

I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras'
as the majority of my customers use this. However, if it goes to 'Extras' I
would like to assist in maintaining it.

Regards,

Pierre

Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
[hidden email]> het volgende:

> > A) move framework/guiapp out of the framework; after all these years no
> code made advantage of it being part of the framework and it is only used
> by the specialpurpose/pos component (which was the component for which it
> was built for); so guiapp can go in the pos component
> >
> > B) specialpurpose/pos: move to "Extras"
> >
>
> No one objected so far; Jacques offered his help for #A.
> Should we focus on #A for now (it is an actionable item) and then discuss
> #B also based on the outcome of similar discussions for other
> specialpurpose components?
>
>

[Pierre Smits]

On all: +1

Regards,

Pierre

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
[hidden email]> het volgende:

>
> > C) $OFBIZ_HOME/debian: move to "Attic"
> >
> > D) the seleniumxml code in framework/testtools: move to "Attic"
> >
> > E) specialpurpose/workflow: move to "Attic"
> >
> > F) specialpurpose/shark: move to "Attic"
> >
> > J) framework/appserver: move to "Extras"
> >
> > K) framework/jetty: move to "Extras" (or "Attic")
>
> The above are components/features that don't seem to be used/maintained by
> the community: some of them are very old (workflow, shark, appserver,
> jetty), some of them are experimental (shark, seleniumxml), some of them
> are very specialized (debian).
> I have proposed some of them for the Attic and some of them for the Extras
> but in theory all of them could go to Extras if we find at least one
> maintainer for each; if not, each of them could go to Attic.
> Any ideas? volunteers (OFBiz committers or not)?
> No one objected or commented on them so far (so I suspect that there could
> be a lazy consensus); for the seleniumxml code there was also a thread some
> weeks ago in the user list where there seemed to be a general consensus
> (also from the original contributors of the work) for the removal (apart
> from Hans who is using it, it doesn't seem to be used much by the
> community).
>
> Jacopo
>
>

[Pierre Smits]

+ 1 on move of majority of apps in specialpurpose to 'Extras', excluding
projectmgr as it displays how to use OFBiz in a different industry than
ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does
deliver some of that versatility.

Regards,

Pierre

Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
[hidden email]> het volgende:

> >
> > H) specialpurpose/*: move several (if not all, apart ecommerce) of the
> components to "Extras" (if there are persons interested to become
> committers/maintainers) or to "Attic"
> >
>
> There seems to be a general agreement to slim down the number of
> applications in this group and move them to Extras (see exceptions below).
> I am summarizing here some notes but we should actually use this thread to
> continue the discussion about what should go to specialpurpose in general
> rather than focusing on the decision about removal of specific
> applications; we can then start a separate thread for each component.
>
> Adrian would like to keep one or two components to demonstrate the concept
> of reusing artifacts to create custom applications (Jacopo: can we use the
> "exampleext" component for this?)
> Hans would like to keep the ones that he considers feature complete like
> asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum.
> Jacopo: in my opinion even in the above list provided by Hans there are
> applications that are barely examples (cmssite) or are very specific
> implementation of very specific requirements (difficult to be used if your
> company doesn't have exactly these requirements): projectmgr and scrum;
> some of these components also extends (adding special purpose fields) the
> generic data model and this happens even if the user is not interested in
> evaluating the specialpurpose component. I also don't think that some of
> the components meet minimum quality requirements to be distributed with
> OFBiz: for example the scrum component uses a mechanism that is unique to
> demo its features (i.e. published a demo webapp with online instructions
> for demo data) that is not used by other applications (and this makes the
> suite of applications inconsistent); also, the component refers to
> resources that are owned by Hans' company. All in all, they seem very
> specific piece of codes that should better live as optional plugins
> downloaded separately. So in my opinion the "concept" of specialpurpose
> application is in general better suited for Apache Extras rather than for
> the OFBiz svn and releases.
>
>
>

[Pierre Smits]

+1. This is an example of bloat. Keeping ill-maintained static documents in
OFBiz (the suite) that are also available through the OFBiz website is not
adding value.

Regards,

Pierre

Op 20 maart 2012 12:48 schreef Jacopo Cappellato <
[hidden email]> het volgende:

>
> > O) framework/documents: move the content to Wiki and then move to "Attic"
> >
>
> The broader topic is to move all the artifacts related to online help out
> of the framework; they should all live under "applications".
>
>
>

[hans_bakker]

The idea behind this that documents in wiki are not according the
version..(only the latest)

This directory has it for the related version AND can be in different
languages and formats: html, pdf

do judge before you understand......
Regards,

Hans


On 03/21/2012 06:01 PM, Pierre Smits wrote:

> +1. This is an example of bloat. Keeping ill-maintained static documents in
> OFBiz (the suite) that are also available through the OFBiz website is not
> adding value.
>
> Regards,
>
> Pierre
>
> Op 20 maart 2012 12:48 schreef Jacopo Cappellato<
> [hidden email]>  het volgende:
>
>>> O) framework/documents: move the content to Wiki and then move to "Attic"
>>>
>> The broader topic is to move all the artifacts related to online help out
>> of the framework; they should all live under "applications".
>>
>>
>>

[Pierre Smits]

Currently, rptdesign is used in specialpurpose applications like ebaystore
and scrum, but also in core applications (accounting, order and product).
We have to provide reports in our applications, as it would be difficult to
maintain the concept of  completeness of functionality without them.
Endusers requirements always dictate some kind of reports in applications.

I prefer to have a working solution ootb in OFBiz. Birt delivers that at
the moment.

Removing it creates another proposition issue (on top of all the others we
can think of why OFBiz is hard to sell).

Replacing it by something else would dictate roadmapping.

Regards,

Pierre




Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
[hidden email]> het volgende:

> >
> > L) framework/birt (and related dependencies/reports spread around): move
> to "Extras"
> >
> > M) framework/bi (and related dependencies - ecas/business rules and data
> - spread around): move to "Extras"
> >
>
> This is an area where Hans and I are in disagreement and we didn't get
> much feedback from others.
>
> So I would like to explain here why I think we should move the Birt
> component and the Birt reports out of the framework and consider them as
> optional tools.
>
> There are currently 18 reports in the applications implemented with Birt;
> but they really seem experiments rather than something really usable; to
> give you some examples:
>
> * in most of them there is this code like this:
>
> userLogin = null;
> try {
>    userLogin =
> delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
> } catch(e) {
>        Debug.logError(e,"");
> }
>
> * all the retrieval logic (scripts) is inlined with layout definition and
> this is something we try to avoid in all the existing screens
> * entity list iterators are not properly closed
> * some of the widget based financial reports have been converted to Birt:
> their layout is still very simple and comparable to the widget based
> versions available before Birt; so the conversion to Birt added a
> dependencies on this component without adding real value (the rptdesign
> files mix together data preparation scripts and ui definitions and in order
> to maintain them you have to use the Birt designer); also some of them are
> now broken: Income Stetements, Balance Sheet etc... This is probably caused
> by the recent refactoring of JSR-223 but the original widget based PDF are
> still there and are working fine...
> * building a report with this Birt integration still requires a lot of
> development work (similar to the one required to create a screen); but then
> the code in the rptdesign is very difficult to maintain without the editor
>
> My questions are:
> * do you really think that this way of integrating rptdesign reports is
> the answer to fill the gap of a good reporting tool in OFBiz? Are you
> actually using this integration for your reports?
> * do we all agree to make this Birt integration the best practice
> mechanism for all OFBiz reports?
> * do you really think that we should replace all the existing widget
> generated reports and FOP reports with rptdesign reports built using the
> existing Birt integration under the framework?
>
> If any of your answers will be "no" then in my opinion it would be much
> better to:
> 1) make Birt integration an optional component, downloaded separately
> 2) move the existing rptdesign reports out of the applications and keep
> them in the external Birt component
> 3) at this point users will have the option to use the Birt component or
> not, but the ootb code will be clean and without dependencies on it; most
> of all, we will not deliver reports that looks similar (ugly) but they are
> implemented randomly with Birt or Widgets
> 4) start evaluating, as a community, what should be the best practices for
> ootb reports: what is the tool we want, what are the minimal requirements
> etc... and then work together to get it in place and then migrate all
> existing reports to it in order to have a consistent system; if the
> community will not be able to reach a consensus on this, then we should
> leave the decision about the reporting tool to use to the end user
>
> I think that the Birt integration is a nice optional component, and I see
> that there may be interested parties, but in its current status it is not
> something ready for becoming the primary reporting tool for the ootb
> applications.
>
> Jacopo

[Jacopo Cappellato-4]

Infra wouldn't be happy if we host the website in that demo instance; websites potentially have a lot of visits and that server is not intended for the load; this is similar to Confluence based pages: we will no more be allowed to use direct links to them from the website.

Jacopo

On Mar 21, 2012, at 11:46 AM, Hans Bakker wrote:

> ---- then this could be in contrast with the ASF infrastructure offered to the projects. -----
>
> ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/
>
> Regards,
> Hans
>
> On 03/20/2012 06:48 PM, Jacopo Cappellato wrote:
>>> G) specialpurpose/ofbizwebsite: move to "Attic"
>>>
>> Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future.
>> I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects.
>>
>> Jacopo
>

[Mansour]

Jacques,

inline:


On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux
<[hidden email]> wrote:

> Hi Mansour,
>
>
> From: "Mansour Al Akeel" <[hidden email]>
>>
>> Jacques,
>>
>> We use RTL.
>> May be you are right about the the ease of use to find an item, but
>> the user who has permission to all these functionality is an admin,
>> and normally, she is comfortable finding any item quickly. The rest of
>> the uses don't have that much items and menus shown.
>
>
> This makes sense for a deployment, not OOTB. It's IMO easier to select Flat
> Grey, if you prefer, for your deployments and to keep
> Tomahawk as OOTB default for the reasons I explained and others I add below.
>

Yes, this will work. So you are offering a fancier theme for the demo
purposes, targeting new comers,
and developers, can make a copy of FlatGray and customize it. Sound good.

>
>> I know, other themes may look better, or fancier, but most users use
>> flat gray to base their work on and extend/customize it, because it's
>> easier and cleaner. I am not sure if bigger organization prefer
>> fancier look and feel over cleaner. And to be honest, I think flat
>> gray looks more professional than others. Therefore, it give a
>> positive first impression, when demonstrated.
>>
>> Additional themes may still exist beside FlatGray, but I recommend to
>> make it the default one.
>
>
> What makes you think "most users use flat gray to base their work" ?

Sorry, I didn't express it properly. I meant most user based on my
experience. I have two developers, I worked with,
extend flat gray, and customize it as they need. This is not a number
that can be a base for a statistical study,
and generalize it. It's only my limited experience. Sorry for the confusion.

> Could you define "easier and cleaner", and why Flat Grey is easier and
> cleaner (besides that it's the only one that is RTL which I
> understand for you is a must have)

Cleaner and easier in terms of usage:
The menu is at the top, showing all the available item, makes it easy
to see what I need in case I navigated to the wrong section, or need
another
section. Nothing hidden. In fact even as a demo, it has some positive effect.

and Cleaner and easier in terms of development:
Flat Gray code is not cluttered. (that is how I feel).

> What makes you think Flat Grey looks more professionnal? For me Flat Gray
> has not enough contrast. In other words all looks
> grey/pale and it's difficult to spot things.

I work more with enterprise portals than with ERPs. From what I have
seen, portal severs default theme is mostly light,
with darker high light. And I find FlatGray closer to them than
Tomahawk theme is.

For example:
http://portals.apache.org/jetspeed-2/
and:
http://www.liferay.com/products/liferay-portal/overview

After all, It is not that hard for a developer to change the style of
OFBiz themes to reflect the colors she likes.

> With Tomahawk I quickly spot buttons, links, etc. because there is more
> contrast. Maybe it's
> If you read me, it's not about being fancier but ergonomic which is for me
> the only priority for the community to use OFBiz OOTB
> (contrary to deployments)

It's the opposite to me. I find it easier to spot things using
FlatGray. But again not a big deal.

>
> Also I'd like to know why Flat Grey is the only Theme being marked as being
> Sight-Impaired Accessible? Adrian? I remember I began to
> add <<title="Skip navigation" accesskey="2>> (which is really only a
> small/poor beginnng) but that's for all themes. What is
> specific to Flat Grey?
>

> The only things I could concede:
> 1. Like 1 to 5% of the male population (women are rarely touched) I'm
> daltonian (kind of sight-impaired ;o) so my vision about
> contrast is maybe biased
> 2. Maybe, because it uses a blackboard background style rather than a white
> paper style, Tomahawk is more arduous for eyes on a long
> term (hours of work)

Yes. I can see this, and I agree.

>
> Thanks for sharing your opinion :o)
>
> Jacques
>

Finally, it's a personal preference.
However, I like to keep FlatGray. Doesn't have to be the default,
Unless demos in RTL needed.

Thank you.

>
>>
>> On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux
>> <[hidden email]> wrote:
>>>
>>> I see that most people prefer Flat Grey.
>>>
>>> Let me explain why I prefer Tomahawk.
>>>
>>> Did you ever wonder why the paper we write on has more than often a
>>> greater
>>> height than width, why newspaper have many columns, etc.
>>> Here is an answer
>>>
>>> http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns
>>>
>>> OK, my argument: don't you feel a pain to find an application, a menu
>>> entry
>>> in Flat Grey? No? Then you are used to find it at some place and don't
>>> care
>>> anymore. Now just imagine the same for a new user...
>>>
>>> This is where Tomahawk is better. It's far easier to find an entry in 2
>>> colums (applications in Tomahawk) than in 7 columns (applications in Flat
>>> Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in
>>> Flat Grey). Just try it
>>>
>>> Another point: Product screens are awful in Flat Grey (to many buttons
>>> for
>>> menus, hard to spot). Though actually I believe Tomahawk would benefit
>>> from
>>> a third column, for instance for Product. This could be 2 twin columns if
>>> more than, say, 15 entries would show in a column. Like we have for
>>> Applications, though not sure how it's organized. I mean why some are in
>>> right column and other in left one? Also something wich could help spot
>>> entries quicker would be to allow sorting entries in menus by language.
>>> It's
>>> now only done based on English.
>>>
>>> OK, now there is the RTL feature. Who use it? Few I guess
>>> (http://en.wikipedia.org/wiki/Right-to-left
>>> http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does
>>> not
>>> diminish RTL importance, but ponders it in choice for a default theme.
>>>
>>> My 2 cts
>>>
>>> Jacques
>>>
>>>
>>> From: "Ashish Vijaywargiya" <[hidden email]>
>>>
>>>> My vote will be to keep two themes in the project. IMO Flatgrey theme is
>>>> the best to keep as the default one for the project.
>>>>
>>>> --
>>>> Ashish
>>>>
>>>> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato <
>>>> [hidden email]> wrote:
>>>>
>>>>> > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of
>>>>> > them
>>>>> to "Extras"; keep just one (or two)
>>>>> >
>>>>>
>>>>> Jacques proposed to keep Tomahawk (default) and Flat Grey.
>>>>> Olivier proposed to keep just one (Tomahawk, I guess).
>>>>> No other comments so far.
>>>>> What should be do with the remaining themes? Attic or Extras? Are there
>>>>> volunteers for Extras? I would suggest that, if we move them to Extras
>>>>> we
>>>>> create *one* project only (for all the themes) rather than one project
>>>>> for
>>>>> theme... but I would love to get your feedback on this.
>>>>>
>>>>> Jacopo
>>>>
>>>>
>>>>
>>>
>

[Mansour]

I would recommend keeping partymgr and assetmaint.
I am not sure if accounting depends on assetmain.


On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits <[hidden email]> wrote:

> + 1 on move of majority of apps in specialpurpose to 'Extras', excluding
> projectmgr as it displays how to use OFBiz in a different industry than
> ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does
> deliver some of that versatility.
>
> Regards,
>
> Pierre
>
> Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
> [hidden email]> het volgende:
>
>> >
>> > H) specialpurpose/*: move several (if not all, apart ecommerce) of the
>> components to "Extras" (if there are persons interested to become
>> committers/maintainers) or to "Attic"
>> >
>>
>> There seems to be a general agreement to slim down the number of
>> applications in this group and move them to Extras (see exceptions below).
>> I am summarizing here some notes but we should actually use this thread to
>> continue the discussion about what should go to specialpurpose in general
>> rather than focusing on the decision about removal of specific
>> applications; we can then start a separate thread for each component.
>>
>> Adrian would like to keep one or two components to demonstrate the concept
>> of reusing artifacts to create custom applications (Jacopo: can we use the
>> "exampleext" component for this?)
>> Hans would like to keep the ones that he considers feature complete like
>> asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum.
>> Jacopo: in my opinion even in the above list provided by Hans there are
>> applications that are barely examples (cmssite) or are very specific
>> implementation of very specific requirements (difficult to be used if your
>> company doesn't have exactly these requirements): projectmgr and scrum;
>> some of these components also extends (adding special purpose fields) the
>> generic data model and this happens even if the user is not interested in
>> evaluating the specialpurpose component. I also don't think that some of
>> the components meet minimum quality requirements to be distributed with
>> OFBiz: for example the scrum component uses a mechanism that is unique to
>> demo its features (i.e. published a demo webapp with online instructions
>> for demo data) that is not used by other applications (and this makes the
>> suite of applications inconsistent); also, the component refers to
>> resources that are owned by Hans' company. All in all, they seem very
>> specific piece of codes that should better live as optional plugins
>> downloaded separately. So in my opinion the "concept" of specialpurpose
>> application is in general better suited for Apache Extras rather than for
>> the OFBiz svn and releases.
>>
>>
>>