OFBiz › OFBiz - User

component dependency

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Hansen

component dependency

I am looking for information regarding the inter-dependency among all ofbiz
components. I fount that the ofbiz-component.xsd define a depends-on element
but it never be used in any of the ofbiz-component.xml.

Is there any effective way to know this kind of information. So that I can
safely remove those components I do not want without affecting the
functionalities of the other compoents that I want to keep.

Thanks in advance. Any infomraiton or pointer is appreciated.

ryan-116

Re: component dependency

Hansen Wang wrote:
> I am looking for information regarding the inter-dependency among all ofbiz
> components. I fount that the ofbiz-component.xsd define a depends-on element
> but it never be used in any of the ofbiz-component.xml.
>
> Is there any effective way to know this kind of information. So that I can
> safely remove those components I do not want without affecting the
> functionalities of the other compoents that I want to keep.
>

Hi Hansen,

I am new to Ofbiz, so take my advice with some caution, but my thoughts
would be as follows:

* study the entity reference (webtools->Entity Reference)
* look at the servicedefs, as many of the services call other services
* look at the service-eca entries, as these hook various points of
service invocation
* the best way to disable access to components you don't need/want would
be to disable any exported services that you won't be using (in the
servicedef set "export=false") and then customise the webapps/widgets to
remove functionality you don't want (edit controller.xml,
ofbiz-component.xml, .ftl files, widget xml files). Ideally you want to
keep your customisations in copies of the apps in the hot-deploy
directory, that way you can update the upstream code without overwriting
your changes.

Hopefully more experienced ofbiz users will correct anything I've got
wrong above.

-ryan

Nicolas Mervaillie-2

Re: component dependency

Hi,

May be you can also check the build.xml files. Don't know how accurante it
is but can help.
Disabling components is difficult because there are a lot of
inter-dependencies.
If you try to disable browser access on the applications, you can use roles
or disable the webapps in by commenting out <webapp> entries in
component.xml files.

Nicolas

2008/3/8, Ryan Sweet <[hidden email]>:

>
> Hansen Wang wrote:
> > I am looking for information regarding the inter-dependency among all
> ofbiz
> > components. I fount that the ofbiz-component.xsd define a depends-on
> element
> > but it never be used in any of the ofbiz-component.xml.
> >
> > Is there any effective way to know this kind of information. So that I
> can
> > safely remove those components I do not want without affecting the
> > functionalities of the other compoents that I want to keep.
> >
>
>
> Hi Hansen,
>
> I am new to Ofbiz, so take my advice with some caution, but my thoughts
> would be as follows:
>
> * study the entity reference (webtools->Entity Reference)
> * look at the servicedefs, as many of the services call other services
> * look at the service-eca entries, as these hook various points of
> service invocation
> * the best way to disable access to components you don't need/want would
> be to disable any exported services that you won't be using (in the
> servicedef set "export=false") and then customise the webapps/widgets to
> remove functionality you don't want (edit controller.xml,
> ofbiz-component.xml, .ftl files, widget xml files). Ideally you want to
> keep your customisations in copies of the apps in the hot-deploy
> directory, that way you can update the upstream code without overwriting
> your changes.
>
> Hopefully more experienced ofbiz users will correct anything I've got
> wrong above.
>
>
> -ryan
>
>
>

SkipDever

RE: component dependency

It is not at all difficult disabling dependencies. I recently used just the
party manager in a project and deleted all the rest. Took a couple of days
replacing / commenting out the dependencies, but it was certainly not hard.

Just delete the applications you dont want and get to work.

Skip

-----Original Message-----
From: Nicolas Mervaillie [mailto:[hidden email]]
Sent: Sunday, March 09, 2008 10:47 AM
To: [hidden email]
Subject: Re: component dependency

Hi,

May be you can also check the build.xml files. Don't know how accurante it
is but can help.
Disabling components is difficult because there are a lot of
inter-dependencies.
If you try to disable browser access on the applications, you can use roles
or disable the webapps in by commenting out <webapp> entries in
component.xml files.

Nicolas

2008/3/8, Ryan Sweet <[hidden email]>:

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.21.4/1313 - Release Date: 3/5/2008
9:50 AM

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.21.4/1313 - Release Date: 3/5/2008
9:50 AM

Hansen

Re: component dependency

It seems that to have a complete dependent list for a specific component,
one has to go through the build file for compile time dependency and the
service implementation codes (both xml and java) and other java codes for
runtime dependency.

It would be usuful to have such information (something like rpm dependency
list) handy especially for those application components as they are supposed
to be less dependent on other components comparing to framework components.

I must acknowledge that I do not have a strong use case for this. My
question was more triggered by when I encountered the "depends-on" element
of the component's definition files.

Thanks,
Hansen

On 3/9/08, skip@thedevers <[hidden email]> wrote:

>
> It is not at all difficult disabling dependencies. I recently used just
> the
> party manager in a project and deleted all the rest. Took a couple of
> days
> replacing / commenting out the dependencies, but it was certainly not
> hard.
>
> Just delete the applications you dont want and get to work.
>
> Skip
>
> -----Original Message-----
> From: Nicolas Mervaillie [mailto:[hidden email]]
> Sent: Sunday, March 09, 2008 10:47 AM
> To: [hidden email]
> Subject: Re: component dependency
>
>
> Hi,
>
> May be you can also check the build.xml files. Don't know how accurante it
> is but can help.
> Disabling components is difficult because there are a lot of
> inter-dependencies.
> If you try to disable browser access on the applications, you can use
> roles
> or disable the webapps in by commenting out <webapp> entries in
> component.xml files.
>
> Nicolas
>
> 2008/3/8, Ryan Sweet <[hidden email]>:
> >
> > Hansen Wang wrote:
> > > I am looking for information regarding the inter-dependency among all
> > ofbiz
> > > components. I fount that the ofbiz-component.xsd define a depends-on
> > element
> > > but it never be used in any of the ofbiz-component.xml.
> > >
> > > Is there any effective way to know this kind of information. So that I
> > can
> > > safely remove those components I do not want without affecting the
> > > functionalities of the other compoents that I want to keep.
> > >
> >
> >
> > Hi Hansen,
> >
> > I am new to Ofbiz, so take my advice with some caution, but my thoughts
> > would be as follows:
> >
> > * study the entity reference (webtools->Entity Reference)
> > * look at the servicedefs, as many of the services call other services
> > * look at the service-eca entries, as these hook various points of
> > service invocation
> > * the best way to disable access to components you don't need/want would
> > be to disable any exported services that you won't be using (in the
> > servicedef set "export=false") and then customise the webapps/widgets to
> > remove functionality you don't want (edit controller.xml,
> > ofbiz-component.xml, .ftl files, widget xml files). Ideally you want to
> > keep your customisations in copies of the apps in the hot-deploy
> > directory, that way you can update the upstream code without overwriting
> > your changes.
> >
> > Hopefully more experienced ofbiz users will correct anything I've got
> > wrong above.
> >
> >
> > -ryan
> >
> >
> >
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.21.4/1313 - Release Date: 3/5/2008
> 9:50 AM
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.21.4/1313 - Release Date: 3/5/2008
> 9:50 AM
>
>