Hello Bertrand and everyone, Thank you very much for applying me for the GSoC 2015. I will do all my best. Could you please help me with information about how to prepare to coding phase which starts in May. 1. Where is a good point to start prepare for work? I didn't have an experience in integration testing(I have written only unit tests). So could you probably provide some nice developed examples of integration tests in Sling? 2. As I wrote I plan to concentrate on classes under bundles directory. Do you have some priority between modules and classes here or I can prioritize it just like "low coverage first"? 3. Communication. How often could we communicate and which way is the best? I understand that you have no much free time, so please write me your vision of this moment. 4. If there is something I have missed, but it's important, please write me that. I really want to finish this project as good as I can.
In LinkedIn I saw that you're living in Switzerland. I plan to visit Switzerland this summer(In time between July and August). So we can meet if you are interested. And I speak German as well. Best regards, Petr 2015-03-24 17:12 GMT+03:00 Petr Shypila <[email protected]>: > Hi everyone, > > as you already know I'm trying to take a part of Google Summer of Code > program with SLING-1437 issue. I've wrote a proposal for this project, so > could you please take a look on it and give me some feedback? It will be > very nice from your side. The main problem I see in my proposal it's a weak > work plan. I just don't know what to write in this section, since I will > just write tests. Probably do you have some ideas? Thank you very much in > advance. > > =====PROPOSAL===== > Hi everyone. My name is Petr and I want to work on issue SLING-1437 as a > part of Google Summer of Code 2015. > > Why I think It's important for community: > I see that framework's code coverage is low and more than that, some of > them are not covered with tests at all. And I want to fix it. > > Why it's important for me: > The main goal is that in my opinion I don't have enough skills in writing > unit and integration tests. So on this project I can really improve my > skills. More than that, I'll make a product with which work my team and me > better. > > Why I'm a good person for this project: > I have already found and fixed issue SLING-4505 and provide some unit > tests (see SLING-4527). > As I wrote, I'm working with Sling for a year and I know this framework > pretty good. Every time I have some side activities beside my study and > work. For example in september 2014 I got a first place on hackathon > Garage48. One month ago I finished 4-month educational program where I've > learned some advanced Java technologies like class-loading, concurrency, > java memory model and so on. Few weeks ago I also successfully finished > Statistical Learning course on Stanford Online. And for this summer my main > goal will be to complete this project. > > First for all I plan to concentrate on modules with 0% coverage under > /bundles directory. And then cover other important classes with low > coverage. "Coding phase" starts at May 25th, so before this date I think > it's a good time to learn project deeper, investigate role of each module > which I will cover, and look on other implemented unit and integration > tests under a project. There is a list of libraries, which I plan to use > when I will write tests: JUnit, Mockito, Sling testing tools. At the end of > a project I plan cover all modules which are not covered yet and improve > test coverage of other's modules. > =================== > > Kind regards, > Petr > > 2015-03-20 11:13 GMT+03:00 Petr Shypila <[email protected]>: > >> Hi Bertrand, >> >> Thank you for your quick answer. >> 2015-03-19 19:00 GMT+03:00 Bertrand Delacretaz <[email protected]>: >> >>> Ok, so your problem is that many pom.xml files from the Sling modules >>> have duplicated <dependency> entries, right? >>> >> Yes, that's exactly what I mean. >> >> >> >>> If that's what you mean that's by design - the high modularity of >>> Sling and the OSGi dependency rules make it much better for each >>> module to have its own list of dependencies. We do have some common >>> dependencies in the Sling parent pom but only very few, by design. >>> >>> Always depending on the latest version of an API, like you would do in >>> more static systems, would be counterproductive as a module might not >>> actually need that latest version. So it's good for the Sling modules >>> to have their own lists. >>> >>> Does this clarify it for you? >> >> >> Yes, thank you. I didn't know that. Thank you for the clarification. >> >> Best, >> -Petr >> > >
