GSOC 2012/Student Application cafarm/Maven FOSS Repository Extension
Integrate Proxy Settings and Network Connections(Locations)
- Email Address: email@example.com
- Telephone: 732-687-6604
- Freenode IRC Nick: cafarm
NOTE: We require all students to blog about the progress of their project time to time.
You are strongly encouraged to register on the Freenode network and participate in our IRC channels. For more information and other instructions, see:
Please answer following questions.
Why do you want to work with the Fedora Project?
I believe the Fedora Project is a great place to begin my experience with the open source community. I like that it's well-organized, respected, and professional, and that it has the facilities and experience to truly support new contributors. In addition, it's exciting to think that I can play a part in the development of a product with such broad reach.
Do you have any past involvement with the Fedora project or with any another open source project as a contributor (if possible please add some references as well)?
Did you participate with the past GSoC programs, if so which years, which organizations?
Will you continue contributing/ supporting the Fedora project after the GSoC 2012 program, if yes, which team(s)/area(s), you are interested with?
Yes. My interest is in the Java SIG.
Why should we choose you over the other applicants?
I am proposing a project I feel I am well suited to accomplish with minimal guidance. I have a fair amount of experience writing code and producing software people use on a daily basis. I know what it takes to make reliable and maintainable code, and I am a proven self-learner.
Please describe your proposal in detail. Include:
An overview of your proposal
I propose creating a Maven FOSS repository extension as suggested by Carlo de Wolf. The extension would allow developers to enforce the use of only dependencies which are available on a specific target platform, or more specifically in this proposal, sanctioned components for the Fedora platform in particular. Therefore, with minimal effort, developers would have the opportunity to spot Fedora dependency issues on build, even if they build on a non-Fedora platform.
The need you believe it fulfills
The need this proposal fulfills is to reduce the burden on packagers when attempting to integrate Java projects into Fedora. Currently it can be difficult for packagers to define a common set of Fedora-available components for projects with a wide array of dependencies. The proposal suggests to automate this process and move any resulting issues upstream where they are more appropriately handled by developers.
Any relevant experience you have
I have experience with Maven, Java, revision control systems, and bash scripting. I am comfortable with the Maven philosophy and I have created fairly complex POMs utilizing profiles, assemblies, and a variety of plugins. I have worked on Java software of which development spanned more than three months and of which a small user base relies on a daily basis. I use a revision control system and custom bash scripts daily.
How do you intend to implement your proposal
I intend to continue the work of Carlo de Wolf's existing prototype for the proposal. The prototype consists of an mvn wrapper script that would be called in place of mvn when a developer is interested in determining the results of "Fedora packaging". The wrapper script loads Maven with an extra component library for Plexus. Plexus allows the system to inject a custom repository implementation into Maven, resolving artifacts with the Fedora repository in place of the standard Maven repository.
Final deliverable of the proposal at the end of the period
The final deliverable will be a Maven extension, as described above, and an accompanying project site, if necessary.
A rough timeline for your progress
- Community Bonding Period: Get to know the community and research Plexus, Aether, and the more intricate details of Maven's implementation.
- Interim Period: Start fleshing out Carlo's prototype implementation. One of the big hurdles is in determining if his idea of using the repository system as the flow controller will result in stack overflows. Thats an architectural decision we need to determine as soon as possible.
- Mid-Term: Have a clear direction of the final architecture and a well laid out path toward completion.
- Interim Period: Implement our strategy using test driven development.
- Final week: Produce the project site and documentation.
Any other details you feel we should consider
While I have a strong CS academic background, the majority of my programming knowledge is self-taught. I genuinely enjoy the art of coding and I perform best with a challenge.
Have you communicated with a potential mentor? If so, who?
Yes. Carlo de Wolf.