You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Hansen Wang <ha...@gemmall.com> on 2008/03/08 02:01:41 UTC

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.

Re: component dependency

Posted by Hansen Wang <ha...@gemmall.com>.
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 <sk...@thedevers.org> 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:nmervaillie@gmail.com]
> Sent: Sunday, March 09, 2008 10:47 AM
> To: user@ofbiz.apache.org
> 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 <ry...@sourcelabs.com>:
> >
> > 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
>
>

RE: component dependency

Posted by "skip@thedevers" <sk...@thedevers.org>.
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:nmervaillie@gmail.com]
Sent: Sunday, March 09, 2008 10:47 AM
To: user@ofbiz.apache.org
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 <ry...@sourcelabs.com>:
>
> 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


Re: component dependency

Posted by Nicolas Mervaillie <nm...@gmail.com>.
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 <ry...@sourcelabs.com>:
>
> 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
>
>
>

Re: component dependency

Posted by Ryan Sweet <ry...@sourcelabs.com>.
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