subject:"Framework refactor"

Thank you David,

please see inline:

On Mar 15, 2012, at 6:08 AM, David E Jones wrote:

 
 I think the Moqui Framework is already to a point where migration of
 OFBiz business-level artifacts could begin immediately.

Of course I would be happy to see (and help with) an effort to create a 
relatively complex proof of concepts for the migration. Then we will have a 
better ground to evaluate pros and cons of the two frameworks.

 
 Doing a migration like this would bring up other issues... including
 whether or not to clean up the data model and services while at it,
 especially rewriting messier parts of OFBiz like the ShoppingCart*
 objects and order processing stuff in general.
 

It will be very difficult to rewrite existing stuff, and doing this before or 
after the migration wouldn't change its complexity.
For this reason I think we can keep this topic out of this thread for now.
However, instead of rewriting, we could clean up what we have in OFBiz before 
the migration... especially if this could simplify the migration or make the 
existing code better organized.
For example, in another thread I was proposing to merge the existing 
application components into one, with possibly one webapp and less (and more 
consolidated) files: this may seem a huge effort but it may not be, because it 
could be done in baby steps with a lot of string replacements, moving/renaming 
files around etc... we could even create some scripts to simplify the effort.
But again, also this could be done before/after the migration (or never).

 If you want to stick with everything as-is and just do a migration, that
 should actually be much less work than you might think. I have some FTL
 templates to transform entity and service definitions, and a partial
 template for simple-methods. Similar templates could be made for screens
 and forms, though they are more complicated and may require more manual
 work. Things like groovy scripts and Java classes will also require a
 bit more work, but many patterns are similar so it would be much less
 work than moving to an object-relational sort of framework (ie
 Hibernate/JPA type of thing).

This doesn't help much to make me comfortable :-)
David, it may help if you could list a series of tasks (if any) we could 
perform in one of the OFBiz application components to make it more ready to be 
migrated: the tasks should ideally be doable in steps, and after each step the 
component should be usable in the existing OFBiz framework; but the code should 
be more compliant with the future layout of Moqui (or with what the migration 
scripts will expect); for example we could:
* merge/split service, entity, screen/forms definitions in one/more files
* merge Groovy scripts into one file with several methods (one per data 
preparation script)
* merge/split Java classes for services
* merge/split xml files with services
* etc. etc..

 
 While on the topic, some notes about things I saw in some related threads:
 
 1. the DSL/Helper class effort is in principle just an improved API for
 framework tools;

Not only this; well, yes it is simply this at the technical level but it is 
much much more in the end result and approach: in fact in my poc I have laid 
out some simple but very effective best practices for programming services and 
events: the code I added is minimal (a few lines... that after Adrian's 
refactoring became 10 times more... but the OFBiz community likes heavy stuff 
:-) ) and in fact the building blocks of my work have been there since we 
introduced Groovy for scripts (to replace Beanshell); but since then no one 
really did this small step to enable Groovy (with a series of best practices 
and a small set of methods) to be used in a way that is perfect for OFBiz (and 
it was the reason that made Minilang such a productive tool).
I really think that the 50 lines of code I wrote, together with the best 
practices defined by the two examples I have provided (for error/event/message 
handling) would represent a huge step ahead if used extensively to create new 
code (or to convert old one).
But of course the same concepts can be easily applied to Moqui.

 the OFBiz framework tools were originally implemented
 independently, and based on a LOT of static methods and static
 initialization, resulting in an API that is made up of a bunch of
 independent objects that I've found are opaque even to developers with
 years of OFBiz experience (ie they are not aware of functionality
 because it is so hard to find); the Moqui API takes care of this problem
 with an API designed to actually be an API as opposed to a bunch of
 independent classes that evolved; for more info on that, see:
 
 http://www.moqui.org/apiJavadoc/index.html
 
 ... and the central object of the API (that also has contextual details
 for the current request/user/etc):
 
 http://www.moqui.org/apiJavadoc/org/moqui/context/ExecutionContext.html
 
 Here are some quick examples of how this looks in actual use (from the

Re: Framework refactor (Moqui-/Mantle-specific)

2012-03-15 Thread Adrian Crum


On 3/15/2012 7:57 AM, Jacopo Cappellato wrote:
Not only this; well, yes it is simply this at the technical level but 
it is much much more in the end result and approach: in fact in my poc 
I have laid out some simple but very effective best practices for 
programming services and events: the code I added is minimal (a few 
lines... that after Adrian's refactoring became 10 times more... but 
the OFBiz community likes heavy stuff :-) )


The refactoring might have added a few lines to the Groovy 
implementation, but it also eliminates the need for these classes:


BshUtil.java
GroovyUtil.java
BeanShellEngine.java
BSFEngine.java
GroovyEngine.java
BsfEventHandler.java
GroovyEventHandler.java

and when mini-language implements JSR-223, these classes will not be needed:

SimpleEventHandler.java
SimpleServiceEngine.java

The refactoring also adds support for many more scripting languages.

So, I'm having a hard time understanding how the elimination of nine 
classes (1100 lines of code) while adding support for more scripting 
languages can be considered heavy stuff.


-Adrian

Re: Framework refactor (Moqui-/Mantle-specific)


On Mar 15, 2012, at 9:38 AM, Adrian Crum wrote:

 On 3/15/2012 7:57 AM, Jacopo Cappellato wrote:
 Not only this; well, yes it is simply this at the technical level but it is 
 much much more in the end result and approach: in fact in my poc I have laid 
 out some simple but very effective best practices for programming services 
 and events: the code I added is minimal (a few lines... that after Adrian's 
 refactoring became 10 times more... but the OFBiz community likes heavy 
 stuff :-) )
 
 The refactoring might have added a few lines to the Groovy implementation, 
 but it also eliminates the need for these classes:
 
 BshUtil.java
 GroovyUtil.java
 BeanShellEngine.java
 BSFEngine.java
 GroovyEngine.java
 BsfEventHandler.java
 GroovyEventHandler.java
 
 and when mini-language implements JSR-223, these classes will not be needed:
 
 SimpleEventHandler.java
 SimpleServiceEngine.java
 
 The refactoring also adds support for many more scripting languages.
 
 So, I'm having a hard time understanding how the elimination of nine classes 
 (1100 lines of code) while adding support for more scripting languages can be 
 considered heavy stuff.

Adrian, it was a joke not real criticism on you.
However I was not talking about the JSR-223 work in general but about the 
conversion of the specific DSL language class into the helper/factory pattern; 
that added a lot of code to a poc class that was intended to enhance Groovy for 
OFBiz. But you are right, in *theory* 100 different languages could use the new 
helper classes now and at that point the overhead would make a lot of sense: 
but we will never really know if they will be used out of OFBiz.

Jacopo

 
 -Adrian

Re: Framework refactor (Moqui-/Mantle-specific)

On Mar 15, 2012, at 9:46 AM, Jacopo Cappellato wrote:

 Adrian, it was a joke not real criticism on you.

And to be very clear: I appreciate all the work you did to add support to 
JSR-223

Jacopo

Re: Framework refactor (Moqui-/Mantle-specific)

2012-03-15 Thread Adrian Crum


On 3/15/2012 9:20 AM, Jacopo Cappellato wrote:

On Mar 15, 2012, at 9:46 AM, Jacopo Cappellato wrote:


Adrian, it was a joke not real criticism on you.

And to be very clear: I appreciate all the work you did to add support to 
JSR-223


We're cool. ;-)

-Adrian

Re: Framework refactor (Moqui-/Mantle-specific)

David,

a side note (but important): is Moqui using (or there are plans to use) jars or 
external tools whose license would prevent us from bundling Moqui in an OFBiz 
release under the ASL 2.0? This would be a show stopper...

Jacopo

On Mar 15, 2012, at 6:08 AM, David E Jones wrote:

 This might actually be good in a separate email, but anyway...
 
 The Moqui Framework would be a separate project from OFBiz, and while
 some OFBiz committers could certainly become moderators for Moqui that
 would be based on their personal efforts and merits and not anything to
 do with what happens or has happened in OFBiz.
 
 Moqui has a lot more extension points built-in than the OFBiz Framework,
 so you can actually do quite a bit without changing the framework
 itself. For cases where changes are needed (or wanted) to Moqui itself
 they would go through the normal feature request and patch submission
 process for Moqui to be reviewed by a moderator. Initially this would be
 me, and I obviously have some skin invested in an effort like this so
 I'd try to be responsive as possible (I have been so far with Moqui, but
 most of the time it has had light traffic so I've been able to get
 things reviewed and changed/fixed within a couple of days).
 
 One of the easiest ways to do that is with a pull request on GitHub. In
 fact, if the OFBiz variation of the Moqui Framework was managed on
 GitHub you could customize things there as desired while still being
 able to submit changes back to Moqui and get updates from Moqui so that
 OFBiz can more easily participate in the Moqui community. In git
 terminology this would actually be a fork, and I think is what Jacopo
 was talking about.
 
 Still, for the most part my guess is that this would not be needed and
 I'd recommend starting with just the jar files (or even just the war
 file) and not set things up for easily changing the framework until the
 need for doing so is well established.
 
 For this interested in considering Moqui for use in OFBiz, the tutorial
 and framework intro docs are probably the best places to start, and the
 Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
 running on Moqui, and the tutorial and run/deploy docs are actually
 cwiki documents (confluence-style wiki text)):
 
 http://www.moqui.org/framework/docs/Tutorial.html
 
 http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download
 
 http://www.moqui.org/framework/docs/RunDeploy.html
 
 Anyway, sorry for the delay in responding to this. I'm still a bit busy
 on contracts and I only catch up on the OFBiz mailing lists every week
 or so.
 
 -David

Re: Framework refactor (Moqui-/Mantle-specific)

The only library that is not friendly right now is the Redstone XMLRPC
library, which is LGPL licensed. That could be replaced by the Apache
XML-RPC project. The only reasons I used Redstone are that it is much
smaller (library bloat is a real problem), and it is a bit easier to use.

There are a couple of libraries that use CDDL (winstone servlet
container) and EPL (Mylin WikiText), but they are in binary form only so
should be fine.

If there is enough interest I'd be happy to change Moqui to use Apache
XML-RPC instead of Redstone.

-David

Jacopo Cappellato wrote:
David,

a side note (but important): is Moqui using (or there are plans to use) jars
or external tools whose license would prevent us from bundling Moqui in an
OFBiz release under the ASL 2.0? This would be a show stopper...

Jacopo

On Mar 15, 2012, at 6:08 AM, David E Jones wrote:

This might actually be good in a separate email, but anyway...

The Moqui Framework would be a separate project from OFBiz, and while
some OFBiz committers could certainly become moderators for Moqui that
would be based on their personal efforts and merits and not anything to
do with what happens or has happened in OFBiz.

Moqui has a lot more extension points built-in than the OFBiz Framework,
so you can actually do quite a bit without changing the framework
itself. For cases where changes are needed (or wanted) to Moqui itself
they would go through the normal feature request and patch submission
process for Moqui to be reviewed by a moderator. Initially this would be
me, and I obviously have some skin invested in an effort like this so
I'd try to be responsive as possible (I have been so far with Moqui, but
most of the time it has had light traffic so I've been able to get
things reviewed and changed/fixed within a couple of days).

One of the easiest ways to do that is with a pull request on GitHub. In
fact, if the OFBiz variation of the Moqui Framework was managed on
GitHub you could customize things there as desired while still being
able to submit changes back to Moqui and get updates from Moqui so that
OFBiz can more easily participate in the Moqui community. In git
terminology this would actually be a fork, and I think is what Jacopo
was talking about.

Still, for the most part my guess is that this would not be needed and
I'd recommend starting with just the jar files (or even just the war
file) and not set things up for easily changing the framework until the
need for doing so is well established.

For this interested in considering Moqui for use in OFBiz, the tutorial
and framework intro docs are probably the best places to start, and the
Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
running on Moqui, and the tutorial and run/deploy docs are actually
cwiki documents (confluence-style wiki text)):

http://www.moqui.org/framework/docs/Tutorial.html

http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download

http://www.moqui.org/framework/docs/RunDeploy.html

Anyway, sorry for the delay in responding to this. I'm still a bit busy
on contracts and I only catch up on the OFBiz mailing lists every week
or so.

-David

Re: Framework refactor (Moqui-/Mantle-specific)


NOTE: replying to this in multiple messages for better digestibility. :)

Jacopo Cappellato wrote:
 Thank you David,
 
 please see inline:
 
 On Mar 15, 2012, at 6:08 AM, David E Jones wrote:
 
 I think the Moqui Framework is already to a point where migration
 of OFBiz business-level artifacts could begin immediately.
 
 Of course I would be happy to see (and help with) an effort to create
 a relatively complex proof of concepts for the migration. Then we
 will have a better ground to evaluate pros and cons of the two
 frameworks.

There is an example application in Moqui that is similar to the one in
OFBiz, though focusing on the main screens and not including all of the
JS and other feature demo screens.

The online demo (running on Amazon Elastic Beanstalk) is here:

http://demo.moqui.org/apps/example/Example

The source code can be viewed through GitHub here:

https://github.com/jonesde/moqui/tree/master/runtime/component/example

-David

Re: Framework refactor (Moqui-/Mantle-specific)



Jacopo Cappellato wrote:
 Doing a migration like this would bring up other issues...
 including whether or not to clean up the data model and services
 while at it, especially rewriting messier parts of OFBiz like the
 ShoppingCart* objects and order processing stuff in general.
 
 
 It will be very difficult to rewrite existing stuff, and doing this
 before or after the migration wouldn't change its complexity. For
 this reason I think we can keep this topic out of this thread for
 now. However, instead of rewriting, we could clean up what we have in
 OFBiz before the migration... especially if this could simplify the
 migration or make the existing code better organized. For example, in
 another thread I was proposing to merge the existing application
 components into one, with possibly one webapp and less (and more
 consolidated) files: this may seem a huge effort but it may not be,
 because it could be done in baby steps with a lot of string
 replacements, moving/renaming files around etc... we could even
 create some scripts to simplify the effort. But again, also this
 could be done before/after the migration (or never).

Some of it could certainly be improved with a rewrite, or perhaps more
of a serious refactor. For example, using the database for shopping cart
data instead of an object in the session would be far more flexible for
a variety of order processing apps, especially outside of the normal
ecommerce submit-all-at-once flow.

But yes, this introduces another whole big set of issues and
discussions. Actually, frankly I'm surprised there is consideration of
any major framework changes, let alone moving to a new framework,
because so much effort is required to update or migrate all of the
existing business artifacts. That has killed a lot of framework
enhancement efforts over the years.

The main trick I'd see with combining webapps in the current
ofbiz/applications components is the request-map uri and view-map name
namespaces, ie the issue with duplicate names pointing to different
events and screens and such.

In Moqui these controller files would go away and the request-map and
view-map data goes into the screen definitions, but I can't think of any
changes that could be made now and supported by OFBiz to help move
toward this.

 If you want to stick with everything as-is and just do a migration,
 that should actually be much less work than you might think. I have
 some FTL templates to transform entity and service definitions, and
 a partial template for simple-methods. Similar templates could be
 made for screens and forms, though they are more complicated and
 may require more manual work. Things like groovy scripts and Java
 classes will also require a bit more work, but many patterns are
 similar so it would be much less work than moving to an
 object-relational sort of framework (ie Hibernate/JPA type of
 thing).

 This doesn't help much to make me comfortable :-) David, it may help
 if you could list a series of tasks (if any) we could perform in one
 of the OFBiz application components to make it more ready to be
 migrated: the tasks should ideally be doable in steps, and after each
 step the component should be usable in the existing OFBiz framework;
 but the code should be more compliant with the future layout of Moqui
 (or with what the migration scripts will expect); for example we
 could: * merge/split service, entity, screen/forms definitions in
 one/more files * merge Groovy scripts into one file with several
 methods (one per data preparation script) * merge/split Java classes
 for services * merge/split xml files with services * etc. etc..

As for what can be done in advance to prepare for it, I don't think that
splitting or combining files is too big a deal because that can be done
by a tool more easily than by a human.

The main area where Moqui differs from OFBiz Framework in terms of
artifacts per file is the screens. In Moqui there is one screen per file
as opposed to multiple screens per file, and they are hierarchical as
opposed to flat (or more of a network for decoration/inclusion/etc).
This could be done manually, but it could also be done by a tool and
perhaps more easily.

-David

Re: Framework refactor (Moqui-/Mantle-specific)



Jacopo Cappellato wrote:
 3. running in a single webapp: while this isn't necessary with
 Moqui, the Moqui Screens are a combination of the controller.xml
 entries for the particular screen and the OFBiz Screen Widget, and
 are hierarchical instead of being flat like the request-map URIs in
 OFBiz; this allows apps to plug into a screen hierarchy from
 separate places (by explicit inclusion, a database record, or
 implicitly by directory structure)
 
 The existing OFBiz screen/form widget is an area where OFBiz should
 be greatly improved in my opinion. Some of the things I don't like: *
 the configuration by exception patter should be used more
 extensively (most common screen definitions, controller entries
 etc... should not be required) * it is difficult to build complex
 Ajax screens * I don't like the xml code for screen/form actions: it
 is limited and it is an additional programming language to learn * in
 simpler screen it is an overkill to maintain in separate files the
 data preparation script, the form definition and the screen
 definition * the html code that is produced by the widgets is ugly
 and difficult to maintain
 
 It seems that some of the points above have been addressed by Moqui;
 David, did you ever consider to integrate other ui frameworks in
 Moqui? I know that in Moqui there is a more powerful mechanism to
 automatically render ui elements (e.g. submenu items for subscreens
 etc...) but frankly speaking I am less interested in them because I
 have learned that these tools are great to cover the 80% of the
 requirements of a ui but the work on the remaining 20% still has to
 be done in each and every screen to make it really usable. But I
 would be really interested to see a rather complex Moqui screen that
 uses Ajax and calls events: this would help me to evaluate the
 advantages of the new solution.

I don't know of any magic formulas for web-based UI stuff. Even a lot of
the desktop UI stuff is quite a pain and only elaborate visual-design
tools make it easier... and when those aren't adequate for what you want
to build life gets hard in a hurry.

One thing that the Moqui screens have that help with this is that it is
easier to extend the form and screen definitions by just adding macros
to an FTL template that extends and/or overrides the default templates.
You can add your new tags to an XSD file if you want so that things will
validate properly in your IDE, but that is not necessary for the new
tags to function.

This still isn't a silver bullet, but at least it makes it easier to
incorporate consistent UI widgets based on jQuery plugins or your own
hand-rolled stuff or whatever so that it is not necessary to have HTML
and/or JavaScript snippets to use each of these on each screen/page that
needs them.

It is also easier to inline HTML and JavaScript in a screen definition,
so that doesn't have to be maintained in a separate file... and have
have HTML inline in a form field and such. In other words, you can drop
it just about anywhere, making it much easier to do crazy stuff with the
screen and form XML files so you don't have to drop to FTL templates so
often.

OOTB the Moqui XML Screens and XML Forms use more JavaScript and dynamic
stuff than the OFBiz ones, but there is still a LOT of room for
improvement and it is something I'd like to do more of, or work with
other who do it to get it into the project (any takers? :) ).

If you have other ideas about what an artifact might look like that
would be easier for UI stuff, I would be very interested in discussing
it more. You have a lot of good ideas Jacopo, and I appreciate them a
great deal.

-David

Re: Framework refactor (Moqui-/Mantle-specific)

2012-03-14 Thread David E Jones


I think the Moqui Framework is already to a point where migration of
OFBiz business-level artifacts could begin immediately.

Doing a migration like this would bring up other issues... including
whether or not to clean up the data model and services while at it,
especially rewriting messier parts of OFBiz like the ShoppingCart*
objects and order processing stuff in general.

If you want to stick with everything as-is and just do a migration, that
should actually be much less work than you might think. I have some FTL
templates to transform entity and service definitions, and a partial
template for simple-methods. Similar templates could be made for screens
and forms, though they are more complicated and may require more manual
work. Things like groovy scripts and Java classes will also require a
bit more work, but many patterns are similar so it would be much less
work than moving to an object-relational sort of framework (ie
Hibernate/JPA type of thing).

While on the topic, some notes about things I saw in some related threads:

1. the DSL/Helper class effort is in principle just an improved API for
framework tools; the OFBiz framework tools were originally implemented
independently, and based on a LOT of static methods and static
initialization, resulting in an API that is made up of a bunch of
independent objects that I've found are opaque even to developers with
years of OFBiz experience (ie they are not aware of functionality
because it is so hard to find); the Moqui API takes care of this problem
with an API designed to actually be an API as opposed to a bunch of
independent classes that evolved; for more info on that, see:

http://www.moqui.org/apiJavadoc/index.html

... and the central object of the API (that also has contextual details
for the current request/user/etc):

http://www.moqui.org/apiJavadoc/org/moqui/context/ExecutionContext.html

Here are some quick examples of how this looks in actual use (from the
sendEmailTemplate.groovy script; sorry for the wrapping):

def emailTemplate =
ec.entity.makeFind(moqui.basic.email.EmailTemplate).condition(emailTemplateId,
emailTemplateId).one()

String bodyText =
ec.screen.makeRender().rootScreen(emailTemplate.bodyScreenLocation).renderMode(text).render()

Map cemParms = [sentDate:ec.user.nowTimestamp, subject:subject,
body:bodyHtml, fromAddress:emailTemplate.fromAddress,
toAddresses:toAddresses, ccAddresses:emailTemplate.ccAddresses,
bccAddresses:emailTemplate.bccAddresses, contentType:text/html,
emailTemplateId:emailTemplateId,fromUserId:ec.user.userId]
ec.service.sync().name(create,
moqui.basic.email.EmailMessage).parameters(cemParms).call()

2. consolidating OFBiz data model and services into a single component:
this is the way the Mantle UDM and USL are currently organized, though
they are restricted to very generic stuff and application-specific
extensions would live in the corresponding application

3. running in a single webapp: while this isn't necessary with Moqui,
the Moqui Screens are a combination of the controller.xml entries for
the particular screen and the OFBiz Screen Widget, and are hierarchical
instead of being flat like the request-map URIs in OFBiz; this allows
apps to plug into a screen hierarchy from separate places (by explicit
inclusion, a database record, or implicitly by directory structure)



This might actually be good in a separate email, but anyway...

The Moqui Framework would be a separate project from OFBiz, and while
some OFBiz committers could certainly become moderators for Moqui that
would be based on their personal efforts and merits and not anything to
do with what happens or has happened in OFBiz.

Moqui has a lot more extension points built-in than the OFBiz Framework,
so you can actually do quite a bit without changing the framework
itself. For cases where changes are needed (or wanted) to Moqui itself
they would go through the normal feature request and patch submission
process for Moqui to be reviewed by a moderator. Initially this would be
me, and I obviously have some skin invested in an effort like this so
I'd try to be responsive as possible (I have been so far with Moqui, but
most of the time it has had light traffic so I've been able to get
things reviewed and changed/fixed within a couple of days).

One of the easiest ways to do that is with a pull request on GitHub. In
fact, if the OFBiz variation of the Moqui Framework was managed on
GitHub you could customize things there as desired while still being
able to submit changes back to Moqui and get updates from Moqui so that
OFBiz can more easily participate in the Moqui community. In git
terminology this would actually be a fork, and I think is what Jacopo
was talking about.

Still, for the most part my guess is that this would not be needed and
I'd recommend starting with just the jar files (or even just the war
file) and not set things up for easily changing the framework until the
need for doing so is well

Re: Framework refactor

2012-03-05 Thread Nicolas Malin


Hi Jacopo,

Interesting discussion :)

Like you said, the selected solution will have all the features we need. 
At this time Apache OFBiz offering a great functional framework with 
technical interface, this allows to functional developer to stay focused 
on their needsand don't waste on technical problem. It's really 
important to don't lose it.


My feedback between Neogia and OFBiz (since we have in the same case 
that choice 3) and 4))


 * Fork : easier to improve the framework, but really difficult to back 
improvements to original project. Many waste time to realize 
improvement in parallel. I don't recommend it
 * Synchronize by repository : import a external framework release, 
provides flexibility to update the external source and show own 
improvement. But with time past, the differences grow, increasing the 
synchro time and decreasing the back improvement quality. We stop this 
solution there are two years.
  * At this time, with develop addon manager system to separate each 
improvement on dedicate addon. This simplify the synchronization with 
external source, keep back improvement quality. We lost in commit 
celerit, it's a little more complicated to improve an addon than only 
commit in a repository.


Whatever solution, I am available to help you.

Nicolas

Le 02/03/2012 09:28, Jacopo Cappellato a écrit :

On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:


Jacopo,

You would even consider forking?

 From Wikipedia [*]:

[...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of 
the term fork, blurring the distinction with branch. With a DVCS such as Mercurial or 
Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your 
changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS 
hosting expressly supporting independent branches, such that the technical, social and financial barriers to 
forking a source code repository are massively reduced.

In order of preference (descending), here are the options I see for the future 
of the OFBiz framework:

1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then 
release it separately from the Apache OFBiz ERP
2) greatly clean up and improve the existing framework (I was not sure if this 
could go at #1)
3) if the above will not be possible (frankly speaking, in the committers 
group, apart from David, none of us ever implemented with success an open 
source framework) we should also consider to drop the existing code and have 
our community focusing on the ERP part (as Hans seems to advocate); at this 
point Moqui would be the most natural choice; if we will ever go with this path 
a great exchange of information will have to happen between the two projects: 
for example OFBiz will probably have to ask the Moqui framework to evolve some 
of its features; given the current nature of the Moqui project, I doubt that 
the OFBiz committers will be ever invited as committers there; if Moqui will be 
our choice, I see two possibilities:
3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be 
possible if Moqui release will have all the features we need (and if Moqui 
community will be interested in getting contribution to evolve in the direction 
required by OFBzi)
3.b) if 3.a will not be possible because OFBiz will need some features that Moqui 
community will not consider as a good fit for Moqui, then, under the guidance and bless 
of David, we could work on a fork: get the code from a Moqui release, import in our 
repository and add to it, in a controlled way, the features we need; of course this 
should be always kept as close as possible to the original code; we could synch our 
custom code with every new Moqui release; I was not thinking about *stealing* code to 
Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in 
the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it 
will be still an ugly solution but for example when you said: My proposal is that 
Apache OFBiz will be in the future just the ERP system based on many opensource products 
like birt and also Moqui you are actually implying that the ERP applications 
will be able to use Birt... but this requires some sort of framework and what would you 
do if Moqui will not think that Birt is a good fit for them?
4) if Moqui will not be a good option we may consider other frameworks (?), but 
it will be difficult, or continue with what we have

Jacopo



[*]: http://en.wikipedia.org/wiki/Fork_(software_development)



--
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: Framework refactor

2012-03-05 Thread shi . jinghai

+1 to 3.a).


On 2012-3-2, at 下午4:28, Jacopo Cappellato wrote:

 
 On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
 
 Jacopo,
 
 You would even consider forking?
 
 From Wikipedia [*]:
 
 [...] More recently, distributed revision control (DVCS) tools have 
 popularised a less emotive use of the term fork, blurring the distinction 
 with branch. With a DVCS such as Mercurial or Git, the normal way to 
 contribute to a project is to first branch the repository, and later seek to 
 have your changes integrated with the main repository. Sites such as Github, 
 Bitbucket and Launchpad provide free DVCS hosting expressly supporting 
 independent branches, such that the technical, social and financial barriers 
 to forking a source code repository are massively reduced.
 
 In order of preference (descending), here are the options I see for the 
 future of the OFBiz framework:
 
 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; 
 then release it separately from the Apache OFBiz ERP
 2) greatly clean up and improve the existing framework (I was not sure if 
 this could go at #1)
 3) if the above will not be possible (frankly speaking, in the committers 
 group, apart from David, none of us ever implemented with success an open 
 source framework) we should also consider to drop the existing code and have 
 our community focusing on the ERP part (as Hans seems to advocate); at this 
 point Moqui would be the most natural choice; if we will ever go with this 
 path a great exchange of information will have to happen between the two 
 projects: for example OFBiz will probably have to ask the Moqui framework to 
 evolve some of its features; given the current nature of the Moqui project, I 
 doubt that the OFBiz committers will be ever invited as committers there; if 
 Moqui will be our choice, I see two possibilities:
 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be 
 possible if Moqui release will have all the features we need (and if Moqui 
 community will be interested in getting contribution to evolve in the 
 direction required by OFBzi)
 3.b) if 3.a will not be possible because OFBiz will need some features that 
 Moqui community will not consider as a good fit for Moqui, then, under the 
 guidance and bless of David, we could work on a fork: get the code from a 
 Moqui release, import in our repository and add to it, in a controlled way, 
 the features we need; of course this should be always kept as close as 
 possible to the original code; we could synch our custom code with every new 
 Moqui release; I was not thinking about *stealing* code to Moqui and the fact 
 that David is both the founder of OFBiz and of Moqui and he is both in the 
 OFBiz PMC and the leader of the Moqui project will definitely facilitate 
 this; but it will be still an ugly solution but for example when you said: 
 My proposal is that Apache OFBiz will be in the future just the ERP system 
 based on many opensource products like birt and also Moqui you are 
 actually implying that the ERP applications will be able to use Birt... but 
 this requires some sort of framework and what would you do if Moqui will not 
 think that Birt is a good fit for them?
 4) if Moqui will not be a good option we may consider other frameworks (?), 
 but it will be difficult, or continue with what we have
 
 Jacopo
 
 
 
 [*]: http://en.wikipedia.org/wiki/Fork_(software_development)

Re: Framework refactor

2012-03-03 Thread Bruno Busco

Jacopo,
I would go, or at least, deeply consider option:

3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be
possible if Moqui release will have all the features we need (and if Moqui
community will be interested in getting contribution to evolve in the
direction required by OFBzi)

I think that David will be more than interested in evaluating every feature
needed by OFBiz.
He has already started the mantle and crust projects that, on top of the
Moqui framework, should be something like a reworked OFBiz.

-Bruno

2012/3/2 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com


 On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:

  Jacopo,
 
  You would even consider forking?

 From Wikipedia [*]:

 [...] More recently, distributed revision control (DVCS) tools have
 popularised a less emotive use of the term fork, blurring the distinction
 with branch. With a DVCS such as Mercurial or Git, the normal way to
 contribute to a project is to first branch the repository, and later seek
 to have your changes integrated with the main repository. Sites such as
 Github, Bitbucket and Launchpad provide free DVCS hosting expressly
 supporting independent branches, such that the technical, social and
 financial barriers to forking a source code repository are massively
 reduced.

 In order of preference (descending), here are the options I see for the
 future of the OFBiz framework:

 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community;
 then release it separately from the Apache OFBiz ERP
 2) greatly clean up and improve the existing framework (I was not sure if
 this could go at #1)
 3) if the above will not be possible (frankly speaking, in the committers
 group, apart from David, none of us ever implemented with success an open
 source framework) we should also consider to drop the existing code and
 have our community focusing on the ERP part (as Hans seems to advocate); at
 this point Moqui would be the most natural choice; if we will ever go with
 this path a great exchange of information will have to happen between the
 two projects: for example OFBiz will probably have to ask the Moqui
 framework to evolve some of its features; given the current nature of the
 Moqui project, I doubt that the OFBiz committers will be ever invited as
 committers there; if Moqui will be our choice, I see two possibilities:
 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be
 possible if Moqui release will have all the features we need (and if Moqui
 community will be interested in getting contribution to evolve in the
 direction required by OFBzi)
 3.b) if 3.a will not be possible because OFBiz will need some features
 that Moqui community will not consider as a good fit for Moqui, then, under
 the guidance and bless of David, we could work on a fork: get the code from
 a Moqui release, import in our repository and add to it, in a controlled
 way, the features we need; of course this should be always kept as close as
 possible to the original code; we could synch our custom code with every
 new Moqui release; I was not thinking about *stealing* code to Moqui and
 the fact that David is both the founder of OFBiz and of Moqui and he is
 both in the OFBiz PMC and the leader of the Moqui project will definitely
 facilitate this; but it will be still an ugly solution but for example when
 you said: My proposal is that Apache OFBiz will be in the future just the
 ERP system based on many opensource products like birt and also Moqui
 you are actually implying that the ERP applications will be able to use
 Birt... but this requires some sort of framework and what would you do if
 Moqui will not think that Birt is a good fit for them?
 4) if Moqui will not be a good option we may consider other frameworks
 (?), but it will be difficult, or continue with what we have

 Jacopo



 [*]: http://en.wikipedia.org/wiki/Fork_(software_development)

Re: Framework refactor

2012-03-02 Thread Jacopo Cappellato


On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:

 Jacopo,
 
 You would even consider forking?

From Wikipedia [*]:

[...] More recently, distributed revision control (DVCS) tools have 
popularised a less emotive use of the term fork, blurring the distinction 
with branch. With a DVCS such as Mercurial or Git, the normal way to 
contribute to a project is to first branch the repository, and later seek to 
have your changes integrated with the main repository. Sites such as Github, 
Bitbucket and Launchpad provide free DVCS hosting expressly supporting 
independent branches, such that the technical, social and financial barriers to 
forking a source code repository are massively reduced.

In order of preference (descending), here are the options I see for the future 
of the OFBiz framework:

1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then 
release it separately from the Apache OFBiz ERP
2) greatly clean up and improve the existing framework (I was not sure if this 
could go at #1)
3) if the above will not be possible (frankly speaking, in the committers 
group, apart from David, none of us ever implemented with success an open 
source framework) we should also consider to drop the existing code and have 
our community focusing on the ERP part (as Hans seems to advocate); at this 
point Moqui would be the most natural choice; if we will ever go with this path 
a great exchange of information will have to happen between the two projects: 
for example OFBiz will probably have to ask the Moqui framework to evolve some 
of its features; given the current nature of the Moqui project, I doubt that 
the OFBiz committers will be ever invited as committers there; if Moqui will be 
our choice, I see two possibilities:
3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be 
possible if Moqui release will have all the features we need (and if Moqui 
community will be interested in getting contribution to evolve in the direction 
required by OFBzi)
3.b) if 3.a will not be possible because OFBiz will need some features that 
Moqui community will not consider as a good fit for Moqui, then, under the 
guidance and bless of David, we could work on a fork: get the code from a Moqui 
release, import in our repository and add to it, in a controlled way, the 
features we need; of course this should be always kept as close as possible to 
the original code; we could synch our custom code with every new Moqui release; 
I was not thinking about *stealing* code to Moqui and the fact that David is 
both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the 
leader of the Moqui project will definitely facilitate this; but it will be 
still an ugly solution but for example when you said: My proposal is that 
Apache OFBiz will be in the future just the ERP system based on many opensource 
products like birt and also Moqui you are actually implying that the ERP 
applications will be able to use Birt... but this requires some sort of 
framework and what would you do if Moqui will not think that Birt is a good fit 
for them?
4) if Moqui will not be a good option we may consider other frameworks (?), but 
it will be difficult, or continue with what we have

Jacopo



[*]: http://en.wikipedia.org/wiki/Fork_(software_development)

Re: Framework refactor

2012-03-02 Thread Adrian Crum


On 3/2/2012 8:28 AM, Jacopo Cappellato wrote:

In order of preference (descending), here are the options I see for the future 
of the OFBiz framework:

1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then 
release it separately from the Apache OFBiz ERP


This is the approach I prefer.


2) greatly clean up and improve the existing framework (I was not sure if this 
could go at #1)


I agree this is less preferable, but if we decide to go this route I 
will help.



3) if the above will not be possible (frankly speaking, in the committers 
group, apart from David, none of us ever implemented with success an open 
source framework) we should also consider to drop the existing code and have 
our community focusing on the ERP part (as Hans seems to advocate); at this 
point Moqui would be the most natural choice; if we will ever go with this path 
a great exchange of information will have to happen between the two projects: 
for example OFBiz will probably have to ask the Moqui framework to evolve some 
of its features; given the current nature of the Moqui project, I doubt that 
the OFBiz committers will be ever invited as committers there; if Moqui will be 
our choice, I see two possibilities:


Some of us have implemented successful ERP frameworks, just not open 
source ones. Also keep in mind that the OFBiz framework we have today 
includes designs from many contributors. So, let's make sure we give 
credit where credit is due, without diminishing David and Andrew's role.


-Adrian

Framework refactor (was: Definitively remove beanshell from OFBiz)

2012-03-01 Thread Adrian Crum

I included currency in the framework because i18n libraries the
framework is based on will include it.

A framework for ERP applications would be built on the framework I
proposed - I mentioned that in the document. In my mind, things should
be modular, instead of the monolithic design we have now. So, geos would
be a separate component that uses the framework - just like scripting is
a separate component. The framework plus a selection of additional
components could comprise a framework for ERP applications. I believe
this approach will broaden the user base because we will eliminate the
all or nothing approach used now.

I understand the workflow you are suggesting - cut down the size of the
existing framework and then switch to something else. In an ideal world
we could do that. Unfortunately, we have a lot of committers who believe
more is better, so while we're cutting down in one area, someone else
will be adding code in another area.

The workflow I pictured was to introduce a new component and build from
the ground up. Initially there will be some code duplication due to
parallel development paths, but once the new component is finished,
other OFBiz artifacts can be updated to use it and any excess can be
removed. In other words, the code removal is motivated by the fact that
it is no longer needed.

-Adrian

On 3/1/2012 10:15 AM, Jacopo Cappellato wrote:

The document is interesting and I agree with the approach in general.
I don't agree, but this is a small detail, with the assertion that currency
should be part of a framework: I can think of several applications not dealing with money
:-)
And if we want to design a framework for ERP applications then we could have some
additional pieces (like Geos, Uoms, Currencies)... but this would be more a common base
to ERP applications.
I like the idea of one component framework: at that point it would be easier
to deploy and we could use an external tomcat as the default setup (no more embedded
catalina).
I also think that the official OFBiz ERP (i.e. the features currently in the
applications folder) should also be implemented by *one* application/component: based
on naming conventions and patterns to simplify customizations and reuse but still one application
where features are hidden thru permissions.

But this is for OFBiz 2.0, nice to discuss, but my idea for a lightweight
framework was less revolutionary and could be considered as a preparation step
in the direction of the new OFBiz: cutting down old branches and unused code in
order to have a smaller system to refactor according to the new vision. At that
point, with a cleaner ground, we could better plan the next step: implementing
a new framework or considering other options (e.g. Moqui) or even keeping what
we have

Jacopo

On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:

As far as I know, most scripting engines have some sort of embedded cache. The
problem will be that we can't clear the embedded cache like we can with our own
cache implementation. I don't see that as a show stopper - it's mostly
inconvenient.

I can help out with the conversion. I don't think the task will be that hard.

Regarding a slimmed down framework, I proposed one some time ago:

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

and that document was in response to David's proposal to base OFBiz on Moqui
(another option).

-Adrian

On 3/1/2012 8:53 AM, Jacopo Cappellato wrote:

Implementing JSR-223 should be rather easy but if I am not wrong it would
prevent the ability to cache the scripts (task that is currently done in
org.ofbiz.base.util.GroovyUtil, that is using the the more flexible
GroovyClassLoader mechanism); we could probably use the javax.script.Compilable
interface but I am not sure...
One advantage of JSR-223 would be that we could dynamically select the script
engine based on the (for example) file extension without the need to maintain
several classes like GroovyUtil, BsfUtil etc...
The idea would be that, instead of having a GroovyUtil class we could have a
generic ScriptUtil class with code like the following:

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine scriptEngine =
manager.getEngineByExtension(fileExtension);
Object result = scriptEngine.eval(scriptFileReader, scriptContext);

and this code would be generic and could be used to plug in all the scripting
engines that support JSR-223.

However doing this in OFBiz would mean that we have to refactor all the code that is
currently using the variousscriptUtil classes and in my opinion a simpler
path (that is inline with Erwan's proposal to convert all remaining beanshell
snippets to Groovy and then deprecate or remove BshUtil) would be:

1) migrate the remaining Beanshell snippets to Groovy
2) deprecate or remove (I see a lot of value in having lighter framework [*])
Beashell support (and other artifacts related to

Re: Framework refactor (was: Definitively remove beanshell from OFBiz)


On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:

 I understand the workflow you are suggesting - cut down the size of the 
 existing framework and then switch to something else. In an ideal world we 
 could do that. Unfortunately, we have a lot of committers who believe more is 
 better, so while we're cutting down in one area, someone else will be adding 
 code in another area.

Yes, I know what you mean: I still think that, if the goal is clear and the 
strategy makes sense (e.g. simplify/standardize the tools used, for example 
migrate everything from bsh to groovy, and then slim down the current framework 
to the bare minimum technologies used by the official applications in order to 
simplify and renew the code base) we could try to work to get a majority 
approval and a shared strategy and then everyone will have to stick to the plan 
and help to implement it... i.e. working as a community rather than as 
individual with commit rights and different visions.

Jacopo

Re: Framework refactor

2012-03-01 Thread Adrian Crum

You are a lot more optimistic than I am. Despite the best efforts of PMC 
members to provide advice/guidance/suggestions, committers still do what 
they please. It's worth a try, but I don't have much hope for success.


-Adrian

On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:

On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:


I understand the workflow you are suggesting - cut down the size of the 
existing framework and then switch to something else. In an ideal world we 
could do that. Unfortunately, we have a lot of committers who believe more is 
better, so while we're cutting down in one area, someone else will be adding 
code in another area.

Yes, I know what you mean: I still think that, if the goal is clear and the strategy 
makes sense (e.g. simplify/standardize the tools used, for example migrate 
everything from bsh to groovy, and then slim down the current framework to the bare 
minimum technologies used by the official applications in order to simplify and renew the 
code base) we could try to work to get a majority approval and a shared strategy 
and then everyone will have to stick to the plan and help to implement it... i.e. working 
as a community rather than as individual with commit rights and different visions.

Jacopo

Re: Framework refactor

I don't think it will be easy and actually it may be unfeasible but I see some 
good reasons for hope:

* the general discussion/vote would involve all committers and not only PMC 
members: everyone would be involved in the decision and in the 
responsibilities/consequences around it
* our committers group is made of clever persons that know we are all playing 
on top of a system that is bigger than us, that is very complex and has been 
built thanks to the visions and great ideas/skills of others; we have to make 
sure we do not ruin what we are asked to maintain and improve and, with such a 
big and complex beast, working together as a group is the only responsible way 
of achieving this difficult task... on the other hand continuing to think as 
individuals with our own personal goals and ideas will make a mess of this 
project soon

Jacopo

On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:

 You are a lot more optimistic than I am. Despite the best efforts of PMC 
 members to provide advice/guidance/suggestions, committers still do what they 
 please. It's worth a try, but I don't have much hope for success.
 
 -Adrian
 
 On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:
 On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:
 
 I understand the workflow you are suggesting - cut down the size of the 
 existing framework and then switch to something else. In an ideal world we 
 could do that. Unfortunately, we have a lot of committers who believe more 
 is better, so while we're cutting down in one area, someone else will be 
 adding code in another area.
 Yes, I know what you mean: I still think that, if the goal is clear and the 
 strategy makes sense (e.g. simplify/standardize the tools used, for example 
 migrate everything from bsh to groovy, and then slim down the current 
 framework to the bare minimum technologies used by the official applications 
 in order to simplify and renew the code base) we could try to work to get a 
 majority approval and a shared strategy and then everyone will have to stick 
 to the plan and help to implement it... i.e. working as a community rather 
 than as individual with commit rights and different visions.
 
 Jacopo

Re: Framework refactor

2012-03-01 Thread Jacques Le Roux


From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com

I don't think it will be easy and actually it may be unfeasible but I see some 
good reasons for hope:

* the general discussion/vote would involve all committers and not only PMC 
members: everyone would be involved in the decision
and in the responsibilities/consequences around it
* our committers group is made of clever persons that know we are all playing 
on top of a system that is bigger than us, that is
very complex and has been built thanks to the visions and great ideas/skills of 
others; we have to make sure we do not ruin what
we are asked to maintain and improve and, with such a big and complex beast, 
working together as a group is the only responsible
way of achieving this difficult task... on the other hand continuing to think 
as individuals with our own personal goals and ideas
will make a mess of this project soon


I'd be very happy to see some sense of responsability to increase in the 
community. And I have the feeling that it's the case. We
communicate better, and better respect each other ideas and ways. This said, 
there are huges task ahead...

As I said in another email, I'm more for the step by step approach than to try 
a dramatic change,  ie more evolution thant
revolution

PS: to be more clear, when I speak about step by step approach I think about 
something like this part of a previous email:


1) migrate the remaining Beanshell snippets to Groovy
2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to 
old/unused script engines)
3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and 
convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223


In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with 
several other technologies (removed at #2)


Kind regards,

Jacopo

[*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only 
support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to 
quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example 
in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to 
integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using 
javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean 
way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script engine would be easy 
(but the support of the new script engine will not be included in the project to keep it light and focused)


Then, when done (I mean not only this part but also some needeeed others), an 
approach like suggested by Adrian could be adopted...

My 2cts

Jacques




Jacopo

On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:


You are a lot more optimistic than I am. Despite the best efforts of PMC 
members to provide advice/guidance/suggestions,
committers still do what they please. It's worth a try, but I don't have much 
hope for success.

-Adrian

On 3/1/2012 1:48 PM, Jacopo Cappellato wrote:

On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote:


I understand the workflow you are suggesting - cut down the size of the 
existing framework and then switch to something else.
In an ideal world we could do that. Unfortunately, we have a lot of committers 
who believe more is better, so while we're
cutting down in one area, someone else will be adding code in another area.

Yes, I know what you mean: I still think that, if the goal is clear and the strategy 
makes sense (e.g. simplify/standardize the
tools used, for example migrate everything from bsh to groovy, and then slim 
down the current framework to the bare minimum
technologies used by the official applications in order to simplify and renew the 
code base) we could try to work to get a
majority approval and a shared strategy and then everyone will have to stick to 
the plan and help to implement it... i.e.
working as a community rather than as individual with commit rights and 
different visions.

Jacopo

Re: Framework refactor

Before even start to plan a new framework we should indeed at least carefully 
review what David did in Moqui.
I actually already spent some time reviewing some parts of it and I will 
continue for sure as I am very interested in all the work that David does.
If the OFBiz community will ever consider to adopt Moqui as the new framework 
then a lot of decision will have to be taken: forking Moqui and import its 
source files in the OFBiz svn? Use Moqui releases as external jars and have 
the OFBiz community only work on the ERP part? Collaborate with the Moqui 
community to get the features that we need in OFBiz?
A lot of questions for the future... but in the meantime I agree with Jacques 
that we can take small steps to improve what we already have: agree on a plan 
(e.g. simplifying/cleaning the framework in preparation of a future evolution, 
Moqui or something else) and then stick to it moving at small steps in the same 
direction.

Jacopo


On Mar 2, 2012, at 6:59 AM, Hans Bakker wrote:

 Shouldn't we considering replacing the ofbiz framework with th Moqui 
 framework?
 
 David (with Andy) created the OFBiz framework, learned from it and created 
 Moqui using this knowledge.
 
 Why not have all people interested refactoring the OFBiz framework join the 
 Moqui project?
 
 David, what do you think?
 
 
 Regards,
 Hans
 
 
 On 03/02/2012 10:31 AM, Jacques Le Roux wrote:
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 I don't think it will be easy and actually it may be unfeasible but I see 
 some good reasons for hope:
 
 * the general discussion/vote would involve all committers and not only PMC 
 members: everyone would be involved in the decision
 and in the responsibilities/consequences around it
 * our committers group is made of clever persons that know we are all 
 playing on top of a system that is bigger than us, that is
 very complex and has been built thanks to the visions and great 
 ideas/skills of others; we have to make sure we do not ruin what
 we are asked to maintain and improve and, with such a big and complex 
 beast, working together as a group is the only responsible
 way of achieving this difficult task... on the other hand continuing to 
 think as individuals with our own personal goals and ideas
 will make a mess of this project soon
 
 I'd be very happy to see some sense of responsability to increase in the 
 community. And I have the feeling that it's the case. We
 communicate better, and better respect each other ideas and ways. This said, 
 there are huges task ahead...
 
 As I said in another email, I'm more for the step by step approach than to 
 try a dramatic change,  ie more evolution thant
 revolution
 
 PS: to be more clear, when I speak about step by step approach I think 
 about something like this part of a previous email:
 
 1) migrate the remaining Beanshell snippets to Groovy
 2) deprecate or remove (I see a lot of value in having lighter framework 
 [*]) Beashell support (and other artifacts related to old/unused script 
 engines)
 3) (optional, something for the future) refactor the GroovyUtil class (and 
 code that is using it) to be generic (ScriptUtil) and convert all the 
 calling code to use it in a Groovy unaware way; this will implement the 
 JSR-223
 
 In this way, when we will work on #3 we could concentrate only on migration 
 of groovy classes rather than having to cope with several other 
 technologies (removed at #2)
 
 Kind regards,
 
 Jacopo
 
 [*] In my opinion one of the main big steps that the OFBiz project should 
 consider is to greatly slim down the framework and only support the 
 technology we really need (picking the best for each task); then with a 
 much smaller codebase, we will be able to quickly improve the framework 
 (less code to maintain etc...) to be compliant with new standards etc.. 
 (e.g. JSR-223). For example in this context: ideally the OFBiz project 
 should have all the scripts implemented in Groovy (one technology) and a 
 simple way to integrate other scripting languages; we could achieve this 
 implementing JSR-223 so that even the OFBiz code would be using 
 javax.script.* rather than groovy.* packages OR it would be also fine if we 
 would still be using groovy.* packages but in a clean way (e.g. all calling 
 code could use interfaces to hide Groovy specific code) so that adding a 
 new script engine would be easy (but the support of the new script engine 
 will not be included in the project to keep it light and focused)
 
 Then, when done (I mean not only this part but also some needeeed others), 
 an approach like suggested by Adrian could be adopted...
 
 My 2cts
 
 Jacques
 
 
 
 Jacopo
 
 On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote:
 
 You are a lot more optimistic than I am. Despite the best efforts of PMC 
 members to provide advice/guidance/suggestions,
 committers still do what they please. It's worth a try, but I don't have 
 much hope for success.
 
 -Adrian
 
 On 3/1/2012 1:48 PM,

Re: Framework refactor


On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:

 Jacopo,
 
 You would even consider forking? This sounds more that you want to be in 
 control than going for the best and work together.

me?

 I would like to propose to join the Moqui framework and when ready, use in 
 OFBiz the jars only as we do with other open source products.

As I said, this is something to consider for sure... but in the same time we 
have to consider all options: currently the OFBiz community is about the 
development of a framework and ERP system and if we change this goal it will be 
a big decision, so we have to consider all the pros and cons.

 
 My proposal is that Apache OFBiz will be in the future just the ERP system 
 based on many opensource products like birt and also Moqui
 
 Regards,
 Hans

Re: Framework refactor

2012-03-01 Thread Hans Bakker


Jacopo,

please read in the original message.you took it away here.
you wrote:
-
If the OFBiz community will ever consider to adopt Moqui as the new 
framework then a lot of decision will have to be taken: forking Moqui 
and import its source files in the OFBiz svn?

-

That you even consider this as the first optionnot sound good..

Regards



On 03/02/2012 02:05 PM, Jacopo Cappellato wrote:

On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:


Jacopo,

You would even consider forking? This sounds more that you want to be in 
control than going for the best and work together.

me?


I would like to propose to join the Moqui framework and when ready, use in 
OFBiz the jars only as we do with other open source products.

As I said, this is something to consider for sure... but in the same time we 
have to consider all options: currently the OFBiz community is about the 
development of a framework and ERP system and if we change this goal it will be 
a big decision, so we have to consider all the pros and cons.


My proposal is that Apache OFBiz will be in the future just the ERP system 
based on many opensource products like birt and also Moqui

Regards,
Hans

Re: Framework refactor