On Jan 3, 2010, at 3:53 AM, Bruno Busco wrote: > When I sayd "at least me" I should have said "To implement the > framework-only distribution end-user requirements here > http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"; > We should agree or change what is written there and then work to implement it.
Please keep in mind that is just your document. There is no such thing as implicit agreement, and if there are disagreements on the mailing list IMO that is just as valid as someone going in and changing your document (and most people would probably consider it less rude too, which is maybe why no one has made changes there). BTW, looking through those... where are the CMS related requirements? What sorts of business activities drive these requirements? Actually, to be more accurate, I wouldn't call any of the things you listed there requirements, they all look like designs to me, ie solutions to the problems rather than the problems themselves. > The framework-only work should of course generate two workproducts: > - A standalone framework implementing the requirements > - A set of additional components, each with its declared dependencies, > that can be plugged in the framework-only installation. > > For my next project all I would like to do is to select the newly > needed components and plug them in the framework-only. > > The sets of components framework+party+content+commonext should give > us a basic configuration that, from the user POV should be similar to > a CMS system but powered by OFBiz. And what about those who not only don't care either way about CMS, but really don't want to bother with CMS in the system? One way or another you're sure to get complaints... > This CMS configuration, IMO, should have the greatest number of > potential users and, for this reason, should receive a greater > contribution from a greater community. That is an interesting opinion, and it's great that you have been looking into this. Could you share what you have based this opinion on, it might be enlightening to others too. > This configuration is also what we would need to run the OFBiz web > site itself (if we are still interested in getting this up and > running). > > Of course, as you say, there are some things in the selected > components (framework, party, content, commonext) that are not > required. These parts are, for sure, the ones that do not let the > database to be even created because depends on other components. There > are entities that should be moved away from party as the complete > org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other > that should be extended in other components. Again, that's based on your designs which are based on requirements you haven't shared yet. > So coming to your question: "what should we change in how we're doing things?" > May be nothing. Just discuss/agree on the requirements for the > framework-only and then start working on a branch. That sounds like a change to me... One way or another if we're moving things around, especially moving higher level stuff into the framework, then we should definitely discuss it first and even try to reach a consensus around it. For example, one specific idea might be to move some of the email stuff from content to the framework somewhere. Sending and receiving emails is pretty low-level, though that doesn't mean we'd want to move all of it as the CommunicationEvent stuff is definitely higher level and ties to many many other things in the system, and that's a much harder line to draw. For the most part the dividing line between framework and the base applications is that business-driven things stay in the apps, and technical facilitation and interfacing lives in the framework. If we want to change that, it would be a big change, and you can certainly expect some disagreement. On the other hand, you can certainly work on decoupling in the base applications in order to isolate the parts that you want to. They'll stay in the applications directory, but you can certainly make changes to make things run fine in spite of deleting or disabling other components. -David > 2010/1/2 David E Jones <d...@me.com>: >> >> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote: >> >>>> One major question is whether framework, on its own, should even be >>>> runnable as an application. In my opinion, it is a library, not an app >>>> and doesn't need to be operational on its own. >>> >>> The more we discuss about this the more I get convinced that what we >>> (or at least me) intend for framework-only distribution should be >>> better named "OFBiz-core". >>> The OFBiz-core could consist of framework + party + content + commonext. >>> >>> A distribution with these components set up is somewhat similar to >>> what I mean for a framework where developer can start building its >>> office automation application without the necessity to disable >>> anything but having all the power of the framework and the "core" >>> applications. >> >> Your "at least me" comment is right on. Consider that what you want, at >> least right now, is framework + party + content + commonext. Do you think >> that will be the same for your next project? Do you think that this is the >> same for a majority of current and prospective users of OFBiz? >> >> I'd be willing to bet a good deal of money that this level of granularity is >> not adequate to describe what you actually need/want, and that within each >> of the parts you listed (framework, party, content, commonext) there are >> dozens or hundreds of more specific things that you either want or don't >> want. >> >> Now consider that with many thousands of such things that will be wanted or >> not wanted, there are an incredible number of combinations of these things. >> Each combination is a potential "core" packaging of OFBiz. >> >> So, the question is what will be of most use to the largest number of users? >> That question a good guiding thought, and because of the community nature of >> this project it will of course be tempered by what contributors (committers >> or not) actually decide is important to them. >> >> Based on that, what should we change in how we're doing things? >> >> -David >> >>
