Inline
Le 18/03/2012 13:05, Jacques Le Roux a écrit :
Thanks for the proposition Jacopo,
Inline...
From: <adrian.c...@sandglass-software.com>
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.
+1
I agree notably the forms page
https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples
The rest could be in specialpurpose, with another name?
I use datafile to connect legacy systems to OFBiz.
I've never used except 1 month ago ;-) , and it was very effective.
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.
+1
Yes, ecomclone for instance should stay with ecommerce
-Adrian
Quoting Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com>:
...
IMPORTANT: Please consider that the list is not based on what I
think the perfect framework should be (so PLEASE do not reply
stating what your ideal framework should have), but simply on the
following considerations:
* can the component be easily removed by the project? is it
independent and can live outside as a plugin?
* do we need all this custom code? can't we find a simpler, lighter
and better way to implement this?
* is this feature used by other code in the system?
* is the feature functional? or is it largely incomplete?
* is this an old component/code?
* is this used by a lot of persons? (this is tricky to decide but
you can get a feeling of it by reading the mailing lists,
considering commit activity, the status of the feature etc...)
DISCLAIMER: I know it will be a painful decision because each of us
reading this will have a connection with some of the code listed
below: several hours spent on it, great ideas that never came to a
finished plan; in fact I feel the same for a few of the things in
the list.... there are great ideas that didn't come to a
finalization... it doesn't mean that moving them out of the project
will kill them and this may actually help to get more visibility
and different user group; so please when you will read it... think
to the greater good of the community.
Legenda for what I propose for each piece of code:
* Attic: remove from code base and document the removal for future
reference in this page
* Extras: identify a person interested in maintaining the code as a
separate project hosted as an Apache Extra project (not officially
under the ASF); add a link to it from the page that will contain
"OFBiz Extras"
And now (drums)..... THE LIST - PART 1(but this is really a very
first pass only, PART 2 will come soon with more granular -
subcomponent - details):
A) move framework/guiapp out of the framework; after all these
years no code made advantage of it being part of the framework and
it is only used by the specialpurpose/pos component (which was the
component for which it was built for); so guiapp can go in the pos
component
I can handle the framework/guiapp move to pos component
B) specialpurpose/pos: move to "Extras"
C) $OFBIZ_HOME/debian: move to "Attic"
D) the seleniumxml code in framework/testtools: move to "Attic"
E) specialpurpose/workflow: move to "Attic"
F) specialpurpose/shark: move to "Attic"
G) specialpurpose/ofbizwebsite: move to "Attic"
specialpurpose/ofbizwebsite could go to extras rather... if someone is
interested to continue the effort...
+1
H) specialpurpose/*: move several (if not all, apart ecommerce) of
the components to "Extras" (if there are persons interested to
become committers/maintainers) or to "Attic"
I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of
them to "Extras"; keep just one (or two)
only one and other to extras, in our customer project, all are using
depending on end-user choice
I would move all to extras and keep Tomahawk and Flat Grey. I'd prefer
to keep Tomahawk the defautl as it is now.
J) framework/appserver: move to "Extras"
K) framework/jetty: move to "Extras" (or "Attic")
L) framework/birt (and related dependencies/reports spread around):
move to "Extras"
M) framework/bi (and related dependencies - ecas/business rules and
data - spread around): move to "Extras"
N) framework/jcr: move back into the Jackrabbit branch until the
work is completed and can replace the existing "content framework"
+1
This should be coordinated with
https://issues.apache.org/jira/browse/OFBIZ-4709
O) framework/documents: move the content to Wiki and then move to
"Attic"
So get rid of the online help also?
online help is more efficient way to have end user help and sometime
existing feature boundary. In some customer project online help is using
to define what is operational or not, it's very convenient for business
Analyst and End user.
P) framework/datafile: (who is currently using it?) move to
"Extras" or "Attic"; we could replace it with commons-csv or
similar tool
I second Adrian on datafile. Though I have not used it for years, it
can be handy at any moment.
Q) framework/example and framework/exampleext: move to specialpurpose
Kind regards,
Jacopo
For the rest I agree
Jacques
