We can probably start with something simple: add an ant task that simply builds the framework (applications and specialpurpose will be ignored) and then an ant task to run the framework only. This will require some minor tweaks to the base component loading mechanism, but it should be trivial. Right now the only way (I am aware of) of building a framework only distro is to remove (or similar) the application and specialpurpose folders.
Jacopo On Feb 6, 2010, at 9:09 AM, Adrian Crum wrote: > A tool would certainly help. If such a tool was included in OFBiz, then it > would have to be compatible with the Apache license. > > -Adrian > > --- On Sat, 2/6/10, Chris Snow <[email protected]> wrote: > >> From: Chris Snow <[email protected]> >> Subject: Re: what a mess! is framework independence ever going to be >> possible? >> To: [email protected] >> Date: Saturday, February 6, 2010, 12:02 AM >> Thanks for the feedback Adrian. >> Would it be worth me writing a tool that >> runs as part of the build process that reports on the >> dependencies? It >> could throw a warning/error when a new invalid dependency >> is checked in? >> >>> Chris, >>> >>> Framework independence has been a goal for quite a >> while. There is no >>> disagreement that the framework should run on its own. >> The disagreements >>> arise in what constitutes the framework. >>> >>> Let's assume for a moment that framework independence >> means running the >>> components in the framework folder independently from >> anything else in >>> OFBiz. Right away the problem with that idea is that >> visual themes are in >>> a separate folder outside the framework folder. Does >> framework >>> independence include the visual themes folder? That >> has not been >>> discussed. Then there are the multitude of >> dependencies upon the >>> applications folder. >>> >>> From my perspective, achieving this objective will >> require a two pronged >>> approach: 1) Identify the framework dependencies on >> outside components, >>> and 2) avoid introducing new framework dependencies on >> outside components. >>> >>> The first prong can be accomplished through >> contributions from people like >>> you - find the dependencies and create patches to fix >> them. >>> >>> The responsibility of the second prong is up to the >> committers. We need to >>> be more vigilant to guard against introducing new >> dependencies. >>> >>> Personally I believe it will be possible, BUT it won't >> be easy. The >>> obstacles to overcome will be getting people to >> contribute to the effort, >>> and getting committers to avoid introducing new >> dependencies. >>> >>> -Adrian >>> >>> >>> --- On Fri, 2/5/10, Christopher Snow <[email protected]> >> wrote: >>> >>>> From: Christopher Snow <[email protected]> >>>> Subject: what a mess! is framework independence >> ever going to be >>>> possible? >>>> To: [email protected] >>>> Date: Friday, February 5, 2010, 10:58 PM >>>> I'm back to the process of working >>>> out how to get a standalone framework running >> based on >>>> trunk, but I have found that the dependencies have >> got out >>>> of hand (if I've understood the code right): >>>> >>>> Framework depends on Themes >>>> Themes depends on Content >>>> Content depends on Party >>>> >>>> The questions I'm starting to ask myself are: >>>> >>>> "Is is ever going to be possible to have >> framework >>>> independence in trunk? Independence in 9.04 is >>>> relatively trivial (rewrite security screens) >> perhaps the >>>> most sensible thing would be to do a fork of 9.04 >> and then >>>> back port all framework related commits from >> trunk? " >>>> >>>> Any ideas anyone? >>>> >>>> Many thanks, >>>> >>>> Chris >>>> >>> >>> >>> >>> >> >> >> -- >> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP >> >> Tel: 01453 890660 >> Mob: 07944 880950 >> Www: www.snowconsulting.co.uk >> >> > > >
