Lose Weight Program for OFBiz

[Jacques Le Roux]

Hans,

The problem is that it's completly outdated and nobody is able/want to maintain it

Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc.

Jacques

From: "Hans Bakker" <[hidden email]>

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

[Jacques Le Roux]

From: "Mansour Al Akeel" <[hidden email]>

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

That's an important point, and makes me need to consider indeed!
I mean it's not obvious for new comers that only one theme is RTL able
I think it should be default because of that, and keep Tomahawk as OOTB alternative

Jacques

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

[Jacques Le Roux]

partymgr  is in application will not move, you meant ProjectMgr  right?

Jacques

From: "Mansour Al Akeel" <[hidden email]>

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

[hans_bakker]

Jacques,

sure  at the time is was up-to-date and this was a proposal how we can
use ofbiz for the website, however because of the strict apache rules it
was not used...but can still be a template for any local ofbiz website.....

It remains weak: being an 'ofbiz' provider but not using it yourself.....

Regards,
Hans

On 03/21/2012 08:55 PM, Jacques Le Roux wrote:

> Hans,
>
> The problem is that it's completly outdated and nobody is able/want to
> maintain it
>
> Just compare with http://ofbiz.apache.org/ which follows ASF rules
> with for instance a TM on Logo, etc.
>
> Jacques
>
> From: "Hans Bakker" <[hidden email]>
>> ---- 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
>>

[Jacques Le Roux]

And there are parts in framework

Jacques

From: "Hans Bakker" <[hidden email]>

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

Hans,

The OFBiz project can hardly be regarded as an OFBiz Provider. Look at the
list of Providers on the site. Then look at the source of their websites
and have a feel for how many (besides your company) use OFBiz as a WCM.

There are several solutions in the field providing for website
functionality. Some of which including a richer set of functionality and
better user experience.

Regards,

Pierre

Op 21 maart 2012 15:03 schreef Hans Bakker
<[hidden email]>het volgende:

> Jacques,
>
> sure  at the time is was up-to-date and this was a proposal how we can use
> ofbiz for the website, however because of the strict apache rules it was
> not used...but can still be a template for any local ofbiz website.....
>
> It remains weak: being an 'ofbiz' provider but not using it yourself.....
>
> Regards,
> Hans
>
>
> On 03/21/2012 08:55 PM, Jacques Le Roux wrote:
>
>> Hans,
>>
>> The problem is that it's completly outdated and nobody is able/want to
>> maintain it
>>
>> Just compare with http://ofbiz.apache.org/ which follows ASF rules with
>> for instance a TM on Logo, etc.
>>
>> Jacques
>>
>> From: "Hans Bakker" <[hidden email]**>
>>
>>> ---- then this could be in contrast with the ASF infrastructure offered
>>> to the projects. -----
>>>
>>> ??? try: http://demo-trunk.ofbiz.**apache.org/ofbiz/<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,

Yes. You are right. I meant projectmgr.  :)

I believe assetmaint and projectmgr are used more than others and good
to keep them where they are.

Thank you.

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

> partymgr  is in application will not move, you meant ProjectMgr  right?
>
> Jacques
>
> From: "Mansour Al Akeel" <[hidden email]>
>
>> 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.
>>>>
>>>>
>>>>
>

[Jacques Le Roux-3]

They are more generic sure, I wonder for the pos...

Jacques

From: "Mansour Al Akeel" <[hidden email]>

> Jacques,
>
> Yes. You are right. I meant projectmgr.  :)
>
> I believe assetmaint and projectmgr are used more than others and good
> to keep them where they are.
>
> Thank you.
>
> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
> <[hidden email]> wrote:
>> partymgr is in application will not move, you meant ProjectMgr right?
>>
>> Jacques
>>
>> From: "Mansour Al Akeel" <[hidden email]>
>>
>>> 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.
>>>>>
>>>>>
>>>>>
>>
>

[Anil Patel-3]

People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so?

Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom.

Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists.

Finally if a Project in Extras is useful for business, people will keep improving it and community will grow.

Thanks and Regards
Anil Patel
HotWax Media Inc

On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:

> They are more generic sure, I wonder for the pos...
>
> Jacques
>
> From: "Mansour Al Akeel" <[hidden email]>
>> Jacques,
>> Yes. You are right. I meant projectmgr.  :)
>> I believe assetmaint and projectmgr are used more than others and good
>> to keep them where they are.
>> Thank you.
>> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
>> <[hidden email]> wrote:
>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>
>>> Jacques
>>>
>>> From: "Mansour Al Akeel" <[hidden email]>
>>>
>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>
>>

[Mansour]

Anil,
I agree with you.

Jacques,
I don't use pos, but I think it's good idea to keep it where it's. I
think it's more likely, it will be used more than what goes in Extra.
It fits "specialpurpose".



On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel <[hidden email]> wrote:

> People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so?
>
> Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom.
>
> Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists.
>
> Finally if a Project in Extras is useful for business, people will keep improving it and community will grow.
>
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
>
> On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:
>
>> They are more generic sure, I wonder for the pos...
>>
>> Jacques
>>
>> From: "Mansour Al Akeel" <[hidden email]>
>>> Jacques,
>>> Yes. You are right. I meant projectmgr.  :)
>>> I believe assetmaint and projectmgr are used more than others and good
>>> to keep them where they are.
>>> Thank you.
>>> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
>>> <[hidden email]> wrote:
>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>
>>>> Jacques
>>>>
>>>> From: "Mansour Al Akeel" <[hidden email]>
>>>>
>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>

[Anil Patel-3]

>
> Jacques,
> I don't use pos, but I think it's good idea to keep it where it's. I
> think it's more likely, it will be used more than what goes in Extra.
> It fits "specialpurpose".
>

Why do you think a component will be used more if its in specialpurpose section, instead of Extras.

Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying "UX sucks" :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer.

In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras.

One of the reasons (I am sure there were many) why OpenTaps was started is License.

I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow.

Regards
Anil Patel

>
>
> On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel <[hidden email]> wrote:
>> People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so?
>>
>> Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom.
>>
>> Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists.
>>
>> Finally if a Project in Extras is useful for business, people will keep improving it and community will grow.
>>
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>>
>> On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:
>>
>>> They are more generic sure, I wonder for the pos...
>>>
>>> Jacques
>>>
>>> From: "Mansour Al Akeel" <[hidden email]>
>>>> Jacques,
>>>> Yes. You are right. I meant projectmgr.  :)
>>>> I believe assetmaint and projectmgr are used more than others and good
>>>> to keep them where they are.
>>>> Thank you.
>>>> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
>>>> <[hidden email]> wrote:
>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Mansour Al Akeel" <[hidden email]>
>>>>>
>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>

[Mansour]

Anil,
I did not mean that putting a component under "specialpurposes" will
make it used more by developers.
I meant because it will be used more than other component, let's not move it.
From Jacopo's first email about the Lose Weight :

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"

He didn't mention anything about what type of applications should
go/remain under "specialpurposes".
Since (I think), pos is used more than what went into Exta or Attic, I
suggested keeping it where it's.
The question is, will POS be maintained by ofbiz community or another
party ? If it's will be separated from ofbiz, what about XUL
integration code?
should it remain part of  the core ofbiz (framework), or moved to the
component that needs it, and becomes the responsibility of the "POS"
maintainer ?


With regard to changing the License, I think it's possible on any part
of Ofbiz and not only components under Extra.
In all cases, users who uses POS more than I do, can give better suggestion.



On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel <[hidden email]> wrote:

>>
>> Jacques,
>> I don't use pos, but I think it's good idea to keep it where it's. I
>> think it's more likely, it will be used more than what goes in Extra.
>> It fits "specialpurpose".
>>
>
> Why do you think a component will be used more if its in specialpurpose section, instead of Extras.
>
> Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying "UX sucks" :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer.
>
> In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras.
>
> One of the reasons (I am sure there were many) why OpenTaps was started is License.
>
> I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow.
>
> Regards
> Anil Patel
>
>>
>>
>> On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel <[hidden email]> wrote:
>>> People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so?
>>>
>>> Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom.
>>>
>>> Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists.
>>>
>>> Finally if a Project in Extras is useful for business, people will keep improving it and community will grow.
>>>
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>>
>>> On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:
>>>
>>>> They are more generic sure, I wonder for the pos...
>>>>
>>>> Jacques
>>>>
>>>> From: "Mansour Al Akeel" <[hidden email]>
>>>>> Jacques,
>>>>> Yes. You are right. I meant projectmgr.  :)
>>>>> I believe assetmaint and projectmgr are used more than others and good
>>>>> to keep them where they are.
>>>>> Thank you.
>>>>> On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
>>>>> <[hidden email]> wrote:
>>>>>> partymgr is in application will not move, you meant ProjectMgr right?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Mansour Al Akeel" <[hidden email]>
>>>>>>
>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>
>

[Olivier.heintz]

Le 20/03/2012 10:15, Jacopo Cappellato a écrit :
> Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared.
>
> There seems to be a general agreement (with exceptions) about the following points:
> * the size of OFBiz should be reduced
> * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them)
> * some components/features can go to Extras
> * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately)
in the plug-in approach don't forget Apache-OFBiz sub-project for
plug-in done with all it's needed in Apache approach (best practice,
user help, large community, ....)

> I am starting separate threads to discuss specific topics/actionable items.
>
> Kind regards,
>
> Jacopo
>
> On Mar 18, 2012, at 10:10 AM, 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
>>
>

[Olivier.heintz]

Le 20/03/2012 15:31, [hidden email] a écrit :
> I like the idea of keeping reporting tools separate from OFBiz. In my
> experience, IT departments are already using a reporting tool for
> other applications and they would prefer to integrate that tool with
> OFBiz, instead of learning/using a new tool that comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to
maximize ready-to-use report and for small company which have not yet a
real reporting tool.

>
> -Adrian
>
> Quoting Jacopo Cappellato <[hidden email]>:
>
>>>
>>> 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
>
>
>
>

[Olivier.heintz]

+1 birt to extra
and there will also a jasperReport in extras

Le 20/03/2012 15:34, Mansour Al Akeel a écrit :

> +1 birt to Extra.
>
>
> On Tue, Mar 20, 2012 at 10:31 AM,<[hidden email]>  wrote:
>> I like the idea of keeping reporting tools separate from OFBiz. In my
>> experience, IT departments are already using a reporting tool for other
>> applications and they would prefer to integrate that tool with OFBiz,
>> instead of learning/using a new tool that comes bundled with it.
>>
>> -Adrian
>>
>>
>> Quoting Jacopo Cappellato<[hidden email]>:
>>
>>>> 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
>>
>>
>>

[Olivier.heintz]

Le 20/03/2012 15:58, Jacques Le Roux a écrit :

> From: "Jacopo Cappellato" <[hidden email]>
>>> 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?
>
> Yes, I know there are POS users out there. So I now wonder if we
> should not wait before moving it out of specialpurpose. When you think
> about it, it's the twin of eCommerce. With a bit more involvment
> though, mostly because of its relation with Entity Sync (maintenance)
> which is actually part of the framework (entityext component).

IMO, pos is one of the perfect example which should go in a
Apache-OFbiz-SubProject not out of Apache-Ofbiz,
of course +1 to becoming a plug-in but one of the Apache-OFBiz official
plug-in
>
> Jacques

[Olivier.heintz]

Le 21/03/2012 11:50, Pierre Smits a écrit :
> 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.
+1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz

ps: most of our(the company I'm working for) future contribution will be
complete Projectmgr migration to portlet ;-)

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

Hi Olivier,

I would love to exchange thoughts regarding migration to portlets.

Regards,

Pierre

Sent from my iPhone

On 21 mrt. 2012, at 17:26, Olivier Heintz <[hidden email]> wrote:

> Le 21/03/2012 11:50, Pierre Smits a écrit :
>> 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.
> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
>
> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)
>> 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?
>>>
>>>
>

[Jacopo Cappellato-4]

On Mar 21, 2012, at 5:26 PM, Olivier Heintz wrote:

> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
>
> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)

Just to avoid any confusion:
* with this +1 you are asking to keep projectmgr as it is now (specialpurpose)
* we do not have "official Apache subprojects" in the small OFBiz community because they could be an overkill for what we do (subprojects needs PMC etc...) and we should be careful to even evaluate this path because it will add a lot of "paperwork" to our daily processes
* transforming the architecture of the component(s) to enable plug-in can be discussed, even if in some ways they are already plugins; but I am wide open to discuss/evaluate your new proposals even if this discussion should be kept separate from the current thread

Jacopo

[Jacopo Cappellato-4]

As a next step, after all these threads about the slim down will settle down, we should probably, as a community, start to prepare the plan of action, aka roadmap (we could use Jira for it): add there all the actionable tasks coming out of this discussions; then, in these mailing lists we should also start to discuss, as a community, what are the other priorities/goals for the next few months of the project. We should probably start slowly with some cleanup tasks and refactoring of old code, bug fixes etc... but we could also come up with some more interesting priorities (like JCR or reporting tools): then, based on the priorities identified by the community we will start to explore how to design them; if an agreement is found we will add the tasks to the roadmap as well; then we will have a clear and shared plan of actions to keep us all busy for a while
If migration to portlets will be a priority item is something that should be discussed with the community: the community is small and it should stay focused on a few key goals at the time; if the community will decide that the migration to portlets is something desirable then we will definitely explore this concept.

Jacopo

On Mar 21, 2012, at 5:33 PM, Pierre @GMail wrote:

> Hi Olivier,
>
> I would love to exchange thoughts regarding migration to portlets.
>
> Regards,
>
> Pierre
>
> Sent from my iPhone
>
> On 21 mrt. 2012, at 17:26, Olivier Heintz <[hidden email]> wrote:
>
>> Le 21/03/2012 11:50, Pierre Smits a écrit :
>>> 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.
>> +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz
>>
>> ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-)
>>> 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?
>>>>
>>>>
>>