I see, if that is the case then we should continue disabling them but do so in the components' own build.gradle file to make the build cleaner.
On Wed, Jul 27, 2016 at 3:58 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > Hmmm... not sure about this because jars with incompatible licenses should > not be required to build a release. > > Jacopo > > On Wed, Jul 27, 2016 at 2:18 PM, Taher Alkhateeb < > slidingfilame...@gmail.com > > wrote: > > > Actually, I think you can also enable these files and declare whatever > > proprietary libraries you need since they will be pulled from an external > > repository, please correct me if I'm wrong anyone I'm not the best guy to > > speak legalese in here. > > > > On Wed, Jul 27, 2016 at 3:07 PM, Taher Alkhateeb < > > slidingfilame...@gmail.com > > > wrote: > > > > > Hi Mridul, Everyone, > > > > > > Now that we have a stable running build, perhaps it's time to move > > forward > > > with this discussion? All the excluded java files are listed in the > > master > > > build.gradle. If you move them to specialpurpose we can figure out a > > simple > > > solution to hide these exclusions away from the master build script and > > > declare them in the components build.gradle files away from the > framework > > > and applications. > > > > > > Do we have an available JIRA? Are you still interested in applying the > > > work? > > > > > > Taher Alkhateeb > > > > > > On Sun, Jun 19, 2016 at 11:09 PM, Jacques Le Roux < > > > jacques.le.r...@les7arts.com> wrote: > > > > > >> This needs to be carefully reviewed indeed (I did not yet) > > >> > > >> Jacques > > >> > > >> > > >> Le 18/06/2016 à 13:00, Pierre Smits a écrit : > > >> > > >>> I agree that there are common patterns. And the common patterns > should > > be > > >>> in the base component, to enable the payment and shipment solution > > >>> integrations. These integration solutions should be optional when > > >>> implementing an OFBiz setup. > > >>> > > >>> An example please evaluate the MultiSafepay integration component I > > >>> created. > > >>> See for a high level description: > > >>> http://oem.ofbizci.net/oci-2/products/p_omultisafepay. > > >>> Visit for the code: https://github.com/ORRTIZ/omultisafepay > > >>> And for the implementation instruction: > > >>> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement > > >>> > > >>> This component applies the common patterns, without any new entities > to > > >>> be > > >>> created, and a minimal adjustment to the e-commerce and the product > > >>> component. > > >>> > > >>> Best regards, > > >>> > > >>> Pierre Smits > > >>> > > >>> ORRTIZ.COM <http://www.orrtiz.com> > > >>> OFBiz based solutions & services > > >>> > > >>> OFBiz Extensions Marketplace > > >>> http://oem.ofbizci.net/oci-2/ > > >>> > > >>> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak < > > >>> mridul.pat...@hotwaxsystems.com> wrote: > > >>> > > >>> Creating payment/shipping/tax solution specific components would > > >>>> introduce > > >>>> 17 new components to specialpurpose and that doesn’t seems like a > > >>>> favorable > > >>>> approach. > > >>>> > > >>>> These integrations usually share a common code pattern and in longer > > >>>> vision we could possibly implement payment/shipping integration > > >>>> frameworks > > >>>> with a lot lesser and cleaner code that makes introducing new > payment > > >>>> processor or shipping solution a lot easier with the help of > > >>>> configurations > > >>>> and little code. Most of us seems to be fine with three new > components > > >>>> for > > >>>> payment processor, tax integration and shipping integration and that > > >>>> would > > >>>> leave us room for further refactoring. > > >>>> > > >>>> I think many on this thread has already given approval for three new > > >>>> components so that’s the way we should go. > > >>>> > > >>>> -- > > >>>> Thanks & Regards, > > >>>> Mridul Pathak > > >>>> HotWax Systems > > >>>> http://www.hotwaxsystems.com > > >>>> > > >>>> On Jun 17, 2016, at 12:37 PM, Pierre Smits <pierre.sm...@gmail.com> > > >>>>> > > >>>> wrote: > > >>>> > > >>>>> Hi all, > > >>>>> > > >>>>> Moving all 3rd party related integrations solutions from > accounting, > > >>>>> product and order into 1 special purpose component makes is worse > to > > >>>>> maintain. Moving those from accounting into one in special purpose, > > >>>>> those > > >>>>> from product into one and those from order into another just shifts > > the > > >>>>> problem from the base applications stack to a another stack, which > is > > >>>>> the > > >>>>> complexity that results from the total being being bigger than the > > sum > > >>>>> of > > >>>>> its parts. > > >>>>> > > >>>>> I understand and accept that there might be adopters of old release > > out > > >>>>> there that are still on those old releases and use some (or all) of > > the > > >>>>> > > >>>> 3rd > > >>>> > > >>>>> party integrations. But I believe that breaking these sets up in to > > the > > >>>>> smaller components not only makes maintenance less complex but also > > >>>>> increases the appeal of OFBiz (visavis completeness and > flexibility). > > >>>>> > > >>>> Given > > >>>> > > >>>>> that this is in the 'improvement' section of what we do, I > understand > > >>>>> > > >>>> that, > > >>>> > > >>>>> it won't be back ported to running release branches. So, there is a > > >>>>> means > > >>>>> to communicate up front and prepare the adopters who want to > migrate. > > >>>>> > > >>>>> Therefore I suggest we split the 3rd party payment solutions > > >>>>> integrations > > >>>>> up into: > > >>>>> /specialpurpose/paypay > > >>>>> /specialpurpose/orbital > > >>>>> etc > > >>>>> > > >>>>> and the 3rd party shipment solutions integrations up into: > > >>>>> /specialpurpose/dhl > > >>>>> /specialpurpose/fedex > > >>>>> /specialpurpose/ups > > >>>>> etc > > >>>>> > > >>>>> and the same for the other 3rd party solutions integrations. > > >>>>> > > >>>>> After all, these functionalities should be optionals, not > mandatories > > >>>>> > > >>>> from > > >>>> > > >>>>> an integration perspective. Splitting them up will also bring the > > >>>>> benefit > > >>>>> of easier maintenance, bringing in contributors who are experienced > > >>>>> with > > >>>>> that piece of software and if adoption/use is 0, an easier path to > > the > > >>>>> attic (in stead of waiting and waiting untill all goes to being > > unused. > > >>>>> > > >>>>> Bringing this to separate components in special purpose doesn't > mean > > we > > >>>>> need to bring those into the build process (as long as they are not > > >>>>> > > >>>> fixed). > > >>>> > > >>>>> Leaving them out of the component-load.xml file (or commented out) > > will > > >>>>> avoid that, and give adopters an opt-in choice. > > >>>>> > > >>>>> So to recap: > > >>>>> +1 on the move out of the base applications stack > > >>>>> -1 on the move in catch-all components in another stack. > > >>>>> > > >>>>> Best regards, > > >>>>> > > >>>>> Pierre Smits > > >>>>> > > >>>>> ORRTIZ.COM <http://www.orrtiz.com> > > >>>>> OFBiz based solutions & services > > >>>>> > > >>>>> OFBiz Extensions Marketplace > > >>>>> http://oem.ofbizci.net/oci-2/ > > >>>>> > > >>>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb < > > >>>>> > > >>>> slidingfilame...@gmail.com > > >>>> > > >>>>> wrote: > > >>>>>> +1 thank you for your dedication and thinking of this > > >>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" < > > >>>>>> > > >>>>> mridul.pat...@hotwaxsystems.com> > > >>>> > > >>>>> wrote: > > >>>>>> > > >>>>>> Hi Taher, > > >>>>>>> > > >>>>>>> I was just trying to suggest that we will have to create two > > >>>>>>> components > > >>>>>>> > > >>>>>> in > > >>>>>> > > >>>>>>> specialpurpose, one for payment processor related functionality > and > > >>>>>>> one > > >>>>>>> > > >>>>>> for > > >>>>>> > > >>>>>>> tax related functionality and the reason behind it. Which means > we > > >>>>>>> > > >>>>>> should > > >>>> > > >>>>> probably drop the idea of introducing a directory named “reference” > > and > > >>>>>>> instead create two separate components. > > >>>>>>> > > >>>>>>> Our main goal here is to move these files out of core > applications > > >>>>>>> and > > >>>>>>> most of us are fine with moving it to specialpurpose. I think we > > can > > >>>>>>> conclude our approach as most of us seems fine with having two > > >>>>>>> separate > > >>>>>>> components in specialpurpose which was the original suggestion as > > >>>>>>> well. > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Thanks & Regards, > > >>>>>>> Mridul Pathak > > >>>>>>> HotWax Systems > > >>>>>>> http://www.hotwaxsystems.com > > >>>>>>> > > >>>>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb < > > >>>>>>>> > > >>>>>>> slidingfilame...@gmail.com> > > >>>>>> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> Hi Mridul, > > >>>>>>>> > > >>>>>>>> Thank you for the detailed and well thought out feedback. > > >>>>>>>> > > >>>>>>>> I am a little confused however, what is the point you are trying > > to > > >>>>>>>> > > >>>>>>> state? > > >>>>>>> > > >>>>>>>> The only point from my previous email was to suggest avoiding > > >>>>>>>> creating > > >>>>>>>> > > >>>>>>> a > > >>>>>> > > >>>>>>> directory called reference in the top level ofbiz directory and > > >>>>>>>> > > >>>>>>> instead > > >>>> > > >>>>> keep it in /specialpurpose. If you want to keep it in > > >>>>>>>> specialpurpose/reference, fine, if you want to keep it in > > >>>>>>>> specialpurpose/your-component-here fine, if you want to do > > anything > > >>>>>>>> in > > >>>>>>>> specialpurpose then also fine My point was simply to suggest > > >>>>>>>> steering > > >>>>>>>> > > >>>>>>> away > > >>>>>>> > > >>>>>>>> from ofbiz top level directory. > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> > > >>>>>>>> Taher Alkhateeb > > >>>>>>>> > > >>>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak < > > >>>>>>>> mridul.pat...@hotwaxsystems.com> wrote: > > >>>>>>>> > > >>>>>>>> Hi Taher, > > >>>>>>>>> > > >>>>>>>>> Payment integration files in accounting/thirdparty are not just > > >>>>>>>>> > > >>>>>>>> unused > > >>>> > > >>>>> files and all of it is not dead code. There is the whole > > >>>>>>>>> > > >>>>>>>> functionality > > >>>> > > >>>>> built around those files which is very crucial to production > delivery > > >>>>>>>>> > > >>>>>>>> of > > >>>>>> > > >>>>>>> order management or ecommerce on top of OFBiz. There are many > > service > > >>>>>>>>> definition files whose implementation is written in these java > > >>>>>>>>> files. > > >>>>>>>>> > > >>>>>>>> Some > > >>>>>>> > > >>>>>>>> examples are, > > >>>>>>>>> > > >>>>>>>>> accounting/servicedef/services_authorizedotnet.xml > > >>>>>>>>> accounting/servicedef/services_clearcommerce.xml > > >>>>>>>>> accounting/servicedef/services_cybersource.xml > > >>>>>>>>> accounting/servicedef/services_orbital.xml > > >>>>>>>>> accounting/servicedef/services_paypal.xml > > >>>>>>>>> etc. > > >>>>>>>>> > > >>>>>>>>> Along with that, many of the configurations needed to use these > > >>>>>>>>> > > >>>>>>>> payment > > >>>>>> > > >>>>>>> solutions are maintained in accounting/config/payment.properties > > >>>>>>>>> > > >>>>>>>> file. A > > >>>>>> > > >>>>>>> ProductStore in OFBiz as well can be configures to use on of > these > > >>>>>>>>> > > >>>>>>>> payment > > >>>>>>> > > >>>>>>>> processors. > > >>>>>>>>> > > >>>>>>>>> Also, these file are intentionally excluded from compile > process, > > >>>>>>>>> but > > >>>>>>>>> > > >>>>>>>> can > > >>>>>>> > > >>>>>>>> be included if you want to use/deliver one of these existing > > payment > > >>>>>>>>> solution in OFBiz in production. Following is the code snippet > > from > > >>>>>>>>> accounting/build.xml, > > >>>>>>>>> > > >>>>>>>>> <target name="init"> > > >>>>>>>>> <condition property="verisign-exclude" > > >>>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**"> > > >>>>>>>>> <not><available file="lib/payflow.jar"/></not> > > >>>>>>>>> </condition> > > >>>>>>>>> <patternset id="src.exc.set"> > > >>>>>>>>> <!-- exclude the payment processor packages; comment > this > > >>>>>>>>> out > > >>>>>>>>> > > >>>>>>>> to > > >>>>>> > > >>>>>>> not exclude if you have libs --> > > >>>>>>>>> <exclude name="${verisign-exclude}"/> > > >>>>>>>>> <exclude > > >>>>>>>>> > > >>>>>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/> > > >>>>>> > > >>>>>>> <exclude > > >>>>>>>>> > > name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/> > > >>>>>>>>> <exclude > > name="org/ofbiz/accounting/thirdparty/orbital/**"/> > > >>>>>>>>> <exclude > > >>>>>>>>> name="org/ofbiz/accounting/thirdparty/securepay/**"/> > > >>>>>>>>> <exclude > name="org/ofbiz/accounting/thirdparty/ideal/**"/> > > >>>>>>>>> </patternset> > > >>>>>>>>> </target> > > >>>>>>>>> > > >>>>>>>>> It clearly mentions that if you have required libraries for any > > of > > >>>>>>>>> > > >>>>>>>> the > > >>>> > > >>>>> third party payment solutions, you could comment out the exclusion. > > >>>>>>>>> Usually, when someone needs to use one of the available payment > > >>>>>>>>> > > >>>>>>>> processor, > > >>>>>>> > > >>>>>>>> they download the required jar and place it in accounting/lib > > >>>>>>>>> folder, > > >>>>>>>>> > > >>>>>>>> make > > >>>>>>> > > >>>>>>>> the needed changes in build.xml and they are ready to use the > > >>>>>>>>> > > >>>>>>>> respective > > >>>>>> > > >>>>>>> payment solution. > > >>>>>>>>> > > >>>>>>>>> We have used one or the other payment processors in OFBiz many > a > > >>>>>>>>> > > >>>>>>>> times > > >>>> > > >>>>> to > > >>>>>>> > > >>>>>>>> deliver payment solutions as part of the software. I believe > there > > >>>>>>>>> > > >>>>>>>> are > > >>>> > > >>>>> many > > >>>>>>> > > >>>>>>>> application users and service providers who might be using the > > >>>>>>>>> > > >>>>>>>> payment > > >>>> > > >>>>> processor functionality that comes with OFBiz OOTB. > > >>>>>>>>> > > >>>>>>>>> So, it’s not just about moving some files from core > applications > > to > > >>>>>>>>> > > >>>>>>>> some > > >>>>>> > > >>>>>>> other directory because they seems to be unused, the whole > > >>>>>>>>> > > >>>>>>>> functionality > > >>>>>> > > >>>>>>> needs to be moved so that current or future users of these > > >>>>>>>>> > > >>>>>>>> functionalities > > >>>>>>> > > >>>>>>>> can still use it. And that is the reason if we create a new > > special > > >>>>>>>>> > > >>>>>>>> purpose > > >>>>>>> > > >>>>>>>> component it will help us to keep the functionality intact and > > >>>>>>>>> usable > > >>>>>>>>> > > >>>>>>>> at > > >>>>>> > > >>>>>>> the same time separate it from core applications. That would also > > >>>>>>>>> > > >>>>>>>> enable us > > >>>>>>> > > >>>>>>>> to keep such components out of component-load.xml and > > >>>>>>>>> specialpurpose/build.xml. A README file would help the user > with > > >>>>>>>>> > > >>>>>>>> directions > > >>>>>>> > > >>>>>>>> to use it. > > >>>>>>>>> > > >>>>>>>>> Additionally, I feel that most of these files may need to be > > >>>>>>>>> upgraded > > >>>>>>>>> > > >>>>>>>> and > > >>>>>>> > > >>>>>>>> needs code refactoring probably because they might usually be > left > > >>>>>>>>> > > >>>>>>>> out > > >>>> > > >>>>> as > > >>>>>>> > > >>>>>>>> they do not compile by default with OFBiz. > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> Thanks & Regards, > > >>>>>>>>> Mridul Pathak > > >>>>>>>>> HotWax Systems > > >>>>>>>>> http://www.hotwaxsystems.com > > >>>>>>>>> > > >>>>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb < > > >>>>>>>>>> > > >>>>>>>>> slidingfilame...@gmail.com> > > >>>>>>> > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> Hey Folks, > > >>>>>>>>>> > > >>>>>>>>>> I would prefer to keep dead code away from the top level OFBiz > > >>>>>>>>>> > > >>>>>>>>> directory. > > >>>>>>> > > >>>>>>>> If you keep it there then you make it _closer_ to the framework! > > >>>>>>>>>> > > >>>>>>>>>> Anyway, I don't see a problem with keeping it in > specialpurpose! > > >>>>>>>>>> You > > >>>>>>>>>> > > >>>>>>>>> are > > >>>>>>> > > >>>>>>>> not creating a component, you are just creating a folder called > > >>>>>>>>>> > > >>>>>>>>> reference > > >>>>>>> > > >>>>>>>> and adding stuff to it, and you are not adding it to > > >>>>>>>>>> > > >>>>>>>>> component-load.xml? > > >>>>>>> > > >>>>>>>> Why is it that you cannot add it there? > > >>>>>>>>>> > > >>>>>>>>>> Regards, > > >>>>>>>>>> > > >>>>>>>>>> Taher Alkhateeb > > >>>>>>>>>> > > >>>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak < > > >>>>>>>>>> mridul.pat...@hotwaxsystems.com> wrote: > > >>>>>>>>>> > > >>>>>>>>>> Introducing new directory “reference” seems reasonable > approach > > to > > >>>>>>>>>>> > > >>>>>>>>>> me > > >>>>>> > > >>>>>>> as > > >>>>>>> > > >>>>>>>> it is a combined solution to everyone’s views. > > >>>>>>>>>>> > > >>>>>>>>>>> -- > > >>>>>>>>>>> Thanks & Regards, > > >>>>>>>>>>> Mridul Pathak > > >>>>>>>>>>> Senior Manager > > >>>>>>>>>>> HotWax Systems > > >>>>>>>>>>> http://www.hotwaxsystems.com > > >>>>>>>>>>> > > >>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux < > > >>>>>>>>>>>> > > >>>>>>>>>>> jacques.le.r...@les7arts.com> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> Hi Divesh, > > >>>>>>>>>>>> > > >>>>>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit : > > >>>>>>>>>>>> > > >>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing > > dependencies > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> code > > >>>>>>> > > >>>>>>>> highlight this issue somewhere visible to the programmer > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> (README, > > >>>>>>> > > >>>>>>>> whatever). Why is this important? Because we need to tell our > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> build > > >>>>>>>>> > > >>>>>>>>>> scripts > > >>>>>>>>>>>>>>>>> and our classpath settings to ignore these files. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in > > >>>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the > build > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> system > > >>>>>> > > >>>>>>> to > > >>>>>>> > > >>>>>>>> ignore > > >>>>>>>>>>> > > >>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> instead > > >>>>>>> > > >>>>>>>> break it > > >>>>>>>>>>> > > >>>>>>>>>>>> up into multiple components, then I need to ignore the files > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> in > > >>>>>> > > >>>>>>> each > > >>>>>>>>> > > >>>>>>>>>> component by hand which makes the build script more complex > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> and > > >>>>>> > > >>>>>>> more prone > > >>>>>>>>>>> > > >>>>>>>>>>>> to human error and it would add to the confusion. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> I agree and I think your initial proposition ("How > about > > >>>>>>>>>>>>>>> reference/paymentext and > > reference/whatever-else-you-want?") > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> was > > >>>> > > >>>>> not > > >>>>>>> > > >>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Divesh? > > >>>>>> > > >>>>>>> Actually Jacques, we cannot create component like > > >>>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we > > >>>>>>>>>>>>> > > >>>>>>>>>>>> introduce > > >>>>>> > > >>>>>>> new > > >>>>>>>>> > > >>>>>>>>>> directory "reference" in parallel to specialpurpose, > > applications > > >>>>>>>>>>>>> > > >>>>>>>>>>>> , > > >>>>>> > > >>>>>>> framework . Do you mean to do that ? > > >>>>>>>>>>>>> > > >>>>>>>>>>>> You are right, and following Taher's idea I missed this > point, > > >>>>>>>>>>>> it > > >>>>>>>>>>>> > > >>>>>>>>>>> seems > > >>>>>>> > > >>>>>>>> to me that your proposition of <<introducing a new directory > > >>>>>>>>>>> > > >>>>>>>>>> "reference" in > > >>>>>>>>> > > >>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the > > best > > >>>>>>>>>>> > > >>>>>>>>>> one > > >>>>>> > > >>>>>>> so > > >>>>>>> > > >>>>>>>> far. > > >>>>>>>>>>> > > >>>>>>>>>>>> It could be also that Taher anticipated on the work (I know) > > he > > >>>>>>>>>>>> > > >>>>>>>>>>> will > > >>>>>> > > >>>>>>> do > > >>>>>>> > > >>>>>>>> on refactoring the build system and this possibility will be > open > > >>>>>>>>>>> > > >>>>>>>>>> "soon", > > >>>>>>>>> > > >>>>>>>>>> Taher? > > >>>>>>>>>>> > > >>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping > > >>>>>>>>>>>>> > > >>>>>>>>>>>> integration/s" > > >>>>>> > > >>>>>>> which > > >>>>>>>>>>> > > >>>>>>>>>>>> "doesn’t have the compilation or library reference issues" > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> would > > >>>> > > >>>>> be > > >>>>>>> > > >>>>>>>> in its > > >>>>>>>>>>> > > >>>>>>>>>>>> own independent component/s (ie not under /reference), same > > for > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> other > > >>>>>>>>> > > >>>>>>>>>> stuff > > >>>>>>>>>>> > > >>>>>>>>>>>> with the same status, if exist. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> In this case, shipping integration can be under special > > >>>>>>>>>>>>> purpose. > > >>>>>>>>>>>>> > > >>>>>>>>>>>> So > > >>>>>> > > >>>>>>> specialpurpose/shippingIntegratio. > > >>>>>>>>>>>>> > > >>>>>>>>>>>> Clearly, nobrainer :) > > >>>>>>>>>>>> > > >>>>>>>>>>>> Jacques > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Thanks > > >>>>>>>>>>>>> -- > > >>>>>>>>>>>>> Divesh Dutta. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>> > > >>>>>>> > > >>>> > > >> > > > > > >
