Lose Weight Program for OFBiz

[Jacopo Cappellato-4]

> 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

[Jacopo Cappellato-4]

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

[Jacopo Cappellato-4]

> 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

[Malin Nicolas]

Agree with Jacopo, specialpurpose should be on extras.
Scrum depend of projectmgr, the OFBiz extra will be have a dependency
management to ensure that all needed components will be present.

Nicolas

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>> 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.


--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Malin Nicolas]

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :

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

example and exampleext are they useful for production site ?
if Apache OFBiz implement a plugin manager, why don't use ant (or other)
to prepare OFBiz according to its use.

If you want develop on OFBiz, when you download from svn run : ant
run-install-dev (it's a example ;)) and ant use plugin manager to
resolve all extras project that compose the official OFBiz developer
package.

[my life]
At this time, I comment all unneeded components as example on production
site. It isn't a problem, just I don't find clean :)
[/my life]

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Malin Nicolas]

Le 20/03/2012 12:47, Jacopo Cappellato a écrit :

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

Currently, we work on a POC to use content for reporting, the report
mechanism is selected by the template type. We implement our first
reports with openoffice but I don't see blocking to use birt, jasper or
other. With this methods, all report engine can move on Extras and when
you deploy, you select for specific report the content thus the desired
engine.

My vision : by default Apache OFBiz embed Xsl-fo and when you download a
other report engine, it give some example and standard content reporting.

+1 to move birt in extras :)
> 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


--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

I believe the original purpose of the Example component was to provide  
a very basic application that new developers can analyze and learn  
from. Running the ant task creates an empty application - there is  
nothing to see there.

So, here is the use case: I need to train new developers to write an  
OFBiz application, and I need a basic functional application to point  
them to. The training could occur with a framework-only instance of  
OFBiz.

-Adrian

Quoting Jacopo Cappellato <[hidden email]>:

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

[Adrian Crum-3]

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

[Adrian Crum-3]

My preference is to keep Flat Grey and one other theme - I have no  
preference on what that other theme is.

-Adrian

Quoting Jacopo Cappellato <[hidden email]>:

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

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

[Mansour]

Flat Gray is simple, and clear.
It serves well as a basic theme.
AFAIK, it the only theme that supports both directions for languages
LTR and RTL.


On Tue, Mar 20, 2012 at 10:33 AM,  <[hidden email]> wrote:

> My preference is to keep Flat Grey and one other theme - I have no
> preference on what that other theme is.
>
> -Adrian
>
>
> Quoting Jacopo Cappellato <[hidden email]>:
>
>>> 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
>
>
>
>

[Adrian Crum-3]

I have always had a problem with OS-specific code being maintained in  
OFBiz. Granted, we have some artifacts that must take the OS into  
consideration in order to get OFBiz to work, but it appears to me the  
Debian stuff doesn't fall into that category (I could be wrong, please  
correct me if I am).

For example, we have start scripts (startofbiz.*) as a convenience for  
users running on various platforms, but those scripts are somewhat  
generic. Is the Debian stuff similar to that or not?

+1 on shark and workflow

+0 on the rest.

Quoting Jacopo Cappellato <[hidden email]>:

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

[Mansour]

is it possible to download the "example" separately for new comers ?



On Tue, Mar 20, 2012 at 10:28 AM,  <[hidden email]> wrote:

> I believe the original purpose of the Example component was to provide a
> very basic application that new developers can analyze and learn from.
> Running the ant task creates an empty application - there is nothing to see
> there.
>
> So, here is the use case: I need to train new developers to write an OFBiz
> application, and I need a basic functional application to point them to. The
> training could occur with a framework-only instance of OFBiz.
>
> -Adrian
>
>
> Quoting Jacopo Cappellato <[hidden email]>:
>
>>> 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
>>
>>
>
>
>

[Adrian Crum-3]

Yes, making it an extra is an option.

-Adrian

Quoting Mansour Al Akeel <[hidden email]>:

> is it possible to download the "example" separately for new comers ?
>
>
>
> On Tue, Mar 20, 2012 at 10:28 AM,  
> <[hidden email]> wrote:
>> I believe the original purpose of the Example component was to provide a
>> very basic application that new developers can analyze and learn from.
>> Running the ant task creates an empty application - there is nothing to see
>> there.
>>
>> So, here is the use case: I need to train new developers to write an OFBiz
>> application, and I need a basic functional application to point them to. The
>> training could occur with a framework-only instance of OFBiz.
>>
>> -Adrian
>>
>>
>> Quoting Jacopo Cappellato <[hidden email]>:
>>
>>>> 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
>>>
>>>
>>
>>
>>
>

[Jacques Le Roux]

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

Jacques

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

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

Basically I'd keep only eCommerce and POS, maybe asset maintenance (arguments?).
LDAP could be moved IMO, else why not crowd, etc. The less exceptions the better

Jacques

[Jacques Le Roux]

From: <[hidden email]>
>I believe the original purpose of the Example component was to provide  
> a very basic application that new developers can analyze and learn  
> from. Running the ant task creates an empty application - there is  
> nothing to see there.
>
> So, here is the use case: I need to train new developers to write an  
> OFBiz application, and I need a basic functional application to point  
> them to. The training could occur with a framework-only instance of  
> OFBiz.

This makes sense, but then why in framework and not whole in specialpurporse?
If we slim down specialpurpose, this should not make a huge difference.

Jacques
 

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

[Jacques Le Roux]

From: "Mansour Al Akeel" <[hidden email]>
> Flat Gray is simple, and clear.
> It serves well as a basic theme.
> AFAIK, it the only theme that supports both directions for languages
> LTR and RTL.

Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: it's easier to find you way because of hierarchised menus
(with only 2 levels).
Flat Gray is a must have because of LTR and RTL (thanks Adrian!)

One project for all themes in Extra makes sense to me.
Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic (I never got to use Bizzness), to be voted...

Jacques

>
> On Tue, Mar 20, 2012 at 10:33 AM,  <[hidden email]> wrote:
>> My preference is to keep Flat Grey and one other theme - I have no
>> preference on what that other theme is.
>>
>> -Adrian
>>
>>
>> Quoting Jacopo Cappellato <[hidden email]>:
>>
>>>> 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
>>
>>
>>
>>

[Jacopo Cappellato-4]

Makes sense

Jacopo

On Mar 20, 2012, at 3:58 PM, Jacques Le Roux wrote:

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

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>
>> 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".

What about documents currently in documents folders under framework folders?

Some could be replaced by README, like FrameworkBase.xml.
Not sure for stuff like ReceivingEmail.xml which speaks about MCA (same for other framework specific features)

Jacques