Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java

[Scott Gray-2]

Can a boolean be compared to an integer or did you just break it again?

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 26/11/2009, at 11:29 AM, [hidden email] wrote:

> Author: jleroux
> Date: Wed Nov 25 22:29:21 2009
> New Revision: 884308
>
> URL: http://svn.apache.org/viewvc?rev=884308&view=rev
> Log:
> Complete Scott's fix in r884292 (using initial code in r821643
>
> Modified:
>    ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
> EntityRepositoryMgr.java
>
> Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
> repository/EntityRepositoryMgr.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
> EntityRepositoryMgr.java (original)
> +++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
> EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
> @@ -177,7 +177,7 @@
>
>     public boolean doesXPDLExist(RepositoryTransaction t, String  
> xpdlId) throws RepositoryException {
>         List xpdls = this.getXpdlValues(xpdlId, null, false);
> -        Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,  
> module);
> +        Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls +  
> "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) + ")",  
> module);
>         return (UtilValidate.isNotEmpty(xpdls) ? true : false);
>     }
>
>
>

[Jacques Le Roux]

Oops, Sorry

I missed "> 0" when replacing  xpdls != null && xpdls.size() > 0 by UtilValidate.isNotEmpty(xpdls)
Fixed at r884325

The reason of all these troubles is that Shark is not compiled anymore, not Workflow (this answer Adam question).
Do we really need to keep them in trunk ? We may put them aside but still accessible ?

Jacques

From: "Scott Gray" <[hidden email]>

> Can a boolean be compared to an integer or did you just break it again?
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 26/11/2009, at 11:29 AM, [hidden email] wrote:
>
>> Author: jleroux
>> Date: Wed Nov 25 22:29:21 2009
>> New Revision: 884308
>>
>> URL: http://svn.apache.org/viewvc?rev=884308&view=rev
>> Log:
>> Complete Scott's fix in r884292 (using initial code in r821643
>>
>> Modified:
>>    ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java
>>
>> Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/ repository/EntityRepositoryMgr.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
>> = = = = = = = = ======================================================================
>> --- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java (original)
>> +++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
>> @@ -177,7 +177,7 @@
>>
>>     public boolean doesXPDLExist(RepositoryTransaction t, String  xpdlId) throws RepositoryException {
>>         List xpdls = this.getXpdlValues(xpdlId, null, false);
>> -        Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,  module);
>> +        Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls +  "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) +
>> ")",  module);
>>         return (UtilValidate.isNotEmpty(xpdls) ? true : false);
>>     }
>>
>>
>>
>
>

[Scott Gray-2]

On 26/11/2009, at 11:58 AM, Jacques Le Roux wrote:

> Oops, Sorry
>
> I missed "> 0" when replacing  xpdls != null && xpdls.size() > 0 by  
> UtilValidate.isNotEmpty(xpdls)
> Fixed at r884325

Thanks Jacques

>
> The reason of all these troubles is that Shark is not compiled  
> anymore, not Workflow (this answer Adam question).
> Do we really need to keep them in trunk ? We may put them aside but  
> still accessible ?

When raising discussions like this it is always better to go back and  
read the previous discussions on the same topic and commenting with  
those in mind.  It is really pointless for us to keep rehashing the  
same issue unless anything has changed since the last time.

>
> Jacques
>
> From: "Scott Gray" <[hidden email]>
>> Can a boolean be compared to an integer or did you just break it  
>> again?
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 26/11/2009, at 11:29 AM, [hidden email] wrote:
>>
>>> Author: jleroux
>>> Date: Wed Nov 25 22:29:21 2009
>>> New Revision: 884308
>>>
>>> URL: http://svn.apache.org/viewvc?rev=884308&view=rev
>>> Log:
>>> Complete Scott's fix in r884292 (using initial code in r821643
>>>
>>> Modified:
>>>   ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/  
>>> EntityRepositoryMgr.java
>>>
>>> Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/  
>>> repository/EntityRepositoryMgr.java
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
>>> = = = = = = = =  
>>> =
>>> =
>>> ====================================================================
>>> --- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
>>> repository/ EntityRepositoryMgr.java (original)
>>> +++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
>>> repository/ EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
>>> @@ -177,7 +177,7 @@
>>>
>>>    public boolean doesXPDLExist(RepositoryTransaction t, String  
>>> xpdlId) throws RepositoryException {
>>>        List xpdls = this.getXpdlValues(xpdlId, null, false);
>>> -        Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,  
>>> module);
>>> +        Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls  
>>> +  "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) +  
>>> ")",  module);
>>>        return (UtilValidate.isNotEmpty(xpdls) ? true : false);
>>>    }
>>>
>>>
>>>
>>
>
>

[Adrian Crum]

Except for it being touched occasionally by project-wide changes, I
haven't seen any work done in the Shark component in years.

-Adrian

Jacques Le Roux wrote:

> Oops, Sorry
>
> I missed "> 0" when replacing  xpdls != null && xpdls.size() > 0 by
> UtilValidate.isNotEmpty(xpdls)
> Fixed at r884325
>
> The reason of all these troubles is that Shark is not compiled anymore,
> not Workflow (this answer Adam question).
> Do we really need to keep them in trunk ? We may put them aside but
> still accessible ?
>
> Jacques
>
> From: "Scott Gray" <[hidden email]>
>> Can a boolean be compared to an integer or did you just break it again?
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 26/11/2009, at 11:29 AM, [hidden email] wrote:
>>
>>> Author: jleroux
>>> Date: Wed Nov 25 22:29:21 2009
>>> New Revision: 884308
>>>
>>> URL: http://svn.apache.org/viewvc?rev=884308&view=rev
>>> Log:
>>> Complete Scott's fix in r884292 (using initial code in r821643
>>>
>>> Modified:
>>>    ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
>>> EntityRepositoryMgr.java
>>>
>>> Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
>>> repository/EntityRepositoryMgr.java
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff 
>>>
>>> = = = = = = = =
>>> ======================================================================
>>> --- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
>>> EntityRepositoryMgr.java (original)
>>> +++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
>>> EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
>>> @@ -177,7 +177,7 @@
>>>
>>>     public boolean doesXPDLExist(RepositoryTransaction t, String  
>>> xpdlId) throws RepositoryException {
>>>         List xpdls = this.getXpdlValues(xpdlId, null, false);
>>> -        Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,  
>>> module);
>>> +        Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls +  
>>> "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) + ")",  
>>> module);
>>>         return (UtilValidate.isNotEmpty(xpdls) ? true : false);
>>>     }
>>>
>>>
>>>
>>
>>
>
>
>

[Jacques Le Roux]

From: "Scott Gray" <[hidden email]>

> On 26/11/2009, at 11:58 AM, Jacques Le Roux wrote:
>
>> Oops, Sorry
>>
>> I missed "> 0" when replacing  xpdls != null && xpdls.size() > 0 by  UtilValidate.isNotEmpty(xpdls)
>> Fixed at r884325
>
> Thanks Jacques
>
>>
>> The reason of all these troubles is that Shark is not compiled  anymore, not Workflow (this answer Adam question).
>> Do we really need to keep them in trunk ? We may put them aside but  still accessible ?
>
> When raising discussions like this it is always better to go back and  read the previous discussions on the same topic and
> commenting with  those in mind.  It is really pointless for us to keep rehashing the  same issue unless anything has changed since
> the last time.

Actually if you have read all my message, I think a better proposition would be to remove them *also* from the JavaDoc ant target...

I'm trying to compile them currently, it failed on Delegator new stuff, should not be too hard to solve, looking at it quickly...

Jacques

>>
>> Jacques
>>
>> From: "Scott Gray" <[hidden email]>
>>> Can a boolean be compared to an integer or did you just break it  again?
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 26/11/2009, at 11:29 AM, [hidden email] wrote:
>>>
>>>> Author: jleroux
>>>> Date: Wed Nov 25 22:29:21 2009
>>>> New Revision: 884308
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=884308&view=rev
>>>> Log:
>>>> Complete Scott's fix in r884292 (using initial code in r821643
>>>>
>>>> Modified:
>>>>   ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/  EntityRepositoryMgr.java
>>>>
>>>> Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/  repository/EntityRepositoryMgr.java
>>>> URL:
>>>> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
>>>> = = = = = = = =  = = ====================================================================
>>>> --- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/ repository/ EntityRepositoryMgr.java (original)
>>>> +++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/ repository/ EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
>>>> @@ -177,7 +177,7 @@
>>>>
>>>>    public boolean doesXPDLExist(RepositoryTransaction t, String   xpdlId) throws RepositoryException {
>>>>        List xpdls = this.getXpdlValues(xpdlId, null, false);
>>>> -        Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,   module);
>>>> +        Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls  +  "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false)
>>>> +  ")",  module);
>>>>        return (UtilValidate.isNotEmpty(xpdls) ? true : false);
>>>>    }
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

[Scott Gray-2]

On 26/11/2009, at 12:20 PM, Jacques Le Roux wrote:

> From: "Scott Gray" <[hidden email]>
>> On 26/11/2009, at 11:58 AM, Jacques Le Roux wrote:
>>> The reason of all these troubles is that Shark is not compiled  
>>> anymore, not Workflow (this answer Adam question).
>>> Do we really need to keep them in trunk ? We may put them aside  
>>> but  still accessible ?
>>
>> When raising discussions like this it is always better to go back  
>> and  read the previous discussions on the same topic and commenting  
>> with  those in mind.  It is really pointless for us to keep  
>> rehashing the  same issue unless anything has changed since the  
>> last time.
>
> Actually if you have read all my message, I think a better  
> proposition would be to remove them *also* from the JavaDoc ant  
> target...

I did read your entire message but removing them from the javadoc  
build is a separate discussion to removing them from the trunk and I  
didn't respond to it because it had already been discussed on the  
r884292 thread.

[Jacques Le Roux]

I thought it would be easy to compile after some changes. But obviously nobody has done this for some time.
It's late here, so I reopened https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a "shark.patch" from my current WIP, if
someone  wants to give it a try...

Jacques

From: "Adrian Crum" <[hidden email]>

> Except for it being touched occasionally by project-wide changes, I haven't seen any work done in the Shark component in years.
>
> -Adrian
>
> Jacques Le Roux wrote:
>> Oops, Sorry
>>
>> I missed "> 0" when replacing  xpdls != null && xpdls.size() > 0 by UtilValidate.isNotEmpty(xpdls)
>> Fixed at r884325
>>
>> The reason of all these troubles is that Shark is not compiled anymore, not Workflow (this answer Adam question).
>> Do we really need to keep them in trunk ? We may put them aside but still accessible ?
>>
>> Jacques
>>
>> From: "Scott Gray" <[hidden email]>
>>> Can a boolean be compared to an integer or did you just break it again?
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 26/11/2009, at 11:29 AM, [hidden email] wrote:
>>>
>>>> Author: jleroux
>>>> Date: Wed Nov 25 22:29:21 2009
>>>> New Revision: 884308
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=884308&view=rev
>>>> Log:
>>>> Complete Scott's fix in r884292 (using initial code in r821643
>>>>
>>>> Modified:
>>>>    ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java
>>>>
>>>> Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/ repository/EntityRepositoryMgr.java
>>>> URL:
>>>> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
>>>> = = = = = = = = ======================================================================
>>>> --- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java (original)
>>>> +++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
>>>> @@ -177,7 +177,7 @@
>>>>
>>>>     public boolean doesXPDLExist(RepositoryTransaction t, String  xpdlId) throws RepositoryException {
>>>>         List xpdls = this.getXpdlValues(xpdlId, null, false);
>>>> -        Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,  module);
>>>> +        Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls +  "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) +
>>>> ")",  module);
>>>>         return (UtilValidate.isNotEmpty(xpdls) ? true : false);
>>>>     }
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

[Adam Heath-2]

Jacques Le Roux wrote:
> I thought it would be easy to compile after some changes. But obviously
> nobody has done this for some time.
> It's late here, so I reopened
> https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a
> "shark.patch" from my current WIP, if someone  wants to give it a try...
>
> Jacques

Working on it...

[Adam Heath-2]

Adam Heath wrote:

> Jacques Le Roux wrote:
>> I thought it would be easy to compile after some changes. But obviously
>> nobody has done this for some time.
>> It's late here, so I reopened
>> https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a
>> "shark.patch" from my current WIP, if someone  wants to give it a try...
>>
>> Jacques
>
> Working on it...

I vote to remove it.  Latest shark is LGPL, which isn't compatible.

[Scott Gray-2]

On 26/11/2009, at 1:37 PM, Adam Heath wrote:

> Adam Heath wrote:
>> Jacques Le Roux wrote:
>>> I thought it would be easy to compile after some changes. But  
>>> obviously
>>> nobody has done this for some time.
>>> It's late here, so I reopened
>>> https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a
>>> "shark.patch" from my current WIP, if someone  wants to give it a  
>>> try...
>>>
>>> Jacques
>>
>> Working on it...
>
> I vote to remove it.  Latest shark is LGPL, which isn't compatible.

That has always been the case, we need a better rationale for removal.

Regards
Scott

[Scott Gray-2]

On 26/11/2009, at 1:47 PM, Scott Gray wrote:

> On 26/11/2009, at 1:37 PM, Adam Heath wrote:
>
>> Adam Heath wrote:
>>> Jacques Le Roux wrote:
>>>> I thought it would be easy to compile after some changes. But  
>>>> obviously
>>>> nobody has done this for some time.
>>>> It's late here, so I reopened
>>>> https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a
>>>> "shark.patch" from my current WIP, if someone  wants to give it a  
>>>> try...
>>>>
>>>> Jacques
>>>
>>> Working on it...
>>
>> I vote to remove it.  Latest shark is LGPL, which isn't compatible.
>
> That has always been the case, we need a better rationale for removal.
>
> Regards
> Scott

Also here are a couple of previous threads regarding this topic:
http://markmail.org/thread/jwjh6v7dqeq5z4bn
http://markmail.org/thread/x2cv6m2ikfw7m55g

Regards
Scott

[Adrian Crum-2]

Thanks for the links Scott.

David makes a good point: If it isn't doing any harm, then just leave it in there - someone might use it. And various people have tried to use it - with mixed success. I did a Google search, and for the last two years user questions about the Shark component have been left unanswered.

What bothers me about it as a developer is what happens from time to time when the Shark component needs to be modified in order to make it compatible with changes in the framework. The rest of the project continues to move forward, and that component just sits there. When I make changes to it because of some change in the framework, I have no way to test those changes - because I can't compile it without the required libraries, and even if I could, I have no idea how to use it or test it. I end up crossing my fingers and hoping I didn't break anything.

So, I have mixed feelings about removing it. I'm undecided.

-Adrian

--- On Wed, 11/25/09, Scott Gray <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
> To: [hidden email]
> Date: Wednesday, November 25, 2009, 4:55 PM
> On 26/11/2009, at 1:47 PM, Scott Gray
> wrote:
>
> > On 26/11/2009, at 1:37 PM, Adam Heath wrote:
> >
> >> Adam Heath wrote:
> >>> Jacques Le Roux wrote:
> >>>> I thought it would be easy to compile
> after some changes. But obviously
> >>>> nobody has done this for some time.
> >>>> It's late here, so I reopened
> >>>> https://issues.apache.org/jira/browse/OFBIZ-552 and
> uploaded a
> >>>> "shark.patch" from my current WIP, if
> someone  wants to give it a try...
> >>>>
> >>>> Jacques
> >>>
> >>> Working on it...
> >>
> >> I vote to remove it.  Latest shark is LGPL,
> which isn't compatible.
> >
> > That has always been the case, we need a better
> rationale for removal.
> >
> > Regards
> > Scott
>
> Also here are a couple of previous threads regarding this
> topic:
> http://markmail.org/thread/jwjh6v7dqeq5z4bn
> http://markmail.org/thread/x2cv6m2ikfw7m55g
>
> Regards
> Scott

[Jacques Le Roux]

Personnally, I see more harms than benefits as time goes by. I think it's time for a vote.

If we don't remove it we should at least take care of issues like the one we just crossed with JavaDoc. Actually, I can't see any
other kind of issues, so simply commenting out JavaDoc targets in /shark/build.xml (with a comment about like in
framework/build.xml) would be sufficient in this case.

If we remove it, we could attach an archive of the component at https://issues.apache.org/jira/browse/OFBIZ-552. And as David said
(thanks for the links Scott), we should do the same for the workflow component which is even older...

This is my opinion

Jacques

From: "Adrian Crum" <[hidden email]>

> Thanks for the links Scott.
>
> David makes a good point: If it isn't doing any harm, then just leave it in there - someone might use it. And various people have
> tried to use it - with mixed success. I did a Google search, and for the last two years user questions about the Shark component
> have been left unanswered.
>
> What bothers me about it as a developer is what happens from time to time when the Shark component needs to be modified in order
> to make it compatible with changes in the framework. The rest of the project continues to move forward, and that component just
> sits there. When I make changes to it because of some change in the framework, I have no way to test those changes - because I
> can't compile it without the required libraries, and even if I could, I have no idea how to use it or test it. I end up crossing
> my fingers and hoping I didn't break anything.
>
> So, I have mixed feelings about removing it. I'm undecided.
>
> -Adrian
>
> --- On Wed, 11/25/09, Scott Gray <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
>> To: [hidden email]
>> Date: Wednesday, November 25, 2009, 4:55 PM
>> On 26/11/2009, at 1:47 PM, Scott Gray
>> wrote:
>>
>> > On 26/11/2009, at 1:37 PM, Adam Heath wrote:
>> >
>> >> Adam Heath wrote:
>> >>> Jacques Le Roux wrote:
>> >>>> I thought it would be easy to compile
>> after some changes. But obviously
>> >>>> nobody has done this for some time.
>> >>>> It's late here, so I reopened
>> >>>> https://issues.apache.org/jira/browse/OFBIZ-552 and
>> uploaded a
>> >>>> "shark.patch" from my current WIP, if
>> someone wants to give it a try...
>> >>>>
>> >>>> Jacques
>> >>>
>> >>> Working on it...
>> >>
>> >> I vote to remove it. Latest shark is LGPL,
>> which isn't compatible.
>> >
>> > That has always been the case, we need a better
>> rationale for removal.
>> >
>> > Regards
>> > Scott
>>
>> Also here are a couple of previous threads regarding this
>> topic:
>> http://markmail.org/thread/jwjh6v7dqeq5z4bn
>> http://markmail.org/thread/x2cv6m2ikfw7m55g
>>
>> Regards
>> Scott
>
>
>
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>
> Personnally, I see more harms than benefits as time goes by. I think it's time for a vote.
>
> If we don't remove it we should at least take care of issues like the one we just crossed with JavaDoc. Actually, I can't see any
> other kind of issues, so simply commenting out JavaDoc targets in /shark/build.xml (with a comment about like in
> framework/build.xml) would be sufficient in this case.

Should be <<with a comment about it like in speciapurpose/build.xml>>
Jacques

> If we remove it, we could attach an archive of the component at https://issues.apache.org/jira/browse/OFBIZ-552. And as David said
> (thanks for the links Scott), we should do the same for the workflow component which is even older...
>
> This is my opinion
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> Thanks for the links Scott.
>>
>> David makes a good point: If it isn't doing any harm, then just leave it in there - someone might use it. And various people have
>> tried to use it - with mixed success. I did a Google search, and for the last two years user questions about the Shark component
>> have been left unanswered.
>>
>> What bothers me about it as a developer is what happens from time to time when the Shark component needs to be modified in order
>> to make it compatible with changes in the framework. The rest of the project continues to move forward, and that component just
>> sits there. When I make changes to it because of some change in the framework, I have no way to test those changes - because I
>> can't compile it without the required libraries, and even if I could, I have no idea how to use it or test it. I end up crossing
>> my fingers and hoping I didn't break anything.
>>
>> So, I have mixed feelings about removing it. I'm undecided.
>>
>> -Adrian
>>
>> --- On Wed, 11/25/09, Scott Gray <[hidden email]> wrote:
>>
>>> From: Scott Gray <[hidden email]>
>>> Subject: Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
>>> To: [hidden email]
>>> Date: Wednesday, November 25, 2009, 4:55 PM
>>> On 26/11/2009, at 1:47 PM, Scott Gray
>>> wrote:
>>>
>>> > On 26/11/2009, at 1:37 PM, Adam Heath wrote:
>>> >
>>> >> Adam Heath wrote:
>>> >>> Jacques Le Roux wrote:
>>> >>>> I thought it would be easy to compile
>>> after some changes. But obviously
>>> >>>> nobody has done this for some time.
>>> >>>> It's late here, so I reopened
>>> >>>> https://issues.apache.org/jira/browse/OFBIZ-552 and
>>> uploaded a
>>> >>>> "shark.patch" from my current WIP, if
>>> someone wants to give it a try...
>>> >>>>
>>> >>>> Jacques
>>> >>>
>>> >>> Working on it...
>>> >>
>>> >> I vote to remove it. Latest shark is LGPL,
>>> which isn't compatible.
>>> >
>>> > That has always been the case, we need a better
>>> rationale for removal.
>>> >
>>> > Regards
>>> > Scott
>>>
>>> Also here are a couple of previous threads regarding this
>>> topic:
>>> http://markmail.org/thread/jwjh6v7dqeq5z4bn
>>> http://markmail.org/thread/x2cv6m2ikfw7m55g
>>>
>>> Regards
>>> Scott
>>
>>
>>
>>
>

[Adam Heath-2]

Jacques Le Roux wrote:
> Personnally, I see more harms than benefits as time goes by. I think
> it's time for a vote.

+1 to remove

> If we don't remove it we should at least take care of issues like the
> one we just crossed with JavaDoc. Actually, I can't see any other kind
> of issues, so simply commenting out JavaDoc targets in /shark/build.xml
> (with a comment about like in framework/build.xml) would be sufficient
> in this case.

Well, I've made it compile, which should fix basic parse issues with
javadoc.

> If we remove it, we could attach an archive of the component at
> https://issues.apache.org/jira/browse/OFBIZ-552. And as David said
> (thanks for the links Scott), we should do the same for the workflow
> component which is even older...

Don't need to attach an archive.  It'll exist in svn history.

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>
> Jacques Le Roux wrote:
>> Personnally, I see more harms than benefits as time goes by. I think
>> it's time for a vote.
>
> +1 to remove

Not official, but +1 from me too

>
>> If we don't remove it we should at least take care of issues like the
>> one we just crossed with JavaDoc. Actually, I can't see any other kind
>> of issues, so simply commenting out JavaDoc targets in /shark/build.xml
>> (with a comment about like in framework/build.xml) would be sufficient
>> in this case.
>
> Well, I've made it compile, which should fix basic parse issues with
> javadoc.

Yes, thanks Adam, but we all know this will come over and over in the future...
 
>> If we remove it, we could attach an archive of the component at
>> https://issues.apache.org/jira/browse/OFBIZ-552. And as David said
>> (thanks for the links Scott), we should do the same for the workflow
>> component which is even older...
>
> Don't need to attach an archive.  It'll exist in svn history.

Maybe it's more convenient though to have all ready in one place.

Jacques

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Adam Heath" <[hidden email]>
>> Jacques Le Roux wrote:
>>> Personnally, I see more harms than benefits as time goes by. I think
>>> it's time for a vote.
>>
>> +1 to remove
>
> Not official, but +1 from me too
>
>>
>>> If we don't remove it we should at least take care of issues like the
>>> one we just crossed with JavaDoc. Actually, I can't see any other kind
>>> of issues, so simply commenting out JavaDoc targets in /shark/build.xml
>>> (with a comment about like in framework/build.xml) would be sufficient
>>> in this case.
>>
>> Well, I've made it compile, which should fix basic parse issues with
>> javadoc.
>
> Yes, thanks Adam, but we all know this will come over and over in the future...
>
>>> If we remove it, we could attach an archive of the component at
>>> https://issues.apache.org/jira/browse/OFBIZ-552. And as David said
>>> (thanks for the links Scott), we should do the same for the workflow
>>> component which is even older...
>>
>> Don't need to attach an archive.  It'll exist in svn history.
>
> Maybe it's more convenient though to have all ready in one place.

We could also create a deprecated directories and put there all deprecated components in the future (for now workflow and shark) ?
There will be easy to reach with special directions to use but disconnected from current work...

Jacques
 
> Jacques
>

[Tim Ruppert]

+1 to remove.

Cheers,

Ruppert

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Nov 26, 2009, at 12:32 AM, Jacques Le Roux wrote:

From: "Adam Heath" <[hidden email]>

Jacques Le Roux wrote:

Personnally, I see more harms than benefits as time goes by. I think

it's time for a vote.

+1 to remove

Not official, but +1 from me too