I also suggested that before. What I like is JIRA plugin framework, which is
on top of OSGI. OSGI brings the ability that plugin could be loaded runtime,
which is very important to bring ofbiz up to cloud..
--
Regards,
Michael Xu (xudong)
On Fri, Jan 28, 2011 at 3:59 PM, Adrian Crum <
adrian.c..
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. M
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 c
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 entit
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
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 c
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 librar
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 O
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
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 modular
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.a
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
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
13 matches
Mail list logo
