• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Git, nested projects, Eclipse

 
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Our team is moving from Subversion to Git, and due to peculiarities in our environment I am finding the path confusing.
We use Eclipse and we have been keeping Eclipse configuration in the repository.

The projects in our repository are highly nested, and I'm confused as to the best way to use Eclipse EGit in this context.
The eGit tutorials seem to focus on the easy case, where a Git repository contains a single Eclipse project (and typically where configuration information is not stored in the repository).


To give a sense of what I'm working with, let me describe the structure of our code repository.
The master branch is broken down into two subdirectories, call them A and B.

Taking the easier part first, nested within B is a set of independent Eclipse projects, each of which builds a utility that we developers sometimes run.

Nested within A we have projects A_client, A_webserver, A_batchPrograms, A_serverCommon, A_commonCommon, and A_lib.
Each of these is an Eclipse project, with Eclipse configuration kept in the repository.
However, these are interdependent.

A_commonCommon builds a jar that is added to the classpath of A_client, A_batchPrograms, A_webserver, A_serverCommon.

A_lib contains jar files we use but did not write, which are added to the classpath of A_serverCommon, A_batchPrograms, and A_webserver.

A_serverCommon builds a jar that is added to the classpath of A_batchPrograms and A_webserver.

A_client contains code that A_webserver deploys as both a webstart program and as an applet.

A_webserver also deploys servlets that are referenced from the applet and webstart code built in A_client.
These servlets are also called by code in A_serverCommon, and from within A_webserver itself.

Classpaths for each of these Java projects, tying these projects together, are among the Eclipse configuration kept in the repository.

Within A at the top level we also have some scripts that are used to build the entire application on the server (creating and gathering the resultant jars).


My question concerns the way to hook up these projects into Eclipse so I can use EGit for source control.

What I am thinking might work is if I do the following:

(1) Use eGit or the command line or some other tool to clone the Git repository to a directory on my workstation.

(2) Import the entire repository into Eclipse as an eGIT NON-Java project (because Eclipse doesn't understand nested Java projects very well).  I would use this top-level project for any eGit operations.

(3) Import individually each project (A_commonCommon, A_client, A_lib, A_serverCommon, A_batchPrograms, A_webserver A_) from the Git directory, each as a separate Eclipse Java project, telling Eclipse NOT to copy the files into the Eclipse workspace but to edit them in place.

The idea is that by importing all the sub-projects individually as Java projects, Eclipse will use the source-controlled configuration to tie them together.
But eGit will have to work at the level of the entire repository branch.

Does this sound like an approach that would work?  Is there a better way?

reply
    Bookmark Topic Watch Topic
  • New Topic