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
>

Reply via email to