When in eclipse and you decide to share a project in a subversion repository using subclipse, can you make it create a folder structure for that project automagically somehow?
What I want is for every shared project to add this kind of structure:
/Client/Project/branches
/Client/Project/tags
/Client/Project/trunk/EclipseProject
Where Client is the name of the client, Project is the name of the actual project and EclipseProject is the name of the project as it exists in Eclipse. There may be more than one EclipseProject in this structure, in which case of course the directories doesn't have to be created.
Is this possible to do with a subclipse or am I better off writing a simple shell-script to do this? My first thought was doing a shell script since I don't mind using the terminal, but some of my collegues really don't like command line interfaces but dig Subclipse.
As far as I know, you cannot easily extend Subclipse to make it generate such a structure.
Actually, Subclipse had an issue with the GUI representation of deep structures, only fixed in the latest version 1.4.7 (05 December 2008), so there are not yet to provide any "template structure" ;) They try to represent existing folder trees right.
The only feature which does automatically create folders would be the "Create any intermediate folders that are missing" checkbox to Branch/Tag dialog, to make any missing and required parent directories as part of the transaction during a mkdir/move/copy commands.
That's about it.
Related
I want to import a maven project from GitHub into intellij which in of itself I know how to do however, the project this time was created initially also as an eclipse project and I want to be able to work on it in idea while my team members work on it in eclipse without causing conflicts due to differing project file structures. How can this be done?
When checking it out in Intellij it does ask me if I want to create a project from it and select yes but next, it asks whether to create the project from the existing sources vs from external model. From the external model option it allows me to pick eclipse or maven but not both. Do I just create from existing sources? Which is my best option to do this without screwing it up for the others when I commit and push my changes?
I understand that the easy answer might be: "just use eclipse" however, I think the answer on how to properly do this could be useful later. Not only me but also for others who want to work with the IDE they are most familiar and productive with and not mess with the workflow.
Any help would be appreciated
When importing an Eclipse project into IntelliJ, you have the option to:
Create module files near .classpath files
Keep project and module files in
The idea is to keep your *.iml file concurrently with your Eclipse .project/.classpath (and you can keep them in sync).
That way, you can open the project in both IDE.
What is a "safe" way to share an Eclipse workspace between two computers? I've had problems using Dropbox and I've had problems using Github. I am looking for a best practice that will "just work".
Update
I read below and many other places that sharing a workspace doesn't work. But my collection includes 50 projects, are you saying that I need to create 50 github repos? There's no way to put them all in one repo to save the repetition?
Solution (imperfect, but still improving)
My collection of projects is in a github repo called projects/ which includes 50 subdirectories, each structured appropriately as they would be for an eclipse project.The /projects directory doesn't have meta-data or any other eclipse info (AFAIK)
Separately, in ~ I create a brand new Eclipse workspace. And then I "manually" import each one with Eclipse. I do this on each machine that needs to access those projects via Eclipse.
No, the workspace will contain machine-specific information and locations. Share the projects themselves, preferably through a source code management system like git. If anything in the project refers to something outside the workspace, you'll want it changed to refer to that resource in a portable way (e.g. pick the JRE using an Execution Environment instead by name).
Look at the thread at https://stackoverflow.com/a/37799711/10235188. They describe how to share a workspace and configurations between machines. Otherwise you'll always have problems with absolute paths.
I think it is quite normal to have more than one binary in a project. However, with Eclipse CDT I don't know how to set up the IDE to get things done.
I know I can create several projects - one per binary. And I know I can set the dependencies per project. However, I cannot regard them as one project in Eclipse. If I'd like to share the code with a version control system (like svn), each developer has to import the projects separately.
What I miss is something like the Solution (sln file) in Visual Studio. Should I create a single project and create the make files by myself?
I haven't tried it out yet, but there is this 'project set' which can be ex- and imported. Is this the solution? Can this be put into version control?
My goal it to put everything under version control, not only subprojects. I cannot imagine that CDT makes only sense for single-binary applications.
How can I work properly?
I am quite sure CDT doesn't support sub-projects, which leaves you pretty much with:
one workspace per "set of projects"
one project per binary (like you mention in your question)
project dependencies (like you mention in your question)
In term of version control, that means:
submodules (Git),
subrepos (Mercurial) or
external (SVN)
for each project needing a shared library project.
In short, that means putting under version control various components (set of files), with one referencing specific version of others (that list of specific versions of other components is called a "configuration", based on a component-based approach development)
I have a Helpdesk application that contains modules that can be downloaded and installed separately as required / preferred by the users. The structure is very similar to many software such as Drupal, which modules can be loaded/unloaded easily.
I'm using a single SVN repository for this Helpdesk application and create different tags for each module. And on my Eclipse I have everything as a single project.
My question is, can a single Subversion repository managed as multiple projects in Eclipse?
Can I create one Eclipse project for the whole application and at the same time for each module?
Another requirement is that by splitting each module as a different project would make Eclipse builds faster.
The reason is, I want to delegate programming work of each module to another person without the need to expose everything. The person would only see & work on the module only but commit to the main repository.
I know that Eclipse will have configuration files for every project, would there be any conflict.
I've had good look storing multiple Eclipse projects in one repository. Each of the projects is stored in a separate folder under the repository's root. Then, I use Subclipse to check out each of those folders as a separate Eclipse project.
I do not think that you should nest Eclipse projects (so that a master project contains many sub-projects).
Instead of the master project, you could group the individual projects into what Eclipse calls a Team Project Set (found in the Export/Import menus). This is an XML file that defines where all the projects are. You can put that file into Subversion as well.
So, you would have all the module's projects, and that XML file (which is not a project itself), all in Subversion (could be the same repository, could be spread over several).
I don't believe this is strictly possible. Personally, I would split the modules up into different projects entirely, and I would probably use Eclipse's plugin structure to resolve dependencies between them and the main project. If you ship the plugins as jars, they're still modular. Then, you can control each plugin as a separate project in Eclipse, and a separate folder in SVN.
That is no problem at all! Just create your trunk/tags/branches structure on your svn repo. Create your differen projects and then check thos projects into your trunc folder on your svn system. Finished!
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.