Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Git, nested projects, Eclipse

 
Ranch Hand
Posts: 1408
  • Mark post as helpful
  • send pies
  • 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?

 
You know it is dark times when the trees riot. I think this tiny ad is their leader:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic