This week's book giveaway is in the Java in General forum.
We're giving away four copies of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 and have ishori Sharan & Adam L Davis on-line!
See this thread for details.
Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Git, nested projects, Eclipse

Ranch Hand
Posts: 1408
  • 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?

Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic