Disabling the Shark component?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling the Shark component?

Jacopo Cappellato
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


Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

Si Chen-2
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
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

Jacques Le Roux
Administrator
+1

Jacques

From: "Si Chen" <[hidden email]>

> 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
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

David E Jones-2
In reply to this post by Si Chen-2

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
> [hidden email]
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

Si Chen-2
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
>> [hidden email]
>>
>>
>>

Best Regards,

Si
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

David E Jones-2

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
>>> [hidden email]
>>>
>>>
>>>
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

Jacopo Cappellato
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
>>>> [hidden email]
>>>>
>>>>
>>>>
>>
>> Best Regards,
>>
>> Si
>> [hidden email]
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

Si Chen-2
Hi David,

I hope my comments did not come across the wrong way.  I think it is  
more like what Jacopo is saying--whether that component is actively  
used/maintained as part of the project or not.  Certainly I'm not  
saying that everybody and everything has to be perfect (and certainly  
I am not), but sometimes it sees like there is nobody using Shark any  
more in ofbiz.  Of course, if I'm wrong, then we should keep it in by  
all means.

On Oct 25, 2006, at 9: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
>>>>> [hidden email]
>>>>>
>>>>>
>>>>>
>>>
>>> Best Regards,
>>>
>>> Si
>>> [hidden email]
>>>
>>>
>>>

Best Regards,

Si
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

David E Jones-2

Si,

The point is that it has little to do with what is happening now. The  
question is, where do we want things to go?

-David


On Oct 25, 2006, at 10:50 AM, Si Chen wrote:

> Hi David,
>
> I hope my comments did not come across the wrong way.  I think it  
> is more like what Jacopo is saying--whether that component is  
> actively used/maintained as part of the project or not.  Certainly  
> I'm not saying that everybody and everything has to be perfect (and  
> certainly I am not), but sometimes it sees like there is nobody  
> using Shark any more in ofbiz.  Of course, if I'm wrong, then we  
> should keep it in by all means.
>
> On Oct 25, 2006, at 9: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
>>>>>> [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Si
>>>> [hidden email]
>>>>
>>>>
>>>>
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

David E Jones-2
In reply to this post by Jacopo Cappellato

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
>>>>> [hidden email]
>>>>>
>>>>>
>>>>>
>>>
>>> Best Regards,
>>>
>>> Si
>>> [hidden email]
>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

cjhowe
--- David E Jones <[hidden email]>
wrote:
...
> 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.
...
> -David

In addition to being able, from my point of view, it's
also seeing a clear benefit in utilizing a workflow
when most everything that is used by a large enough
mass in OFBiz is status driven by process and by UI.
The services and SECAs seem to overlap most of the
benefit that I currently understand workflows to
provide.  Everytime I've attempted to look into or use
a workflow style program I've either gotten lost in
the tech speak or found it too dificult to define a
benefiicial scenario that a program should "always"
perform a task.

If someone has a less tech heavy resource on shark or
any other workflow, I would appreciate it.
Reply | Threaded
Open this post in threaded view
|

Re: Disabling the Shark component?

Shi Yusen
In reply to this post by David E Jones-2
It's true that Shark is not popular any more. I saw OSWorkflow had some
codes on OFBiz but I didn't try.

For the BPM part, I have integrated jBPM (a JBoss workflow engine) with
OpenCms. So if you could provide a detail design, I'd like to spend 1 or
2 months in the next year to contribute a prototype of this part.

By the way, I opened a project opencms-ofbiz at sourceforge.net which
I'll start next week to integrate OFBiz with OpenCms through JMS. OFBiz
as the business engine and OpenCms as UI. Is JMS still available in
current version?

Regards,

Shi Yusen/Beijing Langhua Ltd.

在 2006-10-25三的 12:46 -0600,David E Jones写道:

> 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
> >>>>> [hidden email]
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>> Best Regards,
> >>>
> >>> Si
> >>> [hidden email]
> >>>
> >>>
> >>>
> >
>