Hi
If we are talking about Jira and ways to handle or improve it for the
project then I did start a discussion thread a few days ago (link below)
https://lists.apache.org/thread.html/61d310a85759c89ca2aa2a18bdca945a9868caf5a1bff2fb72a774d8@%3Cdev.ofbiz.apache.org%3E
It might be good to take this suggestion into that thread rather than
start an off-topic discussion here.
Thanks
Sharan
On 28/07/16 08:54, Taher Alkhateeb wrote:
Hi Pierre and Everyone,
I gather you might be currently preoccupied to work on this JIRA. If my
understanding is correct, then may I suggest to close this JIRA and other
similar JIRAs and allow those interested in implementing the work to create
their own JIRAs for the following reasons:
1- It is confusing to have too many JIRAs open that no one is working on
which is likely to create duplicates.
2- I think it is fair for those who make the effort of designing,
implementing, testing and patching to have their name on the JIRA as the
Reporter as a recognition of their efforts.
Taher Alkhateeb
On Wed, Jul 27, 2016 at 6:39 PM, Taher Alkhateeb <slidingfilame...@gmail.com
wrote:
Would you be willing to take care of that task Pierre?
On Jul 27, 2016 6:36 PM, "Pierre Smits" <pierre.sm...@gmail.com> wrote:
An issue regarding the move of data up the stack already exists:
https://issues.apache.org/jira/browse/OFBIZ-7016
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
Initially ecommerce was part of the "core" applications, then it was
moved
to specialpurpose because as it it is a "template" for the
implementation
of an ecommerce store rather than a ready to be used application.
I must admit that the same could apply to the other backend
applications so
there is definitely a grey area...
For the short term we could consider to move the demo data up the stack.
Jacopo
On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Hi Jacopo,
You got it 100% right, it was indeed the ecommerce component. Wow!
This
means one of two things should happen, either we move ecommerce as a
core
application, or we untangle this mess. I'm not very familiar with the
history, is there a reason why ecommerce is a specialpurpose
application?
it seems to be highly integrated within the framework.
Taher Alkhateeb
On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
I think that the core reason for the failure is that most of the
tests
need
the demo data that is loaded with the ecommerce component; if you
disable
it the data is not loaded.
Could you please try to enable ecommerce and run them again?
Thanks,
Jacopo
On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Hi everyone,
In continuation with the above discussion, I just made a little
experiment
which gave me scary results. What did I do?
1 - Disabled all specialpurpose components (except example, to
make
it
a
valid XML file) in specialpurpose/component-load.xml
2 - Attempted ./gradlew cleanAll loadDefault testIntegration
3 - Got 100 failing tests
So upon investigating a little I believe these tests fail due to
multiple
issues:
- When we disable specialpurpose, the dependency graph for Jars
changes
and
that breaks some system behavior
- I suspect also some data loading is disabled which fails some of
the
tests
- hidden dependencies exist from framework / applications to
specialpurpose.
What does that mean? It means our framework is brittle and
depends on
specialpurpose, and without it being active the system does not
run
properly.
If we are serious about improving the system and making it
modular,
then
I
find it very important to start with disabling all specialpurpose
components or at least having a second build in buildbot for those
components in isolation of the framework.
I don't think this is a luxury, I highly recommend that we stop
the
specialpurpose components from being active by default to protect
and
isolate the framework and core applications. Actually we need help
from
everyone who is willing to help to volunteer in getting a working
build
with tests passing while all specialpurpose components are
disabled.
Taher Alkhateeb
On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Taher, Gil,
Exactly my thoughts. Nothing (ethically and technically) should
force
an
user to share his/her/its personal plugins. This assumption
must be
part
of
the specifications (assumption as in a theory)
Thanks Taher!
Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit :
Hi Gil,
Thank you for sharing past experiences. It seems we are
tackling
something
that was attempted multiple times before. I am a bit optimistic
though
because having the plugin system integrated into the build
system
is a
different approach that solves multiple problems I think.
I would like to note that I think it is okay to use the same
plugin
system
even for proprietary customer solutions. In fact I think
customers
would
understand it more easily than the concept of hot-deploy. Even
if
the
solution is for one customer and not intended to be shared you
can
still
have a sensible command like ./gradlew installPlugin
-PpluginName=customerPlugin -Prepository=localFileSystem.
Having one solution instead of two solutions I think would
unify
efforts
and thinking processes and terminology used. We have only one
way
of
extending OFBiz which is called plugins, and any changes we do
happen
in
this unified architecture.
So ... food for thought.
Taher Alkhateeb
On Jul 23, 2016 7:34 PM, "gil portenseigne" <
gil.portensei...@nereide.fr>
wrote:
Hi all,
First, I like the idea of gradle being the plugin solution
endebbed
within
OFBiz.
This could allow OFBiz integrators to share their specific
improvments
with a easy to use, OOTB tool (thinking about OfbizExtra
addons
or
Pierre's
OEM initiatives to name a few).
Then, from what i understand about what Nicolas said, is that
it'd
be
good
to keep hot-deploy and create-component tasks for customer
projects.
Why not using plugin into customer project ? It is because
that
is
a
private, specific and complete new application using core and
plugin
functionnalities. It has to be separated since it is not a
plugin
(not
intended to be shared). The plugin dependency could be solved
with
a
build.gradle within the hot-deploy component, checking the
installation
state of the dependent plugin (and installing if needed).
And last, for your information, Nereide do not use addons
anymore,
this
system created more problems than it helped, the original idea
was
good,
but some design flaws did showed up...
Gil
Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :
Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
Hi,
Taher I like you proposal, and I wish to add some complement
:)
hot-deploy is to manage specific customer site component with
the
business
logic specific to each, Apache OFBiz can help to prepare this
but
do
not
more (I will like to have this as best practice)
I think plugins could do that also
I agree to add a new directory plugins and structure it for
the
future
vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like
the
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give
some
coding
contions
This should be in the specifications indeed, Taher already
answered
We can create the plugins directory, and keep specialpurpose
on a
first
step and move step by step each component present.
This is a very important point and we have to be very careful
about
the
transition!
Jacques
I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
-> check if birt is present on the plugins directory, if not
download
from
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
-> enable it on component-load
-> compile, load init date and run init service
When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official
apache
ofbiz release, only plugins present on
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/
Nicolas
Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :
Hi Pierre, all,
I think perhaps my proposal was short and therefore your
understanding
of
it is a bit different than what I had in mind. So I list below
more
specifically what I mean about each point from the ones you
mentioned
above
to further fine-tune the discussion.
- The difference between createComponent and createPlugin is
that
the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file
designed
specifically for plugins. This script contains standard tasks
like
install,
uninstall, perhaps even upgrade. The magic work for plugins
will
be
in
their build scripts to integrate tightly with OFBiz.
- The activate/deactivate tasks are just a little convenience
tasks
that
add/remove components to the component-load.xml instead of
editing
it
by
hand so it is just using what exists. Gradle completely
ignores a
component
if it does not exist in component-load.xml and would not even
compile
it.
So you can think of this as just providing more ease to the
end-user,
similar to your suggestion with the createComponent.
- The install/uninstall tasks are not just a copy-paste of
folders.
It
actually executes business logic (optionally) for any plugin
author
who
wishes to execute it (by calling specific tasks in
build.gradle
for
that
plugin). For example, it might apply patches on some core
applications
(and
reverse patches in case of uninstall). Now our standard
plugins
do
not
touch applications or framework, but since we are introducing
this
feature
I'm trying to also combine a unified solution for all plugins
(Apache
supported and 3rd party). So in one shot we have both ease of
use
for
the
existing components and at the same time a general purpose
plugin
system.
We might even have a task like say "updatePlugin" in the
future
and
it
is
also possible to introduce rudimentary dependency management
(Gradle
is
really good at this).
Finally, what to do about specialpurpose is something we
should
definitely
tackle, however what I am suggesting right now is some
foundational
work
that gives you easy choices when you need to make them, and it
has
the
added bonus of introducing a plugin system for OFBiz which is
badly
needed
to protect the core framework and applications and to provide
an
eco-system
around it. I'm trying to reach a win-win solution if you will.
Regards,
Taher Alkhateeb
On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :
the graph needs to be checked/amended to possibly remove
components
dependencies only introduced by the data model
Sorry, I have noticed I have the bad tendency of using the
word
"introduced" instead of "put" or "add" (due to "introduire"
false
friend
in
French) please replace for me when you see it, thanks! :)
Here the right word would have been "due to" instead of
"introduced
by"
Jacques
PS: http://www.etymonline.com/index.php?term=introduction
