You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@sling.apache.org by Petr Shypila <ik...@gmail.com> on 2015/05/04 07:50:31 UTC

Re: SLING-1437 as a part of Google Summer of Code 2015

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 <ik...@gmail.com>:

> 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 <ik...@gmail.com>:
>
>> Hi Bertrand,
>>
>> Thank you for your quick answer.
>> 2015-03-19 19:00 GMT+03:00 Bertrand Delacretaz <bd...@apache.org>:
>>
>>> 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
>>
>
>