Re: POM relocation to an other version number is not fully supported in Gradle

[Taher Alkhateeb]

I think we can safely ignore. If a problem arises we hardwire the
dependency, so not a big deal at all

On Fri, Sep 21, 2018, 6:15 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hi Jacques
>
> It looks like every transitive dependency defined in our build.gradle to
> xml-apis is getting resolved to xml-apis:2.0.2.
>
> +--- xom:xom:1.2.5
>
> ||+--- xml-apis:xml-apis:1.3.03 -> 2.0.2
>
> +--- xml-apis:xml-apis:1.3.04 -> 2.0.2
>
> org.apache.xmlrpc:xmlrpc-client:3.1.3
>
> |\--- org.apache.xmlrpc:xmlrpc-common:3.1.3
>
> | \--- org.apache.ws.commons.util:ws-commons-util:1.0.2
>
> |  +--- junit:junit:3.8.1 -> 4.11 (*)
>
> |  \--- xml-apis:xml-apis:1.0.b2 -> 2.0.2
>
> Apparently, this has been occurring since earlier gradle versions as well
> and no support yet.
>
> Does the build fail due to this? If it is just a warning, then may be we
> can live with it. And if there is a hard dependency on it, then may be we
> should try forcing the version as shown in the SOF link you sent.
>
> While I do not have any particular opinion on this, may be others can weigh
> in and take a call as to what should be done.
>
> Best,
> Girish
> HotWax Systems
>
>
> On Fri, Sep 21, 2018 at 5:28 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Le 21/09/2018 à 13:29, Jacques Le Roux a écrit :
> > > Hi,
> > >
> > > I cleared by Gradle cache, so had to reload all.
> > my
> >
> > >
> > > I stumbled upon this is in log
> > >
> > >Download
> > https://jcenter.bintray.com/xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
> > >POM relocation to an other version number is not fully supported in
> > Gradle : xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2.
> > >Please update your dependency to directly use the correct version
> > 'xml-apis:xml-apis:1.0.b2'.
> > >
> > > xml-apis-2.0.2 is not a dependency we define in build.gradle.
> > >
> > > We could use this trick
> >
> https://stackoverflow.com/questions/22613596/gradle-download-dependency-error
> > >
> > > But should we or should we simply neglect and wait it resolves by
> itself?
> > >
> > > Jacques
> > >
> > >
> >
> >
>

Re: POM relocation to an other version number is not fully supported in Gradle

[Girish Vasmatkar]

Hi Jacques

It looks like every transitive dependency defined in our build.gradle to
xml-apis is getting resolved to xml-apis:2.0.2.

+--- xom:xom:1.2.5

||+--- xml-apis:xml-apis:1.3.03 -> 2.0.2

+--- xml-apis:xml-apis:1.3.04 -> 2.0.2

org.apache.xmlrpc:xmlrpc-client:3.1.3

|\--- org.apache.xmlrpc:xmlrpc-common:3.1.3

| \--- org.apache.ws.commons.util:ws-commons-util:1.0.2

|  +--- junit:junit:3.8.1 -> 4.11 (*)

|  \--- xml-apis:xml-apis:1.0.b2 -> 2.0.2

Apparently, this has been occurring since earlier gradle versions as well
and no support yet.

Does the build fail due to this? If it is just a warning, then may be we
can live with it. And if there is a hard dependency on it, then may be we
should try forcing the version as shown in the SOF link you sent.

While I do not have any particular opinion on this, may be others can weigh
in and take a call as to what should be done.

Best,
Girish
HotWax Systems


On Fri, Sep 21, 2018 at 5:28 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 21/09/2018 à 13:29, Jacques Le Roux a écrit :
> > Hi,
> >
> > I cleared by Gradle cache, so had to reload all.
> my
>
> >
> > I stumbled upon this is in log
> >
> >Download
> https://jcenter.bintray.com/xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
> >POM relocation to an other version number is not fully supported in
> Gradle : xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2.
> >Please update your dependency to directly use the correct version
> 'xml-apis:xml-apis:1.0.b2'.
> >
> > xml-apis-2.0.2 is not a dependency we define in build.gradle.
> >
> > We could use this trick
> https://stackoverflow.com/questions/22613596/gradle-download-dependency-error
> >
> > But should we or should we simply neglect and wait it resolves by itself?
> >
> > Jacques
> >
> >
>
>

[VOTE] [RELEASE] Apache OFBiz 16.11.05

[Jacopo Cappellato]

 This is the vote thread to release a new bug fix release for the
release16.11 branch. This new release, "Apache OFBiz 16.11.05" will
supersede all the previous releases from the same branch.

The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-16.11.05.zip
* KEYS: text file with keys
* apache-ofbiz-16.11.05.zip.asc: the detached signature file
* apache-ofbiz-16.11.05.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 16.11.05
[ -1] do not release

This vote will be open for at least 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

Kind Regards,

Jacopo

Re: Preparing the new release 16.11.05

[Jacopo Cappellato]

No feedback so far; I will proceed with the release preparation.

Jacopo

On Mon, Sep 17, 2018 at 11:09 AM Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> I am ready to prepare the release files and start a vote but before I do I
> would like to double check about OFBIZ-4361: if people think that it should
> be considered blocker then we could disable the link/feature in the release
> branch and proceed with the release process; when we will have a
> stable/tested/agreed upon refactoring of this "reset password" feature we
> could re-enable the link.
>
> Jacopo
>
> On Fri, Sep 14, 2018 at 11:48 AM Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
>> I don't think this issue is a blocker for a new release, nor does it
>> necessarily warrant a release just for that. It can just be part of a
>> batch
>> as usual.
>>
>> On Fri, Sep 14, 2018, 12:09 PM Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> wrote:
>>
>> > On Mon, Sep 10, 2018 at 2:47 PM Pierre Smits 
>> > wrote:
>> >
>> > > Should OFBIZ-4361 not get resolved for this?
>> >
>> >
>> > It makes sense, thank you.
>> > I have posted a comment in the ticket and hopefully we will come up
>> with a
>> > quick resolution.
>> > Should we wait a few more days to see if we can commit and test that
>> work
>> > before we start the release voting process? However I wouldn't delay the
>> > release preparation more than a few days and I would rather issue this
>> > release and then issue another one in a few weeks.
>> >
>> > Regards,
>> >
>> > Jacopo
>> >
>>
>

Re: Component and Component Set Dependencies

[Jacques Le Roux]

Hi Pierre,

Could you please clarify why we still need to keep these comment now that the 
dependencies are in the graph.

Notably the comment you made

   This diagram is missing:

 * a dependency of Accounting on Manufacturing,

would be interesting if there was an explanation of the exact dependency from Accounting on Manufacturing. If it's not data dependencies, which are 
now resolved for applications.


For order on accounting code dependency, I believe it's impossible to remove. Those need to be interconnected (eg when you send an order you need to 
create an invoice).


Thanks

Jacques


Le 08/09/2018 à 11:20, Pierre Smits a écrit :

It would be better to let the comments stay until all undesirable
dependencies are removed and ticket OFBIZ-3500 has been closed.


Best regards,

Pierre Smits

Apache Trafodion , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Sat, Sep 8, 2018 at 11:15 AM, Deepak Dixit 
wrote:


Hi Jacques,

I think we are good and can delete the comments.

Thanks & Regards
--
Deepak Dixit


On Mon, Aug 20, 2018 at 12:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Great, thanks Deepak

Jacques


Le 20/08/2018 à 06:20, Deepak Dixit a écrit :


Hi Jacques,

I'll check and share details ASAP.

On Sun, Aug 19, 2018 at 3:57 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com >
wrote:

 Hi Deepak,

 Before I remove all the comments at https://cwiki.apache.org/confl
uence/display/OFBIZ/Component+and+Component+Set+Dependencies
  and remove in the graph the dependency
from the
 accounting to workeffort introduced by r1710178 ;
 

 could you please confirm there is no longer data dependencies from
accounting to workeffort since we moved the data to

applications/datamodel?

 I guess there should not be and we should try to clean this graph

for

maybe other such dependencies (only because of data) now that this step

is

 almost complete (after Rishi's future effort on "Shipping data
duplicated
 " thread)

 Thanks

 Jacques

Re: POM relocation to an other version number is not fully supported in Gradle

[Jacques Le Roux]

Le 21/09/2018 à 13:29, Jacques Le Roux a écrit :

Hi,

I cleared by Gradle cache, so had to reload all.

my



I stumbled upon this is in log

   Download 
https://jcenter.bintray.com/xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
   POM relocation to an other version number is not fully supported in Gradle : 
xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2.
   Please update your dependency to directly use the correct version 
'xml-apis:xml-apis:1.0.b2'.

xml-apis-2.0.2 is not a dependency we define in build.gradle.

We could use this trick 
https://stackoverflow.com/questions/22613596/gradle-download-dependency-error

But should we or should we simply neglect and wait it resolves by itself?

Jacques

POM relocation to an other version number is not fully supported in Gradle

[Jacques Le Roux]

Hi,

I cleared by Gradle cache, so had to reload all.

I stumbled upon this is in log

   Download 
https://jcenter.bintray.com/xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
   POM relocation to an other version number is not fully supported in Gradle : 
xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2.
   Please update your dependency to directly use the correct version 
'xml-apis:xml-apis:1.0.b2'.

xml-apis-2.0.2 is not a dependency we define in build.gradle.

We could use this trick 
https://stackoverflow.com/questions/22613596/gradle-download-dependency-error

But should we or should we simply neglect and wait it resolves by itself?

Jacques

Re: Move SecurityPermission, SecurityGroup and SecurityGroupPermission Data to seed data files

[Deepak Nigam]

Thank you all for your inputs.

*Conclusions*: 1) All the 'SecurityPermission' data should be in the seed
data files.
   2) All the 'SecurityGroup' and
'SecurityGroupPermission' data should be in the demo data files.

Apart from this, the 'SecurityGroup' and 'SecurityGroupPermission' data for
the groupId 'super' should remain the seed data files. I will upload the
patch in the ticket soon.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.




On Fri, Sep 21, 2018 at 2:06 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> +1
>
> Jacques
>
>
> Le 21/09/2018 à 07:49, Arun Patidar a écrit :
> > Deepak,
> >
> > IMO,  'SecurityPermission' data should always be part of seed data. but
> > SecurityGroup and SecurityGroupPermission like a sample data so should be
> > part of demo data.
> >
> >
> >
> >
> > Kind Regards,
> >
> > Arun Patidar
> > Director of Information Systems
> >
> > *HotWax CommerceReal OmniChannel. Real Results.*
> > m: +91 9827353082
> > w: www.hotwax.co
> >
> >   
> > 
> > 
> >
> >
> >
> > On Fri, Sep 21, 2018 at 9:59 AM Deepak Nigam  >
> > wrote:
> >
> >> Hello All,
> >>
> >> Currently, SecurityPermission, SecurityGroup and SecurityGroupPermission
> >> data are mixed in demo and seed data files. Shouldn't these all data be
> >> part of seed data files only?
> >>
> >> Most of the SecurityPermission data is already part of seed data except
> the
> >> files HumanresDemoData.xml and SecurityGroupDemoData.xml files, but
> there
> >> is not any fixed pattern for the SecurityGroup and
> >> SecurityGroupPermissionData.
> >>
> >> A Jira ticket OFBIZ-10575
> >>  is available for
> the
> >> same.
> >>
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Nigam
> >> HotWax Systems Pvt. Ltd.
> >>
>
>

Re: Move SecurityPermission, SecurityGroup and SecurityGroupPermission Data to seed data files

[Jacques Le Roux]

+1

Jacques


Le 21/09/2018 à 07:49, Arun Patidar a écrit :

Deepak,

IMO,  'SecurityPermission' data should always be part of seed data. but
SecurityGroup and SecurityGroupPermission like a sample data so should be
part of demo data.




Kind Regards,

Arun Patidar
Director of Information Systems

*HotWax CommerceReal OmniChannel. Real Results.*
m: +91 9827353082
w: www.hotwax.co

  





On Fri, Sep 21, 2018 at 9:59 AM Deepak Nigam 
wrote:


Hello All,

Currently, SecurityPermission, SecurityGroup and SecurityGroupPermission
data are mixed in demo and seed data files. Shouldn't these all data be
part of seed data files only?

Most of the SecurityPermission data is already part of seed data except the
files HumanresDemoData.xml and SecurityGroupDemoData.xml files, but there
is not any fixed pattern for the SecurityGroup and
SecurityGroupPermissionData.

A Jira ticket OFBIZ-10575
 is available for the
same.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

Re: ProductFacility creation on 'Receive Inventory'

[Swapnil Mane]

Hi folks,

Thanks for the detailed discussion.

ProductFacility is required in OFBiz for various processes like inventory
reservation, inventory valuation etc.
If we make ProductFacility optional, then we need code changes in these
workflows and also make sure they are tested properly.

A 'quick route' could be if ProductFacility record doesn't exist and the
user wants to receive the product in that facility.
Prompt user about this "Product is not associate with this facility, do you
still want to receive it?"

If the user select, 'Yes' then create the ProductFacility record and
receive the product else don't receive the product.


- Best Regards,
Swapnil M Mane
Hotwax Systems 

On Thu, Sep 20, 2018 at 2:18 PM Vaibhav Jain 
wrote:

> Hello Deepak,
> IMO, It should be configurable that either *ProductFacility* is required or
> not. But we need to think on the respective points to proceed further
>
> If ProductFacility is required then
>
>1. The user needs to create a ProductFacility record before receiving
>inventory Or
>2. Silently system can create a ProductFacility record for the specific
>one
>
> If ProductFacility is not required then need to check the following
> workflows
>
>1. How to show the inventory of the product which is not associate with
>the respective facility
>2. How inventory reservation will work? as of now, the reservation does
>not handle this type of inventory.
>3. How inventory valuation entertain this inventory? As of now, the
>inventory valuation does not handle this type of inventory.
>4. Do we need any other workflow to manage this type of inventory?
>
> Thanks & Regards
> Vaibhav Jain
> Sr. Enterprise Software Engineer
> HotWax Systems
> m: 782-834-1900 e: vaibhav.j...@hotwaxsystems.com
>
>
> On Wed, Sep 19, 2018 at 11:28 PM Scott Gray 
> wrote:
>
> > Sounds like there are 3 options available:
> > 1. Improve any view/report screens to not rely on ProductFacility but
> > instead report on what is actually in the warehouse via InventoryItem.
> > 2. Require ProductFacility but silently create it when it is absent
> > 3. Require ProductFacility and reject receipt of products when it is
> absent
> >
> > My first thought is that if ProductFacility were truly required then we
> > would have a foreign key constraint on InventoryItem to prevent them from
> > being created.  So I'm guessing the original intent wasn't to require a
> > ProductFacility record.
> >
> > IMO we should first look to improving the view/report screens to not
> > require ProductFacility, if that is not possible or overly complicated
> then
> > we could look at requiring ProductFacility.  If we wanted to require
> > ProductFacility in order to enforce business rules, then that should
> > probably be configurable.
> >
> > Regards
> > Scott
> >
> > On 19 September 2018 at 10:49, Deepak Nigam 
> > wrote:
> >
> > > Thanks, Suraj.
> > >
> > > @All, as per the suggestions provided in the Jira ticket, should we
> > > restrict the receiving of non-associated products and simply return an
> > > error message? WDYT?
> > >
> > > On Wed, Sep 19, 2018 at 2:45 PM Suraj Khurana <
> > > suraj.khur...@hotwaxsystems.com> wrote:
> > >
> > > > Hello Deepak,
> > > >
> > > > Please have a look.
> > > > https://issues.apache.org/jira/browse/OFBIZ-7481
> > > >
> > > > HTH.
> > > >
> > > > --
> > > > Thanks and Regards,
> > > > Suraj Khurana
> > > > Omnichannel OMS Technical Expert
> > > > HotWax Systems
> > > >
> > > >
> > > >
> > > > On Wed, Sep 19, 2018 at 2:38 PM, deepak nigam <
> > > deepak.nigam1...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello All,
> > > > >
> > > > > We can directly receive inventory of a product into a facility by
> > using
> > > > the
> > > > > option 'Facility' -> 'Receive Inventory'. Here we can select a
> > product
> > > > for
> > > > > receiving which is not associated with the receiving facility (e.g.
> > > > product
> > > > > -> Purple Gizmo GZ-5005, facility -> WebS Store Warehouse).
> > > > >
> > > > > After a successful receive also, the product is not getting
> > associated
> > > > with
> > > > > the facility. Due to this, we can't find the newly received product
> > > under
> > > > > the 'Inventory' section of the facility. Should the product be
> > > associated
> > > > > with the facility after receiving?
> > > > >
> > > > >
> > > > >
> > > > > Thanks & Regards
> > > > > --
> > > > > Deepak Nigam
> > > > >
> > > >
> > >
> >
>

Re: Move SecurityPermission, SecurityGroup and SecurityGroupPermission Data to seed data files

[Vaibhav Jain]

+1 Arun
Vaibhav Jain
Sr. Enterprise Software Engineer
HotWax Systems
m: 782-834-1900 e: vaibhav.j...@hotwaxsystems.com


On Fri, Sep 21, 2018 at 1:13 PM Rishi Solanki 
wrote:

> +1 for Arun's thought on considering SecurityPermission as seed and
> SecurityGroup and SecurityGroupPermission as demo.
>
> --
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
> www.hotwax.co
>
>
> On Fri, Sep 21, 2018 at 12:53 PM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
>
> > +1
> >
> > Le vendredi 21 sept. 2018 à 11:19:39 (+0530), Arun Patidar a écrit :
> > > Deepak,
> > >
> > > IMO,  'SecurityPermission' data should always be part of seed data. but
> > > SecurityGroup and SecurityGroupPermission like a sample data so should
> be
> > > part of demo data.
> > >
> > >
> > >
> > >
> > > Kind Regards,
> > >
> > > Arun Patidar
> > > Director of Information Systems
> > >
> > > *HotWax CommerceReal OmniChannel. Real Results.*
> > > m: +91 9827353082
> > > w: www.hotwax.co
> > >
> > >  
> > > 
> > > 
> > >
> > >
> > >
> > > On Fri, Sep 21, 2018 at 9:59 AM Deepak Nigam <
> deepak.nigam1...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hello All,
> > > >
> > > > Currently, SecurityPermission, SecurityGroup and
> > SecurityGroupPermission
> > > > data are mixed in demo and seed data files. Shouldn't these all data
> be
> > > > part of seed data files only?
> > > >
> > > > Most of the SecurityPermission data is already part of seed data
> > except the
> > > > files HumanresDemoData.xml and SecurityGroupDemoData.xml files, but
> > there
> > > > is not any fixed pattern for the SecurityGroup and
> > > > SecurityGroupPermissionData.
> > > >
> > > > A Jira ticket OFBIZ-10575
> > > >  is available for
> > the
> > > > same.
> > > >
> > > >
> > > > Thanks & Regards
> > > > --
> > > > Deepak Nigam
> > > > HotWax Systems Pvt. Ltd.
> > > >
> >
>

Re: Move SecurityPermission, SecurityGroup and SecurityGroupPermission Data to seed data files

[Rishi Solanki]

+1 for Arun's thought on considering SecurityPermission as seed and
SecurityGroup and SecurityGroupPermission as demo.

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Fri, Sep 21, 2018 at 12:53 PM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> +1
>
> Le vendredi 21 sept. 2018 à 11:19:39 (+0530), Arun Patidar a écrit :
> > Deepak,
> >
> > IMO,  'SecurityPermission' data should always be part of seed data. but
> > SecurityGroup and SecurityGroupPermission like a sample data so should be
> > part of demo data.
> >
> >
> >
> >
> > Kind Regards,
> >
> > Arun Patidar
> > Director of Information Systems
> >
> > *HotWax CommerceReal OmniChannel. Real Results.*
> > m: +91 9827353082
> > w: www.hotwax.co
> >
> >  
> > 
> > 
> >
> >
> >
> > On Fri, Sep 21, 2018 at 9:59 AM Deepak Nigam  >
> > wrote:
> >
> > > Hello All,
> > >
> > > Currently, SecurityPermission, SecurityGroup and
> SecurityGroupPermission
> > > data are mixed in demo and seed data files. Shouldn't these all data be
> > > part of seed data files only?
> > >
> > > Most of the SecurityPermission data is already part of seed data
> except the
> > > files HumanresDemoData.xml and SecurityGroupDemoData.xml files, but
> there
> > > is not any fixed pattern for the SecurityGroup and
> > > SecurityGroupPermissionData.
> > >
> > > A Jira ticket OFBIZ-10575
> > >  is available for
> the
> > > same.
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Nigam
> > > HotWax Systems Pvt. Ltd.
> > >
>

Re: Move SecurityPermission, SecurityGroup and SecurityGroupPermission Data to seed data files

[Gil Portenseigne]

+1

Le vendredi 21 sept. 2018 à 11:19:39 (+0530), Arun Patidar a écrit :
> Deepak,
> 
> IMO,  'SecurityPermission' data should always be part of seed data. but
> SecurityGroup and SecurityGroupPermission like a sample data so should be
> part of demo data.
> 
> 
> 
> 
> Kind Regards,
> 
> Arun Patidar
> Director of Information Systems
> 
> *HotWax CommerceReal OmniChannel. Real Results.*
> m: +91 9827353082
> w: www.hotwax.co
> 
>  
> 
> 
> 
> 
> 
> On Fri, Sep 21, 2018 at 9:59 AM Deepak Nigam 
> wrote:
> 
> > Hello All,
> >
> > Currently, SecurityPermission, SecurityGroup and SecurityGroupPermission
> > data are mixed in demo and seed data files. Shouldn't these all data be
> > part of seed data files only?
> >
> > Most of the SecurityPermission data is already part of seed data except the
> > files HumanresDemoData.xml and SecurityGroupDemoData.xml files, but there
> > is not any fixed pattern for the SecurityGroup and
> > SecurityGroupPermissionData.
> >
> > A Jira ticket OFBIZ-10575
> >  is available for the
> > same.
> >
> >
> > Thanks & Regards
> > --
> > Deepak Nigam
> > HotWax Systems Pvt. Ltd.
> >