Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Locked
123
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
123
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
 
|
Still not an excuse - how about an email before you are "too far down the road" that began to ask about the current implementation and what you were planning on doing? That alone would have likely done two things:
1. Forced the community to better document the current implementation. 2. Forced you to think thru whether or not you wanted to support the entire set of functions in the new one or just build in the minor changes you needed into the SDK version. Again, not picking on you - but this is really just something that we should still go back and have the conversation on so that it's clear for all people going forward. Cheers, Ruppert On Feb 5, 2010, at 1:21 AM, Hans Bakker wrote: > A lot of assumptions in this email...... > > perhaps a question for you: > who wrote the help screens in the old ebay component? > > please guide me to another place where this component is explained? > > Regards > Hans > > On Fri, 2010-02-05 at 00:16 -0700, Scott Gray wrote: >> On 4/02/2010, at 10:58 PM, Sam Hamilton wrote: >> >>> Couple of things >>> >>> 1. calling one ebay and one ebaystore is confusing when browsing the >>> source tree - perhaps once we know what the difference is between them >>> call them that? If its correct - call one eBay-XML and the other >>> eBay-API for example. >> >> One uses direct XML and the other is using eBay's SDK to do the heavy lifting. They both use the same API and the use of the SDK is mostly just a excuse for implementing the same thing in a different way. >> >>> >>> 2. eBay has a huge amount of developer documentation once we know what >>> the difference is how about putting a README file in the folder of each >>> pointing to the eBay docs showing what each component is capable of >>> achieving? http://developer.ebay.com/ >> >> Both have the potential to achieve the same goals but it is likely they will just end up taking two different approaches to achieve the same thing. >> Hans may document his component but the other component will likely remain as is (it may have some documentation, I don't know). Either way, the need to document (and continue to document as the components change) the differences between the two is just additional effort required by the community for no good reason, or at least I'm yet to hear a good reason other than "sorry I'm in a hurry". >> >>> 3. If the ebaystore module does everything that the ebay module >>> currently does then why is getting rid of ebay module a bad thing? >> >> There is no guarantee (and it seems pretty unlikely) that the ebaystore will do everything that the ebay module does, while they may achieve the same goals the differences from the user's perspective will likely be quite large. The main reason for the new implementation is that Hans doesn't understand the existing one and found it easier to just start fresh. >> >> All we're really ending up with here is a stack of duplication and additional analysis effort with no benefit. >> >>> >>> Sam >>> >>> >>> On 05/02/2010 12:42, Tim Ruppert wrote: >>>> How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system. >>>> >>>> It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. >>>> >>>> Cheers, >>>> Ruppert >>>> >>>> On Feb 4, 2010, at 2:50 AM, Jacques Le Roux wrote: >>>> >>>>> I will try to have a look today, in order to introduce a 3d party in this discussion... >>>>> >>>>> Jacques >>>>> >>>>> From: "Scott Gray" <[hidden email]> >>>>> Haan, >>>>> >>>>> I'm sorry to hear that, I guess if no one else feels strongly about this then I'll bow out and allow you to continue with your >>>>> duplication of existing code. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>>>> On 3/02/2010, at 11:52 PM, Hans Bakker wrote: >>>>> >>>>>> Scoot, >>>>>> >>>>>> i am sorry. As I mentioned in another email jacopo already saw that we >>>>>> are too far down the road. I cannot change. Anybody with Ebay knowledge >>>>>> would appreciate this contribution and replace the old ebay component >>>>>> directly with the new one. >>>>>> >>>>>> I am sorry i am very busy here and cannot spend more time on this. >>>>>> >>>>>> Hans. >>>>>> >>>>>> p.s. my reaction was on my proposal to have a "work in progress list >>>>>> added" irrelevant anyway. >>>>>> >>>>>> >>>>>> On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote: >>>>>>> On 3/02/2010, at 11:04 PM, Hans Bakker wrote: >>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> I only wondering why you send this email, can you explain that to me? >>>>>>> >>>>>>> As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree >>>>>>> with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? >>>>>>> >>>>>>>> Anyway, thanks for asking, i still think it is required. It showed with >>>>>>>> the ebay component: >>>>>>>> >>>>>>>> 1. creators of the original component would have liked to discuss it. >>>>>>> >>>>>>> Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? >>>>>>> Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide >>>>>>> you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which >>>>>>> will ultimately cause harm to the community. >>>>>>> >>>>>>>> 2. a non committer had already developed a component as we just did. >>>>>>> >>>>>>> Huh? How is that relevant? >>>>>>> >>>>>>>> so a lot of effort could have been saved here..... >>>>>>>> >>>>>>>> However if nobody wants it, sure i will give up. >>>>>>>> >>>>>>>> don't worry about that. >>>>>>> >>>>>>> It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users >>>>>>> confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hans >>>>>>>> >>>>>>>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >>>>>>>>> Hi Hans, >>>>>>>>> >>>>>>>>> Based on your recent commits I guess your considering this discussion over? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>>>>>>>>> >>>>>>>>>>> Jacopo, >>>>>>>>>>> >>>>>>>>>>> what we need is a wiki page where people can announce activities and >>>>>>>>>>> plans. Not only from committers but also from contributors and perhaps >>>>>>>>>>> even users. >>>>>>>>>>> >>>>>>>>>>> I have proposed this before. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think we already have something similar: >>>>>>>>>> >>>>>>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>>>>>>>>> >>>>>>>>>>> In this case we tried to extend the existing ebay component but found >>>>>>>>>>> out that the xml interface could never support the required functions as >>>>>>>>>>> we needed them. >>>>>>>>>> >>>>>>>>>> This is not a good reason for stopping your research about supported features and building a new component. >>>>>>>>>> The valid options I see are: >>>>>>>>>> 1) adding *new* features to the original component using the different technology >>>>>>>>>> 2) and enhancing the existing features, where needed, using the XML approach or >>>>>>>>>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>>> Please also remember that not all required functions >>>>>>>>>>> were known from the start. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Hans >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>>>>>>>>> Hi Hans, >>>>>>>>>>>> >>>>>>>>>>>> first of all, thank you for contributing this big amount of code. >>>>>>>>>>>> >>>>>>>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Scott, >>>>>>>>>>>>> >>>>>>>>>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>>>>>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>>>>>>>>> user requirements of the original ebay component. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause >>>>>>>>>>>> maintenance problems and confusion; I guess we will all agree on this. >>>>>>>>>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new >>>>>>>>>>>> feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and >>>>>>>>>>>> do our best to enhance the existing stuff? >>>>>>>>>>>> >>>>>>>>>>>>> Now we moved the new functionality to a separate component it is getting >>>>>>>>>>>>> more clear if the old component is still required or not. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of >>>>>>>>>>>> you studying the original ebay component we will have to study your new work and verify if the new component implements all >>>>>>>>>>>> the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>>>>>>>>> >>>>>>>>>>>> Kind regards, >>>>>>>>>>>> >>>>>>>>>>>> Jacopo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Let us first complete the new component and get it fully tested and then >>>>>>>>>>>>> restart this discussion. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Hans >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a >>>>>>>>>>>>>> bad idea. >>>>>>>>>>>>>> Please correct me if any of the following is wrong: >>>>>>>>>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant >>>>>>>>>>>>>> is eBay SDK vs. using XML directly? >>>>>>>>>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use >>>>>>>>>>>>>> of raw SOAP or XML when interacting with the actual API? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved >>>>>>>>>>>>>> to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just >>>>>>>>>>>>>> result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with >>>>>>>>>>>>>> huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK >>>>>>>>>>>>>> will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Scott >>>>>>>>>>>>>> >>>>>>>>>>>>>> HotWax Media >>>>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Author: hansbak >>>>>>>>>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>>>>>>>>> New Revision: 905876 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>>>>>>>>> Log: >>>>>>>>>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>> >>>>> >>>>> >>>> >>> >> > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > |
smime.p7s (3K)
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by Adam Heath-2
Fellow committer is in direct response to being clear that it doesn't matter who I'm talking to - Hans, Adam, Scott, David, etc. I'm not calling out a person in particular - only calling out the committer who instead of giving us an improved ebay component has decided to give everyone both a new ebay component and the job of figuring out what is up with these two strangely named, similarly scoped components.
My recommendation - even at this point - is that we start to have a discussion about all of the things this new component does, and the people who are using the old one can put all of their feature coverage on the table - then we can discuss how to bring them together. This may be one ebay component which utilizes both XML for some things and the SDK for others - but without knowing the feature coverage - we're screwed. In this case - it matters very little to anyone what the technology choice ends up being - it's all about: 1. Making it easier for everyone who downloads OFBiz to know what to do with eBay -- These multi channels sales are more and more important each day in this economy. 2. Consolidating so that next time the SDK adds something that the XML does not, we can make good decisions about how to achieve the new features. Let's have this conversation - the committer of the new ebay component should provide a quick outline of what is being supported by all the functions that are newly implemented. This should be easy since the development was just done. Then the people who developed and utilize the current ebay component can put the features out on the table for comparison as well. Once we have that, we can easily do the necessary gap analysis and discussion about what technologies support what, etc, etc. it could be that XML supports everything that we want and this new SDK becomes something that the committer needs to remove and keep in his own repository if there's no business reason to have it but we won't know that until the gap in understanding is bridged. I hope that clarifies the stance and the use of the words "fellow committer" - not trying to be condescending - just really trying to avoid the consistent "personal attack" vibe around here since this has nothing to do with any person in particular. Cheers, Ruppert On Feb 4, 2010, at 11:33 PM, Adam Heath wrote: > Tim Ruppert wrote: >> How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system. >> >> It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. > > Fellow committer seems a bit condescending to me. Not trying to pick > a fight here(which others seem to think is all I enjoy doing), just > trying to help you word your responses better. If I'm wrong, then go > ahead and ignore me. |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by David E. Jones-2
Just trying to not be personal - there is no attack in any message that's been sent. I was asked not to refer to people directly - so I have done that. I'll resend the message removing these words as well so that hopeful we can stop talking about "feelings" and can get directly to talking about the code that we all want to improve.
Cheers, Ruppert On Feb 5, 2010, at 7:05 AM, David E Jones wrote: > > If it has nothing to do with any person in particular, then there should be no need to refer to a person, not even in a way that attempts to disguise the fact that you are referring to a person like writing "Fellow Committer". When you use those words you ARE in fact talking about a person, and even if you don't say who it comes across as pretty clear that you are thinking of a particular person, so it just sounds weird and confusing in a sort of dehumanizing way. > > Isn't it possible to talk about the functionality and approach without commenting on people? It's fine to say that Hans wrote this after so and so wrote that and talk about the this and that and discuss what might be a better approach, and I don't think it's necessary to comment on motives or character or experience, whether a person is named or not. > > We're all people here, and I guess personally I'd rather be consider a person by my given name rather than a "Fellow Committer". If I wanted to be a number or a title, I'd be in a different line of work... > > -David > > > On Feb 5, 2010, at 7:12 AM, Tim Ruppert wrote: > >> Fellow committer is in direct response to being clear that it doesn't matter who I'm talking to - Hans, Adam, Scott, David, etc. I'm not calling out a person in particular - only calling out the committer who instead of giving us an improved ebay component has decided to give everyone both a new ebay component and the job of figuring out what is up with these two strangely named, similarly scoped components. >> >> My recommendation - even at this point - is that we start to have a discussion about all of the things this new component does, and the people who are using the old one can put all of their feature coverage on the table - then we can discuss how to bring them together. This may be one ebay component which utilizes both XML for some things and the SDK for others - but without knowing the feature coverage - we're screwed. >> >> In this case - it matters very little to anyone what the technology choice ends up being - it's all about: >> >> 1. Making it easier for everyone who downloads OFBiz to know what to do with eBay >> -- These multi channels sales are more and more important each day in this economy. >> 2. Consolidating so that next time the SDK adds something that the XML does not, we can make good decisions about how to achieve the new features. >> >> Let's have this conversation - the committer of the new ebay component should provide a quick outline of what is being supported by all the functions that are newly implemented. This should be easy since the development was just done. Then the people who developed and utilize the current ebay component can put the features out on the table for comparison as well. Once we have that, we can easily do the necessary gap analysis and discussion about what technologies support what, etc, etc. >> >> it could be that XML supports everything that we want and this new SDK becomes something that the committer needs to remove and keep in his own repository if there's no business reason to have it but we won't know that until the gap in understanding is bridged. I hope that clarifies the stance and the use of the words "fellow committer" - not trying to be condescending - just really trying to avoid the consistent "personal attack" vibe around here since this has nothing to do with any person in particular. >> >> Cheers, >> Ruppert >> >> On Feb 4, 2010, at 11:33 PM, Adam Heath wrote: >> >>> Tim Ruppert wrote: >>>> How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system. >>>> >>>> It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. >>> >>> Fellow committer seems a bit condescending to me. Not trying to pick >>> a fight here(which others seem to think is all I enjoy doing), just >>> trying to help you word your responses better. If I'm wrong, then go >>> ahead and ignore me. >> > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by samhamilton
Responding to this message - per Jacopo and David's request. Hopefully this gets us back to discussing how we can go about fixing the ambiguity that has been introduced and will push us to a consolidated front on these features:
--- My recommendation - even at this point - is that we start to have a discussion about all of the things this new component does, and the people who are using the old one can put all of their feature coverage on the table - then we can discuss how to bring them together. This may be one ebay component which utilizes both XML for some things and the SDK for others - but without knowing the feature coverage - we're screwed. In this case - it matters very little to anyone what the technology choice ends up being - it's all about: 1. Making it easier for everyone who downloads OFBiz to know what to do with eBay -- These multi channels sales are more and more important each day in this economy. 2. Consolidating so that next time the SDK adds something that the XML does not, we can make good decisions about how to achieve the new features. Let's have this conversation - Hans, if you can provide a quick outline of what is being supported by all the functions that are newly implemented - this should be easy since the development was just done. Then maybe Marco, Ashish and Jacopo - people who helped build the current ebay component - can put the features out on the table for comparison as well. Once we have that, we can easily do the necessary gap analysis and discussion about what technologies support what, etc, etc. it could be that XML supports everything that we want and this new SDK becomes something that we might want to remove - or that this new implementation is the way to go and remove the old one - or even some hybrid of the two - but we won't know until we understand first what we need it to do, then what it can do currently, and come together on how to do it. Cheers, Ruppert On Feb 4, 2010, at 10:58 PM, Sam Hamilton wrote: > Couple of things > > 1. calling one ebay and one ebaystore is confusing when browsing the > source tree - perhaps once we know what the difference is between them > call them that? If its correct - call one eBay-XML and the other > eBay-API for example. > > 2. eBay has a huge amount of developer documentation once we know what > the difference is how about putting a README file in the folder of each > pointing to the eBay docs showing what each component is capable of > achieving? http://developer.ebay.com/ > > 3. If the ebaystore module does everything that the ebay module > currently does then why is getting rid of ebay module a bad thing? > > Sam > > > On 05/02/2010 12:42, Tim Ruppert wrote: >> How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system. >> >> It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. >> >> Cheers, >> Ruppert >> >> On Feb 4, 2010, at 2:50 AM, Jacques Le Roux wrote: >> >>> I will try to have a look today, in order to introduce a 3d party in this discussion... >>> >>> Jacques >>> >>> From: "Scott Gray" <[hidden email]> >>> Haan, >>> >>> I'm sorry to hear that, I guess if no one else feels strongly about this then I'll bow out and allow you to continue with your >>> duplication of existing code. >>> >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 3/02/2010, at 11:52 PM, Hans Bakker wrote: >>> >>>> Scoot, >>>> >>>> i am sorry. As I mentioned in another email jacopo already saw that we >>>> are too far down the road. I cannot change. Anybody with Ebay knowledge >>>> would appreciate this contribution and replace the old ebay component >>>> directly with the new one. >>>> >>>> I am sorry i am very busy here and cannot spend more time on this. >>>> >>>> Hans. >>>> >>>> p.s. my reaction was on my proposal to have a "work in progress list >>>> added" irrelevant anyway. >>>> >>>> >>>> On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote: >>>>> On 3/02/2010, at 11:04 PM, Hans Bakker wrote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I only wondering why you send this email, can you explain that to me? >>>>> >>>>> As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree >>>>> with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? >>>>> >>>>>> Anyway, thanks for asking, i still think it is required. It showed with >>>>>> the ebay component: >>>>>> >>>>>> 1. creators of the original component would have liked to discuss it. >>>>> >>>>> Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? >>>>> Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide >>>>> you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which >>>>> will ultimately cause harm to the community. >>>>> >>>>>> 2. a non committer had already developed a component as we just did. >>>>> >>>>> Huh? How is that relevant? >>>>> >>>>>> so a lot of effort could have been saved here..... >>>>>> >>>>>> However if nobody wants it, sure i will give up. >>>>>> >>>>>> don't worry about that. >>>>> >>>>> It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users >>>>> confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. >>>>> >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >>>>>>> Hi Hans, >>>>>>> >>>>>>> Based on your recent commits I guess your considering this discussion over? >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >>>>>>> >>>>>>>> >>>>>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>>>>>>> >>>>>>>>> Jacopo, >>>>>>>>> >>>>>>>>> what we need is a wiki page where people can announce activities and >>>>>>>>> plans. Not only from committers but also from contributors and perhaps >>>>>>>>> even users. >>>>>>>>> >>>>>>>>> I have proposed this before. >>>>>>>>> >>>>>>>> >>>>>>>> I think we already have something similar: >>>>>>>> >>>>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>>>>>>> >>>>>>>>> In this case we tried to extend the existing ebay component but found >>>>>>>>> out that the xml interface could never support the required functions as >>>>>>>>> we needed them. >>>>>>>> >>>>>>>> This is not a good reason for stopping your research about supported features and building a new component. >>>>>>>> The valid options I see are: >>>>>>>> 1) adding *new* features to the original component using the different technology >>>>>>>> 2) and enhancing the existing features, where needed, using the XML approach or >>>>>>>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>>> Please also remember that not all required functions >>>>>>>>> were known from the start. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>> >>>>>>>>>> first of all, thank you for contributing this big amount of code. >>>>>>>>>> >>>>>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>>>>>>> >>>>>>>>>>> Hi Scott, >>>>>>>>>>> >>>>>>>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>>>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>>>>>>> user requirements of the original ebay component. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause >>>>>>>>>> maintenance problems and confusion; I guess we will all agree on this. >>>>>>>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new >>>>>>>>>> feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and >>>>>>>>>> do our best to enhance the existing stuff? >>>>>>>>>> >>>>>>>>>>> Now we moved the new functionality to a separate component it is getting >>>>>>>>>>> more clear if the old component is still required or not. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of >>>>>>>>>> you studying the original ebay component we will have to study your new work and verify if the new component implements all >>>>>>>>>> the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Let us first complete the new component and get it fully tested and then >>>>>>>>>>> restart this discussion. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Hans >>>>>>>>>>> >>>>>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a >>>>>>>>>>>> bad idea. >>>>>>>>>>>> Please correct me if any of the following is wrong: >>>>>>>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant >>>>>>>>>>>> is eBay SDK vs. using XML directly? >>>>>>>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use >>>>>>>>>>>> of raw SOAP or XML when interacting with the actual API? >>>>>>>>>>>> >>>>>>>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved >>>>>>>>>>>> to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just >>>>>>>>>>>> result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with >>>>>>>>>>>> huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK >>>>>>>>>>>> will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> HotWax Media >>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>> >>>>>>>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Author: hansbak >>>>>>>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>>>>>>> New Revision: 905876 >>>>>>>>>>>>> >>>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>>>>>>> Log: >>>>>>>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>> >>>>> >>>> -- >>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>> >>> >>> >> > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by Jacopo Cappellato-4
Too late - at least then we can discuss it without the other baggage in the thread. Anyways, the message is across so hopefully we can have that laid out so we can let the feature comparison begin! Looking forward to getting this resolved ASAP.
Cheers, Ruppert On Feb 5, 2010, at 7:29 AM, Jacopo Cappellato wrote: > I don't think it is necessary to resend it, the content of the message was clear enough regardless of the form you used. > > Jacopo |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by Tim Ruppert
Hans, could you please comment on this ASAP? I see that additional commits keep going into this new component which doesn't seem like it's getting us closer to reconciling the differences between them and getting back to one common component that everyone can build on.
Cheers, Ruppert On Feb 5, 2010, at 7:28 AM, Tim Ruppert wrote: > Responding to this message - per Jacopo and David's request. Hopefully this gets us back to discussing how we can go about fixing the ambiguity that has been introduced and will push us to a consolidated front on these features: > > --- > > My recommendation - even at this point - is that we start to have a discussion about all of the things this new component does, and the people who are using the old one can put all of their feature coverage on the table - then we can discuss how to bring them together. This may be one ebay component which utilizes both XML for some things and the SDK for others - but without knowing the feature coverage - we're screwed. > > In this case - it matters very little to anyone what the technology choice ends up being - it's all about: > > 1. Making it easier for everyone who downloads OFBiz to know what to do with eBay > -- These multi channels sales are more and more important each day in this economy. > 2. Consolidating so that next time the SDK adds something that the XML does not, we can make good decisions about how to achieve the new features. > > Let's have this conversation - Hans, if you can provide a quick outline of what is being supported by all the functions that are newly implemented - this should be easy since the development was just done. Then maybe Marco, Ashish and Jacopo - people who helped build the current ebay component - can put the features out on the table for comparison as well. Once we have that, we can easily do the necessary gap analysis and discussion about what technologies support what, etc, etc. > > it could be that XML supports everything that we want and this new SDK becomes something that we might want to remove - or that this new implementation is the way to go and remove the old one - or even some hybrid of the two - but we won't know until we understand first what we need it to do, then what it can do currently, and come together on how to do it. > > Cheers, > Ruppert > > On Feb 4, 2010, at 10:58 PM, Sam Hamilton wrote: > >> Couple of things >> >> 1. calling one ebay and one ebaystore is confusing when browsing the >> source tree - perhaps once we know what the difference is between them >> call them that? If its correct - call one eBay-XML and the other >> eBay-API for example. >> >> 2. eBay has a huge amount of developer documentation once we know what >> the difference is how about putting a README file in the folder of each >> pointing to the eBay docs showing what each component is capable of >> achieving? http://developer.ebay.com/ >> >> 3. If the ebaystore module does everything that the ebay module >> currently does then why is getting rid of ebay module a bad thing? >> >> Sam >> >> >> On 05/02/2010 12:42, Tim Ruppert wrote: >>> How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system. >>> >>> It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. >>> >>> Cheers, >>> Ruppert >>> >>> On Feb 4, 2010, at 2:50 AM, Jacques Le Roux wrote: >>> >>>> I will try to have a look today, in order to introduce a 3d party in this discussion... >>>> >>>> Jacques >>>> >>>> From: "Scott Gray" <[hidden email]> >>>> Haan, >>>> >>>> I'm sorry to hear that, I guess if no one else feels strongly about this then I'll bow out and allow you to continue with your >>>> duplication of existing code. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 3/02/2010, at 11:52 PM, Hans Bakker wrote: >>>> >>>>> Scoot, >>>>> >>>>> i am sorry. As I mentioned in another email jacopo already saw that we >>>>> are too far down the road. I cannot change. Anybody with Ebay knowledge >>>>> would appreciate this contribution and replace the old ebay component >>>>> directly with the new one. >>>>> >>>>> I am sorry i am very busy here and cannot spend more time on this. >>>>> >>>>> Hans. >>>>> >>>>> p.s. my reaction was on my proposal to have a "work in progress list >>>>> added" irrelevant anyway. >>>>> >>>>> >>>>> On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote: >>>>>> On 3/02/2010, at 11:04 PM, Hans Bakker wrote: >>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I only wondering why you send this email, can you explain that to me? >>>>>> >>>>>> As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree >>>>>> with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? >>>>>> >>>>>>> Anyway, thanks for asking, i still think it is required. It showed with >>>>>>> the ebay component: >>>>>>> >>>>>>> 1. creators of the original component would have liked to discuss it. >>>>>> >>>>>> Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? >>>>>> Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide >>>>>> you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which >>>>>> will ultimately cause harm to the community. >>>>>> >>>>>>> 2. a non committer had already developed a component as we just did. >>>>>> >>>>>> Huh? How is that relevant? >>>>>> >>>>>>> so a lot of effort could have been saved here..... >>>>>>> >>>>>>> However if nobody wants it, sure i will give up. >>>>>>> >>>>>>> don't worry about that. >>>>>> >>>>>> It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users >>>>>> confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >>>>>>>> Hi Hans, >>>>>>>> >>>>>>>> Based on your recent commits I guess your considering this discussion over? >>>>>>>> >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> >>>>>>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>>>>>>>> >>>>>>>>>> Jacopo, >>>>>>>>>> >>>>>>>>>> what we need is a wiki page where people can announce activities and >>>>>>>>>> plans. Not only from committers but also from contributors and perhaps >>>>>>>>>> even users. >>>>>>>>>> >>>>>>>>>> I have proposed this before. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think we already have something similar: >>>>>>>>> >>>>>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>>>>>>>> >>>>>>>>>> In this case we tried to extend the existing ebay component but found >>>>>>>>>> out that the xml interface could never support the required functions as >>>>>>>>>> we needed them. >>>>>>>>> >>>>>>>>> This is not a good reason for stopping your research about supported features and building a new component. >>>>>>>>> The valid options I see are: >>>>>>>>> 1) adding *new* features to the original component using the different technology >>>>>>>>> 2) and enhancing the existing features, where needed, using the XML approach or >>>>>>>>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>>> Please also remember that not all required functions >>>>>>>>>> were known from the start. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Hans >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>>>>>>>> Hi Hans, >>>>>>>>>>> >>>>>>>>>>> first of all, thank you for contributing this big amount of code. >>>>>>>>>>> >>>>>>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Scott, >>>>>>>>>>>> >>>>>>>>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>>>>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>>>>>>>> user requirements of the original ebay component. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause >>>>>>>>>>> maintenance problems and confusion; I guess we will all agree on this. >>>>>>>>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new >>>>>>>>>>> feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and >>>>>>>>>>> do our best to enhance the existing stuff? >>>>>>>>>>> >>>>>>>>>>>> Now we moved the new functionality to a separate component it is getting >>>>>>>>>>>> more clear if the old component is still required or not. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of >>>>>>>>>>> you studying the original ebay component we will have to study your new work and verify if the new component implements all >>>>>>>>>>> the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Let us first complete the new component and get it fully tested and then >>>>>>>>>>>> restart this discussion. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Hans >>>>>>>>>>>> >>>>>>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a >>>>>>>>>>>>> bad idea. >>>>>>>>>>>>> Please correct me if any of the following is wrong: >>>>>>>>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant >>>>>>>>>>>>> is eBay SDK vs. using XML directly? >>>>>>>>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use >>>>>>>>>>>>> of raw SOAP or XML when interacting with the actual API? >>>>>>>>>>>>> >>>>>>>>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved >>>>>>>>>>>>> to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just >>>>>>>>>>>>> result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with >>>>>>>>>>>>> huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK >>>>>>>>>>>>> will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Scott >>>>>>>>>>>>> >>>>>>>>>>>>> HotWax Media >>>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>>> >>>>>>>>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Author: hansbak >>>>>>>>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>>>>>>>> New Revision: 905876 >>>>>>>>>>>>>> >>>>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>>>>>>>> Log: >>>>>>>>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>> >>>>>> >>>>> -- >>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>> >>>> >>>> >>> >> > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Thanks Hans - and please just come with some information so that we, as a group, can try to get this reconciled into one app again.
Cheers, Ruppert On Feb 15, 2010, at 7:18 PM, Hans Bakker wrote: > Do not worry we are still working on it. This week we will do some more > commits. We plan to have this finished the end of this month. > > Regards, > Hans > > On Mon, 2010-02-15 at 08:42 -0800, rohit wrote: >> Hi Hans, >> >> Just checking if you have reached where you intend with this implementation. >> I hope that you have been not put off from developing it further. I have >> tried some of the features and think they can be very useful. >> >> Thanks, >> >> Rohit >> > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Hans, I see you've been busy again in the ebaystore and just wanted to get an update on when we might be able to see what's going on so that the community can help get back to the single ebay component again soon. I hope things are going well on that new impl!
Cheers, Ruppert On Feb 16, 2010, at 2:04 AM, Tim Ruppert wrote: > Thanks Hans - and please just come with some information so that we, as a group, can try to get this reconciled into one app again. > > Cheers, > Ruppert > > On Feb 15, 2010, at 7:18 PM, Hans Bakker wrote: > >> Do not worry we are still working on it. This week we will do some more >> commits. We plan to have this finished the end of this month. >> >> Regards, >> Hans >> >> On Mon, 2010-02-15 at 08:42 -0800, rohit wrote: >>> Hi Hans, >>> >>> Just checking if you have reached where you intend with this implementation. >>> I hope that you have been not put off from developing it further. I have >>> tried some of the features and think they can be very useful. >>> >>> Thanks, >>> >>> Rohit >>> >> -- >> Antwebsystems.com: Quality OFBiz services for competitive rates >> > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
| Free forum by Nabble | Edit this page |