Re: Lose Weight Program for OFBiz - themes
Comments inline: On Mar 20, 2012, at 5:18 PM, Jacopo Cappellato wrote: I) $OFBIZ_HOME/themes/*: move a few of them to Attic and a few of them to Extras; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. I agree to add other themes in Extras. More because its goes with the idea of using a resource as plugin and putting them in extras. Thanks -- Divesh Jacopo
Re: Lose Weight Program for OFBiz - Birt and BI
+1 for Adrian.
IT departments use specific tools. And they would like to integrate those tools
with OFBiz. So any reporting tool should go in Extras and End User should
download them as per their need. We just need good documentation around all
these efforts to help end users.
Thanks
--
Divesh
On Mar 20, 2012, at 8:01 PM, adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz, instead
of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - guiapp and pos
I second with Scott. I would like to see E-commerce component in Special Purpose because that is the most commonly used component and its code should be well managed. Lots of people see E-commerce as reference application made on top of OFBiz. So having Ecommerce's code managed by Committers is good idea. +1 for moving POS in Extras. Thanks -- Divesh On Mar 21, 2012, at 12:59 AM, Scott Gray wrote: I'm in favor of moving all special purpose apps to Extras (or Attic for some of the older/unused ones) except for ecommerce. Even then the only reason I'd like to keep ecommerce is because it is the only special purpose app that is almost universally useful to OFBiz users and I'd like to keep it under our control for now at least. So I'd like to see pos moved to Extras and perhaps these users of it can step up and help maintain it. Regards Scott On 21/03/2012, at 4:21 AM, Jacopo Cappellato wrote: Makes sense Jacopo On Mar 20, 2012, at 3:58 PM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components? Yes, I know there are POS users out there. So I now wonder if we should not wait before moving it out of specialpurpose. When you think about it, it's the twin of eCommerce. With a bit more involvment though, mostly because of its relation with Entity Sync (maintenance) which is actually part of the framework (entityext component). Jacques
Re: Lose Weight Program for OFBiz - example, exampleext
My +1 for moving them to Extras. Reason is, if we need to keep it for best practice guide or for training then no doubt its a extra work. We can give good documentation with details about how to use /extras/example component to learn and keep it as best practice guide. Also we can promote this in user mailing lists . Thanks -- Divesh On Mar 21, 2012, at 4:14 AM, Jacques Le Roux wrote: From: Mansour Al Akeel mansour.alak...@gmail.com 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). 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 erwan.de-ferrie...@nereide.fr 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
Re: Lose Weight Program for OFBiz - Birt and BI
We could include a metadata interface that external reporting tools to
can use to generate reports.
-Adrian
On 4/3/2012 10:27 AM, Divesh Dutta wrote:
+1 for Adrian.
IT departments use specific tools. And they would like to integrate those tools
with OFBiz. So any reporting tool should go in Extras and End User should
download them as per their need. We just need good documentation around all
these efforts to help end users.
Thanks
--
Divesh
On Mar 20, 2012, at 8:01 PM, adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz, instead
of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
Which is one of reasons to have mostly unused things (not only BIRT) out of OFBiz. BTW from this POV the POS is not a problem, since it's not a webapp, it runs only at demand... Jacques Anne wrote: Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
I think BIRT should be moved to Extras. The main reasons being: - we're still not (IMO) giving enough power to the users themselves to create reports - not every company wants to use BIRT and nor should they have to - the engine is large, the integration is lightweight and last time I looked the API was pretty poorly documented IMO the best thing we could do for reporting in OFBiz is to provide some type of HTTP based data provider interface. Virtually every reporting tool can consume CSV or XML formatted data from web resources and it would allow user's to cut up the data any way they liked via their reporting tool of choice (even something like Excel could be used). We could consider creating some new entities and a UI for controlling what data can be published and to who, possibly even creating a UI that allows dynamic view entities to be constructed and published. Even this idea is possible to deploy as a hot-deploy component so doesn't necessarily need to exist in the framework but it's certainly a much more generic and accessible approach than what we have with BIRT (which it should be noted wasn't chosen for it's features but rather because it was the only one with a permissive license for inclusion). Regards Scott On 26/03/2012, at 8:25 PM, Jacques Le Roux wrote: Which is one of reasons to have mostly unused things (not only BIRT) out of OFBiz. BTW from this POV the POS is not a problem, since it's not a webapp, it runs only at demand... Jacques Anne wrote: Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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.
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 21/03/2012 21:56, Jacques Le Roux a écrit : From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 19:02, Jacques Le Roux a écrit : From: Olivier Heintz holivier.lis...@nereide.biz Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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? Apache 2.0 of course (as it's explain in the mail OFBiz Plugin Management, status and propositions ;-) Jacques Jacques Jacques
Re: Lose Weight Program for OFBiz - Birt and BI
Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Thank you Anne. Perfect. I think options like this can be made visible through some documentation. At least inside the code through comments. I know it's there for BIRT. On Sun, Mar 25, 2012 at 8:09 PM, Anne a...@cohsoft.com.au wrote: Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml: !-- load the BIRT container -- base/config/ofbiz-containers.xml: container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive
Re: Lose Weight Program for OFBiz - Birt and BI
in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
+1 to what Anne said, even I used to think that special-purpose is all the extra stuff accept e-commerce which I wondered why it lies there, pretty much everything is captured in applications if we consider a complete ERP accept assetmaint and and projectmgr, these two should also have been a part of applications, and if not atleast assetmaint, as any organization has assets and its accounted. Projectmgr could stay in special-purpose. Regards Prince From: Anne a...@cohsoft.com.au To: dev@ofbiz.apache.org Sent: Thursday, March 22, 2012 7:16 AM Subject: Re: Lose Weight Program for OFBiz - what should go to specialpurpose 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: From: Mansour Al Akeel mansour.alak...@gmail.com 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 anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Well pretty much all that we think is an additional integration to the core concept of the application, like LDAP,Shark, Workfolw, crowd, all that that is already there seems pretty much thoughtful already. Regards Prince From: Mansour Al Akeel mansour.alak...@gmail.com To: dev@ofbiz.apache.org Sent: Thursday, March 22, 2012 1:36 AM Subject: Re: Lose Weight Program for OFBiz - what should go to specialpurpose 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 jacques.le.r...@les7arts.com wrote: From: Mansour Al Akeel mansour.alak...@gmail.com 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 anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012
Re: Lose Weight Program for OFBiz - guiapp and pos
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
Re: Lose Weight Program for OFBiz - Birt and BI
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 Bakkermailingl...@antwebsystems.com
wrote:
Jacopo,
you are making here a very negative review of the Birt
integrationas
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
Re: Lose Weight Program for OFBiz JCR function
I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) That is the master plan. IMHO there is no reason to build a JCR plugin for Ofbiz, i don't see any real benefit of it. 2012/3/22 Anne a...@cohsoft.com.au: Keep in framework +1 Remove from upcoming release +1 Part of core eventually +1 I think it is (should be) central to content handling, and OFBiz core needs to handle content. Therefore it should be in core. Cheers, Anne. On 22 March 2012 05:04, Jacques Le Roux jacques.le.r...@les7arts.comwrote: From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) Jacques If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.**com jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design
Re: Lose Weight Program for OFBiz - guiapp and pos
enthusiasm is the word :) . The Lose Weight Program is a great lead for future, I understand that some people (and some customer) are afraid by this change. So we would tend to rise over the benefits of an organization whereby we have been working on for some years with Apache OFBiz and justifypassage of several component extras. Thanks for the reminding Jacopo to stop the flood and refocus threads. I looked forward to opening the thread, how to manage migration and how to manage extrascomponents from Apache OFBiz. Nicolas Le 22/03/2012 06:59, Jacopo Cappellato a écrit : 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 -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz JCR function
+1 Thanks Anne, easier when neat :o) Jacques Anne wrote: Keep in framework +1 Remove from upcoming release +1 Part of core eventually +1 I think it is (should be) central to content handling, and OFBiz core needs to handle content. Therefore it should be in core. Cheers, Anne. On 22 March 2012 05:04, Jacques Le Roux jacques.le.r...@les7arts.comwrote: From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) Jacques If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.**com jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz - Birt and BI
From your remarks it seems then that it introduces dependencies from applications.
This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.
warehouse entities and reports on them belong to the applications, not
to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
From your remarks it seems then that it introduces dependencies from
applications. This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
I mean the framework should know nothing about applications
6. Incorporates the warehouse entities.
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.
warehouse entities and reports on them belong to the applications, not
to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
From your remarks it seems then that it introduces dependencies from
applications. This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
sure...but then i do not understand your comment...where do i indicate
there is a dependency from the framework on an application? Warehouse
entities are stored in the application?
On 03/22/2012 06:14 PM, Jacques Le Roux wrote:
I mean the framework should know nothing about applications
6. Incorporates the warehouse entities.
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.
warehouse entities and reports on them belong to the applications,
not to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
From your remarks it seems then that it introduces dependencies from
applications. This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt
integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
On Mar 22, 2012, at 12:43 PM, Erwan de FERRIERES wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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. Please note that all the above points are covered also by screens/FOP; and the code in screens/FOP is cleaner and implements the MVC pattern as all the other screens. You didn't mention the only one reason that really makes meaningful to consider this Birt integration: after you have manually implemented (in the traditional way) controller entries, screens to run the reports and the data preparation code (that needs to be inlined in the Birt report definition) you can use the Birt designer to implement the ui. This is in my opinion a nice to have for an optional component but not enough to make it the default reporting engine for OFBiz. 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 These ones are not part of the Birt integration but are instead part of the BI framework that I originally designed (and you have expanded): in fact I still see a big potential for this tool, that it is for its nature optional and external to OFBiz (ideally it should run in a separate db) and I really hope to see it more exposed tomore contributors in the future if delivered as an optional application. I very strongly think about keeping this in the framework. BI component I agree, can go Regards, Hans I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? In its current status I don't see how this could happen; it was not a good move that some of the ootb reports have been converted to Birt because now we have another technology for reporting that it is not enough to become the primary tool; the reports generated using this tool in its current form are simply not good enough to stay; if we will ever want to deliver with the framework an official tool for reporting then its requirements/features should be carefully evaluated before taking a decision Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? I don't think that adding more Birt reports to OFBiz to make the OFBiz applications more dependent on this imperfect Birt integration would be the right way to go. Instead we should rather gather all the requirements, design/select the proper tool (Birt of what else) and then integrate it properly and finally convert all the application reports to it. But even if we will reach that point I would see some potential to treat it as an optional/separated tool (but this can be discussed). In summary my opinion is: for now *this* Birt integration should go to Extras and improved there; interested users will get it from there (together with the reports); if the community thinks we should have a default reporting tool packaged in OFBiz then we will start the architectural/requirement design phase (at that point we could even bring back again some of the existing Birt code, if we think it is the right way to go). Jacopo -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
+1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - themes
Hi Mansour, From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think most users use flat gray to base their work ? Could you define easier and cleaner, and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add title=Skip navigation accesskey=2 (which is really only a small/poor beginnng) but that's for all themes. What is specific to Flat Grey? The only things I could concede: 1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about contrast is maybe biased 2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long term (hours of work) Thanks for sharing your opinion :o) Jacques On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns (applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it Another point: Product screens are awful in Flat Grey (to many buttons for menus, hard to spot). Though actually I believe Tomahawk would benefit from a third column, for instance for Product. This could be 2 twin columns if more than, say, 15 entries would show in a column. Like we have for Applications, though not sure how it's organized. I mean why some are in right column and other in left one? Also something wich could help spot entries quicker would be to allow sorting entries in menus by language. It's now only done based on English. OK, now there is the RTL feature. Who use it? Few I guess (http://en.wikipedia.org/wiki/Right-to-left http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not diminish RTL importance, but ponders it in choice for a default theme. My 2 cts Jacques From: Ashish Vijaywargiya vijaywargiya.ash...@gmail.com My vote will be to keep two themes in the project. IMO Flatgrey theme is the best to keep as the default one for the project. -- Ashish On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: I) $OFBIZ_HOME/themes/*: move a few of them to Attic and a few of them to Extras; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Lose Weight Program for OFBiz
Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...) DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with
Re: Lose Weight Program for OFBiz
Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the
Re: Lose Weight Program for OFBiz
Thanks Jacopo for your quick response. It clears my doubt. Regards Vikas On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you
Re: Lose Weight Program for OFBiz
Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too? Thanks Sam On 21 Mar 2012, at 16:23, Vikas Mayur wrote: Thanks Jacopo for your quick response. It clears my doubt. Regards Vikas On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its
Re: Lose Weight Program for OFBiz
We will setup a page in the OFBiz website, for sure. The final decision on the projects that will appear there will be done by the OFBiz PMC but I guess that initially it will only contain projects in Apache Extras; there may be exceptions to to this rule, I guess. Jacopo On Mar 21, 2012, at 11:05 AM, Sam Hamilton wrote: Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too? Thanks Sam On 21 Mar 2012, at 16:23, Vikas Mayur wrote: Thanks Jacopo for your quick response. It clears my doubt. Regards Vikas On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain
Re: Lose Weight Program for OFBiz - themes
I prefer to keep the Flat Grey and one other. Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: I) $OFBIZ_HOME/themes/*: move a few of them to Attic and a few of them to Extras; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Lose Weight Program for OFBiz - example, exampleext
+1 on removal from core (framework), as it doesn't add any value in a framework. However, having it available as a separate downloadable application (to be used from hot-deploy or special purpose) would be beneficiary for newcomers in the development scene. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Q) framework/example and framework/exampleext: move to specialpurpose Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the example application should document the layout of a typical OFBiz component only? If yes, we could use the output of the ant create-component task to document the best practice layout. Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications. I think that from the discussion it could emerge the following solution to please everyone: * keep the example component in the framework but slim it down to the bare essential * move the exampleext component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose I still think that it would be nicer to not bundle the example component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this. Jacopo
Re: Lose Weight Program for OFBiz - ofbizwebsite
+1 Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz JCR function
Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished Re 3: draft up requirements for content framework replacement +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz - ofbizwebsite
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
Re: Lose Weight Program for OFBiz - guiapp and pos
A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
On all: +1 Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: C) $OFBIZ_HOME/debian: move to Attic D) the seleniumxml code in framework/testtools: move to Attic E) specialpurpose/workflow: move to Attic F) specialpurpose/shark: move to Attic J) framework/appserver: move to Extras K) framework/jetty: move to Extras (or Attic) The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian). I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic. Any ideas? volunteers (OFBiz committers or not)? No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community). Jacopo
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
+ 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - documents
+1. This is an example of bloat. Keeping ill-maintained static documents in OFBiz (the suite) that are also available through the OFBiz website is not adding value. Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: O) framework/documents: move the content to Wiki and then move to Attic The broader topic is to move all the artifacts related to online help out of the framework; they should all live under applications.
Re: Lose Weight Program for OFBiz - documents
The idea behind this that documents in wiki are not according the version..(only the latest) This directory has it for the related version AND can be in different languages and formats: html, pdf do judge before you understand.. Regards, Hans On 03/21/2012 06:01 PM, Pierre Smits wrote: +1. This is an example of bloat. Keeping ill-maintained static documents in OFBiz (the suite) that are also available through the OFBiz website is not adding value. Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: O) framework/documents: move the content to Wiki and then move to Attic The broader topic is to move all the artifacts related to online help out of the framework; they should all live under applications.
Re: Lose Weight Program for OFBiz - Birt and BI
Currently, rptdesign is used in specialpurpose applications like ebaystore
and scrum, but also in core applications (accounting, order and product).
We have to provide reports in our applications, as it would be difficult to
maintain the concept of completeness of functionality without them.
Endusers requirements always dictate some kind of reports in applications.
I prefer to have a working solution ootb in OFBiz. Birt delivers that at
the moment.
Removing it creates another proposition issue (on top of all the others we
can think of why OFBiz is hard to sell).
Replacing it by something else would dictate roadmapping.
Regards,
Pierre
Op 20 maart 2012 12:47 schreef Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com het volgende:
L) framework/birt (and related dependencies/reports spread around): move
to Extras
M) framework/bi (and related dependencies - ecas/business rules and data
- spread around): move to Extras
This is an area where Hans and I are in disagreement and we didn't get
much feedback from others.
So I would like to explain here why I think we should move the Birt
component and the Birt reports out of the framework and consider them as
optional tools.
There are currently 18 reports in the applications implemented with Birt;
but they really seem experiments rather than something really usable; to
give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin =
delegator.findByPrimaryKey(UserLogin,UtilMisc.toMap(userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition and
this is something we try to avoid in all the existing screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to Birt:
their layout is still very simple and comparable to the widget based
versions available before Birt; so the conversion to Birt added a
dependencies on this component without adding real value (the rptdesign
files mix together data preparation scripts and ui definitions and in order
to maintain them you have to use the Birt designer); also some of them are
now broken: Income Stetements, Balance Sheet etc... This is probably caused
by the recent refactoring of JSR-223 but the original widget based PDF are
still there and are working fine...
* building a report with this Birt integration still requires a lot of
development work (similar to the one required to create a screen); but then
the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is
the answer to fill the gap of a good reporting tool in OFBiz? Are you
actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice
mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget
generated reports and FOP reports with rptdesign reports built using the
existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be much
better to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep
them in the external Birt component
3) at this point users will have the option to use the Birt component or
not, but the ootb code will be clean and without dependencies on it; most
of all, we will not deliver reports that looks similar (ugly) but they are
implemented randomly with Birt or Widgets
4) start evaluating, as a community, what should be the best practices for
ootb reports: what is the tool we want, what are the minimal requirements
etc... and then work together to get it in place and then migrate all
existing reports to it in order to have a consistent system; if the
community will not be able to reach a consensus on this, then we should
leave the decision about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I see
that there may be interested parties, but in its current status it is not
something ready for becoming the primary reporting tool for the ootb
applications.
Jacopo
Re: Lose Weight Program for OFBiz - ofbizwebsite
Infra wouldn't be happy if we host the website in that demo instance; websites potentially have a lot of visits and that server is not intended for the load; this is similar to Confluence based pages: we will no more be allowed to use direct links to them from the website. Jacopo On Mar 21, 2012, at 11:46 AM, Hans Bakker wrote: then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz - themes
Jacques, inline: On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Hi Mansour, From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. Yes, this will work. So you are offering a fancier theme for the demo purposes, targeting new comers, and developers, can make a copy of FlatGray and customize it. Sound good. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think most users use flat gray to base their work ? Sorry, I didn't express it properly. I meant most user based on my experience. I have two developers, I worked with, extend flat gray, and customize it as they need. This is not a number that can be a base for a statistical study, and generalize it. It's only my limited experience. Sorry for the confusion. Could you define easier and cleaner, and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) Cleaner and easier in terms of usage: The menu is at the top, showing all the available item, makes it easy to see what I need in case I navigated to the wrong section, or need another section. Nothing hidden. In fact even as a demo, it has some positive effect. and Cleaner and easier in terms of development: Flat Gray code is not cluttered. (that is how I feel). What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. I work more with enterprise portals than with ERPs. From what I have seen, portal severs default theme is mostly light, with darker high light. And I find FlatGray closer to them than Tomahawk theme is. For example: http://portals.apache.org/jetspeed-2/ and: http://www.liferay.com/products/liferay-portal/overview After all, It is not that hard for a developer to change the style of OFBiz themes to reflect the colors she likes. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) It's the opposite to me. I find it easier to spot things using FlatGray. But again not a big deal. Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add title=Skip navigation accesskey=2 (which is really only a small/poor beginnng) but that's for all themes. What is specific to Flat Grey? The only things I could concede: 1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about contrast is maybe biased 2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long term (hours of work) Yes. I can see this, and I agree. Thanks for sharing your opinion :o) Jacques Finally, it's a personal preference. However, I like to keep FlatGray. Doesn't have to be the default, Unless demos in RTL needed. Thank you. On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns (applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it Another point: Product screens are awful in
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - ofbizwebsite
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 mailingl...@antwebsystems.com 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
Re: Lose Weight Program for OFBiz - themes
From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, inline: On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Hi Mansour, From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. Yes, this will work. So you are offering a fancier theme for the demo purposes, targeting new comers, and developers, can make a copy of FlatGray and customize it. Sound good. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think most users use flat gray to base their work ? Sorry, I didn't express it properly. I meant most user based on my experience. I have two developers, I worked with, extend flat gray, and customize it as they need. This is not a number that can be a base for a statistical study, and generalize it. It's only my limited experience. Sorry for the confusion. Could you define easier and cleaner, and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) Cleaner and easier in terms of usage: The menu is at the top, showing all the available item, makes it easy to see what I need in case I navigated to the wrong section, or need another section. Nothing hidden. In fact even as a demo, it has some positive effect. and Cleaner and easier in terms of development: Flat Gray code is not cluttered. (that is how I feel). What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. I work more with enterprise portals than with ERPs. From what I have seen, portal severs default theme is mostly light, with darker high light. And I find FlatGray closer to them than Tomahawk theme is. For example: http://portals.apache.org/jetspeed-2/ and: http://www.liferay.com/products/liferay-portal/overview After all, It is not that hard for a developer to change the style of OFBiz themes to reflect the colors she likes. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) It's the opposite to me. I find it easier to spot things using FlatGray. But again not a big deal. Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add title=Skip navigation accesskey=2 (which is really only a small/poor beginnng) but that's for all themes. What is specific to Flat Grey? The only things I could concede: 1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about contrast is maybe biased 2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long term (hours of work) Yes. I can see this, and I agree. Thanks for sharing your opinion :o) Jacques Finally, it's a personal preference. However, I like to keep FlatGray. Doesn't have to be the default, Unless demos in RTL needed. That's an important point, and makes me need to consider indeed! I mean it's not obvious for new comers that only one theme is RTL able I think it should be default because of that, and keep Tomahawk as OOTB alternative Jacques Thank you. On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - ofbizwebsite
Jacques, sure at the time is was up-to-date and this was a proposal how we can use ofbiz for the website, however because of the strict apache rules it was not used...but can still be a template for any local ofbiz website. It remains weak: being an 'ofbiz' provider but not using it yourself. Regards, Hans On 03/21/2012 08:55 PM, Jacques Le Roux wrote: Hans, The problem is that it's completly outdated and nobody is able/want to maintain it Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc. Jacques From: Hans Bakker mailingl...@antwebsystems.com 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
Re: Lose Weight Program for OFBiz - documents
And there are parts in framework Jacques From: Hans Bakker mailingl...@antwebsystems.com The idea behind this that documents in wiki are not according the version..(only the latest) This directory has it for the related version AND can be in different languages and formats: html, pdf do judge before you understand.. Regards, Hans On 03/21/2012 06:01 PM, Pierre Smits wrote: +1. This is an example of bloat. Keeping ill-maintained static documents in OFBiz (the suite) that are also available through the OFBiz website is not adding value. Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: O) framework/documents: move the content to Wiki and then move to Attic The broader topic is to move all the artifacts related to online help out of the framework; they should all live under applications.
Re: Lose Weight Program for OFBiz - ofbizwebsite
Hans, The OFBiz project can hardly be regarded as an OFBiz Provider. Look at the list of Providers on the site. Then look at the source of their websites and have a feel for how many (besides your company) use OFBiz as a WCM. There are several solutions in the field providing for website functionality. Some of which including a richer set of functionality and better user experience. Regards, Pierre Op 21 maart 2012 15:03 schreef Hans Bakker mailingl...@antwebsystems.comhet volgende: Jacques, sure at the time is was up-to-date and this was a proposal how we can use ofbiz for the website, however because of the strict apache rules it was not used...but can still be a template for any local ofbiz website. It remains weak: being an 'ofbiz' provider but not using it yourself. Regards, Hans On 03/21/2012 08:55 PM, Jacques Le Roux wrote: Hans, The problem is that it's completly outdated and nobody is able/want to maintain it Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc. Jacques From: Hans Bakker mailingl...@antwebsystems.com** then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.**apache.org/ofbiz/http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Anil, I agree with you. Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Anil, I did not mean that putting a component under specialpurposes will make it used more by developers. I meant because it will be used more than other component, let's not move it. From Jacopo's first email about the Lose Weight : Legenda for what I propose for each piece of code: * Attic: remove from code base and document the removal for future reference in this page * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain OFBiz Extras He didn't mention anything about what type of applications should go/remain under specialpurposes. Since (I think), pos is used more than what went into Exta or Attic, I suggested keeping it where it's. The question is, will POS be maintained by ofbiz community or another party ? If it's will be separated from ofbiz, what about XUL integration code? should it remain part of the core ofbiz (framework), or moved to the component that needs it, and becomes the responsibility of the POS maintainer ? With regard to changing the License, I think it's possible on any part of Ofbiz and not only components under Extra. In all cases, users who uses POS more than I do, can give better suggestion. On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz JCR function
Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz
Le 20/03/2012 10:15, Jacopo Cappellato a écrit : Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) in the plug-in approach don't forget Apache-OFBiz sub-project for plug-in done with all it's needed in Apache approach (best practice, user help, large community, ) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
Re: Lose Weight Program for OFBiz - Birt and BI
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for
other applications and they would prefer to integrate that tool with
OFBiz, instead of learning/using a new tool that comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to
maximize ready-to-use report and for small company which have not yet a
real reporting tool.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
+1 birt to extra
and there will also a jasperReport in extras
Le 20/03/2012 15:34, Mansour Al Akeel a écrit :
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM,adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz,
instead of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components? Yes, I know there are POS users out there. So I now wonder if we should not wait before moving it out of specialpurpose. When you think about it, it's the twin of eCommerce. With a bit more involvment though, mostly because of its relation with Entity Sync (maintenance) which is actually part of the framework (entityext component). IMO, pos is one of the perfect example which should go in a Apache-OFbiz-SubProject not out of Apache-Ofbiz, of course +1 to becoming a plug-in but one of the Apache-OFBiz official plug-in Jacques
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - guiapp and pos
Hi Olivier, I would love to exchange thoughts regarding migration to portlets. Regards, Pierre Sent from my iPhone On 21 mrt. 2012, at 17:26, Olivier Heintz holivier.lis...@nereide.biz wrote: Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - guiapp and pos
On Mar 21, 2012, at 5:26 PM, Olivier Heintz wrote: +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Just to avoid any confusion: * with this +1 you are asking to keep projectmgr as it is now (specialpurpose) * we do not have official Apache subprojects in the small OFBiz community because they could be an overkill for what we do (subprojects needs PMC etc...) and we should be careful to even evaluate this path because it will add a lot of paperwork to our daily processes * transforming the architecture of the component(s) to enable plug-in can be discussed, even if in some ways they are already plugins; but I am wide open to discuss/evaluate your new proposals even if this discussion should be kept separate from the current thread Jacopo
Re: Lose Weight Program for OFBiz - guiapp and pos
As a next step, after all these threads about the slim down will settle down, we should probably, as a community, start to prepare the plan of action, aka roadmap (we could use Jira for it): add there all the actionable tasks coming out of this discussions; then, in these mailing lists we should also start to discuss, as a community, what are the other priorities/goals for the next few months of the project. We should probably start slowly with some cleanup tasks and refactoring of old code, bug fixes etc... but we could also come up with some more interesting priorities (like JCR or reporting tools): then, based on the priorities identified by the community we will start to explore how to design them; if an agreement is found we will add the tasks to the roadmap as well; then we will have a clear and shared plan of actions to keep us all busy for a while If migration to portlets will be a priority item is something that should be discussed with the community: the community is small and it should stay focused on a few key goals at the time; if the community will decide that the migration to portlets is something desirable then we will definitely explore this concept. Jacopo On Mar 21, 2012, at 5:33 PM, Pierre @GMail wrote: Hi Olivier, I would love to exchange thoughts regarding migration to portlets. Regards, Pierre Sent from my iPhone On 21 mrt. 2012, at 17:26, Olivier Heintz holivier.lis...@nereide.biz wrote: Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 Patelanil.pa...@hotwaxmedia.com 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 Akeelmansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeelmansour.alak...@gmail.com 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 Smitspierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - guiapp and pos
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
Re: Lose Weight Program for OFBiz - example, exampleext
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 jacques.le.r...@les7arts.com wrote: From: Nicolas Malinmalin.nico...@librenberry.net 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 : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - example, exampleext
Le 20/03/2012 23:44, Jacques Le Roux a écrit : From: Mansour Al Akeel mansour.alak...@gmail.com 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 erwan.de-ferrie...@nereide.fr 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
Re: Lose Weight Program for OFBiz - ofbizwebsite
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 mailingl...@antwebsystems.com 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
Re: Lose Weight Program for OFBiz - Birt and BI
From: Olivier Heintz holivier.lis...@nereide.biz
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com 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.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz JCR function
From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) Jacques If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz - guiapp and pos
From: Olivier Heintz holivier.lis...@nereide.biz Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Hi Anil, From: Anil Patel anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
From: Mansour Al Akeel mansour.alak...@gmail.com 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 anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 21/03/2012 19:02, Jacques Le Roux a écrit : From: Olivier Heintz holivier.lis...@nereide.biz Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 jacques.le.r...@les7arts.com wrote: From: Mansour Al Akeel mansour.alak...@gmail.com 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 anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com 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 pierre.sm...@gmail.com 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 jacopo.cappell...@hotwaxmedia.com het volgende: H)
Re: Lose Weight Program for OFBiz - guiapp and pos
From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 19:02, Jacques Le Roux a écrit : From: Olivier Heintz holivier.lis...@nereide.biz Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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
Re: Lose Weight Program for OFBiz - Birt and BI
+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 jacques.le.r...@les7arts.comwrote:
From: Olivier Heintz holivier.lis...@nereide.biz
Le 20/03/2012 15:31,
adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.coma
é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.comjacopo.cappell...@hotwaxmedia.com
:
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: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz JCR function
Keep in framework +1 Remove from upcoming release +1 Part of core eventually +1 I think it is (should be) central to content handling, and OFBiz core needs to handle content. Therefore it should be in core. Cheers, Anne. On 22 March 2012 05:04, Jacques Le Roux jacques.le.r...@les7arts.comwrote: From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) Jacques If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.**com jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
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 mansour.alak...@gmail.com 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 jacques.le.r...@les7arts.com wrote: From: Mansour Al Akeel mansour.alak...@gmail.com 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 anil.pa...@hotwaxmedia.com 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 anil.pa...@hotwaxmedia.com 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 mansour.alak...@gmail.com 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
Re: Lose Weight Program for OFBiz - example, exampleext
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 holivier.lis...@nereide.biz wrote: Le 20/03/2012 23:44, Jacques Le Roux a écrit : From: Mansour Al Akeel mansour.alak...@gmail.com 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 erwan.de-ferrie...@nereide.fr** 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: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
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 mailingl...@antwebsystems.com wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
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 Bakkermailingl...@antwebsystems.com wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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:
Re: Lose Weight Program for OFBiz
Le 19/03/2012 13:12, Hans Bakker a écrit : Scott, I appreciate your reply , but this apache extra's stuff is not working.: the Apache extra's is now over one year old, in that time there are 125 extra's for 84 projects. I even counted all the test and apple dirs.most projects are empty and do not have any extra's sorry i see moving out of special purpose components to extra's as a big error. Your advantages below will not work because Apache extra will be not a success. What is apache extra? A link screen to google projects which have some link to a apache project. Good for single developers, not good for us (Antwebsystems) because we rather use our own infrastructure which is integrated with the OFBiz system scrum component what is not possible with an external svn. If we (the ofbiz community) gives the correct tools (plugin management, Continuous Integration, release publishing, ...) to works with OFBiz Extra and Apache-OFBiz, 1) company could work with their own infrastructure which could be integrated with Apache-OFBiz and OFBiz-Extra 2) it will be possible to have OOTB solution for specifics need 3) users can easily view what is working and so use choose and use it ERP is really a good use case for Kernel and added features, and so it should work with Apache-OFBiz andd OFBiz-Extra Extra publicity? not really , we can publisize links in the ofbiz wiki to our own repository just the same. Regards, Hans On 03/19/2012 05:32 PM, Scott Gray wrote: Hi Hans, I don't want to argue the merits of removing specific portions of code/features/components but I think it's worth mentioning some of the benefits of moving features to Extras: - Greater access to contributors, if someone is making regular quality contributions to a specific Extra then they can easily be granted commit access. Easier for the contributor and no worry for the PMC that we have to grant access to the entire codebase (which in turn is better for the entire community) - Moving something to Extras shouldn't be considered as a loss to OFBiz or to the community. It is merely a means of streamlining and consolidating what is offered by OFBiz OOTB. Personally I envision OFBiz Extras as potentially becoming a vibrant community in itself, if we seed that community with a decent set of add-on functionality then it's quite possible other people would start to do the same. Providing and managing an Extra for the community would bring a type of recognition that donating it directly to OFBiz never could. For a company such as yours that likes to promote itself quite a bit it could actually work out to be an advantage for you. - The benefits of a slimmer OFBiz really can't be understated, at the moment we have something like 7000+ services, I don't know about you but I'd be lucky to be able to describe what maybe 10-20% actually do. The idea that you can download OFBiz, pop over to Extras and gran the things you actually need sounds super appealing to me. Sure it's an extra step that needs to be taken but I don't think that outweighs that benefits of being able to run only what you need. - New features for old releases. With components existing outside of OFBiz, contributors could make newer versions of components compatible with older releases of OFBiz, essentially allowing what we don't currently. If we can build a good community around Extras then I think we could see some amazing things happen in this regard. People could be empowered to do things that would never be accepted into OFBiz but would still be useful to a large number of people. Perhaps someone wants to develop Catalog Manager 2.0 using Apache Wicket or Apache Click or some other UI framework, they could do that and know that it will have an audience because we'll be actively endorsing the Extras community as a place to go for additional functionality. Anyway, I'm not arguing any of your points, I just want to make it clear to you and everyone else that I see this as an opportunity to make more features available for OFBiz rather than any attempt to take out the trash (that's the Attic's job). Regards Scott On 19/03/2012, at 9:05 PM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also
Re: Lose Weight Program for OFBiz
It seems weird to keep a 'demo application' in the framework, purely to facilitate developers. It adds no value to using ofbiz in production. So it should be removable from the framework and and self-contained (no dependencies from other applications). Op 18 maart 2012 12:16 schreef adrian.c...@sandglass-software.com het volgende: I think Example should stay in the framework, but get rid of all of the showroom stuff that has been added to it. In other words, keep it and return it to its original purpose - a very basic component for new users to understand OFBiz. I use datafile to connect legacy systems to OFBiz. I agree that specialpurpose should be slimmed down, but we should retain one or two components to demonstrate the concept of reusing artifacts to create custom applications. -Adrian Quoting Jacopo Cappellato jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com : In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...) DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours spent on it, great ideas that never came to a finished plan; in fact I feel the same for a few of the things in the list there are great ideas
Re: Lose Weight Program for OFBiz
Hi Hans, Of course you do not have to agree. But, like you implied earlier: let's put it to the vote and see what the outcome will. I assume that you will adhere/comply to the result as well. Regards, Pierre Op 19 maart 2012 13:15 schreef Hans Bakker mailingl...@antwebsystems.comhet volgende: Jacopo, I appreciate you reply and effort, can however not agree with you. Perhaps for you good reasoning, not for me. Regards, Hans On 03/19/2012 05:08 PM, Jacopo Cappellato wrote: Hi Hans, please see inline: On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. The not complete is not the only motivation: I have also considered if they seem to be used and maintained; or if they follow best practices or if they are very specific: some of them are actually a very specific way to implement a very specific set of requirements and may be better represented as independent optional components that can be downloaded and used only by users with these specific needs. Keeping all them in will also mean that, if and when the community will decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens to ABC or from the OFBiz Framework to Moqui) they will also need to be maintained and migrated by the community... when the user based may be very limited. Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. Then I was even more surprised, because reporting is a pretty weak point in OFBiz, to remove the Birt integration and data warehouse entities. I agree that reporting is a weak point in OFBiz; I disagree that the integrated Birt component is the answer to this problem: the integration is minimal and the reports that are implemented with Birt are very good example of how weak the current integration is: they have a bunch of data preparation code buried in them and their layout is very simple too. And you still have to define controller entries for the reports and also screen/forms for the parameters to invoke them... this is really a small help provided by the framework; a real integration, ready to be released with OFBiz, should do much more than this (like letting the user to define a new report using the report designer only and then publish it to OFBiz from there without requiring all these programming tasks). And as a side effect for having this integration we have to bundle and deliver to all the users a big amount of jars; instead this should be an optional (downloaded separately) component that only interested users should get (and these users will probably already have their own Birt setup). OFbiz should stay lighter and should delegate the decision about what reporting engine to use to the user. I suspect that, if the user community is really using this integration to build reports, we would get a lot of them contributed... and this is not happening. I cannot agree with the removal of these components, Birt integration and JCR (in the short term) Fair enough; we will see what others have to say on this subject as well. Then we will take the best decision for the community. Some other proposals: 1. I would like to push for more junit tests and use even this as a measure to keep a component in the system or not. (cobertura minimum percentage?) This is a good idea indeed if the presence/lack of junit test will be used as an additional element for the decision; but it can't be the only one because we could have a component that has a lot of junit tests but for some reason is not a good fit for OFBiz (for example because its implementation doesn't follow best practices, or no one is willing to maintain it etc...); in this case it should
Lose Weight Program for OFBiz JCR function
New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily.
Re: Lose Weight Program for OFBiz
Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...) DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with some of the code listed below: several hours
Re: Lose Weight Program for OFBiz
Jacopo, there is another alternative not listed here: Use the Moqui approach and separate in 1. framework, 2. services and entities 3. application components and concider a conversion path to the moqui framework. Regards Hans On 03/20/2012 04:15 PM, Jacopo Cappellato wrote: Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists,
Re: Lose Weight Program for OFBiz
I think that the slim down approach we are trying to implement, will help if and when we will decide to migrate to Moqui: Moqui is already a slimmed down framework and if our ootb applications will not rely on a fat framework will be easy to migrate; also having less code to maintain and migrate will make the migration to Moqui a more viable option for the community. Of course the migration to Moqui will represent a revolutionary approach that would be carefully evaluated with the community while this slim down roadmap is an evolution (that can be done in steps) that is not alternative to the switch to Moqui. Jacopo On Mar 20, 2012, at 10:28 AM, Hans Bakker wrote: Jacopo, there is another alternative not listed here: Use the Moqui approach and separate in 1. framework, 2. services and entities 3. application components and concider a conversion path to the moqui framework. Regards Hans On 03/20/2012 04:15 PM, Jacopo Cappellato wrote: Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some
Re: Lose Weight Program for OFBiz
On Mar 20, 2012, at 10:28 AM, Hans Bakker wrote: Use the Moqui approach and separate in 1. framework, 2. services and entities 3. application components By the way, as I mentioned in another thread, I like very much the idea above of having a lighter framework, a library of generic services and entities and *one* ERP component/application that represents the implementation of a specific ERP system that is still rather generic/configurable (but not too much, we could build it considering a medium company in the retail industry purchasing/manufacturing/selling different types of products like services and goods and most of all we should give up pretending that what we have right now can be used to serve a universal company or be extended to serve virtually any company in the World)... similar to the existing applications but much cleaner; then some add ons (external to the above layers) could add reporting/etc... capabilities or add external specialized applications (e.g. steel industry, scrum, paper industry etc...). Jacopo
Re: Lose Weight Program for OFBiz JCR function
On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz JCR function
Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz JCR function
Le 20/03/2012 11:48, Jacopo Cappellato a écrit : Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) I agree, refactoring content to separate a little more technical and functional element, it's not easier to implement JCR without a main reflexion on content. We implement an EDM with content and an interface between document repository (file, text, sound) and content service appears needed, independently than JCR (open the plugin document engine solution :) ) Nicolas At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Lose Weight Program for OFBiz - Birt and BI
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
Lose Weight Program for OFBiz - guiapp and pos
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?
