Lose Weight Program for OFBiz

[Olivier.heintz]

Le 21/03/2012 16:16, Anil Patel a écrit :

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

As I said in a previous email, imo
1) it's very important for the end-user to be very clear especially for
the license,
2) for visibility, we should not have too many "project" or
'repository", so in OFBiz-extras, we should have only a few project, not
one per plug-in, but one per repository.
example of repository
- all plug-in with a Apache 2.0 license and hight quality level
- all plug-in with a Apache 2.0 license, in development process
- all plug-in with a Apache 2.0 license, with no more activity
- all plug-in with a GPL license and hight quality level
- all plug-in with a GPL license, in development process
- all plug-in coming from a company or community with a associated license
- ...


> 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.
of course, I agree, but only if maturity, support type (large community,
commercial, ...) license constrain is readable.

> 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 21/03/2012 17:40, Jacopo Cappellato a écrit :
> 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)
no
> * 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
ok
> * 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
I have started a dedicated thread about it 3 days ago (OFBiz Plugin
Management, status and propositions) ;-)

a plug-in repository is a directory, so it's possible to add it in svn
repository in the same level that ofbiz, (if it's authorized by Apache
rules)

IMO it's important to say to the community that, for example projectmgr
is still in the Apache-OFBiz project even if it's necessary to do
something after downloading ofbiz to install more "things"
> Jacopo

[Olivier.heintz]

discussion on  "OFBiz Plugin Management, status and propositions" should
be on the corresponding thread

Le 20/03/2012 16:59, Mansour Al Akeel a écrit :

> Ant+Ivy would fit easier with the structure of ofbiz components.
> If we want to move to maven, then a modification to
> org/ofbiz/base/location/FlexibleLocation.java has to be
> done to allow loading resource from a jar file. I am assuming with
> maven, you want to package the whole component in
> a jar file. I think this is good idea, and it will have to done for OSGI anyway.
> But for the moment, I think Ant+Ivy are more suitable.
>
>
>
>
> On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux
> <[hidden email]>  wrote:
>> From: "Nicolas Malin"<[hidden email]>
>>
>>> 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.
>>
>> Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I
>> know the historical ;o)?
>> I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven
>> during a Geronimo developement
>>
>>
>>> [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]
>>
>> Yes, I do the same, and certainly others as well...
>>
>> Jacques
>>
>>
>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : [phone]
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : [phone]
>>> Site : http://www.librenberry.net/
>>>

[Olivier.heintz]

Le 20/03/2012 23:44, Jacques Le Roux a écrit :

> From: "Mansour Al Akeel" <[hidden email]>
>> Everyone has different preference about how would the basic component
>> skeleton looks like (ie, with ajax, without, exta functionality ....
>> ).
>> Even if a basic example included with ofbiz distribution, in the
>> future it will grow again with extra unneeded functionality, or it
>> will be an on going discussion about what should go there.
>>
>> It's much easier to provide a very basic skeleton as a separate
>> download, to serve as an example and a reference. There could be more
>> than one example provided, each showing different capabilities and
>> different techniques. This is better than creating one huge example to
>> show everything, and better than showing only the basics without any
>> additional tips (ie, ajax).

+1 for additional download for a example (or exempleext) showing all the
current development best practice. This component could be update by a
other plug-in which install a extra functionality to showing how to use it.

>>
>> Those who are not satisfied with the examples as a skeleton, can
>> maintain their own copy that will make him/her start a component
>> quickly.
>>
>> Examples are not needed to run ofbiz.
>
> So they (examples and examplesext) could be in specialpurpose (+1) of
> even Extras (0)
>
> Jacques
>
>>
>> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
>> <[hidden email]> wrote:
>>> 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
>>>>
>>>>
>>> create 2 components, one basic with simple CRUD and no ajax or
>>> whatever, and
>>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>>> components should be in specialpurpose/
>>> I'm not in favor of moving them to extras, as when delivering an
>>> official
>>> release there should be a showcase included. And as Adrian said, when
>>> teaching people how to create apps with OFBiz, this could be really
>>> useful.
>>> And with JSR-223, there's a lot to add !
>>>
>>> --
>>> Erwan de FERRIERES
>>> www.nereide.biz
>>
>

[Olivier.heintz]

Le 21/03/2012 15:03, Hans Bakker a écrit :
> 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.....
>
imo it's a good cms ofbiz capability demonstration, so +1 for extras :-)

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

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

Then we have fo.ftl files and PDF rendering. Minimalistic but working.

Jacques

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

[Jacques Le Roux]

From: "Olivier Heintz" <[hidden email]>

> 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

What are exactly Apache-OFbiz-SubProject  and Apache-OFBiz official plug-in in your mind?
specialpurpose components?

Jacques

>>
>> Jacques
>

[Jacques Le Roux]

Hi Anil,

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

I "fear" it will get less exposition and consequently less audience.

Jacques

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

[Jacques Le Roux]

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

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

It's not XUL but XUI (which is a dead project, replaced by Aria which now "smells"* almost as much)
http://xui.sourceforge.net/index.html
http://www.formaria.org/
This does not prevent the POS to work well...

Jacques
PS: *"smells" like Frank Zappa said about Jazz: "Jazz isn't dead. It just smells funny."
http://www.goodreads.com/quotes/show/3092
Jazz has much evolved since...Not Aria...

> 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 21/03/2012 19:02, Jacques Le Roux a écrit :

> From: "Olivier Heintz" <[hidden email]>
>> 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
>
> What are exactly Apache-OFbiz-SubProject  and Apache-OFBiz official
> plug-in in your mind?
> specialpurpose components?

not, maybe a directory a the same level as ofbiz in the svn repository,
and plug-in manager will be able to download it to hot-deploy (or
specialpurpose) and maybe update some file which is needed (ex: add some
target in ofbiz build.xml)
goals is
- easy install process
- svn repository and comitters are from Apache-OFBiz
>
> Jacques
>
>>>
>>> Jacques
>>
>

[Mansour]

Thank you Jacques. XUL is the mozilla UI thing.
I didn't use any of the framework mentioned her :)


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

> From: "Mansour Al Akeel" <[hidden email]>
>>
>> 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?
>
>
> It's not XUL but XUI (which is a dead project, replaced by Aria which now
> "smells"* almost as much)
> http://xui.sourceforge.net/index.html
> http://www.formaria.org/
> This does not prevent the POS to work well...
>
> Jacques
> PS: *"smells" like Frank Zappa said about Jazz: "Jazz isn't dead. It just
> smells funny."
> http://www.goodreads.com/quotes/show/3092
> Jazz has much evolved since...Not Aria...
>
>
>> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

[Jacques Le Roux]

From: "Olivier Heintz" <[hidden email]>

> Le 21/03/2012 19:02, Jacques Le Roux a écrit :
>> From: "Olivier Heintz" <[hidden email]>
>>> 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
>>
>> What are exactly Apache-OFbiz-SubProject  and Apache-OFBiz official plug-in in your mind?
>> specialpurpose components?
> not, maybe a directory a the same level as ofbiz in the svn repository, and plug-in manager will be able to download it to
> hot-deploy (or specialpurpose) and maybe update some file which is needed (ex: add some target in ofbiz build.xml)
> goals is
> - easy install process
> - svn repository and comitters are from Apache-OFBiz

I see , sounds like something possbile as long the license is respected. The level would be the same than trunk of branches
ie under https://svn.apache.org/repos/asf/ofbiz and could be /plugin

To be discussed futher by the community, versionning comes OOTB, but being in sync with releases and trunk would be another beast. I
guess you have your tools for that, license?

Jacques

>>
>> Jacques
>>
>>>>
>>>> Jacques
>>>
>>
>

[Anne Jessel]

+1 for Birt to extras.

Most of the useful reports OOTB are currently fo.

+1 to JasperReports in extras. I'm happy to volunteer for that one.

Cheers,
Anne.

On 22 March 2012 04:59, Jacques Le Roux <[hidden email]>wrote:

> From: "Olivier Heintz" <[hidden email]>
>
>  Le 20/03/2012 15:31, adrian.crum@sandglass-**software.com<[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.
>>
>
> Then we have fo.ftl files and PDF rendering. Minimalistic but working.
>
> Jacques
>
>
>
>>> -Adrian
>>>
>>> Quoting Jacopo Cappellato <jacopo.cappellato@**hotwaxmedia.com<[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
>>>>
>>>
>>>
>>>
>>>
>>>
>>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[hans_bakker]

Jacopo,

you are making here a very negative review of the Birt integration....as
any component sure there is room for improvement however....

Some positives you did not even notice?

1. can use minilanguage for the retrieval
2. can use ofbiz fieldnames and entity names. (not databasenames)
3. can use OFBiz views.....
4. can fully integrate in the ERP application.
5. has many inbuilt output formats.
6. Incorporates the warehouse entities.

Created/extended the datawarehouse which is essential for ordereporting.
We have very big customers where using order reports directly on the
OFBiz database was not possible.

This warehouse function is essential for large customers

I very strongly think about keeping this in the framework.

BI component I agree, can go....

Regards,
Hans


On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:

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

[Anne Jessel]

If we can agree on exactly what specialpurpose will be for in future, we
might find it easy to decide what to move.

My original thought was that specialpurpose is for the "extras" that most
people won't want. But in future Apache Extras will be doing that. So
should we remove specialpurpose totally? Everything in it goes either to
Extras or to Applications?

I have not decided whether I like that idea. Only thing I am sure of is
that ecommerce should stay somewhere in core, but it looks like everyone
else agrees on that.

Cheers,
Anne.

On 22 March 2012 07:06, Mansour Al Akeel <[hidden email]> wrote:

> Thank you Jacques. XUL is the mozilla UI thing.
> I didn't use any of the framework mentioned her :)
>
>
> On Wed, Mar 21, 2012 at 2:24 PM, Jacques Le Roux
> <[hidden email]> wrote:
> > From: "Mansour Al Akeel" <[hidden email]>
> >>
> >> 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?
> >
> >
> > It's not XUL but XUI (which is a dead project, replaced by Aria which now
> > "smells"* almost as much)
> > http://xui.sourceforge.net/index.html
> > http://www.formaria.org/
> > This does not prevent the POS to work well...
> >
> > Jacques
> > PS: *"smells" like Frank Zappa said about Jazz: "Jazz isn't dead. It just
> > smells funny."
> > http://www.goodreads.com/quotes/show/3092
> > Jazz has much evolved since...Not Aria...
> >
> >
> >> 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.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
> >
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Anne Jessel]

Just wanted to mention an idea I had: add a new group "Examples" alongside
applications and specialpurpose and hot-deploy (maybe replacing
specialpurpose?).

It should be easy to enable/disable the entire group in one go. So new
developers have it easily available, it is easy to enable for demos, and
easy to disable for production.

It could have multiple components, rather than just example and exampleext.
Each component could showcase best practice for a particular function. For
example, there could be one component for Ajax widgets, and one for
Jackrabbit, and so on. I think individual example components would be
easier to maintain than one or two large ones.

Projects in Extras could include a sample component that gets installed in
Examples, showing example code using that Extra.

Having support for Extras examples in core might encourage Extras
developers to provide good sample code.

Cheers,
Anne.

On 22 March 2012 04:36, Olivier Heintz <[hidden email]> wrote:

> Le 20/03/2012 23:44, Jacques Le Roux a écrit :
>
>  From: "Mansour Al Akeel" <[hidden email]>
>>
>>> Everyone has different preference about how would the basic component
>>> skeleton looks like (ie, with ajax, without, exta functionality ....
>>> ).
>>> Even if a basic example included with ofbiz distribution, in the
>>> future it will grow again with extra unneeded functionality, or it
>>> will be an on going discussion about what should go there.
>>>
>>> It's much easier to provide a very basic skeleton as a separate
>>> download, to serve as an example and a reference. There could be more
>>> than one example provided, each showing different capabilities and
>>> different techniques. This is better than creating one huge example to
>>> show everything, and better than showing only the basics without any
>>> additional tips (ie, ajax).
>>>
>> +1 for additional download for a example (or exempleext) showing all the
> current development best practice. This component could be update by a
> other plug-in which install a extra functionality to showing how to use it.
>
>
>>> Those who are not satisfied with the examples as a skeleton, can
>>> maintain their own copy that will make him/her start a component
>>> quickly.
>>>
>>> Examples are not needed to run ofbiz.
>>>
>>
>> So they (examples and examplesext) could be in specialpurpose (+1) of
>> even Extras (0)
>>
>> Jacques
>>
>>
>>> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
>>> <[hidden email]**> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>>  create 2 components, one basic with simple CRUD and no ajax or
>>>> whatever, and
>>>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>>>> components should be in specialpurpose/
>>>> I'm not in favor of moving them to extras, as when delivering an
>>>> official
>>>> release there should be a showcase included. And as Adrian said, when
>>>> teaching people how to create apps with OFBiz, this could be really
>>>> useful.
>>>> And with JSR-223, there's a lot to add !
>>>>
>>>> --
>>>> Erwan de FERRIERES
>>>> www.nereide.biz
>>>>
>>>
>>>
>>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Anne Jessel]

I thought Birt was a report generation/layout tool, like JasperReports and
many others. I don't understand why it would have anything to do with
datawarehousing.

I agree with Hans that datawarehousing is important. But I think that
should be part of BI, or other (possibly framework) functionality not tied
to presentation.

With the single exception of point 5, aren't the listed positives all
related to non-Birt functionality? Birt just manages the presentation? And
point 5 could be handled by competitors to Birt?

Cheers,
Anne.

On 22 March 2012 12:38, Hans Bakker <[hidden email]> wrote:

> Jacopo,
>
> you are making here a very negative review of the Birt integration....as
> any component sure there is room for improvement however....
>
> Some positives you did not even notice?
>
> 1. can use minilanguage for the retrieval
> 2. can use ofbiz fieldnames and entity names. (not databasenames)
> 3. can use OFBiz views.....
> 4. can fully integrate in the ERP application.
> 5. has many inbuilt output formats.
> 6. Incorporates the warehouse entities.
>
> Created/extended the datawarehouse which is essential for ordereporting.
> We have very big customers where using order reports directly on the OFBiz
> database was not possible.
>
> This warehouse function is essential for large customers
>
> I very strongly think about keeping this in the framework.
>
> BI component I agree, can go....
>
> Regards,
> Hans
>
>
>
> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>
>> 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
>>
>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[hans_bakker]

Hi Anne,

Birt has several advantages in the current integration and we use it
often on the warehouse entities. These entities are mostly not in the BI
component but in the application components.

Jasper reports and all others do not use the ofbiz framework but work on
the JDBC driver directly or even worse only work on mysql or are mostly
commercial.

Integration with Birt is using the ofbiz framework and works on any data
base that ofbiz runs on.

Regards,
Hans


With BI i mean the BI screens/forms, not the entities.

On 03/22/2012 09:47 AM, Anne wrote:

> I thought Birt was a report generation/layout tool, like JasperReports and
> many others. I don't understand why it would have anything to do with
> datawarehousing.
>
> I agree with Hans that datawarehousing is important. But I think that
> should be part of BI, or other (possibly framework) functionality not tied
> to presentation.
>
> With the single exception of point 5, aren't the listed positives all
> related to non-Birt functionality? Birt just manages the presentation? And
> point 5 could be handled by competitors to Birt?
>
> Cheers,
> Anne.
>
> On 22 March 2012 12:38, Hans Bakker<[hidden email]>  wrote:
>
>> Jacopo,
>>
>> you are making here a very negative review of the Birt integration....as
>> any component sure there is room for improvement however....
>>
>> Some positives you did not even notice?
>>
>> 1. can use minilanguage for the retrieval
>> 2. can use ofbiz fieldnames and entity names. (not databasenames)
>> 3. can use OFBiz views.....
>> 4. can fully integrate in the ERP application.
>> 5. has many inbuilt output formats.
>> 6. Incorporates the warehouse entities.
>>
>> Created/extended the datawarehouse which is essential for ordereporting.
>> We have very big customers where using order reports directly on the OFBiz
>> database was not possible.
>>
>> This warehouse function is essential for large customers
>>
>> I very strongly think about keeping this in the framework.
>>
>> BI component I agree, can go....
>>
>> Regards,
>> Hans
>>
>>
>>
>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>
>>> L) framework/birt (and related dependencies/reports spread around): move
>>>> to "Extras"
>>>>
>>>> M) framework/bi (and related dependencies - ecas/business rules and data
>>>> - spread around): move to "Extras"
>>>>
>>>>   This is an area where Hans and I are in disagreement and we didn't get
>>> much feedback from others.
>>>
>>> So I would like to explain here why I think we should move the Birt
>>> component and the Birt reports out of the framework and consider them as
>>> optional tools.
>>>
>>> There are currently 18 reports in the applications implemented with Birt;
>>> but they really seem experiments rather than something really usable; to
>>> give you some examples:
>>>
>>> * in most of them there is this code like this:
>>>
>>> userLogin = null;
>>> try {
>>>      userLogin = delegator.findByPrimaryKey("**UserLogin",UtilMisc.toMap("
>>> **userLoginId","admin"));
>>> } catch(e) {
>>>          Debug.logError(e,"");
>>> }
>>>
>>> * all the retrieval logic (scripts) is inlined with layout definition and
>>> this is something we try to avoid in all the existing screens
>>> * entity list iterators are not properly closed
>>> * some of the widget based financial reports have been converted to Birt:
>>> their layout is still very simple and comparable to the widget based
>>> versions available before Birt; so the conversion to Birt added a
>>> dependencies on this component without adding real value (the rptdesign
>>> files mix together data preparation scripts and ui definitions and in order
>>> to maintain them you have to use the Birt designer); also some of them are
>>> now broken: Income Stetements, Balance Sheet etc... This is probably caused
>>> by the recent refactoring of JSR-223 but the original widget based PDF are
>>> still there and are working fine...
>>> * building a report with this Birt integration still requires a lot of
>>> development work (similar to the one required to create a screen); but then
>>> the code in the rptdesign is very difficult to maintain without the editor
>>>
>>> My questions are:
>>> * do you really think that this way of integrating rptdesign reports is
>>> the answer to fill the gap of a good reporting tool in OFBiz? Are you
>>> actually using this integration for your reports?
>>> * do we all agree to make this Birt integration the best practice
>>> mechanism for all OFBiz reports?
>>> * do you really think that we should replace all the existing widget
>>> generated reports and FOP reports with rptdesign reports built using the
>>> existing Birt integration under the framework?
>>>
>>> If any of your answers will be "no" then in my opinion it would be much
>>> better to:
>>> 1) make Birt integration an optional component, downloaded separately
>>> 2) move the existing rptdesign reports out of the applications and keep
>>> them in the external Birt component
>>> 3) at this point users will have the option to use the Birt component or
>>> not, but the ootb code will be clean and without dependencies on it; most
>>> of all, we will not deliver reports that looks similar (ugly) but they are
>>> implemented randomly with Birt or Widgets
>>> 4) start evaluating, as a community, what should be the best practices
>>> for ootb reports: what is the tool we want, what are the minimal
>>> requirements etc... and then work together to get it in place and then
>>> migrate all existing reports to it in order to have a consistent system; if
>>> the community will not be able to reach a consensus on this, then we should
>>> leave the decision about the reporting tool to use to the end user
>>>
>>> I think that the Birt integration is a nice optional component, and I see
>>> that there may be interested parties, but in its current status it is not
>>> something ready for becoming the primary reporting tool for the ootb
>>> applications.
>>>
>>> Jacopo
>>>
>>
>

[Jacopo Cappellato-4]

On Mar 21, 2012, at 8:20 PM, Olivier Heintz wrote:

> not, maybe a directory a the same level as ofbiz in the svn repository, and plug-in manager will be able to download it to hot-deploy (or specialpurpose) and maybe update some file which is needed (ex: add some target in ofbiz build.xml)
> goals is
> - easy install process
> - svn repository and comitters are from Apache-OFBiz

I find a bit confusing all this push for adding your "plug-in" architecture to OFBiz and to implement your plan to migrate screens to screenlet: I understand the enthusiasm and that these 2 tasks are a priority for you and your group, but please understand that this doesn't mean that it must be a priority for the OFBiz community as well.
You can propose this (as you did) but please do not flood every thread with these ideas.
In particular in the "Lose Weight Program" emails we are simply discussing to move or not some of the components to Extras/Attic: let's stay focused on this.

Jacopo

[Malin Nicolas]

Le 22/03/2012 04:47, Hans Bakker a écrit :
> Hi Anne,
>
> Birt has several advantages in the current integration and we use it
> often on the warehouse entities. These entities are mostly not in the
> BI component but in the application components.
>
> Jasper reports and all others do not use the ofbiz framework but work
> on the JDBC driver directly or even worse only work on mysql or are
> mostly commercial.
Just to correct this, Birt is integrate currently in OFBiz (and tks a
lot for the work :) ), but jasper to if you load the interface. By
default you can use JDBC driver with these tools, put all have an api to
integrate it. Last time we work on integration with open office, it's
just a data preparation by the technical interface. If Birt move on
extra, a goal will be the simplify integration between service engine
and report layer.

Nicolas

>
> Integration with Birt is using the ofbiz framework and works on any
> data base that ofbiz runs on.
>
> Regards,
> Hans
>
>
> With BI i mean the BI screens/forms, not the entities.
>
> On 03/22/2012 09:47 AM, Anne wrote:
>> I thought Birt was a report generation/layout tool, like
>> JasperReports and
>> many others. I don't understand why it would have anything to do with
>> datawarehousing.
>>
>> I agree with Hans that datawarehousing is important. But I think that
>> should be part of BI, or other (possibly framework) functionality not
>> tied
>> to presentation.
>>
>> With the single exception of point 5, aren't the listed positives all
>> related to non-Birt functionality? Birt just manages the
>> presentation? And
>> point 5 could be handled by competitors to Birt?
>>
>> Cheers,
>> Anne.
>>
>> On 22 March 2012 12:38, Hans Bakker<[hidden email]>  
>> wrote:
>>
>>> Jacopo,
>>>
>>> you are making here a very negative review of the Birt
>>> integration....as
>>> any component sure there is room for improvement however....
>>>
>>> Some positives you did not even notice?
>>>
>>> 1. can use minilanguage for the retrieval
>>> 2. can use ofbiz fieldnames and entity names. (not databasenames)
>>> 3. can use OFBiz views.....
>>> 4. can fully integrate in the ERP application.
>>> 5. has many inbuilt output formats.
>>> 6. Incorporates the warehouse entities.
>>>
>>> Created/extended the datawarehouse which is essential for
>>> ordereporting.
>>> We have very big customers where using order reports directly on the
>>> OFBiz
>>> database was not possible.
>>>
>>> This warehouse function is essential for large customers
>>>
>>> I very strongly think about keeping this in the framework.
>>>
>>> BI component I agree, can go....
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>>
>>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>
>>>> 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
>>>>
>>>
>>
>

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