DPS909 and OSD600 Winter 2009 Eclipse WTP Weekly Schedule

From CDOT Wiki
Revision as of 14:08, 15 February 2009 by JAnastasiade (talk | contribs) (Add the fourth milestone)
Jump to: navigation, search
Upcoming Special Events and Guest Speakers
  1. Angel Vera, Eclipse WTP Project Team Committer
    • Topic: WTP - API Concepts and Roles
      • Server Tools Architecture
      • Techniques to find the source code for a specific bug
    • Time: Tuesday Feb, 17 from 11:40 a.m. to 1:25 p.m. @ S2149
  2. Lawrence Mandel, Software Developer IBM Rational Software
    • Topic: Eclipse Plug-in Architecture
      • Techniques for developing Eclipse WTP
    • Time: Tuesday Feb, 24 from 11:40 a.m. to 1:25 p.m. @ S2149

Important Date: Eclipse BugDay / February 2009

Introduction

The course is broken into two parts. First, general open source and and community specific skills and ideas are taught. Students learn and/or review how to work with Java EE, WTP, Eclipse project techniques and practices. Second, students focus on bug fixing within the Eclipse WTP project itself.

Part I – Essential Open Source Development and Java/Eclipse Skills and Concepts

Week 1 (Jan 12) Course introduction

  • TODO
    • Create an account on this wiki for yourself
    • Create a personal wiki page on this wiki
    • Add a link for yourself to the People page and the Winter 2009 Open Source Students page
    • Create a blog (wordpress or blogspot or whatever) and create a feed category or tag called "open source"
    • Read the Blog Guidelines for instructions on how to use your blog in the course
    • Add your blog feed and info to the Open Source@Seneca Planet List so that it appears in the OpenSource@Seneca Planet
    • Blog on your reactions to the readings for this week.
    • Begin learning how to use IRC for communication. It is better to get started early such as your Eclipse workplace is set for programming.
    • After you install Eclipse for RCP/Plug-in Developers (175 MB) you will have ECF (Eclipse Communication Framework) and IRC client; you can open an IRC client from the Communication Perspective.


Week 2 (Jan 19) - Eclipse Webtools Overview

The First Milestone

At the end of the second week you must have an working environment:
Please, follow the instructions from tutorial to install Eclipse PlugIn and Eclipse WTP on your systems.

IMPORTANT NOTE: As it was suggested by Mr. Angel Vera: “The best place for the students to post question and get answers to it will be the eclipse newsgroup". There is a long list of newsgroups that you can benefit from depending on the question. As you are going to be working with Webtools, you would probably want to stay within the Eclipse Web Tools Platform Project. This is an open community of adopters and developers working with the Webtools project.

Week 3 (Jan 26) - Navigating the WTP source tree

The Second Milestone

At the end of the third week you must attentively decide and publish the list of your bug(s) (i.e. the bug(s) you want to work on in this course)
Please, update the project column of the table Winter 2009 Open Source Students with the following information: WTP-Bug ID, Severity, and Priority".

IMPORTANT NOTE: The marks obtained on the second milestone will be posted on your course page. Continue to wiki and blog intensively as a provided evidence of your persist involvement and dedication to improve WTP Projects by fixing bugs in such a wonderful community work.


Week 4 (Feb 2) - WTP Servertools Webpage

The Third Milestone

At the end of the this week you must release the first Project Deliverable:
Reproduce the bug. This is your 0.1 Release
Please, update your blog by defining the steps to reproduce your bug (i.e. the bug that you are working on). As a example use this blog


Week 5 (Feb 9) - Test-Driven Development (TDD)


Week 6 (Feb 16) - Eclipse WTP wiki

The Fourth Milestone

At the end of the this week, based on the presentation, you must have a good idea how to search Eclipse source. Blog about your experience in finding the source code (problems, advices, interesting findings). Define the steps to find the code that is related to your bug (i.e. the bug that you are working on).