0

Let me clarify the question : We have a large Java project, with 3 concurrent versions (v6 stable, v7 stable and v8 in development) We are migrating the source code to a Git repository which will have at least 3 branches : v6, v7 (main) and develop. This repo will be distributed and shared among the developers team. Unfortunately, the resources (3rd party libraries) are not the same in the various versions and thus branches.

My question is : In my Eclipse project, how can I switch the needed libraries when I checkout from a branch to another ?

There is a lot of third party libraries, so we can't integrate them in the git repository. I know that I can put the eclipse .project and .classpath files in the Git repo, but :

  1. these files are not part of the real project, they are just for me
  2. another developer uses Eclipse and he'd do the same thing : in the bare repo, my Eclipse files will replace his and vice versa...

Is there a way to put the eclipse files in another location than the project root directory ? Or any other advice ?

Thanks a lot

Bernard Faure
  • 1
  • It's recommended to have the `.project` and `.classpath` files and the `.settings` folder under version control. Make sure not to have absolute paths in the classpath (or as linked resources in the project), so it will be the same for all developers (you can use variables, but better avoid it). – howlger Mar 25 '21 at 16:19
  • @howlger, Eclipse specific files (.settings) can be shared in VCS, but this is not recommended. If all user have a homogeneous development environment, this setup can solve Bernard issues, but is highly error prone. – Claudio Weiler Mar 25 '21 at 16:24
  • @howlger, thanks, I was thinking about such a solution but as Claudio stated it seems a bit brittle. I'll try with my fellow developers anyway – Bernard Faure Mar 25 '21 at 16:41
  • @ClaudioWeiler [This is a common myth](https://stackoverflow.com/a/60669809/6505250). Eclipse puts these files into the project folder to be shared (see also the Eclipse FAQ). – howlger Mar 25 '21 at 16:42
  • @BernardFaure Nope it's not brittle. The opposite is true. Independent whether to use Maven/Gradle, [share the `.project` and `.classpath` files and the `.settings` folder](https://wiki.eclipse.org/FAQ_How_do_I_set_up_a_Java_project_to_share_in_a_repository%3F). – howlger Mar 25 '21 at 16:54
  • @howlger, as a long Eclipse user and fan, I agree with your linked opinion with many, many regards, but this is totally off topic. Sharing Eclipse specific files will not solve Bernard issue, unless they share settings based on environment conventions as variables or fixed paths, and, you also stated they should avoid this. – Claudio Weiler Mar 25 '21 at 20:59
  • @ClaudioWeiler You correctly guessed that Maven or Gradle is not used here (even though the question doesn't say so) and I agree that such a build tool is useful to manage dependencies. But project specific files (POM, `.project`, etc.) have to be shared even if _"these files are not part of the real project"_ and also with Maven it is possible to use local dependencies (which should be avoided). – howlger Mar 25 '21 at 22:07
  • Well many thanks for your answers. As you guessed we don't use Maven nor Graddle. We'll share the Eclipse config files in the repo, as howlger suggested it. By the way why should we avoid to use Eclipse variables ? I plan to use a variable by branch for the compiler destination directory and some User libraries for the 3rd party jars. Should we instead have the same file tree in each developer's computer ? (we could not are we are not using the same OS) – Bernard Faure Apr 02 '21 at 08:58

1 Answers1

0

You should migrate your project to Maven. This tools handle build process and dependencies management, and also integrates very well with Eclipse.

To migrate your project you will need a artifact server to handle your many dependencies and their versions. You can check at Sonatype Nexus and JFrog Artifactory.

Claudio Weiler
  • 589
  • 2
  • 15