Login  Register

Re: Disabling the Shark component?

Posted by David E Jones-2 on Oct 25, 2006; 7:21pm
URL: http://ofbiz.116.s1.nabble.com/Disabling-the-Shark-component-tp173572p173582.html


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]
>
>
>