This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes IDEs, Version Control and other tools and the fly likes Project Architecture, Eclipse and Subversion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Project Architecture, Eclipse and Subversion" Watch "Project Architecture, Eclipse and Subversion" New topic
Author

Project Architecture, Eclipse and Subversion

Rafael Angarita
Ranch Hand

Joined: Jan 09, 2009
Posts: 67
Hello everyone, I hope this is the right forum to post this question.

This is my scenario:

I'm the lead software engineer of a team of 6 developers. Our main project (in which we all are going to be working on) depends on many Eclipse plugins and several plugins that are going to be developed by part of the team at the same time that the main project. Each of these plugins are Eclipse projects themselves.

I was wondering how I should manage those dependencies in the subversion repository. When I develope or modify a plugin of the main project, should I commit the .jar plugin to the svn repository so the other developers only have to do svn update and get the last version?

The other thing is that those plugins I'm developing are Eclipse plugins, so they have to be in the dropins or plugins folder of Eclipse in order to work properly. Therefore, even though I put them in the repository, the others developers will have to download the newer versions and copy them to the right Eclipse folders.

I hope I explained my case clearly, I would appreciate any advise you guys can give me.

Thank you very much.


Rafael Angarita.
SCJP 6.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15662
    
  15

I recommend that you make each plugin be a separate Eclipse project and that each plugin project be a Subversion project in its own right. In other words, make everything as independent of everything else as possible.

Subversion is a bit different from other version control systems, so it's certainly possible to have a master "plugins" project with sub-projects underneath it, for example. You'll probably find it easier if each of the sub-projects has the full SVN kit (branch, tags, and trunk) per-project. To check out and work with one of these sub-projects, you'd just use the SVN browser to select the trunk folder for the sub-project and instruct Eclipse to check it out as a project.

I also recommend using Maven as a offline build platform for stuff like this, where you have lots of dependencies. Sometime's it's easier to be able to issue a single batch command that sets the whole thing in motion instead of racking up Frequent Mouser miles.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Project Architecture, Eclipse and Subversion
 
Similar Threads
is just Subclipse enough? or need install a svn server also?
JetBrains support for 3rd-party plugins
How to adjust credentials used for Subversion in Eclipse Galileo
File structure is detached from SVN repository.
how to checkout sample projects from springsource community