I agree that a good solution would be to just comment out the
component includes in the component-load.xml file in the framework
directory.
To be honest, I'm a little tired of questions about Shark. There
seems to be lots of interest in using it, but no one has really been
both able and sufficiently interested in working on it. Still, I'd
really like to have a workflow engine for OFBiz in the future because
while we have other things that are good for general Business Process
Management (BPM), namely the SECA rules, it would be good to have
something that addresses internal "workflow" management for groups
that do the same processes over and over many times, which is what
the workflow side of BPM is good for.
As for where to document the fact that it is commented out: anyone
that has a basic understanding of the component structure in OFBiz
should be able to figure it out quickly. Jira might be a good place
to mention it, but I guess the question is where would people be most
likely to look for the information... and I have no idea what that
would be. I'd say the Workflow Guide would be the best place, though
I'm not sure if people are too likely too look there. Still, if we
put info there when people inevitably ask on the mailing list without
looking anywhere first, we can point them there.
-David
On Oct 25, 2006, at 10:34 AM, Jacopo Cappellato wrote:
David, all,
the shark, and workflow, components are not causing any problems to
me, but it would be nice, from time to time, to review the existing
components and try to understand if they are still 'alive' and what
we can do to improve them etc... (especially the ones with a user
interface, because are the ones every new user jumps in).
For example, the migration from JPublish to the widgets is now
complete except for the content and shark applications and I'd
really love to see that effort finalized as soon as possible; I'm
wondering if it makes sense to put some effort in converting the
Shark's pages or not.
To partially address these points I'd propose one of the two options:
a) change the name of the application's tab from "Shark" to
something that is more generic such as "Workflow"
b) disable the "workflow" and "shark" components (i.e. comment them
in component-load.xml) and create a new Jira issue that describes
to current status of these components, what it is needed to run
them and possible future plans about them
I'd prefer the latter solution but the former one would be enough
for now.
Does it make sense?
Jacopo
David E Jones wrote:
Si,
Your comments seem to go quite a bit beyond the concern about it
not working 100%. If that was a requirement for functionality in
OFBiz we should really cull quite a lot from the project...
If something is not working 100% (and the Shark stuff IS working,
just not all of it, and it certainly needs to be updated to use a
newer and really released version of Shark), and there is no one
working on it, and it is causing problems, then we should leave it
disabled by default (which I think it is what Jacopo was
proposing), not remove it from the project.
The specialized directory is really meant for other things, namely
application level pieces that are for a specialized and not
generic purpose. Of course, some application like the OTS stuff
that started that way haven't stayed that way, but that was really
the point of it.
-David
On Oct 24, 2006, at 5:50 PM, Si Chen wrote:
David,
I think the concern that I have is that the Shark component
really doesn't work, there's doesn't seem to be any effort to get
it to work right now, and the SECAs do a great job of supporting
real work flow. If it worked, of course it's better to have a
workflow engine than not, but will that be the case at any
foreseeable point in the future? Might it be better to have it
in specialized/ until somebody can get it to work again?
On Oct 24, 2006, at 2:59 PM, David E Jones wrote:
It really isn't correct to say that the license is incompatible,
only that we can't distribute the jar files because of the license.
If we decide on this, we should decide based on goals for the
framework. Right now nothing outside of the shark component uses
Shark, so disabling it would be fine, but if we want to use
workflow in the future in OFBiz it isn't going to be based on
the OFBiz workflow engine (unless someone has a few thousand
hours I don't know about that they want to invest in this...).
So, do I understand from this that the direction we want to go
is to just not have a workflow engine in OFBiz?
Personally, I'd rather see the OFBiz workflow component go
before the Shark component, though it would certainly be nice if
there was another alternative with a friendlier license. Or
perhaps the Shark community would consider a change to the
Apache license, or if they still like the copy-left style stuff
for code changes, then perhaps the Mozilla license?
-David
On Oct 24, 2006, at 2:36 PM, Si Chen wrote:
I agree. How about we just move into that specialized/ SVN
that David has? Even if it worked, it still wouldn't make
sense to have it in the ASF SVN because the actual Shark is not
license compatible.
On Oct 24, 2006, at 1:12 PM, Jacopo Cappellato wrote:
What about disabling the Shark component?
It is a component that has never been completed, we have moved
outside of OFBiz the Shark jars (for license issues) and its
user interface is clearly not maintained updated with the rest
of the project: the Shark component is the only component,
together with the Content component :-( that still hosts
JPublish pages.
What do you think?
Jacopo
Best Regards,
Si
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
