facebook

Multiple-version group development w/Eclipse Best Practices?

  1. MyEclipse IDE
  2.  > 
  3. Off Topic
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #218177 Reply

    smcnamara
    Member

    Does anyone have any pointers/best practices for doing multiple-version group development w/ Eclipse? Currently this is the most painful part of our development process. Our situation is as follows:

    We have a group of several developers working on our project, which is actually a collection of ~10 sub-projects. The project typically has three active branches:

    PRODUCTION (support patches only)

    QA (bug fixes for upcoming release)

    DEVELOPMENT (new development)

    At any point in time, a developer may be asked to work on any one of the active branches. And may be asked to work on multiple branches in a single day.

    We are using Eclipse as our development platform, and have Perforce as our code repository. The two are integrated using the p4eclipse plugin.

    Each developer is allowed to put their development directory anywhere on their machine that they want. At one point we attempted to standardize directory locations, but had fairly extreme pushback from the development team. Since full paths are stored in the eclipse project files, we do not store the project files in the code repository since they need to change for each developer.

    The problem we have is that to quickly change between branches (which changes the branch for all 10 subprojects) we either have to:

    A) Change the configured branch for each of the 10 subprojects

    B) Maintain a different workspace, which entails creating a new set
    of project files for each branch.

    We’ve opted for B, however the creation of the new workspace is time consuming, and error prone since libraries must be re-added and dependencies re-created.

    Does anyone have tips on how they’ve handled this situation that might be useful?

    Also, does anyone find it annoying that you have to re-enter license data for each workspace you create?

    Regards,
    Sean McNamara

    #218200 Reply

    Riyad Kalla
    Member

    General Development using Eclipse, moving to software dev…

    #218203 Reply

    Scott Anderson
    Participant

    Sean,

    We have several branches we work on also and decided to use workspaces to segregate them also. However, we check in all .project and .classpath files since neither have full paths in them, although I believe that was an issue with Eclipse 2.0 that was addressed in 3.0. With 3.0, keeping multiple workspaces as big an issue since it is easy to switch between them and paths are no longer absolute.

    Also, does anyone find it annoying that you have to re-enter license data for each workspace you create?

    I’ll point out that this is true of *all* your preferences, not just the subscription key. The easiest way to handle it is simply to use the preference export/import mechanism. Simply export your settings in your original workspace with Window > Preferences > Export… and them import them all into your new workspace.

    #218204 Reply

    smcnamara
    Member

    Thanks for your reply Scott! It looks like the full path is still used for external library imports in .classpath, but I think that’s something we can probably work around by mandating a single location on all developer workstations.

    Thanks for the tip about exporting/importing preferences.

    -Sean

    #218222 Reply

    Scott Anderson
    Participant

    Sean,

    One way to work around the external library issue is simply to add standard classpath variables that point to each developer’s external library location and then adding the libraries as references to this variable.

    Another way to go is create a project that contains all the external libraries and check that in to souce control so that it’s shared in the workspace. Then you can export the libraries on that project’s build path and simply have the other projects refer to it. Of course, that only gets you all the libraries. For individual control, you can still use “Add Jar…” to add a specific lib to a particular project, and it will be a workspace relative reference at that point, thus eliminating the pathing problem.

    #220166 Reply

    smcnamara
    Member

    Hi Scott-

    Can you clarify exactly what steps you follow to create a new set of projects from a branch? Let me describe our situation and perhaps you can guide me through.

    We are using MyEclipse w/ Eclipse v3.0

    Our SCC provider is Perforce and we have the Perforce plug-in installed.

    We have a set of projects on the HEAD of the code tree which we have been using for development.

    Recently, a branch was created for a release of the software.

    We have bug tickets to work on for the branch.

    How do I quickly create a workspace with all the projects but pointing to the branch? (Note: All .project and .classpath files are in the repository)

    Thanks!

    #220187 Reply

    Scott Anderson
    Participant

    Sean,

    The quickest way to create a workspace on some newly created branches is to do the following:
    1) Launch MyEclipse using a new workspace
    2) Configure your repository so you can access it.
    3) Pull all the projects you need to work on from HEAD
    4) For each project, do these steps
    4a)right click and select Team > Branch… Enter a branch name and root (default name there is good).
    4b) Be sure the checkbox labeled “Start working in the branch” is checked.
    4c) Hit Finish

    That should get you a workspace containing all the new branches. Once that’s done, the developers on your team can simply open a new workspace and pull the branches you created explicitly from the Repository Browsing view.

Viewing 7 posts - 1 through 7 (of 7 total)
Reply To: Multiple-version group development w/Eclipse Best Practices?

You must be logged in to post in the forum log in