date:20110127


Thanks Scott! We will keep that in mind.

-Adrian

On 1/27/2011 11:49 PM, Scott Gray wrote:

On 28/01/2011, at 8:37 PM, Adrian Crum wrote:


There is no doubt there will be problems. We can tackle them one at a time in a 
Jira issue.

I wasn't aware that entity-ext depends on the service engine. Maybe a Jira 
sub-task could break that dependency.

That's kind of the point of entity-ext, to supplement the entity engine with 
service engine capabilities.


I think the entityengine.xml file issue can be resolved through standard Java 
resource loader methods. In other words, applications will name their XML files 
according to a pre-defined format, and the entity-engine jar file will find and 
load all matching XML files. Just think of them as a resource file. Again - 
these details should be discussed further in a Jira issue.

-Adrian


On 1/27/2011 11:23 PM, Raj Saini wrote:

I tried to use the entity engine exactly the way you have described. I faced 
the problems as entity engine depends entity-ext (for some cache management) 
and entity-ext depends on service engine. If we resolve this dependency, entity 
engine can certainly be a standalone jar and as you said it can be packaged as 
OSGi bundle. We will also need to take care of entityengine.xml configuration 
so that it can be loaded from a pre-defined location instead of a classpath.

Raj

On Friday 28 January 2011 12:28 PM, Adrian Crum wrote:

I was picturing the entity engine as a lower level artifact - like a jar file. 
I don't have all of the details worked out yet, but what I picture is this:

1. An application needs a database-agnostic data store.
2. The application accesses the data store though the entity engine API/ jar 
library.

Ofbiz has a very convenient way of defining databases, tables, and views as XML 
files. Plus, it has the ability to create/modify table/index structures during 
start-up. I believe that would be a very handy tool for anyone wanting to 
create any application that requires data storage.

Wrapping the entity engine jar file in an OSGI bundle would be trivial.

If anyone is interested in exploring this further, then they should create a 
Jira issue and we can take it from there.

-Adrian

On 1/27/2011 10:21 PM, Raj Saini wrote:

I will certainly be glad to help in this. I had re-packaged the entity engine 
as and OSGi bundle and exposed the delegator as osgi service. I found minor 
issues like loading of entityengine.xml from classpath and this did not go well 
with the OSGi. Let us wait for the the restructuring of the OFBiz project.

Thanks,

Raj

On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:

Cool. If anyone is interested in working on that, I am available to help.

-Adrian

On 1/27/2011 9:23 PM, Raj Saini wrote:

Yes, I agree. Entity Engine and Service Engine are two such marvellous pieces 
of technologies. Entity engine can very well compete with Java Persistence API 
(JPA) if it is separated from the OFBiz runtime.

Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:

I have suggested that in the past. OFBiz has spawned some great technology 
that, if modified to be stand-alone subsystems, could be their own projects.

-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:

One thing I would like to see is to use the OSGi runtime for framework. This 
will help modularising efforts. For example entity engine, service engine, 
security etc. will be OSGi bundles running on top of OSGi framework such Apache 
Karaf. Apache ServiceMix is already using Karaf (http://karaf.apache.org). I 
did a prototype and embedded the OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.

Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the underlying
core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business processes and
users of the product. It is about security, and about a future proof and
reliable platform for developing applications on.

What do feel is important? What should be removed from the framework. what
should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up a plan for
comming releases.

Regards,

Pierre

Re: OFBiz: The road ahead RE Accounting

Following improvements I would like to see:


   - Better layout of reports
   - e-invoicing
   - import of e-invoices from suppliers
   - import of bank statements


2011/1/27 Pierre Smits 

> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the Accounting application. In order to draw up a plan
> for future releases we would like have your input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre Smits
>

Re: OFBiz: The road ahead RE the framework


Done.

https://issues.apache.org/jira/browse/OFBIZ-4153

Raj

On Friday 28 January 2011 01:07 PM, Adrian Crum wrote:
There is no doubt there will be problems. We can tackle them one at a 
time in a Jira issue.


I wasn't aware that entity-ext depends on the service engine. Maybe a 
Jira sub-task could break that dependency.


I think the entityengine.xml file issue can be resolved through 
standard Java resource loader methods. In other words, applications 
will name their XML files according to a pre-defined format, and the 
entity-engine jar file will find and load all matching XML files. Just 
think of them as a resource file. Again - these details should be 
discussed further in a Jira issue.


-Adrian


On 1/27/2011 11:23 PM, Raj Saini wrote:
I tried to use the entity engine exactly the way you have described. 
I faced the problems as entity engine depends entity-ext (for some 
cache management) and entity-ext depends on service engine. If we 
resolve this dependency, entity engine can certainly be a standalone 
jar and as you said it can be packaged as OSGi bundle. We will also 
need to take care of entityengine.xml configuration so that it can be 
loaded from a pre-defined location instead of a classpath.


Raj

On Friday 28 January 2011 12:28 PM, Adrian Crum wrote:
I was picturing the entity engine as a lower level artifact - like a 
jar file. I don't have all of the details worked out yet, but what I 
picture is this:


1. An application needs a database-agnostic data store.
2. The application accesses the data store though the entity engine 
API/ jar library.


Ofbiz has a very convenient way of defining databases, tables, and 
views as XML files. Plus, it has the ability to create/modify 
table/index structures during start-up. I believe that would be a 
very handy tool for anyone wanting to create any application that 
requires data storage.


Wrapping the entity engine jar file in an OSGI bundle would be trivial.

If anyone is interested in exploring this further, then they should 
create a Jira issue and we can take it from there.


-Adrian

On 1/27/2011 10:21 PM, Raj Saini wrote:
I will certainly be glad to help in this. I had re-packaged the 
entity engine as and OSGi bundle and exposed the delegator as osgi 
service. I found minor issues like loading of entityengine.xml from 
classpath and this did not go well with the OSGi. Let us wait for 
the the restructuring of the OFBiz project.


Thanks,

Raj

On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:
Cool. If anyone is interested in working on that, I am available 
to help.


-Adrian

On 1/27/2011 9:23 PM, Raj Saini wrote:
Yes, I agree. Entity Engine and Service Engine are two such 
marvellous pieces of technologies. Entity engine can very well 
compete with Java Persistence API (JPA) if it is separated from 
the OFBiz runtime.


Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could 
be their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example 
entity engine, service engine, security etc. will be OSGi 
bundles running on top of OSGi framework such Apache Karaf. 
Apache ServiceMix is already using Karaf 
(http://karaf.apache.org). I did a prototype and embedded the 
OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with 
the underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and
users of the product. It is about security, and about a future 
proof and

reliable platform for developing applications on.

What do feel is important? What should be removed from the 
framework. what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important 
regarding the
framework so that we (the community) can take stock and draw 
up a plan for

comming releases.

Regards,

Pierre

Re: OFBiz: The road ahead RE the framework

2011-01-27 Thread Scott Gray

On 28/01/2011, at 8:37 PM, Adrian Crum wrote:

> There is no doubt there will be problems. We can tackle them one at a time in 
> a Jira issue.
> 
> I wasn't aware that entity-ext depends on the service engine. Maybe a Jira 
> sub-task could break that dependency.

That's kind of the point of entity-ext, to supplement the entity engine with 
service engine capabilities.

> 
> I think the entityengine.xml file issue can be resolved through standard Java 
> resource loader methods. In other words, applications will name their XML 
> files according to a pre-defined format, and the entity-engine jar file will 
> find and load all matching XML files. Just think of them as a resource file. 
> Again - these details should be discussed further in a Jira issue.
> 
> -Adrian
> 
> 
> On 1/27/2011 11:23 PM, Raj Saini wrote:
>> I tried to use the entity engine exactly the way you have described. I faced 
>> the problems as entity engine depends entity-ext (for some cache management) 
>> and entity-ext depends on service engine. If we resolve this dependency, 
>> entity engine can certainly be a standalone jar and as you said it can be 
>> packaged as OSGi bundle. We will also need to take care of entityengine.xml 
>> configuration so that it can be loaded from a pre-defined location instead 
>> of a classpath.
>> 
>> Raj
>> 
>> On Friday 28 January 2011 12:28 PM, Adrian Crum wrote:
>>> I was picturing the entity engine as a lower level artifact - like a jar 
>>> file. I don't have all of the details worked out yet, but what I picture is 
>>> this:
>>> 
>>> 1. An application needs a database-agnostic data store.
>>> 2. The application accesses the data store though the entity engine API/ 
>>> jar library.
>>> 
>>> Ofbiz has a very convenient way of defining databases, tables, and views as 
>>> XML files. Plus, it has the ability to create/modify table/index structures 
>>> during start-up. I believe that would be a very handy tool for anyone 
>>> wanting to create any application that requires data storage.
>>> 
>>> Wrapping the entity engine jar file in an OSGI bundle would be trivial.
>>> 
>>> If anyone is interested in exploring this further, then they should create 
>>> a Jira issue and we can take it from there.
>>> 
>>> -Adrian
>>> 
>>> On 1/27/2011 10:21 PM, Raj Saini wrote:
 I will certainly be glad to help in this. I had re-packaged the entity 
 engine as and OSGi bundle and exposed the delegator as osgi service. I 
 found minor issues like loading of entityengine.xml from classpath and 
 this did not go well with the OSGi. Let us wait for the the restructuring 
 of the OFBiz project.
 
 Thanks,
 
 Raj
 
 On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:
> Cool. If anyone is interested in working on that, I am available to help.
> 
> -Adrian
> 
> On 1/27/2011 9:23 PM, Raj Saini wrote:
>> Yes, I agree. Entity Engine and Service Engine are two such marvellous 
>> pieces of technologies. Entity engine can very well compete with Java 
>> Persistence API (JPA) if it is separated from the OFBiz runtime.
>> 
>> Raj
>> 
>> On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
>>> I have suggested that in the past. OFBiz has spawned some great 
>>> technology that, if modified to be stand-alone subsystems, could be 
>>> their own projects.
>>> 
>>> -Adrian
>>> 
>>> On 1/27/2011 8:52 PM, Raj Saini wrote:
 One thing I would like to see is to use the OSGi runtime for 
 framework. This will help modularising efforts. For example entity 
 engine, service engine, security etc. will be OSGi bundles running on 
 top of OSGi framework such Apache Karaf. Apache ServiceMix is already 
 using Karaf (http://karaf.apache.org). I did a prototype and embedded 
 the OFBiz in OSGi runtime 
 (http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.
 
 Thanks,
 
 Raj
 
 On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:
> Hi All,
> 
> This thread is about where you want the community to go with the 
> underlying
> core components of OFBiz (aka the Framework).
> 
> The framework is the enables of all applications and business 
> processes and
> users of the product. It is about security, and about a future proof 
> and
> reliable platform for developing applications on.
> 
> What do feel is important? What should be removed from the framework. 
> what
> should be included? What can be enhanced? And what not?
> 
> Please let all of us know what you think is important regarding the
> framework so that we (the community) can take stock and draw up a 
> plan for
> comming releases.
> 
> Regards,
> 
> Pierre
>>>

Re: List Navigation issue in latest Ofbiz code

We are aware of this issue, and one or more Jira issues have been 
created for it.


Thank you for reporting it.

-Adrian

On 1/27/2011 11:40 PM, Pankaj Singh wrote:

Hi ,
List navigation is not working further in latest ofbiz setup.
Find the URL below and  click on the Find Button to render the list then try
to navigate the list or try to change the size of list which is broken.
*
https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=Product
*


Let us know if any one came across the same issue .

List Navigation issue in latest Ofbiz code

2011-01-27 Thread Pankaj Singh

Hi ,
List navigation is not working further in latest ofbiz setup.
Find the URL below and  click on the Find Button to render the list then try
to navigate the list or try to change the size of list which is broken.
*
https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=Product
*


Let us know if any one came across the same issue .

-- 
Thanks ,
Pankaj

Re: OFBiz: The road ahead RE the framework

There is no doubt there will be problems. We can tackle them one at a 
time in a Jira issue.


I wasn't aware that entity-ext depends on the service engine. Maybe a 
Jira sub-task could break that dependency.


I think the entityengine.xml file issue can be resolved through standard 
Java resource loader methods. In other words, applications will name 
their XML files according to a pre-defined format, and the entity-engine 
jar file will find and load all matching XML files. Just think of them 
as a resource file. Again - these details should be discussed further in 
a Jira issue.


-Adrian


On 1/27/2011 11:23 PM, Raj Saini wrote:
I tried to use the entity engine exactly the way you have described. I 
faced the problems as entity engine depends entity-ext (for some cache 
management) and entity-ext depends on service engine. If we resolve 
this dependency, entity engine can certainly be a standalone jar and 
as you said it can be packaged as OSGi bundle. We will also need to 
take care of entityengine.xml configuration so that it can be loaded 
from a pre-defined location instead of a classpath.


Raj

On Friday 28 January 2011 12:28 PM, Adrian Crum wrote:
I was picturing the entity engine as a lower level artifact - like a 
jar file. I don't have all of the details worked out yet, but what I 
picture is this:


1. An application needs a database-agnostic data store.
2. The application accesses the data store though the entity engine 
API/ jar library.


Ofbiz has a very convenient way of defining databases, tables, and 
views as XML files. Plus, it has the ability to create/modify 
table/index structures during start-up. I believe that would be a 
very handy tool for anyone wanting to create any application that 
requires data storage.


Wrapping the entity engine jar file in an OSGI bundle would be trivial.

If anyone is interested in exploring this further, then they should 
create a Jira issue and we can take it from there.


-Adrian

On 1/27/2011 10:21 PM, Raj Saini wrote:
I will certainly be glad to help in this. I had re-packaged the 
entity engine as and OSGi bundle and exposed the delegator as osgi 
service. I found minor issues like loading of entityengine.xml from 
classpath and this did not go well with the OSGi. Let us wait for 
the the restructuring of the OFBiz project.


Thanks,

Raj

On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:
Cool. If anyone is interested in working on that, I am available to 
help.


-Adrian

On 1/27/2011 9:23 PM, Raj Saini wrote:
Yes, I agree. Entity Engine and Service Engine are two such 
marvellous pieces of technologies. Entity engine can very well 
compete with Java Persistence API (JPA) if it is separated from 
the OFBiz runtime.


Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could 
be their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example 
entity engine, service engine, security etc. will be OSGi 
bundles running on top of OSGi framework such Apache Karaf. 
Apache ServiceMix is already using Karaf 
(http://karaf.apache.org). I did a prototype and embedded the 
OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with 
the underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and
users of the product. It is about security, and about a future 
proof and

reliable platform for developing applications on.

What do feel is important? What should be removed from the 
framework. what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding 
the
framework so that we (the community) can take stock and draw up 
a plan for

comming releases.

Regards,

Pierre

Re: OFBIZ: the road ahead RE Customer Relation Management

Regarding CRM I thing about following improvements


   - Being able to classify an account party as prospect or customer
   - Being able to associate an account party with a team (account team for
   large account with many sub accounts)
   - Being able to associate accounts to other accounts (main account and
   sub accounts)
   - From the account page show information about associated
   agreements/contracts, orders, projects, issues, etc
   - Integrate financial aspects of requests in opportunities
   - On the summary page of the account show an overview of what is in the
   pipeline (diagram?)
   - Integrate more with social network apps - so that Marketing and Account
   Managers have insight in what the accounts (and associated persons) do in
   social networks



2011/1/28 Pierre Smits 

> In my last message I said:
>
>
> *Please join us in this discussion about the Accounting application.*
>
>
> Of course, in the light of this topic, this should have been:
>
> *Please join us in this discussion about the CRM application(s).*
>
> My apologies for any inconveniences caused.
>
>
> Regards,
>
> Pierre
>
>
> 2011/1/27 Pierre Smits 
>
> Hi all,
>>
>> With the release of 10.04 we come to a point in time where we can think
>> about the future of the applications involved in Customer Releation
>> Management. The applications involved here are:
>>
>>- Marketing
>>- SFA
>>
>>
>> In order to draw up a plan for future releases we would like have your
>> input.
>>
>> What do you feel is important? What should be in, what should be removed,
>> what can be improved?
>>
>> Please join us in this discussion about the Accounting application.
>>
>> Regards,
>>
>> Pierre
>>
>
>

Re: OFBiz: The road ahead RE the framework

I tried to use the entity engine exactly the way you have described. I 
faced the problems as entity engine depends entity-ext (for some cache 
management) and entity-ext depends on service engine. If we resolve this 
dependency, entity engine can certainly be a standalone jar and as you 
said it can be packaged as OSGi bundle. We will also need to take care 
of entityengine.xml configuration so that it can be loaded from a 
pre-defined location instead of a classpath.


Raj

On Friday 28 January 2011 12:28 PM, Adrian Crum wrote:
I was picturing the entity engine as a lower level artifact - like a 
jar file. I don't have all of the details worked out yet, but what I 
picture is this:


1. An application needs a database-agnostic data store.
2. The application accesses the data store though the entity engine 
API/ jar library.


Ofbiz has a very convenient way of defining databases, tables, and 
views as XML files. Plus, it has the ability to create/modify 
table/index structures during start-up. I believe that would be a very 
handy tool for anyone wanting to create any application that requires 
data storage.


Wrapping the entity engine jar file in an OSGI bundle would be trivial.

If anyone is interested in exploring this further, then they should 
create a Jira issue and we can take it from there.


-Adrian

On 1/27/2011 10:21 PM, Raj Saini wrote:
I will certainly be glad to help in this. I had re-packaged the 
entity engine as and OSGi bundle and exposed the delegator as osgi 
service. I found minor issues like loading of entityengine.xml from 
classpath and this did not go well with the OSGi. Let us wait for the 
the restructuring of the OFBiz project.


Thanks,

Raj

On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:
Cool. If anyone is interested in working on that, I am available to 
help.


-Adrian

On 1/27/2011 9:23 PM, Raj Saini wrote:
Yes, I agree. Entity Engine and Service Engine are two such 
marvellous pieces of technologies. Entity engine can very well 
compete with Java Persistence API (JPA) if it is separated from the 
OFBiz runtime.


Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could 
be their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example 
entity engine, service engine, security etc. will be OSGi bundles 
running on top of OSGi framework such Apache Karaf. Apache 
ServiceMix is already using Karaf (http://karaf.apache.org). I 
did a prototype and embedded the OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the 
underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and
users of the product. It is about security, and about a future 
proof and

reliable platform for developing applications on.

What do feel is important? What should be removed from the 
framework. what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up 
a plan for

comming releases.

Regards,

Pierre

Re: OFBIZ: the road ahead RE Project Management

When thinking about improving the Project Management suite I think of
following improvements.


   - Ease up on the need to first add persons to resources. Employees should
   always be available for project teams.
   - More/better info on the project summary about the health of the project
   with regards being on time, on budget, and over. Maybe in the form of charts
   (est vs reality) or with smileys.
   - More/better info on the start page of the suite regarding the overall
   health of projects. See previous point
   - Moving time management outside of project mgt to a new app as time mgt
   also occurs in other places.
   - Be able to also do internal project management and FP/FT projects
   (which have a different accounting/billing aspect)

Regards,

Pierre

2011/1/28 Pierre Smits 

> In my last message I said:
>
>
> *Please join us in this discussion about the Accounting application.*
>
>
> Of course, in the light of this topic, this should have been:
>
> *Please join us in this discussion about the Project Management
> application(s).*
>
> My apologies for any inconveniences caused.
>
>
> Regards,
>
> Pierre
>
> 2011/1/27 Pierre Smits 
>
> Hi all,
>>
>> With the release of 10.04 we come to a point in time where we can think
>> about the future of the application(s) involved in Project Management.
>>
>> In order to draw up a plan for future releases we would like have your
>> input.
>>
>> What do you feel is important? What should be in, what should be removed,
>> what can be improved?
>>
>> Please join us in this discussion about the Accounting application.
>>
>> Regards,
>>
>> Pierre
>>
>
>

Re: OFBIZ: The road ahead RE Ecommerce

In my last message I said:


*Please join us in this discussion about the Accounting application.*


Of course, in the light of this topic, this should have been:

*Please join us in this discussion about the eCommerce application(s).*

My apologies for any inconveniences caused.


Regards,

Pierre

2011/1/27 Pierre Smits 

> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the ecommerce application. In order to draw up a plan
> for future releases we would like have your input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre
>

Re: OFBIZ: the road ahead RE Human Resources Management

In my last message I said:


*Please join us in this discussion about the Accounting application.*


Of course, in the light of this topic, this should have been:

*Please join us in this discussion about the HRM application(s).*

My apologies for any inconveniences caused.


Regards,

Pierre

2011/1/27 Pierre Smits 

> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the application(s) involved in Human Resources
> Management.
>
> In order to draw up a plan for future releases we would like have your
> input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre
>

Re: OFBIZ: the road ahead RE Supply Chain Management

In my last message I said:


*Please join us in this discussion about the Accounting application.*


Of course, in the light of this topic, this should have been:

*Please join us in this discussion about the SCM application(s).*

My apologies for any inconveniences caused.


Regards,

Pierre

2011/1/27 Pierre Smits 

> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the applications involved in Supply Chain Management.
> The applications involved here are:
>
>- Order
>- Catalog
>- Manufacturing
>
>
> In order to draw up a plan for future releases we would like have your
> input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre
>

Re: OFBIZ: the road ahead RE Project Management

In my last message I said:


*Please join us in this discussion about the Accounting application.*


Of course, in the light of this topic, this should have been:

*Please join us in this discussion about the Project Management
application(s).*

My apologies for any inconveniences caused.


Regards,

Pierre

2011/1/27 Pierre Smits 

> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the application(s) involved in Project Management.
>
> In order to draw up a plan for future releases we would like have your
> input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre
>

Re: OFBIZ: the road ahead RE Customer Relation Management

In my last message I said:


*Please join us in this discussion about the Accounting application.*

Of course, in the light of this topic, this should have been:

*Please join us in this discussion about the CRM application(s).*

My apologies for any inconveniences caused.


Regards,

Pierre


2011/1/27 Pierre Smits 

> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the applications involved in Customer Releation
> Management. The applications involved here are:
>
>- Marketing
>- SFA
>
>
> In order to draw up a plan for future releases we would like have your
> input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre
>

Re: OFBiz: The road ahead RE the framework

I was picturing the entity engine as a lower level artifact - like a jar 
file. I don't have all of the details worked out yet, but what I picture 
is this:


1. An application needs a database-agnostic data store.
2. The application accesses the data store though the entity engine API/ 
jar library.


Ofbiz has a very convenient way of defining databases, tables, and views 
as XML files. Plus, it has the ability to create/modify table/index 
structures during start-up. I believe that would be a very handy tool 
for anyone wanting to create any application that requires data storage.


Wrapping the entity engine jar file in an OSGI bundle would be trivial.

If anyone is interested in exploring this further, then they should 
create a Jira issue and we can take it from there.


-Adrian

On 1/27/2011 10:21 PM, Raj Saini wrote:
I will certainly be glad to help in this. I had re-packaged the entity 
engine as and OSGi bundle and exposed the delegator as osgi service. I 
found minor issues like loading of entityengine.xml from classpath and 
this did not go well with the OSGi. Let us wait for the the 
restructuring of the OFBiz project.


Thanks,

Raj

On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:
Cool. If anyone is interested in working on that, I am available to 
help.


-Adrian

On 1/27/2011 9:23 PM, Raj Saini wrote:
Yes, I agree. Entity Engine and Service Engine are two such 
marvellous pieces of technologies. Entity engine can very well 
compete with Java Persistence API (JPA) if it is separated from the 
OFBiz runtime.


Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could be 
their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example entity 
engine, service engine, security etc. will be OSGi bundles running 
on top of OSGi framework such Apache Karaf. Apache ServiceMix is 
already using Karaf (http://karaf.apache.org). I did a prototype 
and embedded the OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the 
underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and
users of the product. It is about security, and about a future 
proof and

reliable platform for developing applications on.

What do feel is important? What should be removed from the 
framework. what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up a 
plan for

comming releases.

Regards,

Pierre

Re: OFBiz: The road ahead RE the framework

I will certainly be glad to help in this. I had re-packaged the entity 
engine as and OSGi bundle and exposed the delegator as osgi service. I 
found minor issues like loading of entityengine.xml from classpath and 
this did not go well with the OSGi. Let us wait for the the 
restructuring of the OFBiz project.


Thanks,

Raj

On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:

Cool. If anyone is interested in working on that, I am available to help.

-Adrian

On 1/27/2011 9:23 PM, Raj Saini wrote:
Yes, I agree. Entity Engine and Service Engine are two such 
marvellous pieces of technologies. Entity engine can very well 
compete with Java Persistence API (JPA) if it is separated from the 
OFBiz runtime.


Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could be 
their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example entity 
engine, service engine, security etc. will be OSGi bundles running 
on top of OSGi framework such Apache Karaf. Apache ServiceMix is 
already using Karaf (http://karaf.apache.org). I did a prototype 
and embedded the OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the 
underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and
users of the product. It is about security, and about a future 
proof and

reliable platform for developing applications on.

What do feel is important? What should be removed from the 
framework. what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up a 
plan for

comming releases.

Regards,

Pierre

Re: OFBiz: The road ahead RE the framework

Yes, I agree. Entity Engine and Service Engine are two such marvellous 
pieces of technologies. Entity engine can very well compete with Java 
Persistence API (JPA) if it is separated from the OFBiz runtime.


Raj

On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could be 
their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example entity 
engine, service engine, security etc. will be OSGi bundles running on 
top of OSGi framework such Apache Karaf. Apache ServiceMix is already 
using Karaf (http://karaf.apache.org). I did a prototype and embedded 
the OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the 
underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and
users of the product. It is about security, and about a future proof 
and

reliable platform for developing applications on.

What do feel is important? What should be removed from the 
framework. what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up a 
plan for

comming releases.

Regards,

Pierre

Re: OFBiz: The road ahead RE the framework

I have suggested that in the past. OFBiz has spawned some great 
technology that, if modified to be stand-alone subsystems, could be 
their own projects.


-Adrian

On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for 
framework. This will help modularising efforts. For example entity 
engine, service engine, security etc. will be OSGi bundles running on 
top of OSGi framework such Apache Karaf. Apache ServiceMix is already 
using Karaf (http://karaf.apache.org). I did a prototype and embedded 
the OFBiz in OSGi runtime 
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the 
underlying

core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business 
processes and

users of the product. It is about security, and about a future proof and
reliable platform for developing applications on.

What do feel is important? What should be removed from the framework. 
what

should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up a 
plan for

comming releases.

Regards,

Pierre

Re: OFBiz: The road ahead RE the framework

One thing I would like to see is to use the OSGi runtime for framework. 
This will help modularising efforts. For example entity engine, service 
engine, security etc. will be OSGi bundles running on top of OSGi 
framework such Apache Karaf. Apache ServiceMix is already using Karaf 
(http://karaf.apache.org). I did a prototype and embedded the OFBiz in 
OSGi runtime (http://sourceforge.net/projects/ofbiz-osgi/) and it worked 
well.


Thanks,

Raj

On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:

Hi All,

This thread is about where you want the community to go with the underlying
core components of OFBiz (aka the Framework).

The framework is the enables of all applications and business processes and
users of the product. It is about security, and about a future proof and
reliable platform for developing applications on.

What do feel is important? What should be removed from the framework. what
should be included? What can be enhanced? And what not?

Please let all of us know what you think is important regarding the
framework so that we (the community) can take stock and draw up a plan for
comming releases.

Regards,

Pierre

Re: OFBIZ: the road ahead

Hi David, thanks for setting me straight here.  

Mule might be a pretty good fit for this kind of integration.  One of the 
things ServiceMix focuses on is WS, Mule could work with these interfaces.  

What might not be obvious is that Mule could do all the message marshaling to 
the formats you mentioned and more, like ReST.  Instead of maintaining this 
code, it might be valuable to export maintenance and upkeep on these interfaces 
to Mule.  An additional upside is it gives the client a number of additional 
ways to connect, such as with JMS, also maintained as a part of Mule.

One concern is your observation that "[h]owever, the XML-RPC and JSON ones are 
pretty good", with emphasis on "pretty good".  I read from that they are not 
perfect.  

If these are not the mainline interfaces, they are bound to lag or not be 
accurate.  Mule both provides a external front-end to application APIs, as well 
as a performant means to access them internally.  By unifying these access 
points, maintenance and testing efforts are similarly reduced.  The reduction 
is likely offset by the extra effort to integrate Mule in the first place, but 
functionality should make the risk in the tradeoff worth it, and at some point, 
it's all payback.

I'll do more digging about the interfaces that you talked about here.  I 
clearly didn't understand some of the options available.  

Thanks, Brian

On Jan 27, 2011, at 11:40 AM, David E Jones wrote:

> 
> Brian,
> 
> Have you looked into the integration-oriented features of OFBiz? IMO SOAP is 
> a mess and while there has been a SOAP to OFBiz Service tool for a long time, 
> it has never been very good. However, the XML-RPC and JSON ones are pretty 
> good, and along with general XML message passing (like the OAGIS XML messages 
> in OFBiz) these are used a lot for integration with other systems, and even 
> other types of UIs. The basic idea is that you can call ANY OFBiz service (if 
> it is flagged for external use) through these integration means without 
> having to write any extra code on the server (unless you can't control the 
> service definition and need to build a service to match a certain definition, 
> then obviously you'll need to do some server side coding).
> 
> In addition to those if you are writing anything in Java or that runs on a 
> JVM it is VERY easy to use the Service Engine's remote dispatcher to get an 
> object from JNDI on the OFBiz server and then do service calls, with no extra 
> code on the client or server... just start calling services and passing data 
> in and getting data back.
> 
> Some of your other assertions are not quite correct either. For example, if 
> you want to use another Java web UI technology you can do it in container, 
> even in an OFBiz webapp with other OFBiz stuff, with no problem. Just add it 
> to the web.xml file like you would in any other situation. It's not that big 
> a deal.
> 
> -David
> 
> 
> On Jan 27, 2011, at 2:50 AM, Brian Topping wrote:
> 
>> Hi Pierre,
>> 
>> By your inquiry on the future, do you mean with specific features in the 
>> applications or how they work together?
>> 
>> As an architect, I am interested in not just an ability to integrate my 
>> application against OFBiz, but allow my application to take part in message 
>> orchestration by patching itself into the workflows.  I should like that a 
>> stock OFBiz deployment can be customized through open interfaces with 
>> now-common enterprise integration patterns instead of requiring a 
>> proprietary (if open) means of application customization.  
>> 
>> Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I 
>> think the "major moving parts" of that model might provide a good pattern 
>> for how the applications could work together in the future.  (In other 
>> words, Mule might be preferred, but the applications still remodeled on EIP 
>> for open integration).
>> 
>> If the applications integrated this way and were uncoupled into separate 
>> Maven projects, the applications would also be usable individually where 
>> appropriate.  It would be a challenge to do this, but a new class of user 
>> would result, one that could pick and choose applications that they wanted 
>> to integrate against their local deployment instead of the current 
>> all-or-nothing approach.  
>> 
>> ServiceMix has some rather comprehensive integrations with Maven in this 
>> regard which I don't pretend to understand very well, but a team effort 
>> might result in a solution that really reinvigorates the ecosystem through a 
>> large number of new use cases of existing applications.  For instance, REST 
>> style or WS interfaces might open the applications to use by Ruby or PHP 
>> developers.  The depth and experience wrapped up in the OFBiz ecosystem is 
>> staggering, but it's reach is limited by it's rather monolithic Java-centric 
>> deployment.  If opening it up in this way would significantly alter the user 
>> base, there would be a

Re: OFBIZ: the road ahead RE Project Management

2011-01-27 Thread BJ Freeman


having the project manger display and manage  manufacturing Production Run

=
BJ Freeman
Strategic Power Office with Supplier Automation  

Specialtymarket.com  
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Pierre Smits sent the following on 1/27/2011 1:57 AM:

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the application(s) involved in Project Management.

In order to draw up a plan for future releases we would like have your
input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

Re: OFBIZ: the road ahead RE Supply Chain Management

2011-01-27 Thread BJ Freeman


there are many ways to communicated EDI to suppliers.
though specialpurpose\oagis addresses this
there is AS2 and VANS using EDI format.
Then you have the misceanos "supplier" dropshipper that have their own 
system.


=
BJ Freeman
Strategic Power Office with Supplier Automation  

Specialtymarket.com  
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Pierre Smits sent the following on 1/27/2011 1:51 AM:

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the applications involved in Supply Chain Management.
The applications involved here are:

- Order
- Catalog
- Manufacturing


In order to draw up a plan for future releases we would like have your
input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

Re: OFBIZ: The road ahead RE Ecommerce

2011-01-27 Thread BJ Freeman


see
https://issues.apache.org/jira/browse/OFBIZ-2437

=
BJ Freeman
Strategic Power Office with Supplier Automation  

Specialtymarket.com  
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man

Mike sent the following on 1/27/2011 7:37 AM:

I'd sure like to see more ecommerce themes.  Does anyone have any they
would like to share?

On Thu, Jan 27, 2011 at 1:48 AM, Pierre Smits  wrote:

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the ecommerce application. In order to draw up a plan
for future releases we would like have your input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

Re: OFBiz: The road ahead RE Accounting

2011-01-27 Thread David E Jones


I started a design effort along these lines a while back, perhaps it will get 
some more interest and attention someday, perhaps:

https://cwiki.apache.org/confluence/display/OFBREQDES/OFBiz+EZBiz

-David


On Jan 27, 2011, at 11:49 AM, ScottA wrote:

> 
> I'd love to see the accounting tightened up a bit and put into a more user
> friendly approach. While I am not a great fan of the closed source
> QuickBooks, it does make it very easy to navigate and get things done.
> Within a couple of clicks you are right where you need to be. After two
> years with OFBiz, the entire accounting UI still confuses me. I love the
> idea that OFBiz could run my entire business from start to finish. It has
> all the parts, it just needs the ui and process pieced together.
> -- 
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/OFBiz-The-road-ahead-RE-Accounting-tp3241759p3243017.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: OFBiz: The road ahead RE Accounting

2011-01-27 Thread ScottA


I'd love to see the accounting tightened up a bit and put into a more user
friendly approach. While I am not a great fan of the closed source
QuickBooks, it does make it very easy to navigate and get things done.
Within a couple of clicks you are right where you need to be. After two
years with OFBiz, the entire accounting UI still confuses me. I love the
idea that OFBiz could run my entire business from start to finish. It has
all the parts, it just needs the ui and process pieced together.
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/OFBiz-The-road-ahead-RE-Accounting-tp3241759p3243017.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: OFBIZ: the road ahead

2011-01-27 Thread David E Jones

Brian,

Have you looked into the integration-oriented features of OFBiz? IMO SOAP is a 
mess and while there has been a SOAP to OFBiz Service tool for a long time, it 
has never been very good. However, the XML-RPC and JSON ones are pretty good, 
and along with general XML message passing (like the OAGIS XML messages in 
OFBiz) these are used a lot for integration with other systems, and even other 
types of UIs. The basic idea is that you can call ANY OFBiz service (if it is 
flagged for external use) through these integration means without having to 
write any extra code on the server (unless you can't control the service 
definition and need to build a service to match a certain definition, then 
obviously you'll need to do some server side coding).

In addition to those if you are writing anything in Java or that runs on a JVM 
it is VERY easy to use the Service Engine's remote dispatcher to get an object 
from JNDI on the OFBiz server and then do service calls, with no extra code on 
the client or server... just start calling services and passing data in and 
getting data back.

Some of your other assertions are not quite correct either. For example, if you 
want to use another Java web UI technology you can do it in container, even in 
an OFBiz webapp with other OFBiz stuff, with no problem. Just add it to the 
web.xml file like you would in any other situation. It's not that big a deal.

-David

On Jan 27, 2011, at 2:50 AM, Brian Topping wrote:

> Hi Pierre,
> 
> By your inquiry on the future, do you mean with specific features in the 
> applications or how they work together?
> 
> As an architect, I am interested in not just an ability to integrate my 
> application against OFBiz, but allow my application to take part in message 
> orchestration by patching itself into the workflows.  I should like that a 
> stock OFBiz deployment can be customized through open interfaces with 
> now-common enterprise integration patterns instead of requiring a proprietary 
> (if open) means of application customization.  
> 
> Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I 
> think the "major moving parts" of that model might provide a good pattern for 
> how the applications could work together in the future.  (In other words, 
> Mule might be preferred, but the applications still remodeled on EIP for open 
> integration).
> 
> If the applications integrated this way and were uncoupled into separate 
> Maven projects, the applications would also be usable individually where 
> appropriate.  It would be a challenge to do this, but a new class of user 
> would result, one that could pick and choose applications that they wanted to 
> integrate against their local deployment instead of the current 
> all-or-nothing approach.  
> 
> ServiceMix has some rather comprehensive integrations with Maven in this 
> regard which I don't pretend to understand very well, but a team effort might 
> result in a solution that really reinvigorates the ecosystem through a large 
> number of new use cases of existing applications.  For instance, REST style 
> or WS interfaces might open the applications to use by Ruby or PHP 
> developers.  The depth and experience wrapped up in the OFBiz ecosystem is 
> staggering, but it's reach is limited by it's rather monolithic Java-centric 
> deployment.  If opening it up in this way would significantly alter the user 
> base, there would be a lot more opportunities for everyone involved.  
> 
> I am not trolling here, so please excuse if what I am writing is naive.  I do 
> not have enough technical chops on the guts of OFBiz to know what toes I am 
> stepping on, just presenting a vision of what I would like to integrate 
> against.  I did investigate OFBiz for an ERP solution I need to deliver in 
> the retail space and found that it would be challenging to use the user 
> interface facilities I found to create the customer UI.  My solution was to 
> avoid the problem by building my web UI in a message-oriented manner, back it 
> by Mule, and push the problem out to the future.  It's not a question for me 
> of whether OFBiz will be there when I need it, but more that I will integrate 
> against the applications with standard EIP.  If OFBiz had an accessible EIP 
> presentation like this, it would be a natural choice to integrate with, both 
> for me, and I suspect many other people in my situation.  The Ode style 
> orchestration is more about the applications working together, which would be 
> gravy on the meal.
> 
> $0.02...
> 
> Brian

Re: OFBIZ: The road ahead RE Ecommerce

2011-01-27 Thread Ryan Foster

Stay tuned Mike,

I have two in the works that will be released within the next month.

Ryan L. Foster
801.671.0769
cont...@ryanlfoster.com
ryanlfoster.com

On Jan 27, 2011, at 8:37 AM, Mike wrote:

> I'd sure like to see more ecommerce themes.  Does anyone have any they
> would like to share?
> 
> On Thu, Jan 27, 2011 at 1:48 AM, Pierre Smits  wrote:
>> Hi all,
>> 
>> With the release of 10.04 we come to a point in time where we can think
>> about the future of the ecommerce application. In order to draw up a plan
>> for future releases we would like have your input.
>> 
>> What do you feel is important? What should be in, what should be removed,
>> what can be improved?
>> 
>> Please join us in this discussion about the Accounting application.
>> 
>> Regards,
>> 
>> Pierre
>>

Re: OFBIZ: The road ahead RE Ecommerce

2011-01-27 Thread Mike

I'd sure like to see more ecommerce themes.  Does anyone have any they
would like to share?

On Thu, Jan 27, 2011 at 1:48 AM, Pierre Smits  wrote:
> Hi all,
>
> With the release of 10.04 we come to a point in time where we can think
> about the future of the ecommerce application. In order to draw up a plan
> for future releases we would like have your input.
>
> What do you feel is important? What should be in, what should be removed,
> what can be improved?
>
> Please join us in this discussion about the Accounting application.
>
> Regards,
>
> Pierre
>

Re: OFBIZ: the road ahead

On Jan 27, 2011, at 7:40 AM, Jacques Le Roux wrote:

> Why Mule rather than ServiceMix? I can't see much diff. between them.

ServiceMix is more strongly based on W3C WS where Mule is more open to 
different transports.  I felt for my application that Mule would be more 
performant, although I prefer the infrastructure support that ServiceMix 
provides (OSGi, Maven).

> For PHP I will soon make a proposition. It's based on Quercus (GPL hence of 
> out OFBiz repo) and sitting on my table for almost 2 years now (my bad)

Quercus looks really good and I've considered it in the past for other 
projects.  It has some notable longstanding issues, but they can be worked 
around.

What I am concerned about by having named only two (Ruby, PHP) is that I left 
out dozens of other technologies.  Quercus only solves one (PHP).  What I am 
aiming for is opening up access to the great elements that OFBiz provides to 
any language that can support integration standards, not just repackage Java 
interfaces on a language-by-language basis.  

> I have seen others taking the same approach, for instance to link ElasticPach 
> with OFBiz, or even to link diff. versions of OFBiz...
> But it makes more sense IMO for legacy than for new UIs. Of course this 
> implies to know/use OFBiz widgets, but it's not that hard.

It's very very hard when the OFBiz widgets are assuming a UX workflow or 
stylesheets that are different than the rest of the application.  It's also 
very very hard when the rest of the application is not completely OFBiz based 
(in which case, there would be no reason to do any of this).  

The goal I am talking about is fundamentally different than a star 
configuration of integration where every integration endpoint must have strong 
coupling with every other application through direct API calls.  By using a bus 
configuration, an integration point just publishes itself on the bus, and other 
applications can be routed to whatever application can accept messages of that 
type.  It is the tight coupling to Java interfaces that needs to be weakened, 
IMO.

Fwd: Observed bug in List navigation In New Thames

2011-01-27 Thread Pankaj Singh

Hi ,
We observed a bug in latest SVN ofbiz themes. Please let us know if any one
came across with the same bug .
*Bug :-*
Navigation on rendered list items is not working .Errors are like :-

   - Number of display record is not getting updated (it is always taking
   the default value )
   - Navigation of screen is not working for further records (Next Screen
   button not working ).


Find the steps below to reproduce the same :-

1- Click on *Entity Engine* then .
2- Click on *Entity Data Maintenance*.
3- Search for *ServerHit* Entity.
4- Open the *ServerHit* *Entity* with All option .
5- It will Display more then 50 records then try to move on 2nd Screen or
try to change the no of display record which is not working .


Observed the same behavior in below themas :-

   - Tomahawk: the evolution of the Dropping Crumbs theme
   - Flat Grey - Floating Layout, Sight-Impaired Accessible, Bidirectional



-- 
Thanks ,
Pankaj

Re: OFBIZ: the road ahead

2011-01-27 Thread Jacques Le Roux

Brian Topping wrote:

Hi Pierre,

By your inquiry on the future, do you mean with specific features in the
applications or how they work together?

As an architect, I am interested in not just an ability to integrate my
application against OFBiz, but allow my application to
take part in message orchestration by patching itself into the workflows. I
should like that a stock OFBiz deployment can be
customized through open interfaces with now-common enterprise integration
patterns instead of requiring a proprietary (if open)
means of application customization.

Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I think the
"major moving parts" of that model might
provide a good pattern for how the applications could work together in the
future. (In other words, Mule might be preferred, but
the applications still remodeled on EIP for open integration).

Why Mule rather than ServiceMix? I can't see much diff. between them.

If the applications integrated this way and were uncoupled into separate Maven
projects, the applications would also be usable
individually where appropriate. It would be a challenge to do this, but a new
class of user would result, one that could pick
and choose applications that they wanted to integrate against their local
deployment instead of the current all-or-nothing
approach.

ServiceMix has some rather comprehensive integrations with Maven in this regard
which I don't pretend to understand very well,
but a team effort might result in a solution that really reinvigorates the
ecosystem through a large number of new use cases of
existing applications. For instance, REST style or WS interfaces might open
the applications to use by Ruby or PHP developers.

For PHP I will soon make a proposition. It's based on Quercus (GPL hence of out OFBiz repo) and sitting on my table for almost 2
years now (my bad)

The depth and experience wrapped up in the OFBiz ecosystem is staggering, but
it's reach is limited by it's rather monolithic
Java-centric deployment. If opening it up in this way would significantly
alter the user base, there would be a lot more
opportunities for everyone involved.

I am not trolling here, so please excuse if what I am writing is naive. I do
not have enough technical chops on the guts of
OFBiz to know what toes I am stepping on, just presenting a vision of what I
would like to integrate against. I did investigate
OFBiz for an ERP solution I need to deliver in the retail space and found that
it would be challenging to use the user interface
facilities I found to create the customer UI. My solution was to avoid the
problem by building my web UI in a message-oriented
manner, back it by Mule, and push the problem out to the future.

I have seen others taking the same approach, for instance to link ElasticPach
with OFBiz, or even to link diff. versions of OFBiz...
But it makes more sense IMO for legacy than for new UIs. Of course this implies
to know/use OFBiz widgets, but it's not that hard.

Jacques

It's not a question for me of whether OFBiz will be there when
I need it, but more that I will integrate against the applications with
standard EIP. If OFBiz had an accessible EIP
presentation like this, it would be a natural choice to integrate with, both
for me, and I suspect many other people in my
situation. The Ode style orchestration is more about the applications working
together, which would be grav! y on the meal.

$0.02...

Brian

Re: OFBiz: The road ahead RE the framework

Sorry, I didn't see this thread when I wrote my previous email.  If it should 
be resent to this thread, please let me know.

Cheers, Brian

On Jan 27, 2011, at 4:31 AM, Pierre Smits wrote:

> Hi All,
> 
> This thread is about where you want the community to go with the underlying
> core components of OFBiz (aka the Framework).
> 
> The framework is the enables of all applications and business processes and
> users of the product. It is about security, and about a future proof and
> reliable platform for developing applications on.
> 
> What do feel is important? What should be removed from the framework. what
> should be included? What can be enhanced? And what not?
> 
> Please let all of us know what you think is important regarding the
> framework so that we (the community) can take stock and draw up a plan for
> comming releases.
> 
> Regards,
> 
> Pierre

OFBIZ: the road ahead

Hi Pierre,

By your inquiry on the future, do you mean with specific features in the 
applications or how they work together?

As an architect, I am interested in not just an ability to integrate my 
application against OFBiz, but allow my application to take part in message 
orchestration by patching itself into the workflows.  I should like that a 
stock OFBiz deployment can be customized through open interfaces with 
now-common enterprise integration patterns instead of requiring a proprietary 
(if open) means of application customization.  

Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I 
think the "major moving parts" of that model might provide a good pattern for 
how the applications could work together in the future.  (In other words, Mule 
might be preferred, but the applications still remodeled on EIP for open 
integration).

If the applications integrated this way and were uncoupled into separate Maven 
projects, the applications would also be usable individually where appropriate. 
 It would be a challenge to do this, but a new class of user would result, one 
that could pick and choose applications that they wanted to integrate against 
their local deployment instead of the current all-or-nothing approach.  

ServiceMix has some rather comprehensive integrations with Maven in this regard 
which I don't pretend to understand very well, but a team effort might result 
in a solution that really reinvigorates the ecosystem through a large number of 
new use cases of existing applications.  For instance, REST style or WS 
interfaces might open the applications to use by Ruby or PHP developers.  The 
depth and experience wrapped up in the OFBiz ecosystem is staggering, but it's 
reach is limited by it's rather monolithic Java-centric deployment.  If opening 
it up in this way would significantly alter the user base, there would be a lot 
more opportunities for everyone involved.  

I am not trolling here, so please excuse if what I am writing is naive.  I do 
not have enough technical chops on the guts of OFBiz to know what toes I am 
stepping on, just presenting a vision of what I would like to integrate 
against.  I did investigate OFBiz for an ERP solution I need to deliver in the 
retail space and found that it would be challenging to use the user interface 
facilities I found to create the customer UI.  My solution was to avoid the 
problem by building my web UI in a message-oriented manner, back it by Mule, 
and push the problem out to the future.  It's not a question for me of whether 
OFBiz will be there when I need it, but more that I will integrate against the 
applications with standard EIP.  If OFBiz had an accessible EIP presentation 
like this, it would be a natural choice to integrate with, both for me, and I 
suspect many other people in my situation.  The Ode style orchestration is more 
about the applications working together, which would be gravy on the meal.

$0.02...

Brian

Re: Calendar

2011-01-27 Thread Jacques Le Roux


I'd suggest to use the one from backend

Jacques

From: "Gavin Mabie" 

Hi all



Is there a calendar select (datepicker) for the ecommerce application?  How
do I configure it?



Thanks



Gavin

OFBIZ: the road ahead RE Project Management

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the application(s) involved in Project Management.

In order to draw up a plan for future releases we would like have your
input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

OFBIZ: the road ahead RE Human Resources Management

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the application(s) involved in Human Resources
Management.

In order to draw up a plan for future releases we would like have your
input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

OFBIZ: the road ahead RE Customer Relation Management

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the applications involved in Customer Releation
Management. The applications involved here are:

   - Marketing
   - SFA


In order to draw up a plan for future releases we would like have your
input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

OFBIZ: the road ahead RE Supply Chain Management

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the applications involved in Supply Chain Management.
The applications involved here are:

   - Order
   - Catalog
   - Manufacturing


In order to draw up a plan for future releases we would like have your
input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

OFBIZ: The road ahead RE Ecommerce

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the ecommerce application. In order to draw up a plan
for future releases we would like have your input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre

OFBiz: The road ahead RE Accounting

Hi all,

With the release of 10.04 we come to a point in time where we can think
about the future of the Accounting application. In order to draw up a plan
for future releases we would like have your input.

What do you feel is important? What should be in, what should be removed,
what can be improved?

Please join us in this discussion about the Accounting application.

Regards,

Pierre Smits

Calendar

2011-01-27 Thread Gavin Mabie

Hi all

 

Is there a calendar select (datepicker) for the ecommerce application?  How
do I configure it?

 

Thanks

 

Gavin

Service products and Order Statuses

2011-01-27 Thread Shereen


Hello
I have a question related to the product and the order statuses
when I go and set up the product as a service does that affect the ordinary
flow of the order statuses?
auto approval or auto completion or anything of that kind?
I've looked through the secas but I couldn't find it
I've already made some customization regarding the order statuses and their
changes anhd all worked fine with me when I was using the finished good
products but something very strange happened.
the odrer changes from approved to completed then to approved again 
and this causes me a problem really in the subscriptions table because I've
made products like Gizmo new letter and it seems the subscription records
are created upon the approval or the order so when the order  passes two
approval two records are created
any help please?
-- 
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Service-products-and-Order-Statuses-tp3241751p3241751.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

OFBiz: The road ahead RE the framework